Поделиться через

Утвердить рамки, управляемые политикой

  • Статья

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

Зачем использовать политики DINE и Modify?

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

Например, рассмотрим сценарий, в котором подготовлена новая подписка зоны высадки и помещена в группу управления "corp". Затем измените политики DINE и выполните следующие действия для подписки зоны посадки:

  • Включите Microsoft Defender для облака. Настройте экспорт Defender для облака в центральную рабочую область Log Analytics в управляющей подписке.
  • Включите Defender для Cloud для различных поддерживаемых услуг в зависимости от параметров, указанных в назначении политики.
  • Настройте журналы действий Azure для отправки в центральную рабочую область Log Analytics в подписке управления.
  • Настройте параметры диагностики для всех ресурсов, которые будут отправляться в центральную рабочую область Log Analytics в подписке управления.
  • Разверните необходимые агенты Azure Monitor для виртуальных машин и масштабируемых наборов виртуальных машин Azure, включая подключенные серверы Azure Arc. Подключите их к центральной рабочей области Log Analytics в управляющей подписке.

Заметка

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

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

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

Все назначенные политики помогают вам и владельцам целевой зоны оставаться в соответствии с требованиями. Фактические ресурсы рабочей нагрузки не развертываются с помощью DINE или изменения политик. Мы не рекомендуем это сделать. Дополнительные сведения см. в статье Следует ли использовать политику Azure для развертывания рабочих нагрузок?. Эти политики DINE развертывают или настраивают только вспомогательные ресурсы или параметры.

Эталонные реализации целевых зон Azure используют DINE политики Azure для помощи в достижении управления, основанного на политике, в среде Azure. Но может быть, вы не можете использовать политики DINE или Изменить, или вы не готовы включить этот тип эффект политики Azure из-за:

  • Политики соответствия нормативным требованиям, стандарты или ограничения законодательства.
  • Строгие процессы управления изменениями, требующие одобрения человека для каждого действия в среде Azure.
  • Отсутствие опытности, опыта и понимания того, как управлять политиками DINE и использовать их.
  • Организационные требования, согласно которым все конфигурации ресурсов рабочей нагрузки, включая основные, поддерживающие ресурсы и параметры, должны определяться инфраструктурой как код (IaC) командами, работающими с приложениями для рабочих нагрузок.

Если вы подходите под вышеуказанные примеры или аналогичные сценарии, эта статья поможет вам понять, как внедрить концептуальную архитектуру целевой зоны Azure и придерживаться её принципов проектирования . Хотя вы изначально не будете использовать определенные политики, вы можете постепенно включить их в будущем. Цель состоит в том, чтобы помочь вам достичь управления, управляемого политикой,.

Важный

В этой статье вы увидите два возможных значения, используемых для терминов режима принудительного применения:

  • Отключено или DoNotEnforce
  • Включено или по умолчанию

На портале Azure в режиме принудительного применения используются параметры "Отключено" и "Включено". Шаблоны Azure Resource Manager (ARM) и другие интерфейсы API используют DoNotEnforce и Default для одинаковых параметров.

Дополнительные сведения см. в режиме принудительного применения.

Если вы по-прежнему уверены, что ваша организация не может использовать политики DINE или Modify, в этой статье объясняется, как предотвратить (также известное как отключить) автоматические изменения политик в вашей среде Azure.

Заметка

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

Дополнительные сведения см. в этапах 2 и 3.

Поддержка селекторов ресурсов также применима для управления на основе политик, чтобы гарантировать соблюдение безопасных практик развертывания (SDP). Селекторы ресурсов позволяют постепенно развертывать назначения политик на основе таких факторов, как расположение ресурса, тип ресурса или наличие у ресурса местоположения. Дополнительные сведения см. в этом документе.

Обзор подхода

На следующей схеме приводится сводка предлагаемого поэтапного подхода:

