Что такое служба "Политика Azure"?

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

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

Ниже приведены некоторые полезные действия по управлению, которые можно применить с помощью политики Azure:

• Убедитесь, что команда развертывает ресурсы Azure только в разрешенных регионах.
• Обеспечьте последовательное применение таксономических тегов.
• Требовать от ресурсов отправлять журналы диагностики в рабочую область Log Analytics.

Важно признать, что при внедрении Azure Arc вы можете расширить управление на основе политик в разных облачных поставщиках и даже в локальные центры обработки данных.

Все данные и объекты службы "Политика Azure" шифруются при хранении. Дополнительные сведения см. в статье Шифрование неактивных данных в Azure.

Обзор

Политика Azure оценивает ресурсы и действия в Azure, сравнивая свойства этих ресурсов с бизнес-правилами. Описания бизнес-правил в формате JSON называются определениями политик. Чтобы упростить управление, можно объединить несколько бизнес-правил для формирования инициативы политики, также называемой набором политик.

После формирования бизнес-правил определение политики или инициатива назначается на любой поддерживаемый Azure ресурс. Например, группы управления, подписки, группы ресурсов или отдельные ресурсы. Такое назначение применяется ко всем ресурсам в пределахобласти Resource Manager назначения. При необходимости можно исключить подобласти. Дополнительные сведения см. в статье Область в Политике Azure.

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

Анализ результатов оценки

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

• Ресурс создается или обновляется в области, для которой назначена политика.
• Рамка получает новое назначение для политики или инициативы.
• Политика или инициатива, уже назначенная определенной области, является обновленной.
• Стандартный цикл оценки соответствия требованиям, который происходит каждые 24 часа.

См. сведения о том, когда и как происходит оценка политики, в руководстве по триггерам оценки.

Управление реакцией на оценку

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

• Запретить изменение ресурса.
• Зарегистрируйте изменение в ресурсе.
• Измените ресурс перед изменением.
• Измените ресурс после внесения изменений.
• Разверните связанные ресурсы, соответствующие требованиям.
• Блокировать действия по ресурсам.

Политика Azure позволяет реализовать любой из таких бизнес-ответов путем применения эффектов. Эффекты задаются в разделе правило политики в определении политики.

Исправление несоответствующих ресурсов

В первую очередь эти эффекты влияют на создаваемые или обновляемые ресурсы, но Политика Azure поддерживает также работу с существующими ресурсами, не соответствующими требованиям, без необходимости изменять эти ресурсы. Дополнительные сведения о том, как сделать существующие ресурсы совместимыми, см. в статье "Исправление несоответствующих ресурсов с помощью политики Azure".

Начало работы

Политика Azure и Azure RBAC

Между возможностями Политики Azure и управления доступом на основе ролей Azure (Azure RBAC) есть ряд ключевых отличий. Служба "Политика Azure" оценивает состояние, проверяя свойства ресурсов, которые представлены в Resource Manager и свойства некоторых поставщиков ресурсов. Политика Azure гарантирует, что состояние ресурса всегда соответствует заданным бизнес-правилам, независимо от того, кто внес изменения и кто имеет разрешения на внесение изменений. Политика Azure через эффект DenyAction также может блокировать определенные действия по ресурсам. Некоторые ресурсы Политики Azure, такие как определения политик, определения инициатив и назначения, видны всем пользователям. Такая схема обеспечивает прозрачность для всех пользователей и служб, в среде которых настроены правила политики.

Azure RBAC контролирует действия пользователей в разных областях. Если управление действием требуется на основе сведений о пользователе, azure RBAC является правильным средством для использования. Даже если у пользователя есть доступ на выполнение действия, Политика Azure может заблокирует операции создания или обновления, если полученный ресурс не будет соответствовать требованиям.

Использование Azure RBAC и Политики Azure обеспечивает полный контроль над областью действия в Azure.

Разрешения Azure RBAC в Политике Azure

В службе "Политика Azure" предусмотрено несколько разрешений, известных как операции, двух разных поставщиков ресурсов:

• Microsoft.Authorization
• Microsoft.PolicyInsights

