Статья по безопасности NoSQL (NoSQL Security Cheat Sheet)

Введение

NoSQL-базы (MongoDB, CouchDB, Cassandra и др.) лежат в основе многих современных приложений за счёт гибкой схемы и горизонтального масштабирования. Но иные модели запросов и сценарии развёртывания создают больше рисков для безопасности, чем у классических реляционных СУБД.

Эта статья собирает практические рекомендации по снижению рисков при использовании NoSQL-систем.

Угрозы и типичные сбои

  • NoSQL-инъекция — небезопасная сборка объектов запроса или строк запроса из недоверенного ввода.
  • Открытые административные интерфейсы — веб-админки, порты БД или REST-эндпоинты, доступные из интернета.
  • Слабая или отсутствующая аутентификация и авторизация — доступ по умолчанию «для всех» или избыточные привилегии клиентов.
  • Небезопасное сетевое размещение — без TLS, открытые порты, недостаточная сегментация сети.
  • Небезопасные значения по умолчанию — учётные записи администратора, пароли по умолчанию, слабая конфигурация.
  • Слабые модели контроля доступа — грубые роли, упрощающие горизонтальное злоупотребление.
  • Небезопасная сериализация / десериализация — удалённое выполнение кода через небезопасную десериализацию объектов.
  • Ошибки CORS / публичные API — случайно разрешённые кросс-доменные запросы или слишком широкий доступ.
  • Утечки учётных данных и секретов — пароли к БД в коде, образах, логах CI.
  • Небезопасные бэкапы — копии без шифрования или с публичным доступом.
  • Цепочка поставки и зависимости — уязвимые драйверы, ODM/ORM или плагины.

Принципы «безопасность с проектирования»

  • Считать любой ввод недоверенным — проверять, нормализовать и при необходимости очищать.
  • Наименьшие привилегии — узкие роли для пользователей, сервисов и операторов.
  • Многоуровневая защита — сеть, аутентификация, проверка ввода и мониторинг вместе.
  • Безопасные настройки по умолчанию — смена портов и учётных записей по умолчанию, включённая аутентификация и TLS.
  • Автоматизация секретов и ротации — хранилища секретов и краткоживущие учётные данные.
  • Мониторинг и аудит — журналирование доступа и выявление аномалий.

Практическая защита и примеры

Предотвращение NoSQL-инъекций

Небезопасно (сборка фильтра из строки — Node.js / MongoDB):

// ОПАСНО: запрос из недоверенного ввода
const q = "{ name: '" + req.query.name + "' }";
const filter = eval("(" + q + ")"); // так делать нельзя
db.collection('users').find(filter)

Безопасно (объекты запроса драйвера / параметризация):

// БЕЗОПАСНО: структуру запроса формирует драйвер
const filter = { name: req.query.name };
db.collection('users').find(filter)

Безопасно (белый список для операторов):

// Отклонять инъекцию операторов: не допускать $ в ключах/значениях операторов
if (JSON.stringify(req.body).includes('"$')) throw new Error("Invalid input");

Замечания:

  • Не принимайте от клиента сырые фрагменты JSON для выполнения как запроса.
  • Запрещайте клиенту управлять операторами запроса ($where, $regex, $expr и т.п.), если это не строго необходимо и не проверено.
  • Для текстового поиска используйте безопасные API драйвера (например $text с контролируемым вводом).

Безопасные паттерны драйвера / ODM

  • Отдавайте предпочтение высокоуровневым API (ODM/ORM), которые строят запросы безопасно (Mongoose, Spring Data, паттерны драйвера Datastax и др.).
  • Избегайте возможностей вроде eval() и выполнения сырых запросов из недоверенных данных.
  • Любые сырые выражения перед передачей в БД проверяйте и валидируйте.

Пример — безопасное использование PyMongo

from pymongo import MongoClient
client = MongoClient(uri, tls=True)
collection = client.mydb.users
user = collection.find_one({"email": email_input})

