Безопасно ли хранить критические пароли в переменных среды сервера?

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

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

Это действительно лучший способ избежать паролей в текстовых файлах конфигурации, или есть лучший способ?

Если вы работаете в системе Linux, посмотрите / proc / * / environment и решите, являются ли переменные среды хорошим местом для хранения конфиденциальной информации или нет. / proc / self - это текущий процесс:

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

Не берите в голову, что вещь, устанавливающая переменную среды, вероятно, читает файл где-нибудь.

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

Правильный способ сделать это - запустить приложение как учетную запись с ограниченными правами и сохранить пароль в файле, защищенном правами доступа на уровне файловой системы. Надеемся, что вы можете «включить» файл или аналогичный файл, чтобы сохранить пароль от системы контроля версий (при условии, что VCS не имеет мер безопасности). Чтобы защитить себя от непреднамеренного раскрытия, замаскируйте пароль как хотите - закодируйте с помощью base64, используйте pgp для шифрования, что бы ни имело смысл в наборе параметров вашей серверной программы. Если вы пишете программу для этого, лучшее, что вы можете сделать, - это запрашивать у пользователя пароль только при необходимости, а затем удалять его из памяти, как только он будет использован.

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

Это сводится к основному вопросу безопасности системы в сравнении с удобством. Вы можете добавить «глубокую защиту», имея множество уровней контроля безопасности, которые злоумышленник должен будет нарушить, чтобы добраться до «товаров», но затем, когда законный субъект хочет прочитать или изменить некоторые данные, они должны пройти через кучу обручей. Альтернатива - незашифрованные пароли в текстовых файлах.

Что бы я сделал, если бы действительно хотел защитить некоторую информацию в критически важной системе:

1. Используйте Full Disk Encryption, чтобы содержимое всего постоянного хранилища было зашифровано.

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

3. Внедрить детальный принудительный контроль доступа (MAC) в операционной системе устройства. Вы можете начать с чего-то вроде SELinux в GNU / Linux и установить для него Enforcing, а затем адаптировать политику к точным потребностям производственного программного обеспечения, предоставляя этим учетным записям именно те (и только) разрешения, которые им необходимы для файлов, которые им нужны.

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

5. Убедитесь, что у вас есть специалисты по сетям, чтобы позаботиться о разрешениях брандмауэра, чтобы свести к минимуму подверженность атаке по сети. Аудит (тест на проникновение, а также тестирование кода в «белой коробке») любого программного обеспечения, которое взаимодействует с внешними системами, особенно с общедоступным Интернетом. «Интерфейсы» включают в себя не только прямые сетевые подключения, но также чтение или запись «ненадежных» данных (данных, чьи байты были получены вне ОЗУ / диска / ЦП защищенного сервера).

Это не полный список, но особенно пункт 4, вероятно, имеет отношение к вам, хотя, если вы не выполните хотя бы шаги с 1 по 3, рассмотрение пунктов 4 и 5 не очень вам поможет, потому что ваш Система не является безопасной на достаточно фундаментальном уровне.

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

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

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

Недостаток в вашем сценарии - «создать подходящую переменную среды при настройке серверной системы». Переменная среды - это динамическое свойство процесса. Вы не можете создать его при настройке системы, если под настройкой вы подразумеваете что-то, что переживает перезагрузку. Что вы имеете в виду, по- видимому , что администратор организовал для этого переменного будет присутствовать в среде , когда некоторый вход пользователя в системе . Это делается с помощью конфигурационного файла (обычно ~/.pam_environmentили ~/.profileили файл читать ~/.profile). Таким образом, это решение, по сути, не перемещает пароль из файлов конфигурации.

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

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