Общие сведения о безопасности базы данных в Azure Cosmos DB
ПРИМЕНИМО К:
Nosql Mongodb Кассандра Гремлин Таблица
В этой статье представлены рекомендации по обеспечению безопасности, а также основные возможности, предлагаемые Azure Cosmos DB для предотвращения и обнаружения нарушений в работе баз данных и реагирования на эти нарушения.
Новые возможности безопасности в Azure Cosmos DB
Шифрование неактивных данных теперь доступно для документов и резервных копий, хранящихся в Azure Cosmos DB во всех регионах Azure. Шифрование неактивных данных применяется в этих регионах автоматически как для новых, так и для существующих клиентов. Настраивать ничего не нужно. Вы получаете такие же большие задержки, пропускную способность, доступность и функциональность, как и раньше, благодаря тому, что ваши данные защищены и защищены с помощью шифрования неактивных данных. Данные, хранящиеся в учетной записи Azure Cosmos DB, автоматически шифруются с помощью ключей, управляемых корпорацией Майкрософт, с помощью ключей, управляемых службой. При необходимости можно добавить второй уровень шифрования с ключами, которыми управляете вы (ключи, управляемые клиентом, или CMK).
Как защитить свою базу данных
Ответственность за безопасность данных лежит как на клиенте, так и на поставщике базы данных. В зависимости от выбранного поставщика базы данных доля ответственности клиента может меняться. Если выбрать локальное решение, то клиент должен предоставить все — от защиты конечной точки до физической безопасности оборудования, а это непростая задача. Если выбрать поставщик облачной базы данных PaaS, например Azure Cosmos DB, то обязанности клиента значительно сокращаются. На следующем рисунке, взятом из технического документа корпорации Майкрософт Shared Responsibilities for Cloud Computing (Разделяемые обязанности в облачных вычислениях), показано, как с применением поставщика PaaS, такого как Azure Cosmos DB, сокращается ответственность клиента.
На предыдущей схеме видны высокоуровневые компоненты безопасности в облаке, но о каких элементах необходимо позаботиться конкретно для решения вашей базы данных? И как сравнить решения между собой?
Мы рекомендуем сравнить системы баз данных с помощью следующего контрольного списка требований:
- Параметры безопасности сети и брандмауэра
- Аутентификация пользователей и детальные пользовательские элементы управления
- Возможность глобальной репликации данных в случае регионального сбоя
- Возможность переключения из одного центра обработки данных в другой при отработке отказа
- Репликация локальных данных в рамках центра обработки данных
- Автоматическая архивация данных
- Восстановление удаленных данных из архива
- Защита и изолирование конфиденциальных данных
- Мониторинг атак
- Реагирование на атаки
- Возможность защитить данные в пределах геозоны в соответствии с ограничениями, установленными для управления данными
- Физическая защита серверов в защищенных центрах обработки данных
- Сертификация
И хотя это может показаться очевидным, но последние крупномасштабные нарушения в работе баз данных напоминают нам о простых, но критических важных требованиях, которые необходимо выполнять:
- На серверах устанавливаются исправления и поддерживается актуальность их ПО
- HTTPS по умолчанию/шифрование TLS
- Административные учетные записи с надежными паролями
Каким образом Azure Cosmos DB обеспечивает защиту базы данных
Давайте еще раз рассмотрим приведенный выше список. Сколько из этих требований к безопасности выполняется Azure Cosmos DB? Абсолютно все.
Рассмотрим каждое из них подробнее.
| Требование к безопасности | Подход к обеспечению безопасности Azure Cosmos DB |
|---|---|
| Безопасность сети | Использование брандмауэра для IP-адресов — первый уровень защиты базы данных. Для поддержки входящего трафика брандмауэра база данных Azure Cosmos DB использует политики контроля доступа на основе IP-адресов. Элементы управления доступом на основе IP-адресов аналогичны правилам брандмауэра, используемым традиционными системами баз данных. Однако они расширяются, чтобы учетная запись базы данных Azure Cosmos DB была доступна только из утвержденного набора компьютеров или облачных служб. Дополнительные сведения см. на странице о поддерживаемых брандмауэрах в Azure Cosmos DB. Azure Cosmos DB позволяет включить определенный IP-адрес (168.61.48.0), диапазон IP-адресов (168.61.48.0/8), а также сочетания IP-адресов и диапазонов. Все запросы, полученные от компьютеров, IP-адреса которых не входят в этот список разрешенных, блокируются Azure Cosmos DB. Затем запросы из утвержденных компьютеров и облачных служб должны пройти процесс аутентификации, чтобы получить право на контроль доступа к ресурсам. Теги службы виртуальной сети можно использовать, чтобы обеспечить изоляцию сети и защитить ресурсы Azure Cosmos DB от общего Интернета. Теги служб можно использовать вместо определенных IP-адресов при создании правил безопасности. Указав имя тега службы (например, AzureCosmosDB) в соответствующем исходном поле или поле назначения правила, можно разрешить или запретить трафик для соответствующей службы. |
| Авторизация | Azure Cosmos DB использует для авторизации код проверки подлинности сообщения на основе хэша (HMAC). Каждый запрос хэшируется с помощью секретного ключа учетной записи, а затем хэш в кодировке Base-64 отправляется с каждым вызовом в Azure Cosmos DB. Чтобы проверить запрос, служба Azure Cosmos DB использует соответствующий секретный ключ и свойства для создания хэша, а затем сравнивает это значение со значением в запросе. Если два значения совпадают, операция успешно авторизоваться и запрос обрабатывается. Если они не совпадают, происходит сбой авторизации и запрос отклоняется. Можно использовать либо первичный ключ, либо токен ресурса, обеспечивающий детальный доступ к ресурсу, например документу. Дополнительные сведения см. в статье о защите доступа к ресурсам Azure Cosmos DB. |
| Пользователи и разрешения | Используя первичный ключ для учетной записи, можно создавать ресурсы пользователей и ресурсы разрешений для каждой базы данных. Маркер ресурса связан с разрешением в базе данных и определяет, имеет ли пользователь доступ (на чтение и запись, только на чтение или без доступа) к ресурсу приложения в базе данных. К ресурсам приложения относятся контейнеры, документы, вложения, хранимые процедуры, триггеры и определяемые пользователем функции (UDF). Затем маркер ресурса используется во время аутентификации, чтобы предоставить или запретить доступ к ресурсу. Дополнительные сведения см. в статье о защите доступа к ресурсам Azure Cosmos DB. |
| Интеграция Active Directory (управление доступом на основе ролей Azure) | Вы также можете предоставить или ограничить доступ к учетной записи, базе данных, контейнеру и предложениям Azure Cosmos DB (пропускная способность) с помощью управления доступом (IAM) в портал Azure. IAM обеспечивает управление доступом на основе ролей и интегрируется с Active Directory. Для частных пользователей и групп можно использовать встроенные роли или пользовательские роли. Дополнительные сведения см. в статье Интеграция Active Directory. |
| Глобальная репликация | Azure Cosmos DB предлагает готовое глобальное распределение, которое позволяет реплицировать данные в любой из центров обработки данных Azure по всему миру готовым способом. Глобальная репликация позволяет осуществлять глобальное масштабирование, обеспечивая низкую задержку при обращении к данным по всему миру. В контексте безопасности глобальная репликация обеспечивает защиту данных от региональных сбоев. Дополнительные сведения см. в статье DocumentDB — глобально распределенная служба базы данных в Azure. |
| Отработка отказа между регионами | Если вы реплицировали данные в нескольких центрах обработки данных, Azure Cosmos DB автоматически переключится на операции, если региональный центр обработки данных перейдет в автономный режим. Вы можете создать список расположенных по приоритетам регионов отработки отказа, используя регионы, в которых реплицируются ваши данные. Дополнительные сведения см. в статье об отработке отказа между регионами в Azure Cosmos DB. |
| Локальная репликация | Даже в пределах одного центра обработки данных Azure Cosmos DB автоматически реплицирует данные для обеспечения высокой доступности, предоставляя выбор уровней согласованности. Таким образом гарантируется доступность на уровне 99,99 % в соответствии с соглашением об уровне обслуживания для всех учетных записей в пределах одного и нескольких регионов с нестрогой согласованностью и доступность для чтения на уровне 99,999 % для всех учетных записей базы данных в пределах нескольких регионов. |
| Автоматическая оперативная архивация | Резервные копии баз данных Azure Cosmos DB регулярно создаются и хранятся в геоизбыточное хранилище. Дополнительные сведения см. в статье Автоматическая оперативная архивация и восстановление с помощью Azure Cosmos DB. |
| Восстановление удаленных данных | Автоматическая оперативная архивация может использоваться для восстановления данных, которые были случайно удалены. Это можно сделать максимум через 30 дней после события. Дополнительные сведения см. в статье Автоматическая оперативная архивация и восстановление с помощью Azure Cosmos DB. |
| Защита и изолирование конфиденциальных данных | Ко всем данным, перечисленным в разделе "Новые возможности", теперь применяется шифрование неактивных данных. Личные и другие конфиденциальные данные можно изолировать в определенном контейнере, а доступ для чтения и записи или только для чтения можно ограничить определенным списком пользователей. |
| Мониторинг атак | С помощью ведения журнала аудита и журналов действий можно отслеживать учетную запись на наличие аномальной активности. Вы можете просмотреть, какие операции были выполнены с ресурсами. Эти данные включают в себя; кто инициировал операцию, когда она была выполнена, состояние операции и многое другое. |
| Реагирование на атаки | После того как вы связались с поддержка Azure, чтобы сообщить о потенциальной атаке, запускается пятишаговый процесс реагирования на инциденты. Цель пятишагового процесса — восстановить нормальную безопасность и операции службы. Процесс из пяти этапов восстанавливает службы как можно быстрее после обнаружения проблемы и начала исследования. Дополнительные сведения см. в статье Microsoft Azure Security Response in the Cloud (Реагирование на нарушения безопасности в облаке Microsoft Azure). |
| Установка геозон | Azure Cosmos DB обеспечивает управление данными для отдельных регионов (например, Германия, Китай или US Gov). |
| Защищенное оборудование | Данные в Azure Cosmos DB хранятся на твердотельных накопителях SSD в защищенных центрах обработки данных Azure. Дополнительные сведения о глобальных центрах обработки данных корпорации Майкрософт см. на этой странице. |
| Шифрование HTTPS, SSL и TLS | Все подключения к Azure Cosmos DB поддерживают протокол HTTPS. Azure Cosmos DB поддерживает уровни TLS до 1.2 (в комплекте). На стороне сервера можно применить минимальный уровень TLS. Для этого ознакомьтесь с руководством по самостоятельному обеспечению минимальной версии TLS для самообслуживания в Azure Cosmos DB. |
| Шифрование при хранении | Все данные, хранимые в Azure Cosmos DB, хранятся в зашифрованном виде. Дополнительные сведения см. в статье Шифрование неактивных данных базы данных в Azure Cosmos DB. |
| Установка исправлений на серверы | Являясь управляемой базой данных, Azure Cosmos DB избавляет от необходимости управлять серверами и устанавливать на них исправления. Это делается автоматически. |
| Административные учетные записи с надежными паролями | Пожалуй, даже не нужно упоминать об этом требовании, но, в отличие от некоторых наших конкурентов, в Azure Cosmos DB не может быть учетной записи администратора без пароля. Безопасность с помощью аутентификации на основе секретов TLS и HMAC включена по умолчанию. |
| Сертификаты безопасности и защиты данных | Самый актуальный список сертификатов см. в статье Соответствие требованиям Azure и последний документ о соответствии Требованиям Azure со всеми сертификатами Azure, включая Azure Cosmos DB. |
На следующем снимке экрана показано, как использовать журналы аудита и журналы действий для мониторинга учетной записи. 
Первичный/вторичный ключи
Первичные/вторичные ключи предоставляют доступ ко всем административным ресурсам для учетной записи базы данных. Первичный/вторичный ключи:
- предоставляют доступ к учетным записям, базам данных, пользователям и разрешениям;
- Нельзя использовать для предоставления детализированного доступа к контейнерам и документам.
- создаются в процессе создания учетной записи;
- можно создать повторно в любое время.
Каждая учетная запись состоит из двух ключей: первичного и вторичного. Двойные ключи позволяют повторно создавать или сменять ключи, обеспечивая постоянный доступ к учетной записи и данным.
Первичный/вторичный ключи могут быть двух версий: для чтения и записи и только для чтения. Ключи только для чтения разрешают операции чтения только в учетной записи, но не предоставляют доступ к ресурсам разрешений на чтение.
Смена и повторное создание ключей
Процесс смены и повторного создания ключей прост. Сначала убедитесь, что в приложении постоянно используется либо первичный ключ, либо вторичный ключ для доступа к учетной записи Azure Cosmos DB. Затем выполните следующие шаги. О том, как следить за обновлениями и повторным созданием ключей для учетной записи, см. в статье об отслеживании обновлений ключа с помощью метрик и оповещений.
Если приложение в настоящее время использует первичный ключ
На портале Azure перейдите к своей учетной записи Azure Cosmos DB.
Выберите Ключи в меню слева, а затем выберите Повторно создать вторичный ключ с помощью кнопки с многоточием справа от вторичного ключа.
Убедитесь, что новый вторичный ключ согласованно работает с учетной записью Azure Cosmos DB. Повторное создание ключа может занять от одной минуты до нескольких часов в зависимости от размера учетной записи Azure Cosmos DB.
Замените первичный ключ на вторичный в своем приложении.
Вернитесь на портал Azure и выполните повторное создание первичного ключа.
Если приложение в настоящее время использует вторичный ключ
На портале Azure перейдите к своей учетной записи Azure Cosmos DB.
Выберите Ключи в меню слева, а затем выберите Повторно создать первичный ключ с помощью кнопки с многоточием справа от первичного ключа.
Убедитесь, что новый первичный ключ согласованно работает с учетной записью Azure Cosmos DB. Повторное создание ключа может занять от одной минуты до нескольких часов в зависимости от размера учетной записи Azure Cosmos DB.
Замените вторичный ключ на первичный в своем приложении.
Вернитесь на портал Azure и выполните повторное создание вторичного ключа.
Отслеживание состояния повторного создания ключа
После смены или повторного создания ключа можно отслеживать его состояние из журнала действий. Чтобы отслеживать состояние, выполните следующие действия.
Войдите на портал Azure и перейдите в учетную запись Azure Cosmos DB.
Выберите Ключи в меню слева. Под каждым ключом должна отображаться последняя дата повторного создания ключа.
Корпорация Майкрософт рекомендует повторно создавать ключи по крайней мере раз в 60 дней. Если ваша последняя регенерация была более 60 дней назад, вы увидите значок предупреждения. Кроме того, вы могли видеть, что ключ не был записан. В этом случае учетная запись была создана до 18.06.2022, а даты не были зарегистрированы. Однако вы сможете повторно создать и просмотреть новую дату последней повторной регенерации для нового ключа.
Вы должны увидеть события повторного создания ключа, а также его состояние, время выполнения операции, сведения о пользователе, который инициировал повторное создание ключа. В начале операция создания ключа получает состояние Принято, затем оно сменяется на Запущено, и наконец Успешно после завершения операции.
Дальнейшие действия
Дополнительные сведения о первичных ключах и токенах ресурсов см. в разделе Защита доступа к данным Azure Cosmos DB.
Дополнительные сведения о ведении журнала аудита см. в разделе Ведение журнала диагностики Azure Cosmos DB.
Дополнительные сведения о сертификатах Майкрософт см. в разделе Центр управления безопасностью Azure.