Обзор безопасности базы данных в 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-адресов и диапазонов. Azure Cosmos DB блокирует все запросы, исходящие из компьютеров за пределами этого разрешенного списка. Затем запросы из утвержденных компьютеров и облачных служб должны пройти процесс аутентификации, чтобы получить право на контроль доступа к ресурсам. Теги службы виртуальной сети можно использовать для обеспечения сетевой изоляции и защиты ресурсов Azure Cosmos DB из общего Интернета. Теги служб можно использовать вместо определенных IP-адресов при создании правил безопасности. Указав имя тега службы (например, AzureCosmosDB) в соответствующем поле источника или назначения правила, можно разрешить или запретить трафик соответствующей службы. |
| Авторизация | Azure Cosmos DB использует для авторизации код проверки подлинности сообщения на основе хэша (HMAC). Каждый запрос хэшируется с помощью ключа секретной учетной записи, а последующий хэш в кодировке Base-64 отправляется с каждым вызовом в Azure Cosmos DB. Чтобы проверить запрос, Azure Cosmos DB использует правильный секретный ключ и свойства для создания хэша, а затем сравнивает значение с значением в запросе. Если совпадают два значения, операция успешно авторизована, и запрос обрабатывается. Если они не соответствуют, возникает сбой авторизации и запрос отклоняется. Вы можете использовать первичный ключ или маркер ресурса, что позволяет точно определить доступ к ресурсу, например документу. Дополнительные сведения см. в статье "Безопасный доступ к ресурсам Azure Cosmos DB". |
| Пользователи и разрешения | Используя первичный ключ для учетной записи, можно создавать ресурсы пользователей и ресурсы разрешений для каждой базы данных. Маркер ресурса связан с разрешением в базе данных и определяет, имеет ли пользователь доступ (на чтение и запись, только на чтение или без доступа) к ресурсу приложения в базе данных. Ресурсы приложения включают контейнеры, документы, вложения, хранимые процедуры, триггеры и определяемые пользователем функции. Затем маркер ресурса используется во время аутентификации, чтобы предоставить или запретить доступ к ресурсу. Дополнительные сведения см. в статье "Безопасный доступ к ресурсам Azure Cosmos DB". |
| Интеграция Active Directory (управление доступом на основе ролей Azure) | Вы также можете предоставить или ограничить доступ к учетной записи Azure Cosmos DB, базе данных, контейнерам и предложениям (пропускная способность) с помощью управления доступом (IAM) в портал Azure. IAM обеспечивает управление доступом на основе ролей и интегрируется с Active Directory. Для частных пользователей и групп можно использовать встроенные роли или пользовательские роли. Дополнительные сведения см. в статье об интеграции Active Directory. |
| Глобальная репликация | Azure Cosmos DB предлагает готовое глобальное распределение, которое позволяет реплика отправлять данные в любой из глобальных центров обработки данных Azure в готовый способ. Глобальная репликация позволяет осуществлять глобальное масштабирование, обеспечивая низкую задержку при обращении к данным по всему миру. В контексте безопасности глобальная репликация обеспечивает защиту данных от региональных сбоев. Дополнительные сведения см. в статье "Глобальное распространение данных". |
| Отработка отказа между регионами | Если вы реплика данные в нескольких центрах обработки данных, Azure Cosmos DB автоматически выполняет перекат операций, если региональный центр обработки данных переходит в автономный режим. Вы можете создать приоритетный список регионов отработки отказа с помощью регионов, в которых данные реплика. Дополнительные сведения см. в статье "Региональные отработки отказа" в Azure Cosmos DB. |
| Локальная репликация | Даже в одном центре обработки данных Azure Cosmos DB автоматически реплика tes data for high availability, предоставляя вам выбор уровней согласованности. Таким образом гарантируется доступность на уровне 99,99 % в соответствии с соглашением об уровне обслуживания для всех учетных записей в пределах одного и нескольких регионов с нестрогой согласованностью и доступность для чтения на уровне 99,999 % для всех учетных записей базы данных в пределах нескольких регионов. |
| Автоматическая оперативная архивация | Базы данных Azure Cosmos DB создаются регулярно и хранятся в геоизбыточное хранилище. Дополнительные сведения см. в статье "Автоматическое оперативное резервное копирование и восстановление" с помощью Azure Cosmos DB. |
| Восстановление удаленных данных | Вы можете использовать автоматизированные онлайн-резервные копии для восстановления данных, которые могут быть случайно удалены до 30 дней после события. Дополнительные сведения см. в статье "Автоматическое резервное копирование в Сети" и "Восстановление" с помощью Azure Cosmos DB |
| Защита и изолирование конфиденциальных данных | Ко всем данным, перечисленным в разделе "Новые возможности", теперь применяется шифрование неактивных данных. Персональные данные и другие конфиденциальные данные могут быть изолированы для определенных контейнеров и чтения и записи, или доступ только для чтения может быть ограничен определенными пользователями. |
| Мониторинг атак | С помощью ведения журнала аудита и журналов действий можно отслеживать учетную запись на наличие аномальной активности. Вы можете просмотреть, какие операции были выполнены в ресурсах. Эти данные включают, кто инициировал операцию, когда произошла операция, состояние операции и многое другое. |
| Реагирование на атаки | После того как вы связались с поддержка Azure сообщить о потенциальной атаке, начинается пятишаговый процесс реагирования на инциденты. Целью является восстановление нормальной безопасности и операций службы. Процесс восстанавливает службы как можно быстрее после обнаружения проблемы и запуска исследования. Дополнительные сведения см . в ответе на безопасность Microsoft Azure в облаке. |
| Установка геозон | Azure Cosmos DB обеспечивает управление данными для национальных регионов (например, Германии, Китая и правительства США). |
| Защищенное оборудование | Данные в Azure Cosmos DB хранятся на твердотельных дисках в защищенных центрах обработки данных 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 Cosmos DB в портал Azure.
Выберите "Ключи" в меню слева и нажмите кнопку "Повторно создать вторичный ключ" в правой части дополнительного ключа.
Убедитесь, что новый вторичный ключ согласованно работает с учетной записью Azure Cosmos DB. Повторное создание ключей может занять от одной минуты до нескольких часов в зависимости от размера учетной записи Azure Cosmos DB.
Замените первичный ключ на вторичный в своем приложении.
Вернитесь на портал Azure и выполните повторное создание первичного ключа.
Если приложение в настоящее время использует вторичный ключ
Перейдите к учетной записи Azure Cosmos DB в портал Azure.
Выберите ключи из меню слева и выберите "Повторно создать первичный ключ " в многоточии (...) справа от первичного ключа.
Убедитесь, что новый первичный ключ согласованно работает с учетной записью Azure Cosmos DB. Повторное создание ключей может занять от одной минуты до нескольких часов в зависимости от размера учетной записи Azure Cosmos DB.
Замените вторичный ключ на первичный в своем приложении.
Вернитесь на портал Azure и выполните повторное создание вторичного ключа.
Отслеживание состояния повторного создания ключа
После смены или повторного создания ключа можно отслеживать его состояние из журнала действий. Чтобы отслеживать состояние, выполните следующие действия.
Войдите в портал Azure и перейдите к учетной записи Azure Cosmos DB.
Выберите ключи в меню слева. Последняя дата повторного создания ключей должна отображаться под каждым ключом.
Рекомендуется повторно создавать ключи по крайней мере один раз в 60 дней. Если ваше последнее восстановление было более 60 дней назад, вы увидите значок предупреждения. Кроме того, можно увидеть, что ключ не был записан. Если это так, ваша учетная запись была создана до 18 июня 2022 года, а даты не были зарегистрированы. Однако вы сможете повторно создать и увидеть новую дату последнего восстановления для нового ключа.
Вы должны увидеть события восстановления ключей вместе со своим состоянием, временем выдачи операции и сведениями о пользователе, который инициировал повторное восстановление ключей. Операция создания ключей инициируется с состоянием "Принято". Он изменяется на "Запущен ", а затем на "Успешно" после завершения операции.
Следующие шаги
- Дополнительные сведения о первичных ключах и маркерах ресурсов см. в статье "Безопасный доступ к данным Azure Cosmos DB".
- Дополнительные сведения о ведении журнала аудита см. в разделе Ведение журнала диагностики Azure Cosmos DB.
- Дополнительные сведения о сертификатах Майкрософт см. в разделе Центр управления безопасностью Azure.