Нравится нам это или нет, но нереляционные базы данных с открытым исходным кодом составляют значительную часть сложившейся экосистемы инструментов для хранения данных, повсеместно применяются как в небольших, так и крупных Web-проектах. Вполне вероятно, что кому-то из вас пришлось столкнуться с MongoDB в «продакшене». Умение обезопасить БД от внешних посягательств является необходимым для успешной экплуатации навыком. Об этом и многих других вопросах мы поговорим на PG Day'17 в секции открытых баз данных. Тем временем, мы рады представить вам перевод интересной обзорной публикации, посвященной безопасности MongoDB.
У MongoDB есть всё необходимое для сохранения ваших данных в целости. Мы расскажем о том, что именно может вам понадобиться и как это настраивать.
Безопасность MongoDB снова в новостях. Совсем недавно СМИ наводнили истории, рассказывающие о том, как хакеры захватывали базы данных MongoDB и требовали выкуп в биткойнах. Десятки тысяч инсталляций MongoDB были скомпрометированы, согласно Rapid7.
Все мы беспокоимся о безопасности. Если вы поддерживаете приложения, сети или базы данных, обеспечение безопасности всегда является первостепенной задачей. Поскольку многие компании переходят на программное обеспечение с открытым исходным кодом, такое как MongoDB, для хранения важных корпоративных данных, вопрос безопасности становится еще более актуальным. В зависимости от вашего бизнеса, у вас также могут быть различные государственные (такие как Закон о переносимости и подотчетности медицинского страхования, Health Insurance Portability and Accountability Act, HIPAA) или предпринимательские (Стандарт безопасности данных в индустрии платежных карт, или PCI DSS) стандарты сетевой безопасности, которым вы должны подчиняться.
Безопасно ли программное обеспечение для баз данных MongoDB? Соответствует ли оно этим стандартам? Короткий ответ: да, безопасно, и да, соответствует! Нужно просто знать, как настраивать, конфигурировать и работать с вашей конкретной инсталляцией.
В этой статье я расскажу о защищенности MongoDB. MongoDB безопасна в использовании, если вы знаете, что искать и как это настраивать.
Для начала давайте разберемся, какие ошибки люди допускают при работе с MongoDB с точки зрения безопасности. Есть несколько ключевых моментов, на которых пользователи спотыкаются, когда дело доходит до безопасности MongoDB:
У MongoDB есть пять основных зон безопасности:
Аутентификация LDAP
В MongoDB есть встроенные пользовательские роли, которые выключены по умолчанию. Однако в нем отсутствуют такие элементы, как сложность пароля, ротация по возрасту, а также централизация и идентификация пользовательских ролей с разным набором доступной функциональности. Это важно для прохождения нормативных проверок, таких как соответствие PCI DSS. К примеру, PCI DSS запрещает использовать старые и легко взламываемые пароли и требует изменения пользовательского доступа при каждом изменении статуса (например, когда пользователь покидает отдел или компанию).
К счастью, для заполнения большинства этих пробелов можно использовать LDAP. Многие коннекторы позволяют использовать Windows Active Directory (AD) для взаимодействия с LDAP.
MongoDB 3.2 хранит пользователей в LDAP, но не их роли (они сейчас хранятся на индивидуальных машинах). В MongoDB 3.4 Enterprise должна быть представлена возможность хранения ролей в LDAP для централизованного доступа. (Роли мы обсудим чуть позже).
Рис. 1. Шаги в аутентификации SASL (Simple Authentication and Security Layer).
Используя LDAP и AD, вы можете связать пользователей с вашей корпоративной директорией. Когда они меняют роль или покидают компанию, сотрудники отдела HR смогут удалить их из группы в вашей базе данных. Таким образом, у вас есть автоматизированная система, обеспечивающая уверенность в том, что только те, кому вы хотите предоставить доступ для работы с данными вручную, его получат, и ничего не будет случайно утеряно.
Работать с LDAP в Mongo довольно просто. В MongoDB есть специальная команда, которая говорит ей проверить внешнюю базу данных LDAP: $external.
Вот ещё пара предостережений по использованию LDAP:
Роли пользователей
Контроль доступа на основе ролей (RBAC) лежит в основе MongoDB. Встроенные роли были доступны, начиная с версии 2.6. Вы можете создать свои собственные роли, записав, какие именно действия разрешено выполнять конкретному пользователю. Эта функциональность заложена в ядре MongoDB, и она доступна практически в любой коммерческой версии программного обеспечения с открытым исходным кодом.
Пять основных встроенных ролей в MongoDB, которые вы должны знать:
Wildcard баз данных и коллекций
Wildcard означает предоставление доступа к большим группам баз данных или коллекций (или и того, и другого) на сервере. Поставив значение null, вы можете указать сразу все базы данных или коллекции, и избежать роли dbAdminAnyDatabase. Это позволяет избранным пользователям иметь все права, включая функции администратора.
Это опасно.
Используя wildcard, вы выдаете много особых прав и должны знать, что открываете следующие возможные пути для атаки:
Создание настраиваемой роли
Сила ролей в MongoDB заключается в возможности создания собственных ролей. В настраиваемой роли вы можете указать, что любое действие на любом ресурсе может быть задано для конкретного пользователя. При таком уровне детализации вы можете глубоко контролировать, кто что может делать в вашем окружении MongoDB.
Когда речь идет о задании настраиваемой роли, существует четыре различных типа ресурсов:
Любая роль может наследовать свойства другой роли. Есть массив под названием «роли», и вы можете добавить в него новую роль. Она унаследует свойства указанной роли.
Используйте createRole, чтобы добавить роль в массив.
Вы можете добавлять новые или существующие базы данных к пользователю или роли. Например, можно добавить доступ к базе данных на чтение и запись путём присоединения этой базы данных к роли.
Используйте команду grantPrivilegesToRole, чтобы добавить новые ресурсы к существующей роли.
Ниже представлен пример создания новой роли супер-пользователя. Повторюсь, эта роль необходима для того, чтобы в среде MongoDB был один пользователь без каких-либо ограничений (на случай возникновения непредвиденной ситуации).
Эти команды создают в базе данных geSiblingDB новую роль под названием superRoot и назначают этой роли любой ресурс и любое действие. Затем мы создаем в той же базе данных нового пользователя companyDBA (с паролем) и назначаем ему новую роль superRoot.
Использование SSL для всего
SSL помогает обеспечить безопасность ваших данных в незащищенных сетях. Если вы работаете с базой данных, которая взаимодействует с интернетом, нужно использовать SSL.
Существуют две очень веские причины использовать SSL для защиты MongoDB: конфиденциальность и аутентификация. Без SSL к вашим данным можно получить доступ, скопировать и использовать для незаконных или вредоносных целей. С аутентификацией у вас есть дополнительный уровень безопасности. Инфраструктура закрытого ключа SSL (PKI) гарантирует, что только пользователи с правильным сертификатом CA могут получить доступ к MongoDB.
Поддержка SSL существует в MongoDB уже довольно давно, но в последних версиях была существенно улучшена. Раньше, если вы хотели использовать SSL, вам нужно было скачать его и вручную скомпилировать с версией MongoDB Community. Начиная с версии MongoDB 3.0, SSL компилируется с программным обеспечением по умолчанию.
В устаревших версиях MongoDB также отсутствовала проверка корректности хоста; это был просто флаг, который вы могли проверить в файле конфигурации, удовлетворяющем запросу SSL из соединения.
Последние версии SSL в MongoDB включают следующие ключевые функции:
SSL: Использование настраиваемого CA
Новейшие версии SSL в MongoDB позволяют использовать собственные CA. Хотя это дает вам гибкость в определении того, как вы хотите работать с SSL, есть некоторые оговорки. Если вы просто пытаетесь защитить соединение, возможно, у вас может возникнуть соблазн выбрать sslAllowInvalidCertficates. Однако, как правило, это плохая идея по нескольким причинам:
Чтобы решить эту проблему, настройте net.ssl.CAFile, и MongoDB будет использовать и ключ, и файл CA (это необходимо сделать на клиенте).
Однако использование SSL имеет известный недостаток: производительность. При использовании SSL она точно снизится.
Шифрование диска
Данные находятся либо в состоянии “in transit”, либо “at rest.” Вы можете зашифровать одно из них или оба в MongoDB. Мы поговорили о шифровании данных in transit (SSL). Теперь посмотрим на данные at rest.
Данные at-rest — это данные, хранящиеся на диске. Шифрование таких данных обычно подразумевает их сохранение в зашифрованное хранилище. Это делается для предотвращения физической кражи, а также для создания резервных копий, хранящихся таким образом, что их непросто прочитать третьей стороне. Для этого существуют практические ограничения. Самое большое из них — доверие вашим системным администраторам и уверенность в том, что хакер не получил административный доступ к системе.
Эта проблема присуща не только MongoDB. Превентивные меры, используемые в других системах, работают и здесь. Они могут включать такие инструменты шифрования, как LUKS и cryptfs, или даже более безопасные методы, вроде подписания ключей шифрования с помощью LDAP, смарт-карт и токенов типа RSA.
При выполнении этого уровня шифрования вам необходимо учитывать такие факторы, как автоматическое разделение и дешифрование дисков. Но это не ново для ваших системных администраторов. Они могут управлять этим требованием так же, как в других частях вашей сети. Дополнительным преимуществом является единая процедура шифрования хранилища, а не по одной на каждую технологию, используемую конкретной функцией.
Шифрование данных at-rest может быть реализовано одним из следующих способов или всеми сразу:
Первый вариант можно реализовать с помощью шифрования диска в файловой системе. Его легко настроить с помощью LUKS и dm-crypt. Для соответствия стандартам PCI DSS и других сертификационных требований требуются только первый и второй варианты.
Аудит
В основе любой хорошей архитектуры системы безопасности лежит возможность отслеживать, какой пользователь какие действия выполнил в базе данных (аналогично тому, как вы должны управлять своими фактическими серверами). Аудит позволяет фильтровать выходные данные конкретного пользователя, базы данных, коллекции или исходной локации. Это создает журнал для проверки любых инцидентов в сфере безопасности. Еще важнее то, что он показывает любому аудитору безопасности, что вы предприняли правильные шаги для защиты вашей базы данных от вторжения и для понимания глубины любого вторжения, если это произойдет.
Аудит позволяет полностью отслеживать действия злоумышленника в вашей среде.
Кроме того, вы можете сделать так, чтобы изменения схемы происходили только при надлежащей проверке сотрудниками DBA, так как код разработчика может не сработать, если кто-то изменит формат того, что вы храните в базе данных. Это привносит дополнительный уровень контроля в динамическую производственную схему MongoDB (позволяя хранить что угодно, даже если в этом нет необходимости).
Управление
Управление связано с вставкой и обновлением данных. Это также полезно для проверки того, определено ли имя поля, вроде «bday», «birthday», «ssn» или «social». Проще говоря, управление — это способность внедрять сложные стандарты в систему MongoDB с помощью проверки документов (Document Validation).
Проверка документов позволяет определить, какие области документа являются допустимыми для конкретной коллекции. Вы можете установить параметры для поиска ключей и значений и убедиться, что они соответствуют предопределенным стандартам. Например, вы можете проверить, существует ли ключ, и является ли он правильным типом ключа.
Основными командами проверки документов являются:
Мы не ограничены определенными ключами и ключевыми значениями. Вы также можете использовать строки регулярных выражений. Используя регулярное выражение, можно запустить проверку для строк вроде номера кредитной карты: ^d{4}-d{4}-d{4}-d{4}$. С регулярными выражениями также можно проверить ID пользователя, дату рождения, номер социального страхования и т.д.
Это примеры того, как ваши администраторы баз данных и архитекторы безопасности могут помочь разработчикам не подвергать компанию дополнительному риску.
Сокращение площади атаки вашей сети
Уменьшение площади атаки вашей сети означает попытку контролировать все возможные уязвимости в оборудовании и программном обеспечении вашей сети, доступные для не прошедших аутентификацию пользователей.
Документация MongoDB предлагает вам разместить экземпляр монго на каждом хосте приложения. Это предложение, безусловно, справедливо для уменьшения задержки в среде вашей базы данных (путем ограничения сетевых скачков). Но, хотя это и хорошо для производительности, для безопасности это очень плохо.
Каждый экземпляр монго должен уметь обращаться к:
Можете себе представить, какой это кошмар для безопасности. С каждым экземпляром монго у вас есть еще x соединений, охватывающих вашу сеть. Это на x больше соединений, которые может использовать злоумышленник.
Вместо этого лучше иметь группу серверов MongoDB рядом с приложениями, которым вы позволяете обращаться к другим системам. Настройте балансировщик нагрузки (или что-то подобное) для приложения и разрешите приложениям обращаться только к серверам MongoDB. Это обеспечит разумную настройку типа DMZ, которая предотвратит открытие слишком большого количества соединений в сети.
Рис. 2. MongoDB, развернутый с балансировщиками нагрузки.
Настройки по умолчанию топят базы данных
Базы данных с открытым исходным кодом в целом и MongoDB в частности имеют все параметры безопасности, необходимые для обеспечения защиты ваших данных (без необходимости покупать корпоративную версию).
Знайте, как работает система безопасности в вашей базе данных с открытым исходным кодом. Сохранение настроек по умолчанию — верный путь к катастрофе. Понимая и решая приведенные выше вопросы, вы можете удовлетворить все ваши потребности в безопасности (включая соответствие нормативным требованиям безопасности) и защитить вашу компанию, используя разумные и хорошо известные методы.
Всем, для кого актуальны вопросы эксплуатации MongoDB и безопасности вашего проекта, рады представить несколько докладов с предстоящего PG Day'17: репликация в MongoDB от Henrik Ingo, хранилище MongRocks на основе LSM-Tree Дениса Противенского, безопасность на каждый день в Web-проектах Сергея Новикова и все, что разработчики хотели знать о безопасности баз данных, но боялись спросить Ильи Вербицкого. Присоединяйтесь!
У MongoDB есть всё необходимое для сохранения ваших данных в целости. Мы расскажем о том, что именно может вам понадобиться и как это настраивать.
Безопасность MongoDB снова в новостях. Совсем недавно СМИ наводнили истории, рассказывающие о том, как хакеры захватывали базы данных MongoDB и требовали выкуп в биткойнах. Десятки тысяч инсталляций MongoDB были скомпрометированы, согласно Rapid7.
Все мы беспокоимся о безопасности. Если вы поддерживаете приложения, сети или базы данных, обеспечение безопасности всегда является первостепенной задачей. Поскольку многие компании переходят на программное обеспечение с открытым исходным кодом, такое как MongoDB, для хранения важных корпоративных данных, вопрос безопасности становится еще более актуальным. В зависимости от вашего бизнеса, у вас также могут быть различные государственные (такие как Закон о переносимости и подотчетности медицинского страхования, Health Insurance Portability and Accountability Act, HIPAA) или предпринимательские (Стандарт безопасности данных в индустрии платежных карт, или PCI DSS) стандарты сетевой безопасности, которым вы должны подчиняться.
Безопасно ли программное обеспечение для баз данных MongoDB? Соответствует ли оно этим стандартам? Короткий ответ: да, безопасно, и да, соответствует! Нужно просто знать, как настраивать, конфигурировать и работать с вашей конкретной инсталляцией.
В этой статье я расскажу о защищенности MongoDB. MongoDB безопасна в использовании, если вы знаете, что искать и как это настраивать.
Для начала давайте разберемся, какие ошибки люди допускают при работе с MongoDB с точки зрения безопасности. Есть несколько ключевых моментов, на которых пользователи спотыкаются, когда дело доходит до безопасности MongoDB:
- используют порты, указанные по умолчанию;
- не включают аутентификацию сразу же (самая серьёзная проблема!);
- при использовании аутентификации дают широкий доступ всем и каждому;
- не используют LDAP для принудительной смены паролей;
- не настаивают на использовании SSL в базе данных;
- не ограничивают доступ к базе данных для известных устройств сети (хостов приложения, балансировщиков нагрузки и т.д.);
- не ограничивают то, на каких интерфейсах прослушиваются соединения (правда, этот пункт уже не влияет ни на одну из поддерживаемых версий).
У MongoDB есть пять основных зон безопасности:
- Аутентификация. Аутентификация LDAP централизует элементы в каталоге вашей компании.
- Авторизация. Авторизация определяет, какие права доступа предоставляет база данных в зависимости от роли пользователя.
- Шифрование. Шифрование можно разделить на At-Rest и In-Transit. Оно имеет решающее значение для обеспечения безопасности MongoDB.
- Аудит. Аудит подразумевает возможность видеть, кто что сделал в базе данных.
- Управление. Управление подразумевает проверку документов и конфиденциальных данных (таких как номер счета, пароль, номер социального страхования или дата рождения). Это касается как знания того, где хранятся конфиденциальные данные, так и предотвращения их ввода в систему.
Аутентификация LDAP
В MongoDB есть встроенные пользовательские роли, которые выключены по умолчанию. Однако в нем отсутствуют такие элементы, как сложность пароля, ротация по возрасту, а также централизация и идентификация пользовательских ролей с разным набором доступной функциональности. Это важно для прохождения нормативных проверок, таких как соответствие PCI DSS. К примеру, PCI DSS запрещает использовать старые и легко взламываемые пароли и требует изменения пользовательского доступа при каждом изменении статуса (например, когда пользователь покидает отдел или компанию).
К счастью, для заполнения большинства этих пробелов можно использовать LDAP. Многие коннекторы позволяют использовать Windows Active Directory (AD) для взаимодействия с LDAP.
Примечание: поддержка LDAP доступна только в MongoDB Enterprise. Её нет в версии Community. Но она имеется в других open source версиях MongoDB, таких как Percona Server для MongoDB.
MongoDB 3.2 хранит пользователей в LDAP, но не их роли (они сейчас хранятся на индивидуальных машинах). В MongoDB 3.4 Enterprise должна быть представлена возможность хранения ролей в LDAP для централизованного доступа. (Роли мы обсудим чуть позже).
Рис. 1. Шаги в аутентификации SASL (Simple Authentication and Security Layer).
Используя LDAP и AD, вы можете связать пользователей с вашей корпоративной директорией. Когда они меняют роль или покидают компанию, сотрудники отдела HR смогут удалить их из группы в вашей базе данных. Таким образом, у вас есть автоматизированная система, обеспечивающая уверенность в том, что только те, кому вы хотите предоставить доступ для работы с данными вручную, его получат, и ничего не будет случайно утеряно.
Работать с LDAP в Mongo довольно просто. В MongoDB есть специальная команда, которая говорит ей проверить внешнюю базу данных LDAP: $external.
Вот ещё пара предостережений по использованию LDAP:
- Создавайте пользователя с помощью .createUser, как обычно, но обязательно добавьте теги ресурсов db/collection.
- Кроме того, для аутентификации LDAP требуются еще два поля:
- mechanism: “PLAIN”
- digestPassword: false
Роли пользователей
Контроль доступа на основе ролей (RBAC) лежит в основе MongoDB. Встроенные роли были доступны, начиная с версии 2.6. Вы можете создать свои собственные роли, записав, какие именно действия разрешено выполнять конкретному пользователю. Эта функциональность заложена в ядре MongoDB, и она доступна практически в любой коммерческой версии программного обеспечения с открытым исходным кодом.
Пять основных встроенных ролей в MongoDB, которые вы должны знать:
- read:
- доступ в режиме чтения, обычно даётся большинству пользователей;
- readWrite:
- доступ readWrite позволяет редактировать данные;
- readWrite включает права read;
- dbOwner:
- Включает readWrite, dbAdmin, userAdmin (для базы данных). userAdmin подразумевает добавление и удаление пользователей, выдачу прав пользователям и создание ролей. Эти права назначаются только одному конкретному серверу базы данных;
- dbAdminAnyDatabase:
- создает dbAdmin на все базы данных, но не позволяет администрировать пользователей (например, создавать их и удалять). Вы можете создавать индексы, вызывать процедуры сжатия данных и многое другое. Раздельный доступ здесь не предоставляется;
- root:
- это суперпользователь, но с ограничениями;
- он может выполнять большинство действий, но не все:
- не может изменить системную коллекцию;
- некоторые команды этой роли недоступны в зависимости от версии. Например, роль root в MongoDB 3.2 не позволяет менять oplog или размер профайлера, а в MongoDB 3.4 — читать текущие views.
Wildcard баз данных и коллекций
Wildcard означает предоставление доступа к большим группам баз данных или коллекций (или и того, и другого) на сервере. Поставив значение null, вы можете указать сразу все базы данных или коллекции, и избежать роли dbAdminAnyDatabase. Это позволяет избранным пользователям иметь все права, включая функции администратора.
Это опасно.
Используя wildcard, вы выдаете много особых прав и должны знать, что открываете следующие возможные пути для атаки:
- права readWriteAnyDatabase очень обширны и открывают имена пользователей и их роли для потенциальной атаки через пользователя приложения;
- использование шаблона означает, что вы не ограничиваете конкретные приложения конкретными базами данных;
- wildcard не дают вам использовать мультитенантность при множестве баз данных;
- доступ к новым базам данных не выдается автоматически.
Создание настраиваемой роли
Сила ролей в MongoDB заключается в возможности создания собственных ролей. В настраиваемой роли вы можете указать, что любое действие на любом ресурсе может быть задано для конкретного пользователя. При таком уровне детализации вы можете глубоко контролировать, кто что может делать в вашем окружении MongoDB.
Когда речь идет о задании настраиваемой роли, существует четыре различных типа ресурсов:
- db. Указывает базу данных. Вы можете использовать строку для имени или “” для “any” (никаких шаблонов).
- collection. Указывает набор документов. Вы можете использовать строку для имени или “” для “any” (никаких шаблонов).
- cluster. Указывает шардированный кластер или другие источники метаданных. Является булевым значением true/false.
- anyResource. Означает доступ ко всему, везде. Является булевым значением true/false.
Любая роль может наследовать свойства другой роли. Есть массив под названием «роли», и вы можете добавить в него новую роль. Она унаследует свойства указанной роли.
Используйте createRole, чтобы добавить роль в массив.
Вы можете добавлять новые или существующие базы данных к пользователю или роли. Например, можно добавить доступ к базе данных на чтение и запись путём присоединения этой базы данных к роли.
Используйте команду grantPrivilegesToRole, чтобы добавить новые ресурсы к существующей роли.
Ниже представлен пример создания новой роли супер-пользователя. Повторюсь, эта роль необходима для того, чтобы в среде MongoDB был один пользователь без каких-либо ограничений (на случай возникновения непредвиденной ситуации).
db = db.geSiblingDB(“admin”);
db.createRole({
role: “superRoot”,
privileges:[{
resource: {anyResource:true},
actions: [‘anyAction’]
}]
roles:[]
});
db.createUser({
user: “comanyDBA”,
pwd: “EWqeeFpUt9*8zq”,
roles: [“superRoot”]
})Эти команды создают в базе данных geSiblingDB новую роль под названием superRoot и назначают этой роли любой ресурс и любое действие. Затем мы создаем в той же базе данных нового пользователя companyDBA (с паролем) и назначаем ему новую роль superRoot.
Использование SSL для всего
SSL помогает обеспечить безопасность ваших данных в незащищенных сетях. Если вы работаете с базой данных, которая взаимодействует с интернетом, нужно использовать SSL.
Существуют две очень веские причины использовать SSL для защиты MongoDB: конфиденциальность и аутентификация. Без SSL к вашим данным можно получить доступ, скопировать и использовать для незаконных или вредоносных целей. С аутентификацией у вас есть дополнительный уровень безопасности. Инфраструктура закрытого ключа SSL (PKI) гарантирует, что только пользователи с правильным сертификатом CA могут получить доступ к MongoDB.
Поддержка SSL существует в MongoDB уже довольно давно, но в последних версиях была существенно улучшена. Раньше, если вы хотели использовать SSL, вам нужно было скачать его и вручную скомпилировать с версией MongoDB Community. Начиная с версии MongoDB 3.0, SSL компилируется с программным обеспечением по умолчанию.
В устаревших версиях MongoDB также отсутствовала проверка корректности хоста; это был просто флаг, который вы могли проверить в файле конфигурации, удовлетворяющем запросу SSL из соединения.
Последние версии SSL в MongoDB включают следующие ключевые функции:
- проверка корректности хоста (факультативно);
- возможность указать конкретный setup .key для использования;
- Custom Certificate Authority (CA) для самоподписанных сертификатов и альтернативных подписчиков;
- режимы allowSSL, preferSSL, requireSSL, которые позволяют выбирать детализацию для вашего использования SSL (от менее безопасной до более безопасной).
SSL: Использование настраиваемого CA
Новейшие версии SSL в MongoDB позволяют использовать собственные CA. Хотя это дает вам гибкость в определении того, как вы хотите работать с SSL, есть некоторые оговорки. Если вы просто пытаетесь защитить соединение, возможно, у вас может возникнуть соблазн выбрать sslAllowInvalidCertficates. Однако, как правило, это плохая идея по нескольким причинам:
- позволяет соединение даже если сертификаты отозваны или у них истек срок действия;
- вы не обеспечиваете ограничения по определенному имени хоста;
- вы вовсе не так защищены, как думаете.
Чтобы решить эту проблему, настройте net.ssl.CAFile, и MongoDB будет использовать и ключ, и файл CA (это необходимо сделать на клиенте).
Однако использование SSL имеет известный недостаток: производительность. При использовании SSL она точно снизится.
Шифрование диска
Данные находятся либо в состоянии “in transit”, либо “at rest.” Вы можете зашифровать одно из них или оба в MongoDB. Мы поговорили о шифровании данных in transit (SSL). Теперь посмотрим на данные at rest.
Данные at-rest — это данные, хранящиеся на диске. Шифрование таких данных обычно подразумевает их сохранение в зашифрованное хранилище. Это делается для предотвращения физической кражи, а также для создания резервных копий, хранящихся таким образом, что их непросто прочитать третьей стороне. Для этого существуют практические ограничения. Самое большое из них — доверие вашим системным администраторам и уверенность в том, что хакер не получил административный доступ к системе.
Эта проблема присуща не только MongoDB. Превентивные меры, используемые в других системах, работают и здесь. Они могут включать такие инструменты шифрования, как LUKS и cryptfs, или даже более безопасные методы, вроде подписания ключей шифрования с помощью LDAP, смарт-карт и токенов типа RSA.
При выполнении этого уровня шифрования вам необходимо учитывать такие факторы, как автоматическое разделение и дешифрование дисков. Но это не ново для ваших системных администраторов. Они могут управлять этим требованием так же, как в других частях вашей сети. Дополнительным преимуществом является единая процедура шифрования хранилища, а не по одной на каждую технологию, используемую конкретной функцией.
Шифрование данных at-rest может быть реализовано одним из следующих способов или всеми сразу:
- зашифровать весь диск;
- зашифровать только файлы базы данных;
- зашифровать в приложении.
Первый вариант можно реализовать с помощью шифрования диска в файловой системе. Его легко настроить с помощью LUKS и dm-crypt. Для соответствия стандартам PCI DSS и других сертификационных требований требуются только первый и второй варианты.
Аудит
В основе любой хорошей архитектуры системы безопасности лежит возможность отслеживать, какой пользователь какие действия выполнил в базе данных (аналогично тому, как вы должны управлять своими фактическими серверами). Аудит позволяет фильтровать выходные данные конкретного пользователя, базы данных, коллекции или исходной локации. Это создает журнал для проверки любых инцидентов в сфере безопасности. Еще важнее то, что он показывает любому аудитору безопасности, что вы предприняли правильные шаги для защиты вашей базы данных от вторжения и для понимания глубины любого вторжения, если это произойдет.
Аудит позволяет полностью отслеживать действия злоумышленника в вашей среде.
Примечание: Аудит доступен только в MongoDB Enterprise. Его нет в версии Community. Но он имеется в других open source версиях MongoDB, таких как Percona Server для MongoDB.
Кроме того, вы можете сделать так, чтобы изменения схемы происходили только при надлежащей проверке сотрудниками DBA, так как код разработчика может не сработать, если кто-то изменит формат того, что вы храните в базе данных. Это привносит дополнительный уровень контроля в динамическую производственную схему MongoDB (позволяя хранить что угодно, даже если в этом нет необходимости).
Управление
Управление связано с вставкой и обновлением данных. Это также полезно для проверки того, определено ли имя поля, вроде «bday», «birthday», «ssn» или «social». Проще говоря, управление — это способность внедрять сложные стандарты в систему MongoDB с помощью проверки документов (Document Validation).
Проверка документов позволяет определить, какие области документа являются допустимыми для конкретной коллекции. Вы можете установить параметры для поиска ключей и значений и убедиться, что они соответствуют предопределенным стандартам. Например, вы можете проверить, существует ли ключ, и является ли он правильным типом ключа.
Основными командами проверки документов являются:
- collMod. Определяет ключ для проверки.
- validator. Определяет параметры для проверки.
- validationLevel. Устанавливает строгость валидатора (как часто он включается и насколько серьезные действия выполняет в зависимости от validationAction).
- validationAction. Устанавливает порядок действий, когда что-либо не проходит проверку.
Мы не ограничены определенными ключами и ключевыми значениями. Вы также можете использовать строки регулярных выражений. Используя регулярное выражение, можно запустить проверку для строк вроде номера кредитной карты: ^d{4}-d{4}-d{4}-d{4}$. С регулярными выражениями также можно проверить ID пользователя, дату рождения, номер социального страхования и т.д.
Это примеры того, как ваши администраторы баз данных и архитекторы безопасности могут помочь разработчикам не подвергать компанию дополнительному риску.
Сокращение площади атаки вашей сети
Уменьшение площади атаки вашей сети означает попытку контролировать все возможные уязвимости в оборудовании и программном обеспечении вашей сети, доступные для не прошедших аутентификацию пользователей.
Документация MongoDB предлагает вам разместить экземпляр монго на каждом хосте приложения. Это предложение, безусловно, справедливо для уменьшения задержки в среде вашей базы данных (путем ограничения сетевых скачков). Но, хотя это и хорошо для производительности, для безопасности это очень плохо.
Каждый экземпляр монго должен уметь обращаться к:
- каждому первичному узлу;
- каждому вторичному узлу;
- каждому конфигурационному серверу.
Можете себе представить, какой это кошмар для безопасности. С каждым экземпляром монго у вас есть еще x соединений, охватывающих вашу сеть. Это на x больше соединений, которые может использовать злоумышленник.
Вместо этого лучше иметь группу серверов MongoDB рядом с приложениями, которым вы позволяете обращаться к другим системам. Настройте балансировщик нагрузки (или что-то подобное) для приложения и разрешите приложениям обращаться только к серверам MongoDB. Это обеспечит разумную настройку типа DMZ, которая предотвратит открытие слишком большого количества соединений в сети.
Рис. 2. MongoDB, развернутый с балансировщиками нагрузки.
Настройки по умолчанию топят базы данных
Базы данных с открытым исходным кодом в целом и MongoDB в частности имеют все параметры безопасности, необходимые для обеспечения защиты ваших данных (без необходимости покупать корпоративную версию).
Знайте, как работает система безопасности в вашей базе данных с открытым исходным кодом. Сохранение настроек по умолчанию — верный путь к катастрофе. Понимая и решая приведенные выше вопросы, вы можете удовлетворить все ваши потребности в безопасности (включая соответствие нормативным требованиям безопасности) и защитить вашу компанию, используя разумные и хорошо известные методы.
Всем, для кого актуальны вопросы эксплуатации MongoDB и безопасности вашего проекта, рады представить несколько докладов с предстоящего PG Day'17: репликация в MongoDB от Henrik Ingo, хранилище MongRocks на основе LSM-Tree Дениса Противенского, безопасность на каждый день в Web-проектах Сергея Новикова и все, что разработчики хотели знать о безопасности баз данных, но боялись спросить Ильи Вербицкого. Присоединяйтесь!