Руководство по Создание определения пользовательской политики

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

  • обеспечения безопасности;
  • управления затратами;
  • соблюдения требований организации (например к именованию или расположению).

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

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

Процесс создания пользовательской политики включает следующее:

  • определение бизнес-требований;
  • сопоставление каждого требования со свойством ресурса Azure;
  • сопоставление свойства c псевдонимами;
  • определение требуемого эффекта;
  • составление определения политики.

Предварительные требования

Если у вас еще нет подписки Azure, создайте бесплатную учетную запись, прежде чем начинать работу.

Определение требований

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

  • В каждой учетной записи хранения должна быть включена поддержка протокола HTTPS.
  • В каждой учетной записи хранения должна быть отключена поддержка протокола HTTP.

Требования должны четко определять состояние ресурса.

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

Определение свойств ресурсов

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

Есть много способов определить свойства ресурса Azure. В этом руководстве мы рассмотрим каждый из них:

  • Расширение Политики Azure для VS Code
  • Шаблоны Azure Resource Manager (шаблоны ARM)
    • экспорт существующего ресурса;
    • процедура создания;
    • шаблоны быстрого запуска (GitHub);
    • справочники по шаблонам.
  • Обозреватель ресурсов Azure

Просмотр ресурсов в расширении для VS Code

Расширение VS Code можно использовать для просмотра ресурсов в среде и свойств Resource Manager для каждого ресурса.

Шаблоны ARM

Существует несколько способов просмотреть шаблон ARM, который содержит нужное нам свойство.

Существующий ресурс на портале

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

Предупреждение

Шаблон Resource Manager, экспортированный на портал Azure, невозможно напрямую присвоить свойству deployment для шаблона Resource Manager в определении политики deployIfNotExists.

Снимок экрана: страница

Если открыть эту страницу для учетной записи хранения, отобразится примерно такой шаблон:

...
"resources": [{
    "comments": "Generalized from resource: '/subscriptions/{subscriptionId}/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount'.",
    "type": "Microsoft.Storage/storageAccounts",
    "sku": {
        "name": "Standard_LRS",
        "tier": "Standard"
    },
    "kind": "Storage",
    "name": "[parameters('storageAccounts_mystorageaccount_name')]",
    "apiVersion": "2018-07-01",
    "location": "westus",
    "tags": {
        "ms-resource-usage": "azure-cloud-shell"
    },
    "scale": null,
    "properties": {
        "networkAcls": {
            "bypass": "AzureServices",
            "virtualNetworkRules": [],
            "ipRules": [],
            "defaultAction": "Allow"
        },
        "supportsHttpsTrafficOnly": false,
        "encryption": {
            "services": {
                "file": {
                    "enabled": true
                },
                "blob": {
                    "enabled": true
                }
            },
            "keySource": "Microsoft.Storage"
        }
    },
    "dependsOn": []
}]
...

В разделе properties присутствует параметр supportsHttpsTrafficOnly, которому задано значение false. Это свойство похоже на то, которое нам требуется. Типу ресурса, type, присвоено значение Microsoft.Storage/storageAccounts. Тип позволяет ограничить применение политики для ресурсов только этого типа.

Создание ресурса на портале

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

На вкладке Просмотр и создание внизу есть ссылка Скачать шаблон для автоматизации. Ссылка открывает шаблон для создания ресурса, который мы настроили. В этом случае нас интересуют следующие сведения:

...
"supportsHttpsTrafficOnly": {
    "type": "bool"
}
...
"properties": {
    "accessTier": "[parameters('accessTier')]",
    "supportsHttpsTrafficOnly": "[parameters('supportsHttpsTrafficOnly')]"
}
...

Теперь мы знаем тип свойства и то, что нам нужно свойство supportsHttpsTrafficOnly.

Шаблоны быстрого запуска на GitHub

В разделе шаблонов быстрого запуска Azure на сайте GitHub доступны сотни шаблонов ARM для различных ресурсов. Эти шаблоны обеспечивают отличный способ отыскать требуемое свойство ресурса. Некоторые свойства могут только казаться требуемыми, а в действительности отвечать за что-нибудь другое.

Справочная документация по ресурсам

Чтобы убедиться в том, что supportsHttpsTrafficOnly — это требуемое нам свойство, сверьтесь со справочником по шаблонам ARM для ресурса учетной записи хранения у поставщика хранилища. Объект свойств содержит список допустимых параметров. Перейдя по ссылке StorageAccountPropertiesCreateParameters-object, можно просмотреть таблицу допустимых свойств. Свойство supportsHttpsTrafficOnly там присутствует, а его описание подтверждает, что это то свойство, которое нам требуется для обеспечения соответствия бизнес-требованиям.

Обозреватель ресурсов Azure

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

Найдите ресурс учетной записи хранения и просмотрите его свойства. Свойство supportsHttpsTrafficOnly здесь также присутствует. На вкладке Документация видно, что описание свойства соответствует сведениям из справочника, полученным нами ранее.

Поиск псевдонима свойства

Мы определили свойство ресурса, но нам нужно сопоставить это свойство с псевдонимом.

Есть несколько способов определить псевдонимы ресурса Azure. В этом руководстве мы рассмотрим каждый из них:

  • Расширение Политики Azure для VS Code
  • Azure CLI
  • Azure PowerShell

Получение псевдонимов в расширении VS Code

Расширение Политики Azure для расширения VS Code позволяет легко просматривать ресурсы и обнаруживать псевдонимы.

