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

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

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

Принцип нулевого доверия	Определение	Встречена
Явная проверка	Всегда выполняйте аутентификацию и авторизацию на основе всех доступных точек данных.	Проверьте учетные данные пользователя и доступ.
Использование доступа с минимальными привилегиями	Ограничьте доступ пользователей с помощью технологий Just-In-Time и Just-Enough-Access (JIT/JEA), адаптивных политик на основе риска и защиты данных.	Управление доступом к данным хранилища с минимальными привилегиями.
Предполагайте наличие бреши в системе безопасности	Минимизируйте радиус поражения и ограничьте доступ к сегментам. Используйте сквозное шифрование и аналитику для обеспечения видимости, обнаружения угроз и усиления защиты.	Защита данных в состоянии покоя, данных в движении и данных в использовании. Разделите критически важные данные с сетевыми элементами управления. Используйте Defender для хранилища для автоматического обнаружения угроз и защиты.

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

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

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

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

На схеме:

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

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

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

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

Шаг	Задача	Применены принципы нулевого доверия
1	Защита данных во всех трех режимах: неактивных данных, передачи данных, используемых данных.	Предполагайте наличие бреши в системе безопасности
2	Проверьте пользователей и управляйте доступом к данным хранилища с минимальными привилегиями.	Проверить явно Использование доступа с минимальными привилегиями
3	Логически отделяйте критически важные данные или разделяйте их с помощью сетевых элементов управления.	Предполагайте наличие бреши в системе безопасности
4	Используйте Defender для хранилища для автоматического обнаружения угроз и защиты.	Предполагайте наличие бреши в системе безопасности

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

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

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

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

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

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

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

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

Предотвращение анонимного общедоступного доступа для чтения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

Чтобы использовать управляемый клиентом ключ для шифрования учетных записей хранения, его необходимо включить во время создания учетной записи, и у вас должен быть Key Vault с ключом и управляемым удостоверением с соответствующими разрешениями, уже подготовленными. При необходимости можно также включить 256-разрядное шифрование AES на уровне инфраструктуры службы хранения Azure.

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

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

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

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

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

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

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

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

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

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

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

Задача	Описание
Предотвратите общедоступный доступ, создайте сегментацию сети с частной конечной точкой и приватным соединением.	Частная конечная точка позволяет подключаться к службам, используя единственный частный IP-адрес в виртуальной сети с помощью Azure Private Link. Включение частных конечных точек позволяет платформе Azure проверять сетевые подключения и разрешать только подключение с явным доступом к ресурсу приватного канала, чтобы получить доступ к последующим ресурсам. Вам потребуется отдельная частная конечная точка для каждой службы в учетной записи хранения Azure.
Использование Azure Private Link	Используйте Azure Private Link для доступа к службе хранилища Azure, используя частную конечную точку в вашей виртуальной сети. Используйте процесс согласования, чтобы автоматически утвердить или вручную запросить, по мере необходимости.
Предотвращение общедоступного доступа к источникам данных с помощью конечных точек службы	Можно выполнить сегментацию сети с помощью конечных точек сервиса, включив возможность использования частных IP-адресов в виртуальной сети для доступа к конечной точке без использования общедоступных IP-адресов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Дальнейшие шаги

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

Ссылки

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-05-20