Применение принципов нулевого доверия к хранилищу Azure

Сводка. Чтобы применить принципы нулевого доверия к хранилищу Azure, необходимо защитить данные (неактивных, транзитных и используемых), проверить пользователей и контролировать доступ, отделять или разделять критически важные данные с помощью сетевых элементов управления и использовать Defender для хранения для автоматического обнаружения угроз и защиты.

В этой статье приведены шаги по применению принципов нулевого доверия к служба хранилища Azure:

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

Архитектура хранилища в Azure

Принципы нулевого доверия применяются для служба хранилища Azure в архитектуре, от уровня клиента и каталога до контейнера хранилища на уровне данных.

На следующей схеме показаны компоненты логической архитектуры.

На схеме:

• Учетная запись хранения для эталонной архитектуры содержится в выделенной группе ресурсов. Вы можете изолировать каждую учетную запись хранения в другой группе ресурсов для более детализированных элементов управления доступом на основе ролей (RBAC). Вы можете назначить разрешения RBAC для управления учетной записью хранения на уровне группы ресурсов или группы ресурсов и проверить их с помощью журнала идентификатора Microsoft Entra ID и таких средств, как управление привилегированными пользователями (PIM). Если вы выполняете несколько приложений или рабочих нагрузок с несколькими соответствующими учетными записями хранения в одной подписке Azure, важно ограничить разрешения RBAC каждой учетной записи хранения соответствующим владельцам, хранителям данных, контроллерам и т. д.
• Службы хранилища Azure для этой схемы содержатся в выделенной учетной записи хранения. Для каждой рабочей нагрузки хранилища можно использовать одну учетную запись хранения.
• Более широкий обзор эталонной архитектуры см. в обзоре принципов применения нулевого доверия к Azure IaaS.

Схема не включает очереди Azure и таблицы Azure. Используйте те же рекомендации, приведенные в этой статье, чтобы защитить эти ресурсы.

Что такое в этой статье?

В этой статье описаны шаги по применению принципов нулевого доверия в эталонной архитектуре.

Шаг 1. Защита данных во всех трех режимах: неактивных данных, передачи данных, используемых данных

Вы настраиваете большую часть параметров для защиты неактивных данных, при передаче и использовании при создании учетной записи хранения. Используйте следующие рекомендации, чтобы убедиться, что вы настроите эти защиты. Кроме того, рекомендуется включить Microsoft Defender для облака для автоматической оценки учетных записей хранения в соответствии с тестом безопасности Microsoft Cloud Security, который описывает базовые показатели безопасности для каждой службы Azure.

Дополнительные сведения об этих элементах управления безопасностью хранилища см . здесь.

Использование шифрования при передаче

Вы можете обеспечить защиту данных, включив безопасность на транспортном уровне между Azure и клиентом. Всегда используйте протокол HTTPS, который обеспечивает безопасный обмен данными через общедоступный Интернет. При вызове REST API для доступа к объектам в учетных записях хранения можно применить протокол HTTPS, требуя безопасной передачи данных для учетной записи хранения. Любой запрос, исходящий из небезопасного подключения, отклоняется.

Эта конфигурация включена по умолчанию при развертывании новой учетной записи служба хранилища Azure (безопасная по умолчанию).

Рассмотрите возможность применения политики, чтобы запретить развертывание небезопасных подключений для служба хранилища Azure (secure by Design).

Для этой конфигурации также требуется SMB 3.0 с шифрованием.

Запрет анонимного общедоступного доступа на чтение

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

Дополнительные сведения см. в статье Настройка анонимного общего доступа на чтение для контейнеров и BLOB-объектов.

Запрет авторизации общего ключа

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

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

Эти параметры нельзя изменить после создания учетной записи хранения.

Применение минимальной требуемой версии безопасности транспортного уровня (TLS)

Самая высокая версия, служба хранилища Azure в настоящее время поддерживает TLS 1.2. Применение минимальной версии TLS отклоняет запросы от клиентов, использующих более старые версии. Дополнительные сведения см. в статье "Применение минимальной требуемой версии TLS для запросов к учетной записи хранения".

Определение области операций копирования

Определите область операций копирования, чтобы ограничить операции копирования только теми из исходных учетных записей хранения, которые находятся в одном клиенте Microsoft Entra или имеют Приватный канал в ту же виртуальную сеть (виртуальную сеть), что и целевая учетная запись хранения.

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

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

Общие сведения о том, как работает шифрование неактивных данных

Все данные, записанные в служба хранилища Azure, автоматически шифруются шифрованием службы хранилища (SSE) с 256-разрядным шифром расширенного шифрования (AES). SSE автоматически шифрует данные при их записи в службу хранилища Azure. При считывании данных из службы хранилища Azure она расшифровывает их перед возвратом. Этот процесс не подразумевает никаких дополнительных выплат и не снижает производительность. Использование ключей, управляемых клиентом (CMK), предоставляет дополнительные возможности для управления поворотом ключа шифрования ключей или криптографически стирать данные.

Вы включите CMK из колонки шифрования при создании учетной записи хранения, как показано здесь.

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

Шаг 2. Проверка доступа пользователей и управление доступом к данным хранилища с минимальными привилегиями