Примечание

Расширение VS Code предоставляет только свойства режима диспетчера ресурсов и не отображает свойств режима поставщика ресурсов.

Azure CLI

Для поиска псевдонимов ресурса в Azure CLI используется группа команд az provider. Выполним поиск по запросу "пространство имен Microsoft.Storage", руководствуясь ранее полученными сведениями об этом ресурсе Azure.

# Login first with az login if not using Cloud Shell

# Get Azure Policy aliases for type Microsoft.Storage
az provider show --namespace Microsoft.Storage --expand "resourceTypes/aliases" --query "resourceTypes[].aliases[].name"

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

Azure PowerShell

Для поиска псевдонимов ресурса в Azure PowerShell используется командлет Get-AzPolicyAlias. Выполним поиск по запросу "пространство имен Microsoft.Storage", руководствуясь ранее полученными сведениями об этом ресурсе Azure.

# Login first with Connect-AzAccount if not using Cloud Shell

# Use Get-AzPolicyAlias to list aliases for Microsoft.Storage
(Get-AzPolicyAlias -NamespaceMatch 'Microsoft.Storage').Aliases

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

Определение требуемого эффекта

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

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

Создание определения

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

{
    "properties": {
        "displayName": "<displayName>",
        "description": "<description>",
        "mode": "<mode>",
        "parameters": {
                <parameters>
        },
        "policyRule": {
            "if": {
                <rule>
            },
            "then": {
                "effect": "<effect>"
            }
        }
    }
}

Метаданные

Первые три компонента — это метаданные политики. Этим компонентам мы можем быстро задать значения, так как знаем, для чего создаем правило. Параметр mode касается главным образом тегов и расположения ресурсов. Так как нам не нужно ограничивать оценку только ресурсами, поддерживающими теги, зададим параметру mode значение all.

"displayName": "Deny storage accounts not using only HTTPS",
"description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
"mode": "all",

Параметры

Хотя мы не использовали параметр для изменения оценки, нам нужен параметр, допускающий изменение эффекта для устранения неполадок. Зададим параметр effectType и ограничим его значениями Deny и Disabled. Эти два варианта обеспечивают соответствие нашим бизнес-требованиям. Готовый блок параметров выглядит следующим образом:

"parameters": {
    "effectType": {
        "type": "string",
        "defaultValue": "Deny",
        "allowedValues": [
            "Deny",
            "Disabled"
        ],
        "metadata": {
            "displayName": "Effect",
            "description": "Enable or disable the execution of the policy"
        }
    }
},

Правило политики

Составление правила политики является последним шагом в создании определения пользовательской политики. Мы установили два критерия проверки:

  • Тип учетной записи хранения, type —Microsoft.Storage/storageAccounts.
  • Параметру supportsHttpsTrafficOnly учетной записи хранения не задано значение true.

Так как оба критерия должны удовлетворяться, воспользуемся логическим операторомallOf. Параметр effectType мы передадим эффекту, чтобы не делать статичное объявление. Готовое правило имеет следующий вид:

"if": {
    "allOf": [
        {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
        },
        {
            "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
            "notEquals": "true"
        }
    ]
},
"then": {
    "effect": "[parameters('effectType')]"
}

Завершенное определение

Определив все три части политики, мы получили такое завершенное определение:

{
    "properties": {
        "displayName": "Deny storage accounts not using only HTTPS",
        "description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
        "mode": "all",
        "parameters": {
            "effectType": {
                "type": "string",
                "defaultValue": "Deny",
                "allowedValues": [
                    "Deny",
                    "Disabled"
                ],
                "metadata": {
                    "displayName": "Effect",
                    "description": "Enable or disable the execution of the policy"
                }
            }
        },
        "policyRule": {
            "if": {
                "allOf": [
                    {
                        "field": "type",
                        "equals": "Microsoft.Storage/storageAccounts"
                    },
                    {
                        "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
                        "notEquals": "true"
                    }
                ]
            },
            "then": {
                "effect": "[parameters('effectType')]"
            }
        }
    }
}

Завершенное определение можно использовать для создания новой политики. Портал Azure и все пакеты SDK (для Azure CLI, Azure PowerShell и REST API) по-разному принимают определения, поэтому просмотрите команды для каждого средства, чтобы правильно использовать определения. Затем, используя эффект с заданными параметрами, назначьте определение требуемым ресурсам для управления безопасностью своих учетных записей хранения.

Очистка ресурсов

Если вы завершили работу с ресурсами по этому руководству, следуйте инструкциям ниже, чтобы удалить все созданные назначения или определения:

  1. Выберите Определения (или Назначения, если вы пытаетесь удалить назначение) в разделе Разработка в левой части страницы службы Политика Azure.

  2. Найдите новую инициативу либо определение политики (или назначение), которые вы хотите удалить.

  3. Щелкните строку правой кнопкой мыши или выберите многоточие в конце определения (или назначения), а затем выберите Удалить определение (или Удаление назначения).

Просмотр

В этом руководстве вы успешно выполнили следующие действия:

  • определили бизнес-требования;
  • сопоставили каждое требование со свойством ресурса Azure;
  • сопоставили свойства c псевдонимами;
  • определили требуемый эффект;
  • составили определение политики.

Дальнейшие действия

Используйте определение пользовательской политики для создания и назначения политики, как описано в следующей статье:

Create and assign a policy definition (Создание и назначение определения политики).