Встроенные методы аутентификации MongoDB

Ubuntu, VPS | Amber | Комментировать запись

MongoDB (или просто Mongo) – это документоориентированная система управления базами данных, которая используется для хранения информации во многих современных веб-приложениях. Крайне важно, чтобы лица, ответственные за управление базой данных Mongo (впрочем, это касается любой СУБД), придерживались передовых методов обеспечения безопасности – это позволяет избежать потери данных в случае аварии, предотвратить их попадание в руки злоумышленников и т.п.

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

Примечание: Другие мануалы этой серии вы найдете по тегу mongodb-security.

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

Аутентификация в MongoDB

MongoDB имеет несколько механизмов аутентификации пользователей. По умолчанию применяется механизм SCRAM (Salted Challenge Response Authentication Mechanism). SCRAM проверяет комбинацию учетных данных, представленных пользователем, и сравнивает ее с информацией об этом пользователе, которая известна этому экземпляру MongoDB. Если какие-либо учетные данные пользователя не соответствуют ожиданиям базы данных Mongo, механизм не аутентифицирует такого пользователя: он не получит доступ, пока не представит правильное имя пользователя, пароль и базу данных.

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

Для сред производства с поддержкой сегментирования или репликации, документация MongoDB рекомендует использовать другой механизм аутентификации – x.509. Этот механизм подразумевает распространение действительных сертификатов x.509 (либо самоподписанных, либо полученных от стороннего центра сертификации) между предполагаемыми членами кластера или клиентами. Такие сертификаты отличаются от ключевых файлов тем, что каждая машина получает свой собственный, индивидуальный выделенный сертификат x.509. Это значит, что сертификат одной машины будет полезен только для аутентификации этой машины. Злоумышленники не смогут предоставить серверу БД украденный сертификат x.509 и пройти аутентификацию.

В методе x.509 используется так называемая взаимная аутентификация: то есть когда клиент или член кластера аутентифицируется на сервере, сервер аналогичным образом аутентифицируется на соответствующем клиенте или члене кластера. Если клиент или член кластера попытается подключиться к серверу базы данных с невалидным сертификатом x.509, это будет невозможно, поскольку взаимная проверка подлинности завершится неудачно.

Авторизация в MongoDB

Для авторизации MongoDB использует механизм компьютерной безопасности, который называется «управление доступом на основе ролей». Всякий раз, когда вы создаете пользователя MongoDB, вы можете предоставить ему одну или несколько ролей. Именно роль определяет, какие привилегии имеет этот пользователь и какие действия он может выполнять в данной БД, коллекции, наборе коллекций или кластере. Присваивая пользователю какую-либо роль, вы передаете ему все привилегии этой роли.

MongoDB имеет ряд встроенных ролей, которые предоставляют часто используемые комбинации привилегий. Некоторые роли доступны для каждой БД, но большинство из них доступно только для базы данных admin, поскольку они открывают много административных привилегий. Например, роль readWrite вы можете присвоить пользователю в любой базе данных – тогда пользователь сможет читать и изменять данные, хранящиеся в соответствующей БД в вашей системе. Однако роль readWriteAnyDatabase, которая позволяет пользователю читать и изменять данные в любой базе данных, кроме local и config, доступна только в базе данных admin, поскольку она предоставляет более широкие системные привилегии.

Помимо встроенных ролей, Mongo также позволяет вам определять пользовательские роли, что дает вам еще больший контроль над тем, к каким ресурсам в вашей системе пользователи могут получить доступ. Как и пользователи, роли добавляются в определенную базу данных. За исключением ролей, созданных в базе данных admin, которые могут включать привилегии для любой БД в системе, привилегии пользовательских ролей применяются только к той базе данных, в которой эта роль была создана. С учетом сказанного, роль может включать в свое определение одну или несколько существующих ролей, а также может наследовать привилегии от других ролей в той же БД.

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

Читайте также: Защита MongoDB в Ubuntu