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

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

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

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

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

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

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

Обзор

Политика Azure оценивает ресурсы и действия в Azure, сравнивая свойства этих ресурсов с бизнес-правилами. Описания бизнес-правил в формате JSON называются определениями политик. Чтобы упростить управление, можно объединить несколько бизнес-правил в группу, которая называется инициативой политики или набором политик (policySet). Завершив создание бизнес-правил, вы можете назначить определение или инициативу политики любой области ресурсов из числа поддерживаемых в Azure, например группам управления, подпискам, группам ресурсов или отдельным ресурсам. Такое назначение применяется ко всем ресурсам в пределахобласти Resource Manager назначения. При необходимости можно исключить подобласти. Дополнительные сведения см. в статье Область в Политике Azure.

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

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

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

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

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

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

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

• запрет изменения ресурса;
• запись изменений ресурса в журнал;
• корректировка изменений до применения к ресурсу;
• корректировка изменений после применения к ресурсу;
• развертывание связанных ресурсов для обеспечения соответствия.
• Блокировать действия в ресурсах

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

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

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

Видеообзор

Ниже приведен обзор службы "Политика Azure" с веб-сайта Microsoft Build 2018. Слайды или видеоролик для загрузки можно найти на странице Govern your Azure environment through Azure Policy (Система управления средой Azure с помощью службы "Политика Azure") на канале Channel 9.

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

Политика 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 эффекта или auditIfNotExist действия вместо принудительного применения (deny, modify) deployIfNotExistдля отслеживания влияния определения политики на ресурсы в вашей среде. Если у вас уже есть скрипты для автомасштабирования приложений, установка эффекта принудительного применения может препятствовать таким задачам автоматизации, которые уже существуют.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, возьмем сценарий с определением инициативы — initiativeC и определениями политик — policyA и policyB, каждая из которых имеет различный тип параметра.

В этом случае при определении параметров инициативы initiativeC есть три варианта:

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

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

Дополнительные сведения см. в статье Структура определения инициативы в службе "Политика Azure".

Задания

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

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

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

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

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

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

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

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

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

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

• См. сведения о структуре определения политик.
• Назначение определения политики на портале.