Обработка паролей в рабочей конфигурации для автоматического развертывания
Я видел похожие вопросы здесь, но они, кажется, не отвечают точно, что мне нужно.
Мы используем сценарии 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 в любой агент, который должен запустить развертывание.
6 ответов
Асимметричное шифрование определенно является победителем с точки зрения безопасности и простоты. Я очень успешно развернул производственные приложения SaaS.
Есть несколько хитростей. Во-первых, как вы упомянули, убедитесь, что пара открытого / закрытого ключей установлена на хосте, а не хранится в файлах конфигурации или в коде. Во-вторых, предположим, что инструменты управления и генерации ключей, предоставляемые MS, слабы или ужасны, и планируем соответственно (мы создали простой keygen exe для операций, выполняемых во время развертывания).
Не совсем ответ, но предложение или другой вопрос.
Почему бы не сохранить пароль в зашифрованной строке в файле конфигурации
$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
Как вы сказали в своем вопросе, ваш пароль хранится в PROD в файле конфигурации в виде простого текста. Никакое количество шифрования не может помочь с этим. Кроме того, это своего рода замкнутый цикл - как вы собираетесь защищать ключ шифрования?
Ключевой момент здесь заключается в том, чтобы взглянуть на то, что является практичным, и какие бизнес-процессы используются вашей организацией при развертывании.
Позвольте мне объяснить это на примере. Предположим, что развертывание в PROD выполняется командой инфраструктуры. Эта команда имеет доступ к паролю, который требуется в ваших конфигах. Они никогда не будут раскрывать этот пароль вам (разработчику развертывания) по соображениям безопасности. Вы хотите, чтобы они не вводили пароль во время каждой установки. Думать об этом это лучшее, что вы можете сделать. Им нужно будет ввести пароль хотя бы один раз.
Криптографическое решение на самом деле не будет работать здесь, потому что вашему пакету развертывания в любом случае понадобится способ расшифровки пароля, и если он может сделать это без участия пользователя, то вы можете (разработчик), и это неприемлемо.
Так как пароль в любом случае хранится в файлах конфигурации PROD в виде простого текста, отправляйте пакет развертывания на запрос пароля, только если он не известен. После того, как член команды инфраструктуры предоставит пароль, сохраните его в файле локально. А еще лучше, сохраните его в контейнере для всей машины. Вам не нужен пароль для этого. Следующая установка вокруг ключа будет уже известна, и вашей установке не нужно будет снова запрашивать ключ. Конечно, вы должны предоставить способ изменить сохраненный ключ, если это необходимо.
Подход токенизации, который вы описали, работает. Я делал это довольно успешно, довольно долго. (То есть пройдены внешние проверки безопасности) Поскольку у вас есть простой текстовый пароль в PROD, PROD следует рассматривать как безопасную (безопасную) среду. И поскольку это безопасно, нет ничего плохого в кэшировании (хранении копии) этого безопасного пароля внутри него.
Независимо от того, используете ли вы асимметричное или симметричное шифрование, вам необходимо сохранить ключ дешифрования в своем коде, чтобы перенести угрозу безопасности с файла конфигурации на исполняемый файл (агент). Это намного лучше с точки зрения запутывания, но, возможно, исполняемый файл может быть реверс-спроектирован кем-то, достаточно решительным образом извлеченным из ключа дешифрования.
Как насчет создания запланированного задания для запуска сценариев развертывания? Задайте задачу для запуска с определенной учетной записью пользователя и предоставьте учетной записи соответствующие разрешения.
Интересный вопрос, я также работаю с несколькими средами и сталкиваюсь с различными настройками для разных сред. Мы действительно не вводим пароли в конфигурацию (скомпрометированная машина или ошибка инженера и т. Д.). Если мы делаем это для довольно небезопасных вещей, мы сохраняем их в виде простого текста.
Имея это в виду, может ли сборочная машина просто не иметь списка паролей для каждой среды?
Если вы не хотите, чтобы они оставались в открытом виде, вы можете что-то делать с PowerShell - я уверен, что Jaykul сделал сообщение об этом, когда, но мой (быстрый) поиск в Google только что-то возвратил из Halr (оба PowerShell MVP так что должно быть интересно).