MongoDB на VPS: установка и базовая защита

MongoDB и особенность её установки по умолчанию

MongoDB — документоориентированная NoSQL база данных, хранящая данные в формате, похожем на JSON (точнее, в бинарном формате BSON), без жёсткой предварительно заданной схемы таблиц, характерной для реляционных баз данных вроде MySQL или PostgreSQL. Такая гибкость делает MongoDB удобной для проектов с часто меняющейся структурой данных или с изначально неоднородными документами, но требует отдельного внимания к базовой защите инсталляции сразу после установки.

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

Официальная документация MongoDB Security Checklist

Именно эта особенность — аутентификация выключена по умолчанию сразу после установки из стандартных пакетов — регулярно становится причиной громких утечек данных: автоматизированные сканеры интернета непрерывно ищут открытые порты 27017 (порт MongoDB по умолчанию) и, найдя инсталляцию без аутентификации, получают полный доступ ко всем хранящимся в ней данным без какого-либо взлома в привычном смысле — просто потому, что администратор не включил защиту, предусмотренную самой MongoDB, но не активированную автоматически.

Эта статья разбирает пошаговую установку MongoDB на VPS с сразу включённой базовой защитой: создание пользователей с ограниченными правами, включение обязательной аутентификации, правильную настройку bindIp и ограничение доступа к порту через файрвол, а также базовое представление о replica set как механизме отказоустойчивости.

Установка MongoDB на VPS

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

curl -fsSL https://pgp.mongodb.com/server-7.0.asc | \
  sudo gpg -o /usr/share/keyrings/mongodb-server-7.0.gpg --dearmor
echo "deb [signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg] \
  https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | \
  sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
sudo apt update
sudo apt install -y mongodb-org

После установки пакета сервис mongod по умолчанию не запущен автоматически на некоторых системах — его нужно явно включить и запустить через systemd, а также сразу проверить, что сервис действительно поднялся и слушает ожидаемый порт.

sudo systemctl enable --now mongod
sudo systemctl status mongod
mongosh --eval "db.runCommand({ ping: 1 })"

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

Создание администратора и включение аутентификации

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

mongosh
use admin
db.createUser({
  user: "dbAdmin",
  pwd: passwordPrompt(),
  roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ]
})

Функция passwordPrompt() запрашивает пароль интерактивно, не оставляя его в истории команд оболочки или в логах — это предпочтительнее, чем передавать пароль прямо текстом в команде создания пользователя, особенно на сервере, где история команд может сохраняться и потенциально попасть в резервные копии или логи аудита.

# /etc/mongod.conf
security:
  authorization: enabled

После добавления этой директивы в конфигурационный файл и перезапуска сервиса (sudo systemctl restart mongod) любое подключение к серверу без указания корректных учётных данных будет отклонено — включая попытки выполнить любые операции чтения или записи данных, что и является основной целью этого шага. Проверить, что аутентификация действительно требуется, можно попыткой выполнить любую команду без авторизации сразу после перезапуска — она должна завершиться ошибкой доступа.

Пользователи приложения с минимально необходимыми правами

Использовать учётные данные администратора для подключения из кода приложения — плохая практика: при компрометации приложения (например, через уязвимость в коде, позволяющую выполнить произвольный запрос к базе) злоумышленник получает не только доступ к данным конкретного приложения, но и полные права администрирования всего сервера MongoDB, включая другие базы данных на этом же сервере, если они есть.

use myapp
db.createUser({
  user: "myapp_user",
  pwd: passwordPrompt(),
  roles: [ { role: "readWrite", db: "myapp" } ]
})

Роль readWrite, ограниченная конкретной базой данных myapp, разрешает этому пользователю читать и изменять данные только внутри этой базы, но не даёт доступа к другим базам данных на том же сервере и не позволяет выполнять административные операции вроде создания новых пользователей, изменения ролей или настройки репликации. Для отчётных задач или сервисов, которым нужен только просмотр данных без возможности их изменения, стоит создавать отдельного пользователя с ролью read вместо readWrite — это ограничивает ущерб от компрометации именно этого сервиса чтением, без риска порчи или удаления данных через его учётные данные.

MongoDB также поддерживает пользовательские роли (custom roles), позволяющие описать произвольный набор конкретных разрешённых операций точнее, чем предоставляют встроенные роли вроде readWrite, — это оправдано в проектах со сложными требованиями к разграничению доступа между разными частями одного приложения или разными командами, работающими с одной и той же базой данных.

bindIp: кому разрешено подключаться к серверу

Директива net.bindIp в конфигурации mongod определяет, на каких сетевых интерфейсах сервер принимает входящие соединения — по умолчанию после установки MongoDB часто настроена на приём соединений только с локального адреса 127.0.0.1, что уже безопасно для конфигурации, где приложение работает на том же сервере, что и база данных.

# /etc/mongod.conf
net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.5