Графика, показывающая общий обзор этапов DINE.

  1. Установите значение DoNotEnforce для режима применения в назначениях политик:
    • С помощью этой функции можно изменить поведение заданий, чтобы сделать политику только для аудита, не изменяя определение базовой политики.
    • Этот подход также позволяет вручную исправлять несоответствующие ресурсы, используя задачи исправления , если вы хотите.
  2. Задайте режим применения в назначениях политики на Default, чтобы вновь включить автоматическое восстановление назначений политики DINE на ограниченном масштабе:
    • Можно использовать всю среду, например группу управления песочницей.
    • Или вы можете использовать подписку на некритичную рабочую нагрузку.
  3. Установите режим принудительного исполнения Default для назначений политик в оставшихся политиках DINE во всей среде Azure.

Из-за ограничений нормативного соответствия некоторые клиенты не могут продвинуться дальше первого этапа. Это не проблема и поддерживается в этом состоянии при необходимости. Другие клиенты могут перейти к этапам 2 и 3, чтобы полностью внедрить политики DINE и Modify для поддержки управления, основанного на политиках, в своей среде Azure.

Заметка

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

Этап 1. Отключение автоматических действий политик DINE и изменение политик

При назначении политики по умолчанию применяется эффект , определенный в определении политики. Рекомендуется оставить определение политики как есть. Например, оставьте эффект назначения политики DeployIfNotExists.

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

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

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

Задайте режим принудительного применения отключенным на портале Azure.

Использование шаблона ARM для задания режима принудительного применения в DoNotEnforce

В этом примере кода показано, как использовать шаблон ARM для установки enforcementMode в DoNotEnforce в назначении политики. DoNotEnforce также называется Disabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "DoNotEnforce"
    … // other properties removed for display purposes
  }
}

С помощью режима принудительного применения можно увидеть влияние политики на существующие ресурсы, не инициируя её или создавая записи в журнале действий Azure. Этот сценарий обычно называется "What If" и соответствует методам безопасного развертывания.

Даже если режима применения задано значение , задачи исправления можно активировать вручную. Вы можете устранить конкретные ресурсы, не соответствующие требованиям. Кроме того, можно увидеть, что политика DINE или Modify сделала бы, если для режима принудительного применения было установлено значение Default.

Важный

Если для режима принудительного применения задано значение DoNotEnforce, записи в журнале действий Azure не создаются. Рассмотрите этот фактор, если вы хотите получать уведомления при создании ресурса, нарушающего правила.

Оставайтесь на этапе 1 постоянно

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

Может быть, вам нужно остаться в этом состоянии постоянно или в течение длительного периода, на годы. В этом случае может быть лучше принять эффект политики AuditIfNotExists (AINE) и связанные определения, а также задать режим принудительного применения для Default.

Заметка

Изменив политику AINE и установив режим принудительного применения для Default, вы по-прежнему достигаете той же цели отключения DINE.

При смене с DINE на AINE и возврате режима принудительного применения к Default как долгосрочному или постоянному подходу для первой фазы, вы восстановите записи в журнале действий Azure для статусов соответствия политическим требованиям. Рабочие процессы автоматизации можно создавать из этих записей журнала в общих операциях управления платформой.

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

Не забудьте обновить определение политики, чтобы принять и разрешить эффект назначения политики AuditIfNotExists.

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

Эффект политики Режим принудительного применения Запись журнала действий Действие исправления
ОБЕДАТЬ Включено или по умолчанию Да Исправление, инициируемое платформой, в широком масштабе после создания или обновления ресурсов. Ручное создание задачи исправления необходимо, если зависимый ресурс изменен или уже существовал до назначения политики.
ОБЕДАТЬ Отключено или «DoNotEnforce» Нет Необходимо создать задачу исправления вручную.
Модифицировать Включено или по умолчанию Да Автоматическое исправление во время создания или обновления.
Модифицировать Отключено или не применять Нет Необходимо создать задачу исправления вручную.
Отрицать Включено или по умолчанию Да Создание или обновление запрещено.
Отрицать Отключено или НеПрименять Нет Разрешено создание или обновление. Необходимо вручное исправление.
Аудит/AINE Включено или по умолчанию Да Требуется ручное исправление.
Аудит/AINE Отключено или Не Применять Нет Требуется ручное исправление.

