Назад | Перейти на главную страницу

Как работать с паролями при автоматическом развертывании?

Как ответственные администраторы мы знаем такие общие слабости, как

Но как с этим справиться на практике?

Конечно, с такими технологиями, как аутентификация без пароля через SSH и такими инструментами, как sudo, можно избавиться от сохраненных учетных данных для входа в важных местах, и это действительно помогает при автоматическом развертывании серверов Linux.

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

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

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

Но как бороться, например, с учетная запись основной административной базы данных? По крайней мере, ваш dbas должен это знать (так что вам нужен где-то открытый текст), и как администратор ОС вы должны не знать полномочия. Или развертывание выполняется DevOps, и они не должны знать любой учетных данных на производственных серверах.

Возможные решения

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

  1. Создавайте случайные учетные данные во время развертывания и сохраняйте их в базе данных в режиме однократной записи. И например У dbas есть другой пользователь, который может читать только учетные данные базы данных. Но как работать с паролями в виде открытого текста в файлах конфигурации, например веб-приложения? Их мог читать пользователь root. Также пользователь root базы данных паролей может читать все учетные данные пароля.

  2. Примите пароли в открытом виде и учетные данные по умолчанию во время развертывания и добавьте постскриптум, который изменяет каждый и все пароли. Может быть, даже интерактивным, когда авторизованные люди должны вводить учетные данные во время выполнения скрипта.

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

Что вы думаете? Вы видите здесь какие-нибудь передовые практики?

  1. У вас должна быть безопасная зашифрованная база данных со всеми вашими учетными данными.
  2. Во время развертывания сервер должен быть полностью недоступен извне из-за брандмауэров.
  3. Это нормально, если сценарий генерирует случайный проход и отправляет его вам по электронной почте.
  4. Также можно изменить этот пароль после того, как сервер был подготовлен, ДО того, как вы разрешили доступ к общественности.
  5. Отправлять себе пароль по электронной почте - это нормально, если он использует ваш внутренний почтовый сервер и не маршрутизируется через общедоступный SMTP (SMTPS - это другая история)

Вы можете заменить электронную почту практически любым протоколом. Вы можете где-нибудь ввести пароль, создать одноразовое сообщение, используя onetimesecret api, загрузить его в частную сущность, используя https, или что-нибудь еще, о чем вы можете подумать.

Я думаю, что это все.