Введение ограничений, определяемых политиками

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

Использование политик DINE и Modify?

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

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

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

Примечание.

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

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

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

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

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

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

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

Важно!

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

• Disabled или DoNotEnforce
• Enabled или Default

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

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

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

Примечание.

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

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

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

Общие сведения о подходе

Далее на схеме приведена сводная информация о предлагаемом поэтапном подходе:

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

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

Примечание.

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

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

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

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

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

На этом снимке экрана показано, как использовать портал Azure, чтобы задать для режима принудительного применения значение Disabled при назначении политики. Disabled также называется DoNotEnforce.

Используйте шаблон 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 и соответствует методикам безопасного развертывания.

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

Важно!

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

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

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

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

Примечание.

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

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

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

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

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

Эффект политики	Режим применения политик	Запись журнала действий	Исправление
DINE	Enabled или Default	Да	Исправление неполадок, связанных с платформой, в масштабе после создания или обновления ресурса. Ручное создание задачи по исправлению требуется, если зависимый ресурс изменен или уже существовал перед назначением политики.
DINE	Disabled или DoNotEnforce	No	Требуется создание задачи по исправлению вручную.
Изменить	Enabled или Default	Да	Автоматическое исправление во время создания или обновления.
Изменить	Disabled или DoNotEnforce	No	Требуется создание задачи по исправлению вручную.
Запрет	Enabled или Default	Да	Создание или обновление отклонено.
Запрет	Disabled или DoNotEnforce	No	Создание или обновление разрешено. Требуется исправление вручную.
Аудит/AINE	Enabled или Default	Да	Требуется исправление вручную.
Аудит/AINE	Disabled или DoNotEnforce	No	Требуется исправление вручную.

Примечание.

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

Этап 2. Включение политик DINE и Modify для определенной политики или ограниченной области

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

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

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

Примечание.

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

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

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

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

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

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

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

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

Используйте шаблон ARM, чтобы задать для режима принудительного применения значение Default

В этом примере кода показано, как использовать шаблон 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 или Modify.

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

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

Этап 3. Включение политик DINE и Modify повсеместно

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

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

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

Ниже приведено высокоуровневое представление выполняемых на этом этапе шагов:

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

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

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

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