Центр знаний DevOps
Центр знаний DevOps

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

Мгновенно защитите свои данные с помощью этого руководства по пяти обязательным настройкам безопасности для MongoDB. Узнайте, как перейти от уязвимых настроек по умолчанию к высокозащищенной среде путем внедрения обязательной аутентификации пользователей, строгого контроля доступа на основе ролей (RBAC), привязки IP-адресов сети и сквозного TLS-шифрования. Мы также рассмотрим важнейшие методы аудита, необходимые для соблюдения нормативных требований и немедленного обнаружения угроз, предоставив практические примеры настроек для незамедлительного применения.

32 просмотров

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример: Создание пользователя 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 часто привязывается ко всем доступным сетевым интерфейсам (0.0.0.0), делая ее потенциально доступной для всей сети или, что еще хуже, для общедоступного Интернета, если она работает на облачном экземпляре без надлежащих правил межсетевого экрана.

Ограничение 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 Security Groups или Azure Network Security Groups) для фильтрации трафика до того, как он достигнет сервера.

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

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

Данные, передаваемые между клиентами (приложениями, оболочками, драйверами) и сервером MongoDB, должны быть зашифрованы с использованием Transport Layer Security (TLS) или Secure Sockets Layer (SSL). Передача учетных данных, запросов и результатов по незашифрованным соединениям подвергает данные потенциальному прослушиванию (атаки типа «человек посередине»).

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

Включение TLS/SSL

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

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

net:
  ssl:
    mode: requireTLS
    # Путь к комбинированному файлу сертификата и ключа
    serverCertificateKeyFile: /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 в производственной среде, чтобы гарантировать безопасность всех соединений. Режим preferTLS обычно используется только во время миграции или тестирования.

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

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

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

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

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

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

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

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

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

Интегрируйте журналы аудита MongoDB с централизованными системами управления журналами (например, Splunk, ELK Stack, DataDog) для оповещения в реальном времени и долгосрочного хранения.

Заключение

Реализация этих пяти критически важных конфигураций переводит ваше развертывание MongoDB из состояния уязвимости в состояние устойчивости. Безопасность в MongoDB — это не задача «настроил и забыл»; это непрерывный процесс. Убедитесь, что эти конфигурации — обязательная аутентификация, гранулированный RBAC, строгая привязка сети, шифрование TLS и комплексный аудит — проверяются при каждом развертывании и регулярно пересматриваются. Приоритизация этих шагов значительно снизит риск несанкционированного доступа и компрометации данных.