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

Статья
04/13/2024

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

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

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

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

архитектура служба хранилища в Azure

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

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

На схеме:

Учетная запись хранения для эталонной архитектуры содержится в выделенной группе ресурсов. Вы можете изолировать каждую учетную запись хранения в другой группе ресурсов для более детализированных элементов управления доступом на основе ролей (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 (secure by Design).

Для этой конфигурации также требуется S МБ 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 из колонки шифрования при создании учетной записи хранения, как показано здесь.

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

Примечание.

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

Шаг 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 в эталонной архитектуре.

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

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

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

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

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

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

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

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

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

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

Next Steps

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

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

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

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

Позиция

Description

Рисунок эскиза для плаката инфраструктуры IaaS Для применения нулевого доверия к Azure.

PDF | Visio
Обновлено за март 2024 г.

Используйте эту иллюстрацию вместе с этой статьей: общие сведения о применении принципов нулевого доверия к Azure IaaS

Связанные руководства по решению

На этом плакате представлены эталонные и логические архитектуры и подробные конфигурации отдельных компонентов Нулевого доверия для Azure IaaS. Используйте страницы этого плаката для отдельных ИТ-отделов или специальностей или с версией файла Microsoft Visio, настройте схемы для вашей инфраструктуры.

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