Сначала используйте идентификатор Microsoft Entra для управления доступом к учетным записям хранения. Использование контроль доступа на основе ролей с учетными записями хранения позволяет детализировать функцию задания на основе доступа с помощью OAuth 2.0. Вы можете выровнять детализированный доступ к политике условного доступа.

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

Список ролей учетной записи хранения для детализированного доступа см . в встроенных ролях Azure для хранилища. Назначения RBAC выполняются с помощью параметра контроль доступа учетной записи хранения и могут быть назначены в различных областях.

Вы настраиваете управление доступом из параметров контроль доступа (IAM) учетной записи хранения, как показано здесь.

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

Другим способом предоставления разрешений, связанных с временем, является подписанный URL-адрес (SAS). Рекомендации по использованию SAS на высоком уровне приведены ниже.

• Всегда используйте HTTPS. Если вы развернули предлагаемые политики Azure для целевых зон Azure, будет проверена безопасная передача через HTTPS.
• У вас есть план отзыва.
• Настройте политики истечения срока действия SAS.
• Проверка разрешений.
• Используйте SAS делегирования пользователей по возможности. Этот SAS подписан учетными данными идентификатора Microsoft Entra.

Шаг 3. Логически отделять критически важные данные или разделять критически важные данные с помощью сетевых элементов управления

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

На следующей схеме выделены сетевые подключения к службам служба хранилища Azure в эталонной архитектуре.

Вы настраиваете частные конечные точки из параметров сети учетной записи хранения, как показано здесь.

Шаг 4. Использование Defender для хранилища для автоматического обнаружения угроз и защиты

Microsoft Defender для хранилища обеспечивает дополнительный уровень аналитики, который обнаруживает необычные и потенциально опасные попытки использовать службы хранилища. Microsoft Defender для хранилища встроен в Microsoft Defender для облака.

Defender для хранилища обнаруживает аномальные оповещения о шаблоне доступа, такие как:

• Доступ из незнакомых расположений
• Аномалия приложения
• Анонимный доступ
• Оповещения об извлечении и отправке аномалий
• Кража данных
• Непредвиденное удаление
• Отправка пакета облачной службы Azure
• Оповещения о подозрительных действиях хранилища
• Изменение разрешений доступа
• Проверка доступа
• Исследование данных

Дополнительные сведения о защите от угроз в эталонной архитектуре см. в разделе "Принципы применения нулевого доверия к Azure IaaS".

После включения Defender для хранилища уведомляет вас о оповещениях и рекомендациях по обеспечению безопасности учетных записей хранения Azure.

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

Технические иллюстрации

Эти иллюстрации являются репликами эталонных иллюстраций в этих статьях. Скачайте и настройте их для вашей организации и клиентов. Замените логотип Contoso собственным.

Позиция	Description
Скачать Visio Обновлено за октябрь 2024 г.	Применение принципов нулевого доверия к Azure IaaS Используйте эти иллюстрации со следующими статьями: - Обзор - Служба хранилища Azure - Виртуальные машины - Периферийные виртуальные сети Azure - Виртуальные сети Центра Azure
Скачать Visio Обновлено за октябрь 2024 г.	Применение принципов нулевого доверия к Azure IaaS — на одной странице Обзор процесса применения принципов нулевого доверия к средам IaaS Azure.

Дополнительные технические иллюстрации см. в разделе "Нулевое доверие" для ИТ-архитекторов и разработчиков.

Рекомендуемое обучение

Настройка безопасности хранилища

Обучение

Настройка безопасности хранилища

Научитесь настраивать общие возможности обеспечения безопасности службы хранилища Azure, такие как подписанные URL-адреса. В этом модуле вы узнаете, как: Настройте подписанный URL-адрес (SAS), включая универсальный идентификатор ресурса (URI) и параметры SAS. Настройте шифрование служба хранилища Azure. Внедрять управляемые клиентом ключи. Рекомендуется улучшить служба хранилища Azure безопасность.

Дополнительные сведения о безопасности в Azure см. в каталоге Майкрософт:
Безопасность в Azure | Microsoft Learn

Next Steps

Дополнительные статьи о применении принципов нулевого доверия к Azure см. в следующих статьях:

• Обзор Azure IaaS
  • Виртуальные машины
  • Периферийные виртуальные сети
  • Периферийные виртуальные сети со службами Azure PaaS
  • Виртуальные сети концентратора
• Виртуальный рабочий стол Azure
• Виртуальная глобальная сеть Azure
• Приложения IaaS в Amazon Web Services
• Microsoft Sentinel и XDR в Microsoft Defender

Ссылки

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

• Безопасная передача для учетных записей служба хранилища Azure
• Предотвратите анонимный общий доступ на чтение к контейнерам и BLOB-объектам
• Запрет авторизации общего ключа для учетной записи служба хранилища Azure
• Безопасность сети для учетных записей хранения
• Частные конечные точки и Приватный канал для учетных записей хранения
• Шифрование службы хранилища (SSE)
• Контроль доступа на основе ролей для учетных записей хранения
• Резервное копирование BLOB-объектов Azure
• Рекомендации по использованию SAS
• Проверка частных конечных точек
• Проверка конечных точек службы
• Microsoft Defender для хранилища