Как подключиться к mongodb удаленно
Установка и подключение к MongoDB
В данной инструкции мы рассмотрим процесс установки MongoDB на Linux Ubuntu (Debian). Также будут приведены примеры настройки подключения по сети, защита соединения с помощью шифрования и аутентификации.
Установка
На странице MongoDB Community Downloads смотрим стабильные версии программного продукта. На момент обновления инструкции это была 4.4.
Обратите внимание, установка MongoDB возможна на большое число популярных операционных систем — Amazon, Debian, Ubuntu, macOS, CentOS, Red Hat, Windows и другие.
Переходим на страницу загрузки ключей для проверки подлинности репозитория. Копируем ссылку для версии MongoDB, которую мы планируем установить:
* в данном примере мы скопировали ссылку на ключ для версии 4.4. Обратите внимание, что также есть возможность загрузки ключей для более свежих и менее стабильных версий.
С помощью скопированной ссылки скачиваем и устанавливаем ключ:
Создаем файл для настройки репозитория Ubuntu:
deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse
* focal — название релиза Ubuntu. В данном примере, версия 20.04. На данный момент возможны варианты:
Обновляем список пакетов:
apt-get install mongodb-org
Стартуем сервис и разрешаем его автозапуск:
systemctl start mongod
systemctl enable mongod
Для подключения к СУБД вводим команду:
Можно для проверки ввести команду, которая покажет созданные базы данных:
После первой установки мы должны увидеть следующее:
admin 0.000GB
config 0.000GB
local 0.000GB
В качестве примера работы мы можем попробовать создать новую базу данных и коллекцию. Объекты в MongoDB создаются автоматически при первом к ним обращении.
Для создания базы просто обращается к ней:
* в данном примере будут создана база newDB.
Для создания коллекции, выполняем команду на вставку данных:
Выходим из оболочки SQL:
Доступ по сети
По умолчанию к установленной базе можно подключиться только с локального компьютера. Рассмотрим процесс настройки сетевого доступа.
Для начала, откроем порт в брандмауэре:
* по умолчанию, MongoDB работает на TCP-порту 27017.
В системах на базе Ubuntu и Debian брандмауэр работает по принципу разрешения. Если мы не меняли данной настройки, то нам не обязательно создавать разрешающее правило для Mongo.
Открываем конфигурационный файл СУБД:
Находим директиву net и в ней опцию bindIp — добавляем IP-адрес, на котором наш сервер должен принимать запросы для MongoDB:
net:
port: 27017
bindIp: 127.0.0.1, 192.168.1.15
* в нашем примере мы добавили к 127.0.0.1 адрес 192.168.1.15 — это сетевой адрес нашего сервера, на котором он должен принимать запросы.
Перезапускаем сервис mongod:
systemctl restart mongod
Чтобы проверить подключение, на другом компьютере должен быть установлен клиент для подключения к Mongo. Процесс его установки схож с установкой сервера. Рассмотрим пример для Ubuntu.
Устанавливаем ключ для репозитория:
deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse
* как в случае с сервером, focal — название релиза Ubuntu. В данном примере, версия 20.04. Другие варианты: bionic: 18.04, xenial: 16.04.
Обновляем список пакетов:
Устанавливаем клиентскую часть:
apt-get install mongodb-org-shell
Теперь можно подключиться к нашему серверу:
* в данном примере мы подключаемся к серверу MongoDB 192.168.1.15.
Также мы можем использовать MongoDB Compass — это приложение под Windows, Linux и macOS для работы с базой Mongo в графическом интерфейсе. Скачать его можно на странице официального сайта.
Аутентификация
По умолчанию, мы можем подключиться к СУБД без авторизации. Если нам необходимо повысить безопасность работы с базой, можно требовать ввода логина и пароля.
Заходим в командную оболочку Mongo:
Подключаемся к базе admin:
Создаем пользователя, под которым будем авторизовываться:
* в данном примере мы создадим пользователя с правами доступа на все базы. Логин root, пароль будет запрошен после ввода.
Придумываем и вводим пароль
После создания пользователя мы должны увидеть, примерно, следующую картину:
Successfully added user: <
«user» : «root»,
«roles» : [
<
«role» : «userAdminAnyDatabase»,
«db» : «admin»
>,
«readWriteAnyDatabase»
]
>
Выходим из командной оболочки:
Открываем конфигурационный файл:
Находим директиву security и задаем параметр authorization:
security:
authorization: enabled
Перезапускаем сервис mongod:
systemctl restart mongod
Теперь пробуем подключиться к mongo. Мы можем авторизоваться несколькими способами.
а) Авторизация при подключении:
* в данном примере мы подключимся к базе под пользователем root. Пароль будет запрошен системой после ввода команды.
б) Авторизация после подключения:
Теперь усилим безопасность, зашифровав передачу данных. Для этого нам понадобиться сертификат. В нашем примере, мы будем использовать самоподписанный сертификат, но в продуктивной среде, лучше его купить или запросить у Let’s Encrypt.
Создаем каталог, в котором разместим наши сертификаты:
Сгенерируем самоподписанный сертификат:
Выставим в качестве владельца на файлы сертификата пользователя mongodb:
chown mongodb:mongodb /etc/ssl/mongodb/cert.pem
Открываем конфигурационный файл СУБД:
В директиву net дописываем опции TLS:
net:
.
tls:
mode: requireTLS
certificateKeyFile: /etc/ssl/mongodb/cert.pem
* в данном примере мы указали необходимость шифрования данных при передаче, а также путь до сгенерированного нами сертификата.
Перезапускаем сервис mongod:
systemctl restart mongod
Для подключения к базе с использованием шифрования используем команду:
* в данном примере мы указываем при подключении использовать шифрование с использованием TLS. Опция tlsAllowInvalidCertificates говорит, что клиент должен принять неправильный сертификат (так как у нас он самоподписанный).
Так как у нас еще настроена аутентификация, для подключения введем такую команду:
Для подключения к нашему серверу по сети, полная команда будет такой:
Примеры подключения из языков программирования
Рассмотрим небольшие примеры для подключения к MongoDB из языков программирования PHP и Python.
Для возможности работы PHP с Mongo необходимо установить соответствующее расширение. Выполняем пошагово следующие действия:
apt-get install php-pear php-dev
pecl channel-update pecl.php.net
pecl install mongodb
Для каждого возможного варианта использования PHP необходимо создать отдельный конфигурационной файл. В данном примере, под php 7.4 для cli, php-fpm, apache.
MongoDB — разрешить удаленный доступ
В этом руководстве мы покажем вам, как включить удаленный доступ к серверу MongoDB. Вот протестированная среда:
1. Сервер MongoDB
2. Сервер приложений (та же сеть LAN)
3. Разработчики дома (другая сеть LAN, WAN)
PS По умолчанию MongoDB не разрешает удаленные подключения.
1. Привязать IP
По умолчанию MongoDB связывается только с локальным интерфейсом, это ограничивает удаленные соединения. Если вы не заботитесь о безопасности, просто закомментируйте, чтобы принимать любые удаленные подключения (НЕ рекомендуется).
1.1. Разрешить подключения к локальной сети с сервера приложений.
Поскольку оба находятся в одной и той же локальной сети, вам просто нужно привязать MongoDB к его собственному частному IP-интерфейсу.
Общая ошибка
Не помещайте IP-адрес сервера приложений в bind_ip вариант. это bind_ip опция указывает MongoDB принимать соединения с каких локальных сетевых интерфейсов, а не с какого «удаленного IP-адреса».
По умолчанию — Ошибка подключения
Сейчас — соединение успешно
1.2 Разрешить удаленный доступ для разработчиков дома.
Разработчики получат удаленный доступ через общедоступный IP-адрес MongoDB 45.56.65.100, чтобы позволить это, также связать публичный интерфейс ip.
Заметка
Для разработчиков дома рекомендуется установить VPN-соединение, вместо того, чтобы открывать публичное IP-соединение MongoDB, оно уязвимо для атак людей.
Перезапустите MongoDB для вступления в силу.
2. IpTables Firewall
Если у вас есть брандмауэр, разрешите соединения через порт 27017 Порт MongoDB по умолчанию.
2.1 Любые соединения могут подключаться к MongoDB через порт 27017
2.2 Только определенный IP может подключаться к MongoDB через порт 27017
2.3 Вот правила брандмауэра, используемые на одном из моих серверов MongoDB.
Настройка удаленного доступа для MongoDB в Ubuntu 20.04
Введение
MongoDB (или Mongo) — это документоориентированная база данных с открытым исходным кодом, используемая во многих современных веб-приложениях. По умолчанию она допускает только те подключения, которые исходят с того же сервера, на котором она установлена. Если вы хотите управлять MongoDB удаленно или подключить ее к отдельному серверу приложения, вам необходимо будет внести несколько изменений в исходную конфигурацию по умолчанию.
В этом обучающем руководстве мы настроим систему MongoDB для безопасного доступа с доверенного удаленного компьютера. Для этого вам нужно будет обновить правила брандмауэра, чтобы обеспечить удаленному компьютеру доступ к порту, на котором MongoDB слушает подключения, и обновить файл конфигурации для изменения параметра привязки IP-адреса. А затем, в качестве завершающего шага, вы проверите, сможет ли ваш удаленный компьютер успешно подключиться к вашей базе данных.
Предварительные требования
Для завершения данного обучающего модуля вам потребуется:
Наконец, мы настоятельно рекомендуем вам обеспечить безопасность системы MongoDB путем создания учетной записи пользователя с правами администратора для базы данных и обеспечения аутентификации, хотя это и не требуется для выполнения данного обучающего модуля.
Шаг 1 — Настройка брандмауэра
Если вы выполнили начальную инструкцию по настройке сервера и включили брандмауэр UFW на вашем сервере, тогда ваша система MongoDB будет недоступна из Интернета. Если вы собираетесь использовать MongoDB только локально с запуском приложений на том же сервере, эту безопасную настройку рекомендуется сохранить. Но если вы хотите иметь возможность подключаться к серверу MongoDB с удаленной локации, вам нужно разрешить входящие подключения к порту, на котором прослушивается база данных. Для этого нужно добавить новое правило UFW.
Этот пример вывода показывает, что MongoDB прослушивает подключения на порту по умолчанию 27017 :
В большинстве случаев доступ к MongoDB следует разрешать только из определенных доверенных локаций, таких как другой сервер хостинга приложения. Одним из способов настройки этого ограничения является запуск на сервере MongoDB следующей команды, которая открывает доступ к порту по умолчанию MongoDB только для IP-адреса другого доверенного сервера.
Запустите следующую команду, убедившись, что вы поменяли trusted_server_ip на IP-адрес доверенного удаленного компьютера, который вы будете использовать для доступа к вашему экземпляру MongoDB:
Примечание. Если вывод предыдущей команды показал, что ваша установка MongoDB выполняет прослушивание не на порту по умолчанию, используйте номер этого порта вместо 27017 в данной команде.
Вы можете проверить изменение параметров брандмауэра с помощью ufw :
Вывод покажет, что трафик к порту 27017 с удаленного сервера сейчас разрешен:
В следующем шаге мы свяжем MongoDB с публичным IP-адресом сервера, чтобы получить доступ с удаленного компьютера.
Шаг 2 — Настройка публичного bindIP
Чтобы разрешить удаленные подключения, необходимо отредактировать файл конфигурации MongoDB — /etc/mongod.conf — для дополнительной привязки MongoDB к публичному маршрутизированному IP-адресу вашего сервера. Таким образом ваша система MongoDB сможет прослушивать подключения к вашему серверу MongoDB, выполненные с удаленных компьютеров.
Откройте файл конфигурации MongoDB в предпочитаемом текстовом редакторе. В следующем примере используется nano :
Найдите раздел network interfaces (сетевые интерфейсы), а затем значение bindIp :
Добавьте запятую в эту строку, а затем публичный IP-адрес вашего сервера MongoDB:
Затем перезапустите MongoDB, чтобы изменение вступило в силу:
Шаг 3 — Тестирование удаленного подключения
Теперь, когда вы настроили систему MongoDB для прослушивания подключений, исходящих с ее публичного маршрутизированного IP-адреса, и предоставили удаленному компьютеру доступ через брандмауэр сервера к порту по умолчанию Mongo, можно проверить, сможет ли удаленный компьютер выполнить подключение.
Примечание. Как указано в разделе «Предварительные требования», это обучающее руководство предполагает, что ваш удаленный компьютер — это еще один сервер на базе Ubuntu 20.04. Процедура по обеспечению удаленных подключений, описанная в шагах 1 и 2, должна работать независимо от операционной системы вашего удаленного компьютера. Однако методы тестирования, описанные в этом шаге, не являются универсальными для всех операционных систем.
Вначале войдите на ваш доверенный сервер с помощью SSH:
Запустите следующую команду nc с вашего доверенного удаленного сервера и не забудьте заменить mongodb_server_ip IP-адресом сервера, на котором вы установили MongoDB:
Если доверенный сервер сможет получить доступ к демону MongoDB, его вывод будет означать, что подключение было успешным:
Если вы установили совместимую версию оболочки mongo на вашем удаленном сервере, вы можете на данном этапе подключаться напрямую к экземпляру MongoDB, установленному на сервере хоста.
Одним из способов подключения является URI строки подключения, например:
Примечание. Если вы выполнили рекомендации из руководства Обеспечение безопасности MongoDB в Ubuntu 20.04, у вас будет закрыт доступ к вашей базе данных от пользователей, которые не прошли аутентификацию. В этом случае вам нужно будет использовать URI с указанием действительного имени пользователя, например:
Оболочка автоматически попросит ввести пароль пользователя.
Этим вы подтверждаете, что ваш сервер MongoDB может принимать соединения с доверенного сервера.
Заключение
Теперь вы можете получить доступ к вашей системе MongoDB с удаленного сервера. На этом этапе вы можете управлять вашей базой данных Mongo удаленно с доверенного сервера. Также вы можете настроить приложение, которое будет работать на доверенном сервере и удаленно использовать базу данных.
Если вы не настроили пользователя с правами администратора и не активировали аутентификацию, любой, кто имеет доступ к вашему удаленному серверу, также может получить доступ к вашей системе MongoDB.
Делаем доступ к базе данных MongoDB защищенным
Введение
MongoDB — одна из самых популярных баз данных с открытым исходным кодом. К сожалению, как следствие мы имеем огромное количество неправильно настроенных и незащищенных разверток MongoDB по всему миру. Только за последние пару лет мы стали свидетелями нескольких крупных взломов, обнаживших уязвимости тысяч баз данных MongoDB в сети, что сделало их легкой добычей для злоумышленников.
Однако все может быть по-другому. Есть множество мер, которые вы можете предпринять для обеспечения безопасности ваших данных в MongoDB — от защиты периметра сети до включения Strict-Transport-Security, чтобы использовать такие фичи, как расширенное управление пользователями в MongoDB и систему контроля доступа на основе ролей (Role-Based Access Control — RBAC).
В этой статье мы рассмотрим некоторые из наиболее популярных способов защиты кластера MongoDB.
Смените порт по умолчанию
Начнем с самого простого. Как и любая другая база данных, по умолчанию MongoDB прослушивает клиентские подключения на порту 27017, что ни для кого не является секретом. Сканирование портов (port scanning) — излюбленная техника хакеров (и к тому же достаточно простая), поэтому замена порта прослушивания по умолчанию на какой-либо другой — всегда хорошая идея.
Изменить этот порт можно в параметре конфигурации net.port:
Такая простая предосторожность, вероятно, предотвратила бы значительное количество вышеупомянутых нарушений безопасности данных.
Ограничьте прослушиваемые интерфейсы
Начиная с версии 3.6, MongoDB по умолчанию привязывается к localhost. Эту настройку по умолчанию, вероятнее всего, вам придется изменить, если только все ваши клиенты не подключаются с того же узла.
Не используйте параметр net.bindIpAll и 0.0.0.0 в качестве IP привязки — это заставит сервер прослушивать все доступные интерфейсы.
Используйте сокеты домена Unix
Если ваши клиенты все-таки подключаются с того же узла, в Unix-подобных системах можно полностью отключить прослушивание TCP-сокетов и перевести клиентов на подключение через сокеты домена Unix.
Чтобы это сделать, задайте путь к сокету в bindIp и настройте права доступа к сокету, чтобы разрешить вашим клиентам к нему подключаться:
Ограничьте доступ к сети с помощью файрвола
Однако чаще всего вашим клиентам необходимо подключаться к серверам MongoDB по сети. После изменения порта по умолчанию и ограничения адресов прослушивания, следующий уровень защиты, который вы можете (и должны) использовать, — это защита доступа к сети.
Используйте DROP вместо REJECT для всего остального входящего трафика — это усложнит работу злоумышленника, если он решит просканировать порты на вашем сервере, чтобы увидеть, какое программное обеспечение на нем работает.
Используйте переадресацию портов SSH
Конфигурацию файрвола можно изолировать еще больше, разрешив только один входящий порт SSH, если вы используете возможность протокола SSH перебрасывать порты (port forwarding).
Чтобы сделать это, установите перенаправление локального порта перед подключением к серверу MongoDB:
Эту конфигурацию можно сделать постоянной, используя файл конфигурации SSH (
Используйте обратное SSH-туннелирование
Обратное туннелирование, также известное как переадресация удаленного порта (remote port forward), — еще одна возможность SSH, которая может пригодиться при ограничении сетевого доступа к серверу базы данных.
Обратной стороной медали является то, что сервер должен иметь возможность связаться с клиентской машиной для формирования туннеля. Однако положительным моментом этой технологии является то, что она позволяет отключить все входящие подключения к серверу из ненадежных сетей.
Следующая команда, запущенная с сервера MongoDB, создаст обратный туннель к клиентскому хосту и начнет переадресацию порта 27017 клиентского хоста на локальный порт 38128:
Чтобы это работало, клиентский хост должен быть доступен с сервера, иметь запущенный демон SSH и позволить войти в систему.
Подключайтесь с хоста-бастиона
В сочетании с переадресацией локального порта SSH, хост-бастион может использоваться без шифрования соединения, поэтому вам даже не нужен SSH при подключении к нему:
Другое преимущество использования хоста-бастиона заключается в том, что он позволяет вам установить более строгую политику файрвола на серверах MongoDB, разрешая клиентские соединения только с бастиона.
Используйте X.509 аутентификацию сервера
Теперь же, когда мы прошлись по основным способам защиты сетевого периметра вашего сервера MongoDB, давайте более подробно рассмотрим, как сделать вашу клиент-серверную (и сервер-серверную в случае использования наборов реплик) связь более защищенной.
Настройка TLS-аутентификации сервера позволяет подключенным клиентам проверять подлинность сервера. Для начала вам нужно получить сертификат TLS, который ваш сервер будет предоставлять клиентам, и сертификат CA (Certification Authority — удостоверяющий центр), который клиенты будут использовать для проверки того, что представленный сертификат подписан доверенным центром.
Вы можете использовать certbot для получения бесплатных сертификатов TLS от Let’s Encrypt или просто создать самоподписанный CA и подписать сертификат локально с помощью openssl команд.
Создайте самоподписанный серверны CA:
Сгенерируйте CSR для сервера. Введите имя хоста, который вы будете использовать для подключения к базе данных, в поле Common Name (CN). Также не забудьте добавить хотя бы один из атрибутов «Organization» (O) или «Organizational Unit» (OU). Их значение не важно, если оно одинаково для всех членов кластера — оно будет использоваться для аутентификации члена кластера, о чем мы поговорим позже:
Подпишите сертификат сервера:
В многоузловых кластерах нужно подписывать сертификат для каждого узла. MongoDB требует, чтобы сертификат и ключ находились в одном файле, поэтому объедините их в один PEM-файл:
Теперь вы можете обновить конфигурацию сервера, чтобы включить TLS. Также неплохо было бы отключить устаревшие версии TLS и заставить клиентов использовать TLS 1.3:
Все клиенты должны будут подключаться с использованием TLS:
Используйте X.509 аутентификацию клиентов
Сертификат подлинности клиента позволяет серверу подтвердить подлинность подключающихся клиентов посредством проверки, что X.509 сертификат, представленный клиентом, подписан доверенным центром сертификации.
Как и в случае с серверным TLS, сначала создайте CA для клиентских сертификатов и подпишите им сертификат пользователя, которого мы для примера назовем Элис (Alice).
Создайте самоподписанный клиентский CA:
Сгенерируйте клиентский CSR. Поле «Subject» идентифицирует вашего пользователя MongoDB:
Подпишите сертификат клиента:
Как и для сервера, объедините сертификат и ключ Элис в PEM-файл:
Обратите внимание, что при использовании X.509 аутентификации MongoDB считает именем пользователя все поле Subject сертификата клиента, поэтому созданный выше сертификат будет идентифицировать пользователя MongoDB как CN=alice (а не просто alice ).
Наконец, включите X.509 аутентификацию, предоставив серверу клиентский CA-файл, который он будет использовать для проверки сертификатов, представленных клиентами:
Обратите внимание, что после включения этой опции каждый клиент должен будет представить для подключения действительный клиентский сертификат:
Используйте X.509 аутентификацию участников
Участники в наборах реплик или шардированные кластеры (sharded clusters) также могут аутентифицировать друг-друга с помощью клиентских сертификатов, что является лучшей альтернативой использования файлов-ключей.
MongoDB накладывает несколько ограничений на сертификаты, которые могут использоваться для аутентификации участников:
Каждый сертификат участника должен быть подписан одним и тем же удостоверяющим центром.
Common Name (CN) или Subject Alternative Names (SAN) должны совпадать с именем хоста сервера.
По крайней мере один из атрибутов Organization (O), Organizational Unit (OU) или Domain Component (DC) не должен быть пустым и быть одинаковым для всех участников.
Сертификат, очевидно, не может быть просроченным.
Сертификаты, которые вы сгенерировали для аутентификации сервера выше, удовлетворяют этим требованиям, поэтому все, что вам нужно сделать, это включить X.509 аутентификацию участников в конфигурации:
Чтобы проверить, что она работает, поищите сообщения об аутентификации участников в логах MongoDB, которые будут выглядеть примерно так:
Ограничьте IP участников
Помимо включения X.509 аутентификации участников, вы также можете ограничить соединения до участников только из авторизованных сетей.
Параметр security.clusterIpSourceWhitelist позволяет указать IP и диапазоны CIDR для приема подключений от участников набора реплик или шардированных кластеров:
Если IP подключающегося участника ( mongod или mongos ) отсутствует в списке или диапазоне CIDR, он не будет аутентифицирован.
Используйте управление доступом на основе ролей
Проверка подлинности клиента, которую вы настроили ранее, гарантирует, что ваш сервер MongoDB может проверить подлинность подключающегося клиента. Теперь нужно подумать, что собственно может делать этот самый клиент после подключения.
Авторизация
MongoDB включает автоматическую авторизацию клиента, когда включена аутентификация участника (через файл-ключ или X.509). Если вы по какой-то причине решили не использовать внутреннюю аутентификацию участников, включите авторизацию явно:
Встроенные роли
Чтобы начать использовать RBAC, вашим пользователям MongoDB нужно назначить роли. Роль предоставляет разрешения на выполнение определенных действий (actions) с определенными ресурсами (resources).
Ресурс может быть коллекцией, базой данных или кластером (для действий, требующих разрешений на уровне кластера), а действия определяют операции, которые пользователь может выполнять с данным ресурсом.
MongoDB предоставляет целый ряд встроенных ролей, которые служат хорошей отправной точкой. Вы можете ознакомиться с полным списком встроенных ролей здесь но наиболее распространенными являются:
read : позволяет read-only доступ к несистемным коллекциям в базе данных
readWrite : расширяет read-only роли возможностью изменения данных в несистемных коллекциях
userAdmin : предоставляет разрешения на управление пользователями и ролями
dbAdmin : позволяет выполнять административные действия с базой данных, такие как создание или удаление коллекций и индексов, но не включает доступ к чтению.
Эти роли доступны в каждой базе данных MongoDB и привязаны к конкретной базе данных.
Наконец, встроенная роль root обеспечивает полный доступ ко всем ресурсам и должна использоваться очень-очень редко (или лучше вообще никогда).
Давайте предоставим пользователю Элис, созданному выше, полный доступ к одной конкретной базе данных и позволим ей читать все остальное:
Роли пользователей
Иногда вам может потребоваться немного большей гибкости; например, для создания более детализированных ролей или расширения одной из встроенных ролей парой-тройкой дополнительных разрешений. Для подобных ситуаций MongoDB поддерживает определяемые пользователем роли.
Документ полномочий (privilege document) объединяет определение ресурса со списком действий:
Теперь давайте создадим роль для пользователя «metrics writer», которому разрешено вносить записи только в одну конкретную коллекцию. Кстати, ваша кастомная роль также может расширять существующую роль, чтобы унаследовать ее разрешения:
Пользовательские роли также могут накладывать ограничения аутентификации для подключающихся клиентов, проверяя, что IP клиента разрешен:
Это функция безопасности очень полезна в сочетании с правильной конфигурацией вашего файрвола, что позволит вам более гибко разделять клиентов в сети.
Реализуйте логирование доступа и жрунал запросов
Ведение подробного контрольного журнала является неотъемлемой частью усиления безопасности любой системы. К сожалению, MongoDB не предоставляет встроенного функционала логирования в своей версии с открытым исходным кодом.
Система логирования MongoDB является компонентной. В целях безопасности вас больше всего интересуют следующие компоненты:
network для отражения попыток подключения
accessControl для отражения информации аутентификации
Включите это в конфигурацию:
Журналы MongoDB представляют собой структурированные JSON-документы, поэтому вы также можете отправлять их во внешнюю систему, такую как Elasticsearch, для индексации и анализа с помощью таких инструментов, как Logstash.
Используйте Teleport для безопасного доступа
Teleport Database Access — это продукт с открытым исходным кодом, который реализует многие из лучших практик, обсуждаемых в этой статье, и может использоваться для безопасного доступа к вашим кластерам MongoDB.
В частности, Database Access был разработан с учетом следующих принципов безопасности:
Пользователи проходят аутентификацию с помощью вашего поставщика идентификации и подключаются к базе данных с помощью краткосрочных клиентских сертификатов.
Настраиваемые политики управления доступом на основе ролей позволяют сопоставлять пользователей вашего IdP с разрешенными пользователями MongoDB.
Все авторизации к базе данных и действия команд фиксируются в логе, который можно отправлять в сторонние SIEM-системы.
Начать работу с Database Access можно, изучив документацию и руководство для MongoDB.
Заключение
Простота использования MongoDB делает его популярным выбором среди команд любого размера, которым требуется какое-нибудь NoSQL решение, и привлекательной целью для злоумышленников.
В этой статье мы рассмотрели некоторые из лучших практик и методов усиления защиты кластера MongoDB, от защиты периметра сети до использования аутентификации и авторизации для управления доступом к базе данных.
Мы надеемся, что обсуждаемые темы помогут вам сделать ваши развертки MongoDB более защищенными.
Всех желающих приглашаем на demo-занятие «Map-reduce & Aggregation Framework». На занятии рассмотрим:
В результате вы научитесь строить сложные запросы и писать свои функции.
>> РЕГИСТРАЦИЯ