Предотвращение авторизации общим ключом для учетной записи Службы хранилища Azure
Каждый защищенный запрос к учетной записи Службы хранилища Azure должен быть авторизован. По умолчанию запросы можно авторизовать с помощью учетных данных Microsoft Entra или с помощью ключа доступа к учетной записи для авторизации общего ключа. Из этих двух типов авторизации идентификатор Microsoft Entra обеспечивает более высокую безопасность и удобство использования по общему ключу и рекомендуется корпорацией Майкрософт. Чтобы клиенты использовали идентификатор Microsoft Entra для авторизации запросов, вы можете запретить запросы к учетной записи хранения, авторизованной с общим ключом.
Если запретить авторизацию с общим ключом для учетной записи хранения, служба хранилища Azure будет отклонять все последующие запросы к этой учетной записи, которые авторизованы с помощью ключей доступа к учетной записи. Будут успешно выполнены только защищенные запросы, авторизованные с идентификатором Microsoft Entra. Дополнительные сведения об использовании идентификатора Microsoft Entra см. в статье "Авторизация доступа к данным в служба хранилища Azure".
Свойство AllowSharedKeyAccess учетной записи хранения не задано по умолчанию и не возвращает значение, пока не будет явно задано. Учетная запись хранения разрешает запросы, которые были авторизованы с помощью общего ключа, если это свойство имеет значение null или true.
В этой статье описывается, как использовать платформу DRAG (Detection-Remediation-Audit-Governance) для непрерывного управления авторизацией общего ключа для учетной записи хранения.
Необходимые компоненты
Прежде чем запретить доступ к общему ключу для любой из учетных записей хранения:
- Сведения о том, как запретить общий ключ влияет на маркеры SAS
- Рассмотрите возможность совместимости с другими инструментами и службами Azure
- Рассмотрите необходимость запретить авторизацию общего ключа для использования условного доступа Microsoft Entra
- Авторизация доступа к данным файлов или переходу Файлы Azure рабочих нагрузок
Как запрет доступа по общему ключу влияет на маркеры SAS
Если для учетной записи хранения запрещен доступ по общему ключу, Служба хранилища Azure обрабатывает маркеры SAS на основе типа SAS и службы, которая является целью запроса. В следующей таблице показано, как авторизуется каждый тип SAS, и как Служба хранилища Azure обрабатывает этот SAS, если свойство AllowSharedKeyAccess учетной записи хранения имеет значение false.
| Тип SAS | Тип авторизации | Поведение, если AllowSharedKeyAccess имеет значение false |
|---|---|---|
| SAS для делегирования пользователей (только хранилище BLOB-объектов) | Microsoft Entra ID | Запрос разрешен. Для обеспечения повышенной безопасности Майкрософт рекомендует по возможности использовать SAS для делегирования пользователей. |
| SAS уровня службы | Общий ключ | Запрос запрещен для всех Служб хранилища Azure. |
| SAS для учетной записи | Общий ключ | Запрос запрещен для всех Служб хранилища Azure. |
Метрики и журналы Azure в Azure Monitor не различают типы подписанных URL-адресов (SAS). И фильтр SAS в обозревателе метрик Azure, и поле SAS в журналах службы хранилища Azure в Azure Monitor сообщают о запросах, авторизованных с помощью любого типа SAS. Однако для разных типов подписанного URL-адреса авторизация выполняется по-разному и ведет себя иначе, если доступ по общему ключу запрещен.
- Маркер SAS службы или маркер SAS учетной записи авторизуется по общему ключу и не будет разрешен в запросе к хранилищу BLOB-объектов, если свойство AllowSharedKeyAccess имеет значение false.
- SAS делегирования пользователей авторизован с идентификатором Microsoft Entra и будет разрешен для запроса к хранилищу BLOB-объектов, если для свойства AllowSharedKeyAccess задано значение false.
При оценке трафика в учетную запись хранения следует помнить, что метрики и журналы могут включать запросы, выполненные с помощью SAS делегирования пользователя, как описано в разделе Определение типа авторизации, используемой клиентскими приложениями.
Дополнительные сведения о подписанных URL-адресах см. в статье об использование подписанных URL-адресов SAS в службе хранилища Azure.
Совместимость с другими инструментами и службами Azure
Основное множество служб Azure использует авторизацию по общему ключу для взаимодействия со Службой хранилища Azure. Если запретить авторизацию по общему ключу для учетной записи хранения, эти службы не смогут получать доступ к данным в этой учетной записи, и ваши приложения могут серьезно пострадать.
Некоторые средства Azure предлагают возможность использовать авторизацию Microsoft Entra для доступа к служба хранилища Azure. В следующей таблице перечислены некоторые популярные инструменты Azure и заметки о том, могут ли они использовать идентификатор Microsoft Entra для авторизации запросов на служба хранилища Azure.
| Инструмент Azure | Авторизация Microsoft Entra для служба хранилища Azure |
|---|---|
| Портал Azure | Поддерживается. Сведения об авторизации с помощью учетной записи Microsoft Entra из портал Azure см. в статье "Выбор способа авторизации доступа к данным BLOB-объектов в портал Azure". |
| AzCopy | Поддерживается для служба хранилища BLOB-объектов. Сведения об авторизации операций AzCopy см. в разделе Выбор порядка предоставления учетных данных авторизации в документации AzCopy. |
| Обозреватель службы хранилища Azure | Поддерживается для служба хранилища BLOB-объектов, очередей служба хранилища, служба хранилища таблиц и Azure Data Lake Storage 2-го поколения. Доступ к хранилищу файлов Microsoft Entra ID не поддерживается. Убедитесь, что выбран правильный клиент Microsoft Entra. Дополнительные сведения см. в разделе Начало работы с Обозревателем службы хранилища. |
| Azure PowerShell | Поддерживается. Сведения о том, как авторизовать команды PowerShell для операций больших двоичных объектов или очередей с помощью идентификатора Microsoft Entra, см. в разделе "Запуск команд PowerShell с учетными данными Microsoft Entra" для доступа к данным о blob-объектах или выполнении команд PowerShell с помощью учетных данных Microsoft Entra для доступа к данным очереди. |
| Azure CLI | Поддерживается. Сведения о том, как авторизовать команды Azure CLI с помощью идентификатора Microsoft Entra для доступа к данным больших двоичных объектов и очередей, см. в статье Запуск команд Azure CLI с учетными данными Microsoft Entra для доступа к данным blob-объектов или очередей. |
| Центр Интернета вещей Azure | Поддерживается. Дополнительные сведения см. в разделе Поддержка Центра Интернета вещей для виртуальных сетей. |
| Azure Cloud Shell | Azure Cloud Shell — это интегрированная оболочка на портале Azure. Azure Cloud Shell размещает файлы для хранения в общей папке Azure в учетной записи хранения. Эти файлы станут недоступными, если для этой учетной записи хранения запретить авторизацию по общему ключу. Дополнительные сведения см. в статье Сохранение файлов в Azure Cloud Shell. Чтобы выполнить команды в Azure Cloud Shell для управления учетными записями хранения, в которых запрещен доступ по общему ключу, сначала убедитесь, что вам предоставлены необходимые разрешения для этих учетных записей через Azure RBAC. Дополнительные сведения см. в разделе Что такое управление доступом на основе ролей в Azure (Azure RBAC)?. |
Запретить авторизацию общего ключа для использования условного доступа Microsoft Entra
Чтобы защитить учетную запись служба хранилища Azure с помощью политик условного доступа Microsoft Entra, необходимо запретить авторизацию общего ключа для учетной записи хранения.
Авторизация доступа к данным файлов или переходу Файлы Azure рабочих нагрузок
служба хранилища Azure поддерживает авторизацию Microsoft Entra для запросов Файлы Azure, BLOB-объектов служба хранилища, очередей служба хранилища и таблиц служба хранилища. Однако по умолчанию портал Azure использует авторизацию общего ключа для доступа к общим папкам Azure. Если вы запрещаете авторизацию общего ключа для учетной записи хранения, которая не настроена с соответствующими назначениями RBAC, запросы к Файлы Azure завершаются ошибкой, и вы не сможете получить доступ к общим папкам Azure в портал Azure.
Чтобы устранить эту проблему, рекомендуется использовать один из трех подходов:
- Выполните следующие действия , чтобы авторизовать доступ к данным файла с помощью учетной записи Microsoft Entra или
- Перенос любых Файлы Azure данных в отдельную учетную запись хранения перед запретом доступа к учетной записи с помощью общего ключа или
- Не применяйте этот параметр к учетным записям хранения, поддерживающим рабочие нагрузки Файлы Azure.
Определение учетных записей хранения, разрешающих доступ к общему ключу
Существует два способа идентификации учетных записей хранения, которые разрешают доступ к общему ключу:
- Проверка параметра доступа к общему ключу для нескольких учетных записей
- Настройка Политика Azure для доступа к общему ключу в режиме аудита
Проверка настройки доступа по общему ключу для нескольких учетных записей
Чтобы проверить настройку доступа по общему ключу в наборе учетных записей хранения с оптимальной производительностью, используйте Azure Resource Graph Explorer на портале Azure. Дополнительные сведения об использовании песочницы Graph для ресурсов см. в статье Краткое руководство: выполнение первого запроса по Azure Resource Graph с помощью песочницы Graph.
Выполнение следующего запроса в Resource Graph Explorer возвращает список учетных записей хранения с параметром доступа по общему ключу для каждой учетной записи:
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowSharedKeyAccess = parse_json(properties).allowSharedKeyAccess
| project subscriptionId, resourceGroup, name, allowSharedKeyAccess
Настройка Политика Azure для доступа к общему ключу в режиме аудита
Политика Azure учетные записи служба хранилища должны запретить доступ к общему ключу пользователям с соответствующими разрешениями настраивать новые или существующие учетные записи хранения для разрешения авторизации общего ключа. Настройте эту политику в режиме аудита, чтобы определить учетные записи хранения, в которых разрешена авторизация общего ключа. После изменения приложений на использование Microsoft Entra вместо общего ключа для авторизации можно обновить политику, чтобы запретить доступ к общему ключу.
Дополнительные сведения о встроенной политике см. в статье служба хранилища учетные записи должны препятствовать доступу к общему ключу в списке встроенных определений политик.
Назначение встроенной политики для области ресурсов
Выполните следующие действия, чтобы назначить встроенную политику для соответствующего область в портал Azure:
На портале Azure выполните поиск по слову Политика, чтобы найти панель мониторинга "Политика Azure".
В разделе Разработка выберите Назначения.
Выберите Назначить политику.
На вкладке Основные сведения страницы Назначение политики в разделе Область укажите область назначения политики. Нажмите кнопку "Дополнительно " (...), чтобы выбрать подписку и необязательную группу ресурсов.
В поле определения политики нажмите кнопку "Дополнительно" (...) и введите общий доступ к ключу в поле поиска. Выберите определение политики с именем служба хранилища учетных записей, чтобы предотвратить доступ к общему ключу.
Выберите Review + create (Просмотреть и создать).
На вкладке "Проверка и создание" просмотрите назначение политики и нажмите кнопку "Создать", чтобы назначить определение политики указанному область.
Мониторинг соответствия политике
Чтобы отслеживать учетные записи хранения для соответствия политике доступа к общему ключу, выполните следующие действия.
На панели мониторинга Политика Azure в разделе "Создание" выберите "Назначения".
Найдите и выберите назначение политики, созданное в предыдущем разделе.
Перейдите на вкладку "Представление соответствия ".
Все учетные записи хранения в область назначения политики, которые не соответствуют требованиям политики, отображаются в отчете о соответствии.
Чтобы получить дополнительные сведения о том, почему учетная запись хранения не соответствует требованиям, выберите "Сведения " по причине соответствия требованиям.
Определение типа авторизации, используемой клиентскими приложениями
Перед внесение этого изменения необходимо понять, как запрет авторизации с общим ключом может повлиять на клиентские приложения. Для этого включите ведение журнала и метрики для учетной записи хранения. Затем вы можете проанализировать шаблоны запросов к вашей учетной записи в течение некоторого периода времени и понять, как авторизуются запросы.
Используйте метрики, чтобы определить количество запросов, получаемых учетной записью хранения, которые авторизованы с помощью общего ключа или подписанного URL-адреса (SAS). Используйте журналы, чтобы определить, какие клиенты отправляют эти запросы.
SAS может быть авторизован с помощью общего ключа или идентификатора Microsoft Entra. Дополнительные сведения об интерпретации запросов, выполняемых с помощью подписанного URL-адреса, см. в разделе Как запрет доступа по общему ключу влияет на маркеры SAS.
Определение количества и частоты запросов, авторизованных с помощью общего ключа
Для отслеживания авторизации запросов к учетной записи хранения используйте обозреватель метрик Azure на портале Azure. Дополнительные сведения о метриках Обозреватель см. в обозревателе метрик Azure Monitor.
Чтобы создать метрику, которая отслеживает запросы, авторизованные с помощью общего ключа или SAS, выполните следующие действия.
Войдите в свою учетную запись хранения на портале Azure. В разделе Мониторинг выберите Метрики.
Появится новое поле метрик:
Если это не так, нажмите кнопку "Добавить метрику".
В диалоговом окне Metric (Метрики) укажите следующие значения.
- В поле Scope (Область) оставьте имя учетной записи хранения.
- Задайте для пространства имен метрик значение Account (Учетная запись). Эта метрика будет сообщать обо всех запросах к учетной записи хранения.
- В поле Metric (Метрика) задайте значение Transactions (Транзакции).
- В поле Aggregation (Агрегат) задайте значение Sum (Сумма).
Эта новая метрика будет отображать сумму количества транзакций в учетной записи хранения в течение заданного интервала времени. В результате эта метрика должна выглядеть, как показано на рисунке:
Затем нажмите кнопку Add filter (Добавить фильтр), чтобы создать фильтр по метрике для типа авторизации.
В диалоговом окне фильтра укажите следующие значения.
- В поле Property (свойство) задайте значение Authentication (Авторизация).
- В поле Operator (Оператор) укажите знак равенства (=).
- В поле Values (Значения) выберите Account Key (Ключ учетной записи) и SAS.
В правом верхнем углу выберите диапазон времени, для которого хотите просматривать метрику. Можно также указать, степень детализации агрегирования запросов, задав интервалы от 1 минуты до 1 месяца. Например, чтобы просмотреть запросы за последние 30 дней, агрегированные по дням, задайте в параметре Time range (Диапазон времени) 30 дней, а в параметре Time granularity (Степень детализации времени) — 1 день.
После настройки метрики запросы к учетной записи хранения начнут отображаться на графике. На следующем рисунке показаны запросы, которые были авторизованы с помощью общего ключа или с помощью маркера SAS. Запросы суммируются по дням за последние тридцати дней.
Вы также можете настроить правило генерации оповещений, чтобы получать уведомления, когда к учетной записи хранения будет сделано определенное количество запросов, авторизованных с помощью общего ключа. Дополнительные сведения см. в статье Создание и просмотр оповещений метрик, а также управление ими с помощью Azure Monitor.
Анализ журналов для выявления клиентов, авторизующих запросы с помощью общего ключа или SAS
Журналы Службы хранилища Azure записывают сведения о запросах к учетной записи хранения, в том числе о том, как был авторизован запрос. Вы можете проанализировать журналы, чтобы определить, какие клиенты авторизуют запросы с помощью общего ключа, а какие — с помощью маркера SAS.
Чтобы регистрировать запросы к учетной записи служба хранилища Azure, чтобы оценить, как они авторизованы, можно использовать служба хранилища Azure ведение журнала в Azure Monitor. Дополнительные сведения см. в разделе Мониторинг службы хранилища Microsoft Azure.
Функция "Журнал службы хранилища Microsoft Azure" в Azure Monitor поддерживает использование запросов журналов для анализа. Для запроса журналов можно использовать рабочую область Azure Log Analytics. Дополнительные сведения о запросах журналов см. в разделе Руководство: начало работы с запросами Log Analytics.
Создание параметра диагностики на портале Azure
Чтобы регистрировать в журнале данные службы хранилища Azure с помощью Azure Monitor и анализировать их с помощью Azure Log Analytics, необходимо сначала создать параметр диагностики, который указывает, данные каких типов запросов для каких служб хранилища следует регистрировать в журнале. Чтобы создать параметр диагностики на портале Azure, выполните следующие действия.
Создайте новую рабочую область Log Analytics в подписке, которая содержит вашу учетную запись хранения Azure, или используйте существующую рабочую область Log Analytics. После настройки ведения журнала для вашей учетной записи хранения журналы станут доступны в рабочей области Log Analytics. Дополнительные сведения см. в статье Create a Log Analytics workspace in the Azure portal (Создание рабочей области Log Analytics на портале Azure).
Войдите в свою учетную запись хранения на портале Azure.
В разделе "Мониторинг" выберите Параметры диагностики.
Выберите службу хранилища Microsoft Azure, для которой требуется регистрировать запросы. Например, выберите BLOB-объект для регистрации в журнале запросов в хранилище BLOB-объектов.
Выберите Добавить параметр диагностики.
Укажите имя для параметра диагностики.
Под заголовком Category details (Сведения о категории) в разделе log (журнал) выберите StorageRead, StorageWrite и StorageDelete, чтобы регистрировать все запросы данных в выбранной службе.
В разделе Destination details (Сведения о назначении) установите флажокSend to Log Analytics (Отправлять в Log Analytics). Выберите подписку и созданную ранее рабочую область Log Analytics, как показано на следующем рисунке.
Вы можете создать параметр диагностики для каждого типа ресурса службы хранилища Azure в вашей учетной записи хранения.
После создания параметра диагностики запросы к учетной записи хранения последовательно регистрируются в соответствии с этим параметром. Дополнительные сведения см. в разделе Создание параметров диагностики для сбора журналов ресурсов и метрик в Azure.
Ссылка на поля, доступные в журналах служба хранилища Azure в Azure Monitor, см. в журналах ресурсов.
Журналы запросов для запросов, авторизованных с помощью общего ключа или SAS
Журналы службы хранилища Azure в Azure Monitor включают тип авторизации, который использовался для выполнения запроса к учетной записи хранения. Чтобы получить журналы для запросов, выполненных за последние семь дней, которые были авторизованы с помощью общего ключа или SAS, откройте рабочую область Log Analytics. Затем вставьте следующий запрос в поле создания запроса к журналу и запустите его. Этот запрос отображает десять IP-адресов, с которых чаще всего отправлялись запросы, авторизованные с помощью общего ключа или SAS:
StorageBlobLogs
| where AuthenticationType in ("AccountKey", "SAS") and TimeGenerated > ago(7d)
| summarize count() by CallerIpAddress, UserAgentHeader, AccountName
| top 10 by count_ desc
Вы также можете настроить на основе этого запроса правило генерации оповещений, чтобы получать уведомления о запросах, авторизованных с помощью общего ключа или SAS. Дополнительные сведения см. в статье Создание и просмотр оповещений журналов, а также управление ими с помощью Azure Monitor.
Исправление авторизации с помощью общего ключа
После того как вы проанализируете способы авторизации запросов к учетной записи хранения, можно предпринять действия по запрету доступа с помощью общего ключа. Но сначала необходимо обновить все приложения, использующие авторизацию общего ключа для использования идентификатора Microsoft Entra. Вы можете отслеживать журналы и метрики, как описано в разделе Определение типа авторизации, используемой клиентскими приложениями, чтобы наблюдать за переходом. Дополнительные сведения об использовании идентификатора Microsoft Entra для доступа к данным в учетной записи хранения см. в статье "Авторизация доступа к данным в служба хранилища Azure".
Когда вы будете уверены, что можете безопасно отклонять запросы, авторизованные с помощью общего ключа, задайте для свойства AllowSharedKeyAccess учетной записи хранения значение false.
Предупреждение
Если какие-либо клиенты в настоящее время получают доступ к данным в учетной записи хранения с общим ключом, корпорация Майкрософт рекомендует перенести эти клиенты в идентификатор Microsoft Entra ID, прежде чем запретить доступ к учетной записи хранения с общим ключом.
Привилегии, позволяющие разрешать или запрещать доступ по общему ключу
Чтобы задать свойство AllowSharedKeyAccess для учетной записи хранения, пользователь должен иметь разрешения на создание учетных записей хранения и управление ими. Роли управления доступом на основе ролей Azure (Azure RBAC), предоставляющие эти разрешения, включают в себя действия Microsoft.Storage/storageAccounts/write или Microsoft.Storage/storageAccounts/*. Встроенные роли с этим действием:
Эти роли не предоставляют доступ к данным в учетной записи хранения с помощью идентификатора Microsoft Entra. Однако они включают в себя разрешение Microsoft. Storage/storageAccounts/listkeys/Action, которое предоставляет доступ к ключам доступа учетной записи. Пользователь с этим разрешением может использовать ключи доступа учетной записи для доступа ко всем данным в учетной записи хранения.
Чтобы разрешать или запрещать пользователям доступ по общему ключу для учетной записи хранения, назначение ролей должно быть выполнено в области учетной записи хранения или выше. Дополнительные сведения об области роли см. в разделе Общие сведения об области для Azure RBAC.
Рекомендуется назначать эти роли только тем пользователям, которым необходима возможность создавать учетные записи хранения или обновлять их свойства. Используйте принцип наименьших привилегий, чтобы предоставлять пользователям минимальный набор разрешений, необходимый для выполнения их задач. Дополнительные сведения об управлении доступом с помощью Azure RBAC см. в разделе Рекомендации по использованию Azure RBAC.
Примечание.
Роли администратора классической подписки "администратор службы" и "соадминистратор" включают в себя эквивалент роли владельца Azure Resource Manager. Роль владельца включает в себя все действия, поэтому пользователь, которому назначена одна из этих административных ролей, также может создавать учетные записи хранения и управлять ими. Дополнительные сведения см. в статье о ролях Azure, ролях Microsoft Entra и классических ролях администратора подписки.
Отключение авторизации общего ключа
Используя учетную запись с необходимыми разрешениями, отключите авторизацию общего ключа в портал Azure с помощью PowerShell или с помощью Azure CLI.
Чтобы запретить авторизацию с помощью общего ключа для учетной записи хранения на портале Azure, выполните следующие действия.
Войдите в свою учетную запись хранения на портале Azure.
Выберите параметр Configuration (Конфигурация) в разделе Settings (Параметры).
Задайте для параметра Разрешить доступ с ключом к учетной записи хранения значение Отключено.
После запрета авторизации с использованием общего ключа выполнение запроса к учетной записи хранения с авторизацией по общему ключу будет завершаться ошибкой с кодом 403 (запрещено). Служба хранилища Azure возвращает ошибку, указывающую, что для учетной записи хранения не разрешена авторизация с использованием ключей.
Свойство AllowSharedKeyAccess поддерживается только для учетных записей хранения, использующих модель развертывания с помощью Azure Resource Manager. Сведения о том, какие учетные записи хранения используют модель развертывания Azure Resource Manager, см. в разделе Типы учетных записей хранения.
Проверка запрета доступа по общему ключу
Чтобы убедиться, что авторизация общего ключа больше не разрешена, можно запросить параметры учетной записи служба хранилища Azure с помощью следующей команды. Замените значения заполнителей в скобках своими собственными значениями.
az storage account show \
--name <storage-account-name> \
--resource-group <resource-group-name> \
--query "allow-shared-key-access"
Команда возвращает значение false , если авторизация общего ключа запрещена для учетной записи хранения.
Вы можете дополнительно проверить, попытавшись вызвать операцию данных с ключом доступа к учетной записи. В следующем примере выполняется попытка создания контейнера с использованием ключа доступа. Этот вызов завершится ошибкой, если для данной учетной записи хранения запрещена авторизация по общему ключу. Замените значения заполнителей в квадратных скобках собственными значениями:
az storage container create \
--account-name <storage-account-name> \
--name sample-container \
--account-key <key> \
--auth-mode key
Примечание.
Анонимные запросы не авторизованы и будут продолжаться, если вы настроили учетную запись хранения и контейнер для анонимного доступа на чтение. Дополнительные сведения см. в разделе "Настройка анонимного доступа на чтение" для контейнеров и больших двоичных объектов.
Мониторинг Политика Azure соответствия требованиям
После запрета доступа к общему ключу в нужных учетных записях хранения продолжайте отслеживать политику, созданную ранее для обеспечения постоянного соответствия. В зависимости от результатов мониторинга выполните соответствующие действия, в том числе изменение область политики, запретите доступ к общему ключу для дополнительных учетных записей или разрешить его для учетных записей, где требуется больше времени для исправления.
Обновите Политика Azure, чтобы запретить доступ к общему ключу
Чтобы начать применение назначения Политика Azure, созданного ранее для учетных записей политики служба хранилища, следует запретить доступ к общему ключу, измените эффект назначения политики, чтобы запретить авторизованным пользователям разрешить доступ к общему ключу в учетных записях хранения. Чтобы изменить эффект политики, выполните следующие действия.
На панели мониторинга Политика Azure найдите и выберите ранее созданное назначение политики.
Выберите Изменить назначение.
Перейдите на вкладку "Параметры ".
Un проверка отображаются только параметры, необходимые для ввода или проверки проверка box.
В раскрывающемся списке "Эффект" измените аудит на "Запрет", а затем нажмите кнопку "Рецензирование и сохранение".
На вкладке "Рецензирование и сохранение " просмотрите изменения, а затем нажмите кнопку "Сохранить".
Примечание.
Чтобы изменения политики вступают в силу, может потребоваться до 30 минут.