Большинство встроенных ролей предоставляют разрешения на доступ к ресурсам Политики Azure. Пользователь с ролью Участник политики ресурсов получает доступ к большинству операций службы "Политика Azure". Пользователь с ролью владелец имеет полные права. Роли участника и читателя имеют полный доступ на чтение для операций Политики Azure.

Участник может активировать исправление ресурсов, но не может создавать или обновлять определения и назначения. Администратор доступа пользователей необходим для предоставления управляемого удостоверения deployIfNotExists или modify назначения необходимых разрешений.

Если ни в одной роли нет нужных разрешений, создайте пользовательскую роль.

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

Требования к специальным разрешениям для Политика Azure с помощью Диспетчера виртуальная сеть Azure

Диспетчер виртуальных сетей Azure (предварительная версия) позволяет применять согласованные политики управления и безопасности к нескольким виртуальным сетям Azure во всей облачной инфраструктуре. Динамические группы Диспетчера виртуальных сетей Azure (AVNM) используют определения политики Azure для оценки членства в виртуальной сети в этих группах.

Чтобы создать, изменить или удалить динамические групповые политики Azure виртуальная сеть Manager, вам потребуется:

• Чтение и запись разрешений Azure RBAC в базовую политику
• Разрешения Azure RBAC для присоединения к группе сети. Авторизация классического администратора не поддерживается.

Требуется Microsoft.Network/networkManagers/networkGroups/join/actionразрешение поставщика ресурсов.

Какие ресурсы охватывает Политика Azure

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

Для некоторых поставщиков ресурсов, таких как конфигурация компьютера, Служба Azure Kubernetes и Azure Key Vault, поддерживается более глубокая интеграция для управления параметрами и объектами. Чтобы узнать больше, перейдите в режимы поставщика ресурсов.

Рекомендации по управлению политиками

Ниже приведены несколько указателей и советов, которые следует учитывать.

• Начните с эффекта audit или auditIfNotExists вместо принудительного эффекта (deny, modify, deployIfNotExists) для отслеживания того, как определение политики влияет на ресурсы в вашей среде. Если у вас уже есть скрипты для автомасштабирования приложений, установка эффекта принудительного применения может препятствовать таким задачам автоматизации.

• При создании определений и назначений следует учитывать иерархии организации. Мы рекомендуем создавать определения на более высоких уровнях, таких как группа управления или уровень подписки. Затем создайте назначение на следующем дочернем уровне. Если вы создаете определение в группе управления, назначение можно ограничить до подписки или группы ресурсов в этой группе управления.

• Рекомендуется создавать и назначать определения инициатив, даже если начинается с одного определения политики. Этот метод позволяет добавлять определения политик в инициативу позже, не увеличивая число назначений для управления.

  • Например, представьте, что вы создаете политику определения политикиDefA и добавляете ее в инициативу определения инициативыDefC. Если вы позже создадите другую политику определения политикиDefB с целями, похожими на policyDefA, вы можете добавить ее в рамках инициативыDefC и отслеживать их вместе.

  • После создания назначения инициативы определения политик, добавленные в инициативу, также становятся частью назначений этой инициативы.

  • Когда оценивается назначение инициативы, все политики этой инициативы также оцениваются. Если нужно оценить политику отдельно, то не включайте ее в инициативу.

• Управляйте ресурсами политики Azure как кодом с ручными проверками изменений в определениях политик, инициативах и назначениях. Дополнительные сведения о предлагаемых шаблонах и инструментах см. в статье "Проектирование политики Azure в качестве рабочих процессов кода".

Объекты Политики Azure

К объектам относятся определения политик, определения инициатив и назначения.

Определение политики

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

В службе "Политика Azure" предлагается несколько встроенных политик, доступных по умолчанию. Например:

