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

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

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

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

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

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

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

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

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

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

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

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

Этап 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.

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

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

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

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

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

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

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

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

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

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

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

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

Вы также можете использовать задачу по исправлению вручную в ограниченном объеме или наборе ресурсов, чтобы проверить, как эти политики повлияют на вашу среду. Дополнительные сведения о создании задачи по исправлению см. в документации по политике 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. Обычно это подходит для крупных сценариев управления политиками с сложными требованиями.