Как ответственные администраторы мы знаем такие общие слабости, как
Но как с этим справиться на практике?
Конечно, с такими технологиями, как аутентификация без пароля через SSH и такими инструментами, как sudo, можно избавиться от сохраненных учетных данных для входа в важных местах, и это действительно помогает при автоматическом развертывании серверов Linux.
Но как только вы покидаете операционную систему и устанавливаете приложения, высока вероятность того, что вы столкнетесь с проблемой, где безопасно хранить пароли.
Например, если вы устанавливаете сервер базы данных, скорее всего, вам потребуется сохранить пароль в виде открытого текста в файле конфигурации вашего веб-приложения.
Затем вы должны защитить файл конфигурации, чтобы только администратор мог просматривать учетные данные, и вы должны ограничить права доступа пользователя базы данных, чтобы ограничить возможное влияние на безопасность.
Но как бороться, например, с учетная запись основной административной базы данных? По крайней мере, ваш dbas должен это знать (так что вам нужен где-то открытый текст), и как администратор ОС вы должны не знать полномочия. Или развертывание выполняется DevOps, и они не должны знать любой учетных данных на производственных серверах.
Возможные решения
Поразмыслив над этим в течение более длительного периода времени, я пришел к трем возможным решениям, но у них есть свои слабые стороны:
Создавайте случайные учетные данные во время развертывания и сохраняйте их в базе данных в режиме однократной записи. И например У dbas есть другой пользователь, который может читать только учетные данные базы данных. Но как работать с паролями в виде открытого текста в файлах конфигурации, например веб-приложения? Их мог читать пользователь root. Также пользователь root базы данных паролей может читать все учетные данные пароля.
Примите пароли в открытом виде и учетные данные по умолчанию во время развертывания и добавьте постскриптум, который изменяет каждый и все пароли. Может быть, даже интерактивным, когда авторизованные люди должны вводить учетные данные во время выполнения скрипта.
Асимметрично зашифруйте пароль с помощью ключа доверенной третьей стороны. Когда запрашивается пароль, он должно быть потом изменилось.
Что вы думаете? Вы видите здесь какие-нибудь передовые практики?
Вы можете заменить электронную почту практически любым протоколом. Вы можете где-нибудь ввести пароль, создать одноразовое сообщение, используя onetimesecret api, загрузить его в частную сущность, используя https, или что-нибудь еще, о чем вы можете подумать.
Я думаю, что это все.