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

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

Это руководство показывает пять проверок для production-среды, которые снижают вероятность несанкционированного доступа и упрощают расследование подозрительной активности.

---

1. Включите обязательный контроль доступа и строгую аутентификацию

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

Как включить аутентификацию

Аутентификация обычно включается через файл конфигурации (mongod.conf) или флаги командной строки при запуске.

Файл конфигурации (/etc/mongod.conf):

# Фрагмент /etc/mongod.conf
security:
  authorization: enabled

Командная строка:

mongod --auth --dbpath /var/lib/mongodb

Создание администратора

Создайте первую учетную запись администратора до включения авторизации или используйте исключение localhost в MongoDB во время начальной настройки. После создания первого пользователя перезапустите MongoDB с включенной авторизацией и используйте именованные учетные записи для всего доступа.

Пример: Создание root-пользователя через mongosh

Сначала подключитесь к базе данных (если она уже запущена без аутентификации или используя исключение localhost):

use admin
db.createUser(
  {
    user: "mongoAdmin",
    pwd: passwordPrompt(), // Безопасный запрос пароля
    roles: [ { role: "root", db: "admin" } ]
  }
)

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

2. Внедрите детальный контроль доступа на основе ролей (RBAC)

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

Избегайте использования ролей root или readWriteAnyDatabase для подключений приложений. Вместо этого определите пользовательские роли, которые предоставляют конкретные разрешения на определенные базы данных или коллекции.

Практические шаги по RBAC

1. Определите пользовательские роли: Если встроенных ролей (read, readWrite) недостаточно, создайте роли с детальными действиями доступа (например, только insert и find для конкретной коллекции).
2. Разделите пользователей приложений: Создайте выделенных пользователей для разных уровней приложения (например, app_rw для бэкенда, reporting_ro для аналитики).
3. Ограничьте доступ внешних инструментов: Убедитесь, что инструменты администрирования подключаются с привилегированными учетными записями только при крайней необходимости.

Пример: Создание пользователя только для чтения для конкретной базы данных

use users_db
db.createUser(
  {
    user: "reporting_svc",
    pwd: passwordPrompt(),
    roles: [ { role: "read", db: "users_db" } ] // Только чтение из users_db
  }
)

3. Настройте строгую привязку к сети и межсетевые экраны

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

Ограничьте bindIp

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

Файл конфигурации (/etc/mongod.conf):

# Список IP-адресов или имен хостов для привязки
# Используйте 127.0.0.1 для доступа только с локальной машины
# Используйте внутренний IP-адрес(а) для доступа только с серверов приложений
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Внедрите внешние межсетевые экраны (группы безопасности)

В дополнение к bindIp (который ограничивает процесс MongoDB), вы должны использовать внешний межсетевой экран (например, iptables, группы безопасности AWS или группы безопасности сети Azure) для фильтрации трафика до того, как он достигнет сервера.

Лучшая практика: Разрешайте входящий трафик на порт MongoDB (по умолчанию 27017) только с ваших серверов приложений, балансировщиков нагрузки и административных jump-хостов.

4. Обеспечьте шифрование данных при передаче (TLS)

Данные, передаваемые между клиентами, оболочками, драйверами и MongoDB, должны быть зашифрованы с помощью Transport Layer Security (TLS). Отправка учетных данных, запросов и результатов по незашифрованным соединениям подвергает данные перехвату и атакам типа "человек посередине".

MongoDB поддерживает нативную конфигурацию TLS как для зашифрованного трафика, так и для опциональной проверки сертификата клиента.

Включение TLS

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

Файл конфигурации (/etc/mongod.conf):

net:
  tls:
    mode: requireTLS
    # Путь к объединенному файлу сертификата и ключа
    certificateKeyFile: /etc/ssl/mongodb.pem
    # Путь к файлу центра сертификации (для проверки клиента)
    CAFile: /etc/ssl/ca.pem

Подключение клиента с TLS

Как только сервер требует TLS, все клиенты должны подключаться, используя соответствующие безопасные флаги:

mongosh "mongodb://[email protected]/admin?authSource=admin" --tls --tlsCAFile /path/to/ca.pem

Совет: Используйте mode: requireTLS в production, чтобы гарантировать безопасность всех соединений. Режим preferTLS обычно используется только во время миграции или тестирования.

5. Включите аудит и мониторинг журналов активности

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

Функция аудита MongoDB может регистрировать административные действия, попытки аутентификации, отказы в авторизации и выбранные операции с данными. Доступность зависит от вашего издания или платформы MongoDB; например, аудит доступен в MongoDB Enterprise и MongoDB Atlas, в то время как самоуправляемые развертывания Community требуют других подходов к ведению журналов и мониторингу.

Конфигурация для аудита

Аудит настраивается через раздел auditLog в файле конфигурации. Вы можете указать назначение (файл, syslog, консоль) и критерии фильтрации.

Файл конфигурации (/etc/mongod.conf):

auditLog:
  destination: file
  path: /var/log/mongodb/audit.log
  format: JSON
  # Сосредоточьтесь на ключевых событиях безопасности, таких как аутентификация и административные изменения
  filter: '{ atype: { $in: [ "authenticate", "authCheck", "createCollection", "createUser", "dropDatabase" ] } }'

Основные области мониторинга

• Неудачные попытки аутентификации: Внезапный всплеск указывает на потенциальную атаку методом перебора.
• Создание/удаление пользователей/ролей: Все изменения привилегий должны регистрироваться и проверяться.
• Удаление баз данных или коллекций: Требуются немедленные оповещения для деструктивных операций.

Интегрируйте журналы аудита MongoDB с централизованными системами управления журналами, такими как Splunk, Elastic Stack или Datadog, для оповещения и хранения.

Вывод

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