Заметка

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

Этап 2: Включите DINE и измените политики в рамках определенной политики или уменьшенного масштаба

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

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

Чтобы выполнить эту процедуру, сначала необходимо определить политику или уменьшить область, которая будет использоваться для тестирования и пробовать возможности полной автоматизации политик DINE и Изменения политик.

Заметка

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

Этот подход также называется "канареечное развертывание".

Некоторые рекомендуемые примеры областей и политик показаны в следующей таблице:

Когда вы хотите... Выберите из этих областей Примеры политик для использования
— проверьте возможности автоматического исправления DINE/Modify.
— Проверьте, как все процессы развертывания и конвейеры CI/CD, включая тесты, могут быть затронуты.
— Проверьте, как это может повлиять на вашу рабочую нагрузку.		 — подписка на тестовую среду
— группа управления песочницей
— подписка на зону размещения рабочих нагрузок для непроизводственной среды
- корпоративной среды тестирования «canary»		 — настройте журналы действий Azure для потоковой передачи в указанную рабочую область Log Analytics.
— Развертывание конфигурации Defender для облака.
— включите Azure Monitor для виртуальных машин или масштабируемых наборов виртуальных машин.
— развертывание параметров диагностики в службах Azure.
— Потенциально можно включить только для определенных служб в пределах инициативы.

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

После того как вы определили политику или политики, а также сокращенную область их назначения, следующим шагом является назначение политики и установка режима принудительного применения для Default. Оставьте эффект политики, например, DeployIfNotExists или Modify, как есть на выбранной вами уменьшенной области.

Используйте портал Azure для включения режима принудительного применения

Этот скриншот показывает, как использовать портал Azure для установки режима принудительного применения Включено на назначение политики. "Включен" также называется "по умолчанию."

скриншот, показывающий установку режима принудительного применения в состояние «Включен» на портале Azure.

Использование шаблона ARM для задания режима принудительного применения по умолчанию

В этом примере кода показано, как использовать шаблон ARM для установки значения enforcementMode в Default в назначении политики. Default также называется Enabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "Default"
    … // other properties removed for display purposes
  }
}

Тестирование

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

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

Ниже приведены некоторые примеры тестирования.

  • Начальное развертывание рабочей нагрузки.
  • Развертывание кода или приложения в рабочей нагрузке.
  • 2 день операций и управления рабочей нагрузкой.
  • Вывод из эксплуатации рабочей нагрузки.

Этап 3. Включить DINE и изменить политики повсюду.

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

Мы предполагаем, что тестирование в конце этапа 2 успешно пройдено. Или, возможно, вы удовлетворены тем, что теперь понимаете, как политики DINE или изменения взаимодействуют с вашей рабочей нагрузкой. Теперь вы можете расширить использование политик DINE и Modify в остальной части среды Azure.

Чтобы продолжить, выполните действия, аналогичные шагам, описанным на этапе 2. На этот раз вы установите режим принудительного применения в Default для всех назначений политик DINE и Modify во всей среде Azure.

Ниже приведен общий обзор шагов, которые вы выполняете на этом этапе:

  • Удалите задания, используемые специально для тестирования во время этапа 2.
  • Перейдите к каждому назначению политики DINE и измените его в среде Azure, задав режим принудительного применения для Default. Этот процесс показан в примерах на этапе 2.
  • Создайте задачи исправления для существующих ресурсов, не соответствующих требованиям, следуя руководству в разделе Создание задачи исправления. Новые ресурсы будут автоматически приведены в соответствие, если они соответствуют правилам политики и условиям наличия.

Несмотря на то, что на этапе 3 мы рекомендуем установить режим применения в Default для всех политик DINE и Modify в вашей облачной среде Azure, этот выбор все еще остается на ваше усмотрение. Этот выбор можно сделать на основе каждой политики в соответствии с вашими потребностями и требованиями.

Расширенное управление политиками

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