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

Question

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

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

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

Answer 1

Если вы работаете в системе 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 для шифрования, что бы ни имело смысл в наборе параметров вашей серверной программы. Если вы пишете программу для этого, лучшее, что вы можете сделать, - это запрашивать у пользователя пароль только при необходимости, а затем удалять этот пароль из памяти, как только он будет использован.

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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