• Разрешенные номера SKU учетной записи хранения (запрет). Определяет, находится ли развернутая учетная запись хранения в наборе размеров SKU. Действие политики — запрет всех учетных записей хранения, которые не соответствуют набору определенных размеров SKU.
• Разрешенный тип ресурса (запрет): определяет типы ресурсов, которые можно развернуть. Действие политики — запрет всех ресурсов, которые не являются частью определенного списка.
• Разрешенные расположения (запрет): ограничивает доступные расположения для новых ресурсов. Эта политика используется для соблюдения географических требований.
• Разрешенные номера SKU виртуальных машин (запрет). Указывает набор номеров SKU виртуальных машин, которые можно развернуть.
• Добавьте тег к ресурсам (изменить): применяет обязательный тег и его значение по умолчанию, если запрос развертывания не указывает его.
• Не разрешенные типы ресурсов (запретить): запрещает развертывание списка типов ресурсов.

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

Оценка политики происходит с помощью нескольких различных действий, таких как назначение или обновление политики. Полный список см. в разделе Policy evaluation triggers (Триггеры оценки политики).

Дополнительные сведения о структурах определений политик см. в статье "Основы структуры определений политик Azure".

Использование параметров политики помогает упростить управление политиками за счет сокращения числа определений политики, которые необходимо создать. Параметры можно определить при создании политики, чтобы сделать его более общим. Затем можно повторно использовать определение политики для различных сценариев. Для этого можно передавать различные значения при назначении определения политики. Например, можно указать один набор расположений для подписки.

Параметры определяются при создании определения политики. Определение параметра включает имя параметра и необязательные значения. Например, можно определить параметр политики, location. Затем при назначении политики ему можно присваивать различные значения, такие как EastUS или WestUS.

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

Определение инициативы

Определение инициативы — это совокупность определений политик, которые предназначены для достижения одной ключевой цели. Определение инициативы упрощает управление определениями политик и их назначение. Это достигается благодаря группированию набора политик в один отдельный элемент. Например, можно создать инициативу с названием Включить наблюдение в Microsoft Defender для облака, чтобы отслеживать все доступные рекомендации по безопасности в экземпляре Microsoft Defender для облака.

В соответствии с этой инициативой будут доступны такие определения политики:

• Мониторинг баз данных SQL без шифрования в Microsoft Defender для облака — Для мониторинга баз данных и серверов SQL без шифрования.
• Мониторинг уязвимостей ОС в Microsoft Defender для облака — Для мониторинга серверов, не соответствующих настроенному базовому плану.
• Мониторинг отсутствия Endpoint Protection в Microsoft Defender для облака— Для мониторинга серверов без установленного агента Endpoint Protection.

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

Например, в следующем сценарии у вас есть определение инициативы initiativeC с определениями политик policyA и policyB, где каждая ожидает свой тип параметра:

При определении параметров инициативы для initiativeC у вас есть три варианта:

• Используйте параметры определений политики в рамках этой инициативы: в этом примере allowedLocations и allowedSingleLocation станут параметрами инициативы для initiativeC.
• Укажите значения параметров определений политик в рамках этого определения инициативы. В этом примере можно указать список расположений для параметра allowedLocations и policyBallowedSingleLocation. При назначении этой инициативы можно также указать значения.
• Предоставьте список значений параметров, которые могут использоваться при присвоении этой инициативы. При назначении этой инициативы наследуемые параметры из определения политики в рамках инициативы могут иметь значения только из указанного списка.

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

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

Назначения

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

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

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

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

См. сведения о настройке назначений в руководстве по созданию назначения политики для идентификации ресурсов, не соответствующих требованиям. Также доступны пошаговые инструкции для PowerShell и Azure CLI. Сведения о структуре назначения см. в разделе "Структура назначения политик Azure".

Максимальное количество объектов службы "Политика Azure"

Ниже приведено максимальное количество для каждого типа объекта для службы "Политика Azure". Для определений запись Область означает группу управления или подписку. Для назначений и исключений запись области означает группу управления, подписку, группу ресурсов или отдельный ресурс.

Правила политики имеют больше ограничений на количество условий и их сложность. Дополнительные сведения см. в разделе "Ограничения правил политики".

Следующие шаги

Теперь, когда вы ознакомились с политикой Azure и некоторыми основными понятиями, воспользуйтесь приведенными ниже ссылками, чтобы узнать больше о службе.

• Глоссарий политики Azure.
• Основы структуры определения политики Azure.
• Быстрый старт: Создание назначения политики для выявления ресурсов, не соответствующих требованиям, в портале Azure.