Как сделать безопасный сервер MongoDB?

Я хочу, чтобы мой сайт использовал MongoDB в качестве хранилища данных. Я использовал MongoDB в своей среде разработки без каких-либо проблем, но я беспокоюсь о безопасности на публичном сервере. Мой сервер — это VPS под управлением Arch Linux. На нем также будет работать веб-приложение, поэтому он должен принимать соединения только от localhost. И никакие другие пользователи (по ssh или иным способом) не будут иметь прямой доступ к моему серверу.
Что я должен сделать для защиты моего экземпляра MongoDB?

Ответ 1

Вот оптимальный контрольный список

1. Включить авторизацию—даже если вы развернули свои серверы Mongodb в доверенной сети, включение авторизации является хорошей практикой безопасности. Это обеспечит вам «защиту в глубину», если ваша сеть будет скомпрометирована. Отредактируйте конфигурационный файл mongod, чтобы включить авторизацию.

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

3. Используйте брандмауэры—используйте брандмауэры для ограничения подключений к вашему серверу mongodb других организаций. Лучше всего разрешить доступ к базе данных только серверам приложений. Если вы размещаетесь на AWS, используйте «Группы безопасности» для ограничения доступа. Если вы размещаетесь у провайдера, который не поддерживает конструкции брандмауэра, вы можете легко настроить его самостоятельно с помощью «iptables». Обратитесь к документации mongodb, чтобы настроить iptables для вашего сценария.

4. Использовать ключевые файлы для настройки набора реплик—укажите общий ключевой файл для обеспечения связи между экземплярами mongodb в наборе реплик. Для этого добавьте параметр keyfile в конфигурационный файл. Содержимое файла должно быть одинаковым на всех машинах.

5. Отключить HTTP интерфейс статуса Mongodb, который  предоставляет интерфейс, запущенный по умолчанию на порту 28017, который является «домашней» страницей статуса базы данных. Этот интерфейс не рекомендуется для производственного использования, и его лучше отключить. Используйте параметр конфигурации «nohttpinterface», чтобы отключить http-интерфейс.

6. Отключите REST-интерфейс— REST-интерфейс monogdb не рекомендуется использовать в производстве. Он не поддерживает никакой аутентификации. По умолчанию он выключен. Если вы включили его с помощью опции конфигурации «rest», вам следует отключить его для производственных систем.

7. Настройка Bind_ip — если ваша система имеет несколько сетевых интерфейсов, вы можете использовать опцию «bind_ip», чтобы ограничить сервер mongodb прослушиванием только тех интерфейсов, которые имеют значение. По умолчанию mongodb будет подключаться ко всем интерфейсам.

8. Включить SSL—если вы не используете SSL, ваши данные будут передаваться между клиентом Mongo и сервером Mongo в незашифрованном виде и будут подвержены подслушиванию, фальсификации и атакам «человек посередине». Это особенно важно, если вы подключаетесь к серверу Mongodb через незащищенные сети, такие как Интернет.

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

10. Enterprise mongodb & Kerberos Enterprise— mongodb интегрируется с Kerberos для аутентификации. Более подробная информация приведена в документации по mongodb. Системы/имя пользователя/пароль по своей сути небезопасны — используйте аутентификацию на основе Kerberos, если это возможно.

Ответ 2

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

FireCamp автоматизирует это для вас в облаке, таком как AWS. FireCamp обеспечивает безопасность. 

1. AppAccessSecurityGroup является единственной группой, которой разрешен доступ к MongoDB. Пожалуйста, создайте узел приложения на AppAccessSecurityGroup, а также VPC, на котором работает узел MongoDB. 

2. Создается узел Bastion, и только он может подключаться по SSH к узлам MongoDB. 

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

Ответ 3

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

На сайте Mongodb.org есть базовая информация. Все шаги, описанные здесь, должны быть выполнены, включая параметры безопасности. На самом сайте указано, что MongoDB имеет только очень базовый уровень безопасности. http://www.mongodb.org/display/DOCS/Security+и+аутентификация

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

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

Принципы усиления базы данных:

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

2. Авторизация — минимальное количество необходимых учетных записей с минимальными необходимыми разрешениями, поддерживаются учетные записи только для чтения, поэтому используйте их. Поскольку гранулярный контроль доступа не существует, используйте альтернативные средства, например, веб-сервис перед базой данных, который содержит бизнес-логику, включая правила контроля доступа, или внутри приложения. Минимизируйте разрешения, с которыми Mongodb запускается на платформе, например, он не должен запускаться от имени root.

3. Учетные записи по умолчанию и системные учетные записи — измените пароли всех учетных записей по умолчанию, удалите/заблокируйте/отключите все, что можно, отключите вход, где можно.

4. Ведение журналов и мониторинг — включите ведение журналов и экспортируйте их в центральную систему мониторинга. Определите конкретные предупреждения и процедуры расследования для сотрудников службы мониторинга.

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

6. Шифрование — в зависимости от чувствительности данных, поскольку вы не можете шифровать на уровне базы данных, необходимо шифрование или хеширование любых чувствительных данных на прикладном уровне. Транспортное шифрование также через сетевой уровень (например, VPN).

7. Минимизируйте службы и измените порт прослушивания по умолчанию.

8. Удалите все образцы или тестовые базы данных.

9. Внедрите процесс управления исправлениями для своевременного выявления, оценки и установки всех соответствующих исправлений безопасности.

10. Обеспечьте защиту платформы и платформы виртуализации, если она используется.

11. Настройте соответствующие средства сетевого контроля, например, брандмауэры, виртуальные локальные сети для минимизации доступа к базе данных, службу фильтрации отказов в обслуживании, полностью квалифицированный DNS, разделите производственные и непроизводственные базы данных.

Ответ 4

Несколько самых необходимых вещей, которые нужно запомнить:

1. Удалите привязку IP со всех до только IP (private или localhost), с которого вы ожидаете получить запрос на подключение.

2. Измените привязку портов по умолчанию.

3. Дайте только необходимые разрешения (например, не давать разрешения на обновление/удаление для выбранных пользователей запросов).

4. Настройте ssh-ключи для требуемого соединения ведущий-ведомый, устраняя необходимость в паролях.

5. Вы даже можете настроить зашифрованный туннель для соединения между вашим приложением и mongodb.

Фактически они применимы ко всем службам хранения данных.