Обработка паролей в рабочей конфигурации для автоматического развертывания

Question

Я видел похожие вопросы здесь, но они, похоже, не отвечают точно на то, что мне нужно.

Мы используем скрипты Powershell для развертывания наших приложений и информацию, такую ​​как пароли, в файлах конфигурации для большинства изокружения (UAT и т. д.) представлены в виде простого текста.Это не большая проблема, но когда дело доходит до PREPROD и PROD, это большая проблема.Таким образом, у нас в конфигурации было несколько маркеров, например "{{prompt-password}}", которые открывают диалоговое окно входа в систему (Get-Credential), и лицо, выполняющее развертывание, может ввести учетные данные, и развертывание продолжается.

Но это не очень помогает для автоматического развертывания (то есть развертывание в один клик с помощью таких инструментов, как TeamCity)

Стоит ли использовать асимметричное шифрование (http://msdn.microsoft.com/en-us/library/as0w18af.aspx), где пароль шифруется с помощью открытого ключа, введенный в конфигурации, и закрытый ключ сохраняется (как описано здесь http://msdn.microsoft.com/en-us/library/tswxhw92.aspx) в «агенте» (как в виртуальной машине, с которой TeamCity будет запускать развертывание и которая имеет ограниченный доступ), запускающей автоматическое развертывание, иэто может расшифровать пароль?Не очень сильны в криптографии и прочем, но похоже ли это на путь?Любые другие предложения?Как люди справляются с таким автоматическим развертыванием?

---

Обновление:

Хорошо, я пошел дальше и внедрил его.Я написал консольное приложение на C #, которое использует библиотеки Crypography.Приложение генерирует ключи:

RSACryptoServiceProvider rsa = GetRsa(containerName);
File.WriteAllText("keys.kez",rsa.ToXmlString(true));

Я также получаю открытый ключ:

File.WriteAllText("public.pke", rsa.ToXmlString(false));

Дайте открытый ключ всем, кто должен зашифровать пароль, и попросить их ввестипароль в конфиге.Поместите файл keys.kez в любой агент, который должен запустить развертывание.

Answer 1

Асимметричное шифрование определенно является победителем с точки зрения безопасности и простоты. Я очень успешно развернул производственные приложения SaaS.

Есть несколько хитростей. Во-первых, как вы упомянули, убедитесь, что пара открытого / закрытого ключей установлена ​​на хосте, а не хранится в файлах конфигурации или в коде. Во-вторых, предположим, что инструменты управления и генерации ключей, предоставляемые MS, слабы или ужасны и планируем соответственно (мы создали простой keygen exe для операций, выполняемых во время развертывания.)

Answer 2

Не совсем ответ, но предложение или другой вопрос.

Почему бы не сохранить пароль в зашифрованной строке в файле конфигурации

$credential.Password | ConvertFrom-SecureString | Set-Content c:\temp\password.txt

Я понимаю, что документация, выполняемая процессом с теми же учетными данными, может его вернуть

$password = Get-Content c:\temp\password.txt | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential `
         "username",$password

Вы можете заменить $credential.Password на read-host -assecurestring

Answer 3

Как вы сказали в своем вопросе, ваш пароль хранится в PROD в файле конфигурации в виде простого текста. Никакое количество шифрования не может помочь с этим. Кроме того, это своего рода порочный круг - как вы собираетесь защищать ключ шифрования?

Ключевой момент здесь заключается в том, чтобы взглянуть на то, что является практичным, и какие бизнес-процессы используются вашей организацией при развертывании.

Позвольте мне объяснить это на примере. Предположим, что развертывание в PROD выполняется командой инфраструктуры. Эта команда имеет доступ к паролю, который требуется в ваших конфигах. Они никогда не будут раскрывать этот пароль вам (разработчику развертывания) по соображениям безопасности. Вы хотите, чтобы они не вводили пароль во время каждой установки. Думать об этом это лучшее, что вы можете сделать. Они должны будут ввести пароль хотя бы один раз.

Криптографическое решение на самом деле не будет работать, потому что вашему пакету развертывания в любом случае потребуется способ расшифровки пароля, и если он может сделать это без ввода данных пользователем, то вы можете (разработчик), и это неприемлемо. *

Поскольку пароль в любом случае хранится в файлах конфигурации PROD в виде обычного текста, то пакет развертывания запрашивает пароль только в том случае, если он не известен. После того, как член команды инфраструктуры предоставит пароль, сохраните его в файле локально. А еще лучше, сохранить его в контейнере для всей машины. Вам не нужен пароль для этого. Следующая установка вокруг ключа будет уже известна, и вашей установке не нужно будет снова запрашивать ключ. Конечно, вам нужно предоставить способ изменить сохраненный ключ, если это необходимо.

Подход токенизации, который вы описали, работает. Я делал это довольно успешно, довольно долго. (Т.е. прошли внешние проверки безопасности) Поскольку у вас есть простой текстовый пароль в PROD, PROD следует рассматривать как безопасную (безопасную) среду. И поскольку это безопасно, нет ничего плохого в том, чтобы кэшировать (хранить копию) этого безопасного пароля внутри него.

Answer 4

Интересный вопрос, я также работаю с несколькими средами и сталкиваюсь с различными настройками для разных сред. Мы не вводим пароли в конфигурацию (скомпрометированная машина или ошибка инженера и т. Д.). Если мы делаем это для небезопасных вещей, мы сохраняем их в виде простого текста.

Имея это в виду, может ли сборочная машина просто не иметь списка паролей для каждой среды?

Если вы не хотите, чтобы они оставались в открытом виде, вы можете что-то сделать с PowerShell - я уверен, что Jaykul сделал пост на этом пути назад, но мой (быстрый) поиск в Google только что-то возвратил из Halr ( оба являются PowerShell MVP, так что это должно быть интересно).

http://halr9000.com/article/531

Answer 5

Как насчет создания запланированного задания для запуска сценариев развертывания? Задайте задачу для запуска с определенной учетной записью пользователя и предоставьте соответствующие разрешения учетной записи.

Answer 6

Независимо от того, используете ли вы асимметричное или симметричное шифрование, вам необходимо сохранить ключ дешифрования в своем коде, чтобы перенести угрозу безопасности с файла конфигурации на исполняемый файл (агент).Это намного лучше с точки зрения запутывания, но возможно, что исполняемый файл может быть реверс-спроектирован кем-то, достаточно решительным, чтобы извлечь ключ дешифрования.