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

Question

Как ответственные администраторы, мы знаем о таких распространенных недостатках, как

• CWE-260: Пароль в файле конфигурацииhttp://cwe.mitre.org/data/definitions/260.html
• CWE-522: Недостаточно защищенные учетные данныеhttp://cwe.mitre.org/data/definitions/522.html
• CWE-257: Хранение паролей в восстанавливаемом форматеhttp://cwe.mitre.org/data/definitions/557.html

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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