Использование политик Azure для создания дополнительного уровня безопасности и улучшения операций

Мы можем назначить управление доступом на основе ролей (RBAC) в Azure Resource Manager, и это отличный инструмент для делегирования и реализации принципа наименьших привилегий в Microsoft Azure. Однако это не единственный доступный сервис для ограничения и определения границ в Microsoft Azure. Мы также можем воспользоваться службами . Политики Azure оцениваются при создании ресурсов Azure и позволяют организации проверить, какие ресурсы соответствуют или не соответствуют существующим политикам. Мы можем воспользоваться преимуществами политик Azure, чтобы создать дополнительный уровень безопасности и реализовать политики в предопределенной области, которая может быть , группой управления или . Объединив политики Azure с RBAC, мы получим более надежную защиту.

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

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

Использование политики Azure

Лучший способ понять, как работают политики Azure, — использовать простой сценарий. Давайте создадим политику Azure, которая позволяет предоставлять только определенное количество ресурсов (виртуальных машин в этой статье), и эта политика будет назначена на уровне подписки.

Войдя на портал Azure, перейдите в раздел «Подписки» (выполнив поиск или щелкнув слева). Будет показан список со всеми существующими подписками. Нажмите на нужный. В новой колонке, содержащей всю информацию о данной подписке, нажмите Политики, которая находится в разделе .

В новой колонке мы будем автоматически перенаправлены на Compliance, который даст общее представление обо всех политиках и инициативах Azure, применяемых к среде. Администратор облака может фильтровать по области действия, типу, состоянию соответствия и конкретной строке.

Сейчас мы собираемся создать нашу самую первую политику Azure. Нажмите «Назначить политику». На новой странице наш первый шаг (пункт 1 ниже) — щелкнуть … и список доступных определений будет указан справа. Мы собираемся выбрать Разрешенные типы ресурсов. После этого нам нужно пометить нашу текущую политику Azure (в нашем случае ), и нам нужно определить Scope. В нашем случае это будет уровень подписки.

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

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

• Вычислительные/виртуальные машины
• Compute/virtualmachines/diagnosticSettings
• Вычислительные/виртуальные машины/расширения
• Compute/virtualMachines/metricDefinitions

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

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

В верхней панели мы можем управлять текущей политикой (пункт 1 ниже). В середине экрана в мы можем проверить политики, в данном случае «Запретить », что означает, что новые ресурсы, не соответствующие этой политике, не будут развернуты. Также у нас есть два вида (пункт 2) Non-Compliant и Events. На первой вкладке мы увидим список всех ресурсов, которые не следуют текущей политике (это могут быть ресурсы, созданные до политики, что является текущим случаем).

Когда мы нажимаем «События», у нас появляется список всех пользователей, которым была запрещена текущая политика. Мы можем получить дополнительную информацию, нажав …, а затем Показать журналы действий, чтобы открыть колонку журнала действий. Это позволяет нам углубиться и получить последнюю часть информации, например, какой объект пытался создать пользователь, в какое время и так далее. (Для получения дополнительной информации о службе журнала действий см. эту предыдущую статью.)

Тестирование новой политики

Первый тест — создать любой новый ресурс, не являющийся виртуальной машиной. В приведенном ниже примере мы видим, что объект, который мы создаем, представляет собой новую группу доступности, и мы видим ошибку Были ошибки проверки. Нажмите здесь Посмотреть подробности. Когда мы нажмем на нее, будет отображена более подробная информация.

Устранение неполадок с политиками Azure

Политика Azure, которую мы создали в этой статье, позволяет предоставлять только виртуальные машины. Но виртуальная машина — это больше, чем просто виртуальная машина — когда вы выделяете виртуальную машину, вы затрагиваете сетевые интерфейсы, DevLabs для автоматического отключения, расширения, группы безопасности сети, общедоступные IP-адреса и многое другое.

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

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

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

Пройдите через JSON — я предлагаю вам сделать это, попивая кофе и расслабляясь! Дайте себе время ознакомиться с информацией, и вы найдете блокировщики — в нашем примере я пропустил ресурс DevTestLab, который по умолчанию автоматически отключает ВМ. Когда эта функция включена, наша подготовка не удалась.

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

• DevTestLab/Лаборатории
• Сеть/сетевые интерфейсы
• Сеть/группы сетевой безопасности
• Сетевой/публичный IP-адрес

Очень важно тщательно протестировать любую новую политику Azure, поскольку не каждый оператор/администратор будет создавать виртуальную машину одинаковым образом. Допустим, если один оператор вообще не использует NSG, он не получит ошибку, если в политике отсутствует ресурс Microsoft.Network/networkSecurityGroups.

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