Общие сведения о безопасности базы данных в Azure Cosmos DB для виртуальных ядер MongoDB
Область применения: 
Виртуальные ядра MongoDB
В этой статье рассматриваются рекомендации по обеспечению безопасности базы данных и ключевые функции, предлагаемые Azure Cosmos DB для виртуальных ядер MongoDB, которые помогают предотвратить, обнаруживать и реагировать на нарушения базы данных.
Новые возможности безопасности виртуальных ядер в Azure Cosmos DB для MongoDB
Шифрование неактивных данных теперь доступно для документов и резервных копий, хранящихся в Azure Cosmos DB для виртуальных ядер MongoDB в большинстве регионов Azure. Шифрование неактивных данных применяется в этих регионах автоматически как для новых, так и для существующих клиентов. Нет необходимости настраивать ничего. Вы получаете такую же большую задержку, пропускную способность, доступность и функциональность, как и раньше, с помощью знания о том, что данные безопасны и безопасны при хранении. Данные, хранящиеся в кластере виртуальных ядер Azure Cosmos DB для MongoDB, автоматически шифруются с помощью ключей, управляемых корпорацией Майкрософт, с помощью ключей, управляемых службой.
Как защитить свою базу данных
Ответственность за безопасность данных лежит как на клиенте, так и на поставщике базы данных. В зависимости от выбранного поставщика базы данных доля ответственности клиента может меняться. Если выбрать локальное решение, то клиент должен предоставить все — от защиты конечной точки до физической безопасности оборудования, а это непростая задача. Если выбрать поставщик облачной базы данных PaaS, например Azure Cosmos DB, то обязанности клиента значительно сокращаются. На следующем рисунке, взятом из технического документа корпорации Майкрософт Shared Responsibilities for Cloud Computing (Разделяемые обязанности в облачных вычислениях), показано, как с применением поставщика PaaS, такого как Azure Cosmos DB, сокращается ответственность клиента.
На предыдущей схеме видны высокоуровневые компоненты безопасности в облаке, но о каких элементах необходимо позаботиться конкретно для решения вашей базы данных? И как сравнить решения между собой?
Мы рекомендуем сравнить системы баз данных с помощью следующего контрольного списка требований:
- Параметры безопасности сети и брандмауэра
- Аутентификация пользователей и детальные пользовательские элементы управления
- Возможность глобальной репликации данных в случае регионального сбоя
- Возможность переключения из одного центра обработки данных в другой при отработке отказа
- Репликация локальных данных в рамках центра обработки данных
- Автоматическая архивация данных
- Восстановление удаленных данных из архива
- Защита и изолирование конфиденциальных данных
- Мониторинг атак
- Реагирование на атаки
- Возможность защитить данные в пределах геозоны в соответствии с ограничениями, установленными для управления данными
- Физическая защита серверов в защищенных центрах обработки данных
- Сертификация
И хотя это может показаться очевидным, но последние крупномасштабные нарушения в работе баз данных напоминают нам о простых, но критических важных требованиях, которые необходимо выполнять:
- На серверах устанавливаются исправления и поддерживается актуальность их ПО
- HTTPS по умолчанию/шифрование TLS
- Административные учетные записи с надежными паролями
Каким образом Azure Cosmos DB обеспечивает защиту базы данных
Azure Cosmos DB для виртуальных ядер MongoDB легко выполняет все требования к безопасности.
Рассмотрим каждое из них подробнее.
| Требование по безопасности | Подход к обеспечению безопасности Azure Cosmos DB |
|---|---|
| Безопасность сети | Частный доступ, реализованный через зрелую технологию Приватный канал, позволяет предоставлять доступ к кластеру для ресурсов в виртуальных сетям Azure. Общедоступный доступ позволяет открывать кластер для определенного набора общедоступных IP-адресов. Частный и общедоступный доступ можно объединить и включить или отключить в любое время. Конфигурация по умолчанию: кластеры виртуальных ядер Azure Cosmos DB для MongoDB создаются по умолчанию. Чтобы предоставить доступ к кластеру, параметры сети следует обновить, чтобы включить частный и /или общедоступный доступ к кластеру во время создания кластера или после него. Частный доступ: с включенным частным доступом частную конечную точку можно создать для доступа к частному кластеру из виртуальной сети Azure. Частная конечная точка создается в указанной подсети виртуальной сети. После этого все возможности виртуальной сети Azure доступны кластеру, включая пиринг локальных и глобальных виртуальных сетей, доступ к частным локальным средам, фильтрацию и маршрутизацию сетевого трафика и т. д. Общедоступный доступ. Использование брандмауэра IP является первым уровнем защиты для защиты базы данных. Azure Cosmos DB для виртуальных ядер MongoDB поддерживает управление доступом на основе политик для поддержки входящего брандмауэра. Управление доступом на основе IP-адресов аналогично правилам брандмауэра, используемым традиционными системами баз данных. Однако они расширяются, чтобы кластер Виртуальных ядер Azure Cosmos DB для MongoDB был доступен только из утвержденного набора компьютеров или облачных служб. Все запросы, исходящие от компьютеров за пределами этого разрешенного списка, блокируются Azure Cosmos DB для виртуальных ядер MongoDB. Затем запросы из утвержденных компьютеров и облачных служб должны пройти процесс аутентификации, чтобы получить право на контроль доступа к ресурсам. |
| Локальная репликация | Даже в одном регионе Azure Cosmos DB для виртуальных ядер MongoDB реплицирует данные на уровне хранилища, поддерживая 3 синхронные реплики каждого физического сегмента прозрачно. Кластеры с поддержкой высокой доступности имеют еще один уровень репликации между каждой первичной и резервной парой физических сегментов. Репликация высокого уровня доступности синхронна и обеспечивает отработку отказа нулевой потери данных при отработках отказа, что гарантирует 99,99 % ежемесячного уровня обслуживания доступности для установки одного региона. |
| Глобальная репликация | Azure Cosmos DB для виртуальных ядер MongoDB предлагает репликацию между регионами, которая позволяет реплицировать данные в другой регион Azure. Глобальная репликация позволяет осуществлять глобальное масштабирование, обеспечивая низкую задержку при обращении к данным по всему миру. В контексте безопасности глобальная репликация обеспечивает защиту данных от редких региональных сбоев. При использовании кластера реплики между регионами копия данных всегда присутствует в другом регионе. Реплика в другом регионе, объединенном с высоким уровнем доступности, обеспечивает 99,995 % ежемесячного обслуживания обслуживания для настройки нескольких регионов. |
| Изоляция базы данных | Базы данных виртуальных ядер Azure Cosmos DB для MongoDB размещаются на собственных выделенных ресурсах. Это означает, что каждый кластер получает собственный выделенный узел, называемый физическим сегментом или несколькими в конфигурации с несколькими сегментами. Каждый физический сегмент имеет собственные вычислительные ресурсы и удаленное хранилище, подключенное к нему. Нет общего доступа к инфраструктуре между кластерами, обеспечивая дополнительный уровень физической и логической изоляции для базы данных. |
| Автоматическое резервное копирование кластера | Резервное копирование для кластеров виртуальных ядер MongoDB для Azure Cosmos DB включено во время создания кластера, полностью автоматизировано и не может быть отключено. Восстановление предоставляется для любой метки времени в течение 35-дневного периода хранения резервных копий. |
| Восстановление удаленных данных | Автоматические резервные копии в сети можно использовать для восстановления данных из кластера, которые могут быть случайно удалены до 7 дней после события. |
| Шифрование HTTPS, SSL и TLS | Все сетевые связи с кластерами виртуальных ядер Azure Cosmos DB для MongoDB шифруются. Принимаются только подключения через клиент MongoDB, и шифрование всегда применяется. Когда данные записываются в Azure Cosmos DB для виртуальных ядер MongoDB, данные шифруются во время передачи. Шифрование данных поддерживает уровни TLS до 1,3 (включено). |
| Шифрование при хранении | Данные виртуальных ядер Azure Cosmos DB для MongoDB, включая все резервные копии, шифруются на диске, включая временные файлы. Служба использует 256-разрядный шифр AES, доступный при шифровании службы хранилища Azure. Ключами управляет система. Шифрование хранилища всегда включено, и его нельзя отключить. |
| Мониторинг атак | С помощью журналов аудита и журналов действий можно отслеживать базу данных для нормальной и аномальной активности. Вы можете просмотреть, какие операции были выполнены в ресурсах. Эти данные включают, кто инициировал операцию, когда произошла операция, состояние операции и многое другое. |
| Реагирование на атаки | После того как вы связались с поддержка Azure сообщить о потенциальной атаке, запускается пятишаговый процесс реагирования на инциденты. Целью пятишагового процесса является восстановление нормальной безопасности и операций службы. Пятишаговый процесс восстанавливает службы как можно быстрее после обнаружения проблемы и запуска исследования. Дополнительные сведения см. в разделе "Общая ответственность" в облаке. |
| Защищенное оборудование | Данные в Azure Cosmos DB для виртуальных ядер MongoDB хранятся в защищенных центрах обработки данных Azure. Дополнительные сведения о глобальных центрах обработки данных корпорации Майкрософт см. на этой странице. |
| Установка исправлений на серверы | Azure Cosmos DB для виртуальных ядер MongoDB устраняет необходимость управления обновлениями программного обеспечения и кластерами исправлений, которые выполняются автоматически. |
| Административные учетные записи с надежными паролями | Трудно поверить, что нам даже нужно упомянуть это требование, но в отличие от некоторых наших конкурентов, невозможно иметь административную учетную запись без пароля в Azure Cosmos DB для виртуальных ядер MongoDB. Пароль должен иметь по крайней мере 8 символов, включать в себя буквы верхнего и нижнего регистра, цифры и не буквенно-цифровые символы. Безопасность с помощью проверки подлинности на основе секрета TLS по умолчанию выполняется. |
| Вторичные учетные записи | Для более детального доступа к дополнительным учетным записям пользователей можно создавать в кластерах с правами только для чтения или чтения в базах данных кластера. |
| Сертификаты безопасности и защиты данных | Самый актуальный список сертификатов см. в документации по соответствию Azure и последнему документу о соответствии Azure со всеми сертификациями Azure, включая Azure Cosmos DB. |
На следующем снимке экрана показано, как использовать журналы аудита и журналы действий для мониторинга учетной записи: 
Параметры сетевой безопасности
В этом разделе описаны различные параметры безопасности сети, которые можно настроить для кластера. В кластере можно объединить параметры общедоступного и закрытого доступа. Параметры конфигурации сети можно изменить в любое время.
Нет доступа
Доступ не является параметром по умолчанию для только что созданного кластера, если правила брандмауэра или частные конечные точки не были созданы во время подготовки кластера для общедоступного или закрытого доступа соответственно. В этом случае компьютеры, находящиеся внутри или за пределами Azure, не могут подключаться к узлам базы данных.
Общедоступный IP-доступ с брандмауэром
В параметре общедоступного доступа общедоступный IP-адрес назначается кластеру, а доступ к кластеру защищен брандмауэром. Если общедоступный IP-адрес не указан в одном из правил брандмауэра в кластере, запросы от этого IP-адреса отклоняются брандмауэром и не достигают базы данных.
Закрытый доступ
В параметре закрытого доступа для кластера создается частная конечная точка. Эта частная конечная точка связана с виртуальной сетью Azure и подсетью в этой виртуальной сети. Частная конечная точка позволяет узлам в связанной виртуальной сети и одноранговых виртуальных сетях получать доступ к кластеру виртуальных ядер Azure Cosmos DB для MongoDB.
Общие сведения о брандмауэре
Виртуальные ядра Azure Cosmos DB для MongoDB используют брандмауэр на уровне кластера, чтобы предотвратить доступ ко всем кластерам, пока не укажите, какие компьютеры (IP-адреса) имеют разрешение. Брандмауэр предоставляет доступ к кластеру на основе исходного IP-адреса каждого запроса. Чтобы настроить брандмауэр, создайте правила брандмауэра, указывающие диапазоны допустимых IP-адресов.
Правила брандмауэра позволяют клиентам получать доступ к кластеру и всем базам данных в нем. Правила брандмауэра на уровне кластера можно настроить с помощью портал Azure или программно с помощью таких средств Azure, как Azure CLI.
По умолчанию брандмауэр блокирует доступ ко всему кластеру. Чтобы начать использование кластера с другого компьютера, необходимо указать одно или несколько правил брандмауэра на уровне кластера, чтобы обеспечить доступ к кластеру. Используйте правила брандмауэра, чтобы определить разрешенные диапазоны IP-адресов из Интернета. Правила брандмауэра не влияют на доступ к самому веб-сайту портал Azure. Попытки подключения из Интернета и Azure должны сначала пройти через брандмауэр, прежде чем они смогут получить доступ к базам данных.