Если приложение и MongoDB работают на разных серверах (например, в схеме с отдельным выделенным сервером базы данных), bindIp нужно дополнить приватным IP-адресом сервера приложения — но именно конкретным приватным адресом, а не значением 0.0.0.0, разрешающим приём соединений на любом сетевом интерфейсе сервера, включая публичный, если он есть. Указание 0.0.0.0 без крайней необходимости увеличивает поверхность атаки, делая процесс mongod видимым и доступным для попыток подключения с любого адреса в интернете, даже если сама аутентификация и остаётся его последним рубежом защиты.

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

Файрвол: ограничение доступа к порту 27017

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

sudo ufw allow from 10.0.0.5 to any port 27017 proto tcp
sudo ufw deny 27017/tcp
sudo ufw status verbose

Порядок правил ufw имеет значение — правило allow from для конкретного адреса должно быть добавлено до общего запрещающего правила deny для того же порта, поскольку ufw применяет правила последовательно и первое подходящее правило определяет судьбу пакета. Если сервер приложения и MongoDB работают в одной приватной сети (например, оба на VPS одного провайдера с включённой приватной сетью между инстансами), стоит ограничивать доступ именно приватным адресом, а не открывать порт на публичном интерфейсе сервера вовсе.

Отдельный практичный вариант для инфраструктуры с несколькими серверами приложения — ограничение доступа не по отдельным IP-адресам, а по всей приватной подсети, если она полностью находится под контролем администратора и не используется совместно с чужими проектами на той же сети провайдера.

Базовое представление о replica set

Replica set в MongoDB — группа серверов mongod, поддерживающих синхронизированные копии одних и тех же данных: один узел выступает первичным (primary) и принимает все операции записи, а остальные узлы — вторичными (secondary) и асинхронно реплицируют изменения с первичного узла, аналогично концепции master-slave репликации в реляционных базах данных.

# на каждом узле будущего replica set
# /etc/mongod.conf
replication:
  replSetName: "rs0"

# после перезапуска сервиса, на одном из узлов:
mongosh --eval 'rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "10.0.0.5:27017" },
    { _id: 1, host: "10.0.0.6:27017" },
    { _id: 2, host: "10.0.0.7:27017" }
  ]
})'

Главная практическая ценность replica set — автоматическое переключение (automatic failover): при отказе первичного узла оставшиеся узлы автоматически проводят выборы нового первичного среди доступных вторичных узлов, без ручного вмешательства администратора, что заметно сокращает время простоя по сравнению с единичным сервером без резервирования. Нечётное число узлов (три, а не два) рекомендуется намеренно — это позволяет однозначно определить большинство голосов при выборах нового первичного узла и избежать ситуации, где ни один из двух равнозначных узлов не набирает большинства.

Как и в случае с репликацией реляционных баз данных, важно понимать: replica set защищает от отказа отдельного сервера и распределяет нагрузку на чтение между вторичными узлами, но не заменяет резервное копирование — логическая ошибка вроде случайного удаления коллекции документов реплицируется на все узлы набора так же надёжно, как и любое легитимное изменение, не оставляя возможности восстановить удалённые данные из самого replica set.

Резервное копирование MongoDB

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

mongodump --uri="mongodb://dbAdmin:пароль@127.0.0.1:27017" \
  --authenticationDatabase=admin \
  --out=/backup/mongodb/$(date +%F)

Утилита mongodump создаёт логический дамп данных в формате BSON, пригодный для восстановления через парную утилиту mongorestore, — этот способ универсален и переносим между разными версиями MongoDB и разным окружением, но для больших объёмов данных выполняется заметно медленнее, чем восстановление из файлового снапшота, поскольку требует последовательного чтения и обратной записи каждого документа.

mongorestore --uri="mongodb://dbAdmin:пароль@127.0.0.1:27017" \
  --authenticationDatabase=admin \
  --drop /backup/mongodb/2026-11-09

Флаг --drop перед восстановлением удаляет существующие коллекции в целевой базе данных перед тем, как восстановить их из дампа, — без этого флага восстановленные данные добавляются к уже существующим, что для документов с уникальными индексами (например, по полю _id) обычно приводит к ошибкам конфликта, если восстанавливаемые данные пересекаются с уже присутствующими в базе. Резервные копии, как и для любой другой базы данных, обязательно нужно хранить отдельно от самого сервера MongoDB и периодически проверять их реальную пригодность к восстановлению, а не полагаться на сам факт наличия файла дампа как на гарантию его работоспособности.

Типичные ошибки при развёртывании MongoDB

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

Использование единой учётной записи администратора для подключения из кода всех приложений на сервере вместо создания отдельных пользователей с ограниченными правами для каждого приложения — превращает компрометацию любого одного приложения в компрометацию вообще всех данных на сервере MongoDB.

Настройка bindIp на 0.0.0.0 без реальной необходимости в подключении с произвольных внешних адресов — расширяет поверхность атаки без практической пользы, если приложение и база данных находятся в одной управляемой сети.

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

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

Итог: защита MongoDB требует явных действий администратора

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

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