Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
По мере расширения вашей среды увеличивается спрос на контролируемый конвейер непрерывного развертывания (CD) с прогрессивным управлением степенью воздействия. Соответственно, корпорация Майкрософт рекомендует командам DevOps соблюдать платформу безопасных методов развертывания (SDP). Безопасное развертывание определений и назначений Политики Azure помогает ограничить влияние непреднамеренных действий ресурсов политики.
Высокоуровневый подход к реализации SDP с помощью политики Azure заключается в постепенном развертывании назначений политик по уровням для обнаружения изменений политики, влияющих на среду на ранних этапах, прежде чем она влияет на критически важную облачную инфраструктуру.
Уровни развертывания можно упорядочить различными способами. В этом руководстве уровни разделены различными регионами Azure с уровнем 5 , представляющими некритичные, низкие расположения трафика и уровень 0 , обозначающие наиболее важные, самые высокие расположения трафика.
Шаги для безопасного развертывания назначений политики Azure с эффектами запрета или добавления
Используйте следующую блок-схему в качестве справочного материала для работы с применением платформы SDP к назначениям политик Azure, которые используют эффекты deny или append.
Примечание.
Дополнительные сведения о эффектах политики Azure см. в статье "Общие сведения о работе эффектов".
Номера шагов блок-схемы:
Выбрав определение политики, назначьте политику на уровне высокого уровня, включаемую во все уровни развертывания. Примените селекторы ресурсов , чтобы сузить применимость к наименее критическому уровню с помощью
"kind": "resource location"свойства. Настройте тип эффектаauditс помощью переопределений назначений. Пример селектора с расположениемeastUSи эффектом какaudit:"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS" ] }] }], "overrides":[{ "kind": "policyEffect", "value": "Audit" }]После развертывания назначения и завершения первоначальной проверки соответствия убедитесь, что результат соответствия соответствует ожидаемому.
Кроме того, следует настроить автоматические тесты, которые выполняют проверки соответствия требованиям. Проверка соответствия должна охватывать следующую логику:
- Сбор результатов соответствия
- Если результаты соответствия как ожидалось, процесс должен продолжаться.
- Если результаты соответствия не соответствуют ожиданиям, конвейер должен завершиться ошибкой, и вы должны начать отладку.
Например, можно настроить проверку соответствия с помощью других средств в определенном конвейере непрерывной интеграции или непрерывного развертывания (CI/CD).
На каждом этапе развертывания проверка работоспособности приложения должна подтвердить стабильность службы и влияние политики. Если результаты не соответствуют ожиданиям из-за конфигурации приложения, проведите рефакторинг приложения, если это необходимо.
Повторите, разверните значения свойств селектора ресурсов, чтобы включить следующие уровни. расположения и проверка ожидаемых результатов соответствия требованиям и работоспособности приложений. Пример селектора с добавленным значением местоположения.
"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS", "westUS"] }] }]После успешного назначения политики всем уровням с помощью
auditрежима конвейер должен активировать задачу, которая изменяет эффектdenyполитики и сбрасывает селекторы ресурсов в расположение, связанное с уровнем 0. Пример селектора с одним регионом и набором эффектов для отмены:"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS" ] }] }], "overrides":[{ "kind": "policyEffect", "value": "Deny" }]После изменения эффекта автоматические тесты должны проверить, выполняется ли принудительное применение должным образом.
Повторите, включив дополнительные уровни в конфигурацию селектора ресурсов.
Повторите этот процесс для всех рабочих уровней.
Действия по безопасному развертыванию назначений Политика Azure с изменениями или развертыванием эффектовIfNotExists
Действия для политик с эффектами modify или deployIfNotExists аналогичны шагам, приведенным ранее, с дополнительным использованием режима принудительного применения и активацией задачи по исправлению.
Просмотрите следующую блок-схему с измененными шагами 5-9.
Номера шагов блок-схемы:
Выбрав определение политики, назначьте политику на уровне высокого уровня, включаемую во все уровни развертывания. Примените селекторы ресурсов , чтобы сузить применимость к наименее критическому уровню с помощью
"kind": "resource location"свойства. Настройте режим принудительного применения назначения в DoNotEnforce. Пример селектора сeastUSи режимомПрименения в качестве DoNotEnforce:"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS" ] }] }], "enforcementMode": "DoNotEnforce"После развертывания назначения и завершения первоначальной проверки соответствия убедитесь, что результат соответствия соответствует ожидаемому.
Кроме того, следует настроить автоматические тесты, которые выполняют проверки соответствия требованиям. Проверка соответствия должна охватывать следующую логику:
- Сбор результатов соответствия
- Если результаты соответствия как ожидалось, процесс должен продолжаться.
- Если результаты соответствия не соответствуют ожиданиям, конвейер должен завершиться ошибкой, и вы должны начать отладку.
Проверку соответствия можно настроить с помощью других средств в конвейере непрерывной интеграции и непрерывного развертывания (CI/CD).
На каждом этапе развертывания проверка работоспособности приложения должна подтвердить стабильность службы и влияние политики. Если результаты не соответствуют ожиданиям из-за конфигурации приложения, проведите рефакторинг приложения, если это необходимо.
Вы также можете запускать задачи исправления для исправления имеющихся несоответствующих ресурсов. Убедитесь, что задачи исправления приводят ресурсы в соответствие с ожидаемыми требованиями.
Повторите, разверив значения свойств селектора ресурсов, чтобы включить расположения следующего уровня и проверяя ожидаемые результаты соответствия и работоспособности приложения. Пример селектора с добавленным значением местоположения.
"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS", "westUS"] }] }]После успешного назначения политики всем уровням с помощью режима DoNotEnforce конвейер должен активировать задачу, которая изменяет политику
enforcementModeна включение по умолчанию и сбрасывает селекторы ресурсов в расположение, связанное с уровнем 0. Пример селектора с одним регионом и набором эффектов для отмены:"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS" ] }] }], "enforcementMode": "Default",После изменения эффекта автоматические тесты должны проверить, выполняется ли принудительное применение должным образом.
Повторите, включив дополнительные уровни в конфигурацию селектора ресурсов.
Повторите этот процесс для всех рабочих уровней.
Этапы безопасного обновления версии встроенного определения в назначении политики Azure
В рамках существующего назначения примените переопределения , чтобы обновить версию определения для наименее критического уровня. Мы используем сочетание переопределений, чтобы изменить версию определения и селекторы в условии переопределений для того, чтобы сузить применимость на основе свойства
"kind": "resource location". Все ресурсы, которые находятся за пределами указанных расположений, будут оцениваться по версии, указанной в свойстве верхнего уровняdefinitionVersionв назначении. Пример переопределения обновляет версию определения на2.0.*и применяет её только к ресурсам вEastUs."overrides":[{ "kind": "definitionVersion", "value": "2.0.*", "selectors": [{ "kind": "resourceLocation", "in": [ "eastus"] }] }]После обновления назначения и завершения первоначальной проверки соответствия убедитесь, что результат соответствия соответствует ожидаемому.
Кроме того, следует настроить автоматические тесты, которые выполняют проверки соответствия требованиям. Проверка соответствия должна охватывать следующую логику:
- Сбор результатов соответствия
- Если результаты соответствия как ожидалось, процесс должен продолжаться.
- Если результаты соответствия не соответствуют ожиданиям, конвейер должен завершиться ошибкой, и вы должны начать отладку.
Например, можно настроить проверку соответствия с помощью других средств в определенном конвейере непрерывной интеграции или непрерывного развертывания (CI/CD).
На каждом этапе развертывания проверка работоспособности приложения должна подтвердить стабильность службы и влияние политики. Если результаты не соответствуют ожиданиям из-за конфигурации приложения, проведите рефакторинг приложения, если это необходимо.
Повторите, разверните значения свойств селектора ресурсов, чтобы включить следующие уровни. расположения и проверка ожидаемых результатов соответствия требованиям и работоспособности приложений. Пример с добавленным значением расположения:
"overrides":[{ "kind": "definitionVersion", "value": "2.0", "selectors": [{ "kind": "resourceLocation", "in": [ "eastus", "westus"] }] }]После добавления всех необходимых местоположений в _selectors можно удалить замещение и обновить свойство definitionVersion в задании.
"properties": {
"displayName": "Enforce resource naming rules",
"description": "Force resource names to begin with DeptA and end with -LC",
"definitionVersion": "2.0.*",
}
Следующие шаги
- Узнайте, как программно создавать политики.
- Просмотрите Политика Azure как рабочие процессы кода.
- Изучите рекомендации Корпорации Майкрософт по вопросам безопасного развертывания.
- Просмотрите несоответствующие ресурсы с помощью Политика Azure.