Что такое Политика 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 требуется:

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

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

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

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

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

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

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

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

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

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

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

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

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

• Управляйте ресурсами политики 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 использует систему явных запретов. Вместо этого необходимо исключить дочернюю группу управления или подписку из назначения на уровне группы управления. Затем назначьте менее строгое определение на уровне дочерней группы управления или подписки. Если какое-то назначение приводит к запрету ресурса, доступность такого ресурса можно восстановить, только изменив это запрещающее назначение.

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

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

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

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

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

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

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

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