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

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

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

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

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

Update:

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

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

Я также выхожу из открытого ключа:

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

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

Ответ 1

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

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

Ответ 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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

http://halr9000.com/article/531