Как избежать хранения паролей в управлении версиями?

Какую стратегию вы используете, чтобы избежать хранения паролей в управлении версиями?

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

Хранение паролей в базе данных не является отличным вариантом:

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

Я подумываю о перемещении конфигурации развертывания с машины разработчика на выделенный компьютер, который проверяет код из управления версиями и запускает сборку/развертывание script, но я не совсем уверен, что было бы лучшим способом сделать это.

Мне также нужно сказать, что я не хочу максимальной безопасности: я просто хочу избежать паролей на каждом диске разработчика и сделать это слишком легко.

Итак, я прошу вашего опыта/лучших практик. Как вы это делаете?

Ответы

Ответ 1

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

В Spring вы используете PropertyPlaceholderConfigurer для загрузки файла свойств. Его просто нужно найти с помощью Spring, который обычно просто означает его размещение в соответствующем каталоге под сервером приложений.

В качестве альтернативы вы используете wrapper для запуска сервера приложений, а параметры запуска JVM включают добавление этих файлов свойств в путь к классам, поэтому Spring может найти их.

Ответ 2

Я видел два подхода к этому:

  • Переместите пароли в другое дерево элемента управления источника, к которому у разработчиков нет доступа.
  • Не помещайте пароли в исходный элемент управления, а персональный менеджер сборки должен вводить пароли каждый раз при развертывании. Это было в банке, где работал полный рабочий день, работая над процессами сборки/слиянием/выпуском.

Ответ 3

Это не работает во всех случаях, но именно здесь открывается славность использования NT AUTHORITY\NETWORK SERVICE в качестве идентификатора ваших услуг. Если вы используете это удостоверение, вам не нужно поддерживать пароль для это - вы можете просто использовать учетные данные компьютера AD в виде DOMAINNAME\MACHINENAME $для доступа к вашей защищенной сети и доступа к базе данных.

Есть, конечно, некоторые ключевые моменты, о которых следует помнить - не в последнюю очередь из того, что ни одно из двух приложений, которые совместно используют границу безопасности, размещено на этом же сервере как на этом сервере.

Ответ 4

Поместите пароли в переменные среды o/s пользователя.

Только этот пользователь или корень может считывать значение, то же, что и файл, но с нулевым шансом на его получение в исходное управление.

Ответ 6

Вместо того, чтобы не хранить их, вы можете сохранить их в зашифрованном виде. Таким образом, вы не испытываете боли при отправке файлов учетных данных через IM или EMail все время, когда запускается новый разработчик... Вам просто нужно сообщить им конкретный мастер-пароль один раз, чтобы они могли шифровать учетные данные.