Аутентификация и авторизация

  • Включайте аутентификацию (не запускайте БД без неё).
  • Используйте ролевую модель (RBAC) и наименьшие привилегии для сервисных учётных записей.
  • Разделяйте пользователей для администрирования, бэкапов, только чтения и приложения.
  • При поддержке платформой — федерация удостоверений или краткоживущие учётные данные (например AWS IAM → DynamoDB).

Дополнительно см. статьи:

Authentication Cheat Sheet

Authorization Cheat Sheet

Сеть и транспорт

  • Привязывайте сервисы к внутренним интерфейсам, а не к 0.0.0.0.
  • Используйте сегментацию сети / приватные подсети и группы безопасности.
  • Требуйте TLS (шифрование при передаче) для соединений драйверов и админ-консолей.
  • Отключайте удалённое управление или ограничивайте его админскими сетями / VPN.

Укрепление конфигурации

  • Меняйте порты по умолчанию и отключайте демо-пользователей.
  • Отключайте или ограничивайте функции выполнения кода на сервере (например db.eval в MongoDB, серверные скрипты).
  • Включайте TLS для внутренней репликации, если СУБД это поддерживает.

Управление секретами

  • Не вшивайте учётные данные БД в код — используйте менеджер секретов (Vault, AWS Secrets Manager, Azure Key Vault).
  • Не помещайте секреты в образы контейнеров и не допускайте их попадания в логи CI.
  • Регулярно ротируйте учётные данные; по возможности — одноразовые токены.

См. также Secrets Management Cheat Sheet.

Журналирование, мониторинг и аудит

  • Включайте аудит (попытки подключения, действия администратора, неуспешная аутентификация).
  • Направляйте логи в SIEM с защитой от подделки.
  • Настраивайте оповещения по аномалиям (всплеск запросов, медленные запросы, крупные выгрузки).
  • Отслеживайте подозрительные команды (админ-операции, $where, задания map-reduce).

Резервные копии и снимки

  • Шифруйте бэкапы в покое и при передаче.
  • Ограничивайте доступ к хранилищу резервных копий.
  • При необходимости обезличивайте ПДн в копиях согласно политике.
  • Регулярно проверяйте процедуры восстановления.

Краткий чек-лист безопасности NoSQL

  • Включены аутентификация и RBAC
  • TLS для клиентов и межузлового трафика
  • БД на внутренних IP / в приватных сетях
  • Сервисные учётные записи с минимальными правами
  • Клиент не управляет операторами запроса без явной валидации
  • Нет сырого выполнения запросов и eval на сервере
  • Учётные данные в менеджере секретов с ротацией
  • Укреплённая конфигурация (отключены небезопасные значения по умолчанию)
  • Зашифрованы и изолированы бэкапы
  • Мониторинг и аудит доступа и админ-действий
  • Актуальные версии СУБД и драйверов

Стоит и не стоит

Стоит:

  • Строить запросы объектами драйвера, а не конкатенацией строк.
  • Валидировать и белым списком ограничивать поля (колонки/ключи), приходящие от пользователя.
  • Ограничивать админ-интерфейсы и требовать MFA для административного доступа.
  • Встраивать проверки безопасности в CI/CD.

Не стоит:

  • Выставлять порты БД и админ-консоли в публичный интернет.
  • Принимать от клиента сырые JSON-запросы или выполнять eval над недоверенными строками.
  • Подключать приложение от имени root/админской учётной записи БД.
  • Полагаться только на сетевые меры, если запросы к БД написаны небезопасно.

Примеры опасных паттернов (кратко)

  • Разрешить клиенту передать { "$where": "this.balance > 0" } — риск удалённого выполнения кода или чрезмерной нагрузки на CPU.
  • Склеивать пользовательский ввод в строки языка запросов или shell-команды для утилит БД.
  • Оставить MongoDB без аутентификации на публичном IP.

Ссылки

© Перевод на русский язык. Оригинальные материалы: OWASP Cheat Sheet Series.
Этот проект использует материалы OWASP, распространяемые по лицензии CC BY-SA 4.0.