В каждом положении отыщется что-нибудь утешительное, если хорошо поискать (Д. Дефо).

Безопасность базы данных — как использовать шифрование для защиты данных MongoDB

Главное меню » Базы данных » Безопасность базы данных — как использовать шифрование для защиты данных MongoDB

20.01.2019

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

Поскольку MongoDB является нереляционной базой данных, нет необходимости определять столбцы перед вставкой данных; и поэтому документы в одной и той же коллекции могут иметь разные поля друг от друга.

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

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

Однако для СУБД NoSQL этот подход не будет лучшим вариантом. Учитывая, что не все документы могут иметь все поля, которые вы хотите использовать в своем шифровании, шифрование на уровне столбца не может быть выполнено.

Шифрование данных на уровне приложений довольно дорого и сложно реализовать. Поэтому мы остаемся с возможностью шифрования данных на уровне базы данных.

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

Шифрование данных в MongoDB

Любая операция с базой данных включает любую из этих двух форм данных: данные в покое или данные в движении.

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

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

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

Шифрование данных при передаче

Передача данных между MongoDB и серверным приложением осуществляется двумя способами: через безопасность транспортного уровня (TLS) и протокол защищенных сокетов (SSL).

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

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

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

Конфигурация TLS / SSL для клиентов

Существуют различные настройки параметров TLS / SSL, которые можно использовать при настройке этих протоколов.

Например, если вы хотите подключиться к экземпляру Mongod с использованием шифрования, вы должны запустить свой экземпляр следующим образом:

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

—ssl включает соединение TLS / SSL.
—sslCAFile указывает файл pem центра сертификации (CA) для проверки сертификата, представленного mongod или mongos. Следовательно, оболочка Mongo проверит сертификат, выданный экземпляром mongod, по указанному файлу CA и имени хоста.

Вы также можете подключить экземпляр MongoDB, для которого требуется сертификат клиента. Мы используем пример кода ниже

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

Опция —sslPEMKeyFile указывает файл .pem, который содержит сертификат оболочки mongo и ключ для представления экземпляру mongod или mongos. Во время процесса подключения:

Оболочка mongo проверит, получен ли сертификат от указанного центра сертификации (—sslCAFile), и если нет, оболочке не удастся подключиться.

Во-вторых, оболочка также проверит, соответствует ли имя хоста, указанное в параметре —host, SAN/CN в сертификате, представленном mongod или mongos. Если это имя хоста не совпадает ни с одним из двух, соединение не будет установлено.

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

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

Дополнительные параметры, которые можно использовать в соединениях:

requireSSL : это ограничит каждый сервер для использования только зашифрованных соединений TLS/SSL.

—sslAllowConnectionsWithoutCertificates : это разрешает проверку, если только клиент представляет сертификат, в противном случае, если клиент все еще будет подключен в зашифрованном режиме. Например:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols : эта опция запрещает серверам принимать входящие соединения, использующие определенные протоколы. Это можно сделать с помощью:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Шифрование данных в покое

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

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

Файлы всей базы данных шифруются с использованием прозрачного шифрования данных (TDE) на уровне хранилища.

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

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

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

Вращение ключей шифрования

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

KMIP — Мастер ротаций

В этом случае изменяется только главный ключ, поскольку он управляется извне. Процесс вращения ключа описан ниже.

1. Главный ключ для дополнительных элементов в наборе реплик поворачивается по одному. Т.е.
```
mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```
  После завершения процесса mongod завершит работу, и вам нужно будет перезапустить вторичное устройство без параметра kmipRotateMasterKey.
```
mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
	--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```
2. Первичный набор реплик отключается : с помощью метода rs.stepDown(), первичный деактивируется, что приводит к выбору нового первичного.
3. Проверьте состояние узлов, используя метод rs.status(), и, если основной указывает, что он был понижен, поверните его главный ключ. Перезапустите пошаговый элемент, включая параметр kmipRotateMasterKey .
```
mongod --enableEncryption --kmipRotateMasterKey \
--kmipServerName <KMIP Server HostName> \
--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```

Логирование

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

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

Начиная с версии 3.4 MongoDB, есть параметр security.redactClientLogData, который предотвращает запись потенциально конфиденциальных данных в журнал процесса mongod. Однако эта опция может усложнить диагностику журнала.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Просмотров поста: 55