Применение принципов нулевого доверия к периферийной виртуальной сети с помощью Служб PaaS Azure

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

Дополнительные сведения о применении принципов нулевого доверия в среде IaaS Azure см. в разделе Обзор применения принципов нулевого доверия к Azure IaaS.

Автономная или периферийная сеть нулевого доверия для служб PaaS Azure

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

• База данных Azure SQL имеет собственный брандмауэр, который можно использовать для разрешения доступа клиентских IP-адресов, которым требуется доступ к серверу базы данных Azure SQL.
• Учетные записи хранения Azure имеют параметр конфигурации, разрешающий подключения из определенной виртуальной сети или блокировать доступ к общедоступной сети.
• служба приложение Azure поддерживает ограничения доступа для определения упорядоченного приоритетом списка разрешений и запретов, который управляет сетевым доступом к приложению.

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

Кроме того, сервисы PaaS могут использовать полные доменные имена (FQDN), которые преобразуются в динамически назначаемый общедоступный IP-адрес, выделяемый из пула общедоступных IP-адресов в определенном регионе для типа сервиса. Из-за этого вы не сможете разрешить трафик в определенную службу PaaS или из нее с помощью их общедоступного IP-адреса, который может измениться.

Корпорация Майкрософт рекомендует использовать частные конечные точки. Частная конечная точка — это интерфейс виртуальной сети, использующий частный IP-адрес из виртуальной сети. Этот сетевой интерфейс подключает вас конфиденциально и надежно к службе через Azure Private Link. Включив частную конечную точку, вы переносите службу в виртуальную сеть.

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

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

Эталонная архитектура

На следующей схеме показана общая эталонная архитектура для рабочих нагрузок на основе PaaS.

На схеме:

• Спицевая виртуальная сеть содержит компоненты для поддержки PaaS-приложения.
• Приложение PaaS — это двухуровневое приложение, которое использует службы приложение Azure для веб-приложения или внешнего интерфейса и База данных SQL Azure для реляционных баз данных.
• Каждый уровень содержится в выделенной подсети для входящего трафика с выделенной группой сетевой безопасности.
• Веб-уровень содержит выделенную подсеть для исходящего трафика.
• Доступ к приложению предоставляется через Шлюз приложений, содержащийся в собственной подсети.

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

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

• Одна виртуальная сеть
• Один Шлюз приложений Azure (App GW), включая Web Application Firewall (WAF)
• Три группы безопасности сети (с именем NSG на схеме) для баз данных, приложений и интерфейсных уровней
• Две группы безопасности приложений (с именем ASG на схеме)
• Две частные конечные точки

Кроме того, ресурсы для виртуальной сети концентратора развертываются в соответствующей подписке на подключение.

Что такое в этой статье

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

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

Шаг 1. Использование Microsoft Entra RBAC или настройка пользовательских ролей для сетевых ресурсов

Встроенные роли Microsoft Entra RBAC можно использовать для участников сети. Однако другим подходом является использование пользовательских ролей. Менеджерам сетей Spoke VNet не требуется полный доступ к сетевым ресурсам, который предоставляется ролью "Участник сети" в Microsoft Entra RBAC, но им необходимо больше разрешений, чем предусмотрено другими распространенными ролями. Настраиваемую роль можно использовать для ограничения доступа только к тому, что необходимо.

Один из простых способов реализации — развернуть настраиваемые роли, которые содержатся в Azure Landing Zone Reference Architecture.

Определенная роль, которую можно использовать, — это пользовательская роль управления сетями, которая имеет следующие разрешения:

• Прочитайте все в области охвата
• Любые действия с поставщиком сети
• Любые действия с поставщиком поддержки
• Любые действия с поставщиком ресурсов

Эту роль можно создать с помощью скриптов в репозитории эталонной архитектуры целевой зоны Azure на GitHub или с помощью Microsoft Entra ID с пользовательскими ролями Azure.

Шаг 2. Изолировать инфраструктуру в собственную группу ресурсов

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

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

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

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

Дополнительные рекомендации:

• Используйте группу безопасности для этой роли вместо указанных лиц.
• Управление доступом к группе безопасности с помощью методов управления корпоративными удостоверениями.

Если вы не используете политики, которые принудительно перенаправляют журналы в группах ресурсов, настройте это в журнале активностей группы ресурсов:

1. Найдите группу ресурсов в портале Azure.
2. Перейдите к журналу действий — экспорт журнала действий и выберите + Добавить параметр диагностики.
3. На экране параметра диагностики выберите все категории журналов (особенно безопасность) и отправьте их в соответствующие источники ведения журнала, например рабочую область Log Analytics для наблюдения или учетную запись хранения для долгосрочного хранения. Приведем пример:

Сведения о проверке этих журналов и оповещениях см. в разделе "Параметры диагностики ".

Демократизация подписки

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

Дополнительные сведения см. в принципах проектирования зоны приземления Azure.

Шаг 3. Создание группы безопасности сети для каждой подсети

Группы безопасности сети Azure используются для фильтрации сетевого трафика между ресурсами Azure в виртуальной сети Azure. Рекомендуется применить группу безопасности сети к каждой подсети. Это предусматривается политикой Azure по умолчанию при развертывании зон размещения Azure. В этой группе содержатся правила безопасности, которые разрешают или запрещают исходящий и входящий сетевой трафик нескольких типов ресурсов Azure. Для каждого правила можно указать исходные и конечные IP-адреса, протокол (например, TCP или UDP) и порт.

Для многоуровневых приложений рекомендуется создать выделенную группу безопасности сети (NSG) на следующей схеме для каждой подсети, в которую размещается сетевой компонент.

На схеме:

• Каждый уровень приложения имеет выделенную подсеть входящего трафика, например одну для веб-уровня и другую для уровня данных.
• приложение Azure Services имеет выделенную подсеть исходящего трафика для определенной службы приложений.
• Группа безопасности сети настроена для каждой из этих подсетей.

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

См. статью "Создание, изменение или удаление группы безопасности сети Azure" для управления параметрами групп безопасности сети.

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

Шаг 4. Защита трафика и ресурсов в виртуальной сети

В этом разделе описаны следующие рекомендации.

• Развертывание базовых правил запрета для групп безопасности сети
• Развертывание правил для конкретного приложения
• Планирование трафика управления в виртуальной сети
• Развертывание ведения журнала потоков группы безопасности сети

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

Ключевым элементом нулевого доверия является использование минимального уровня доступа. По умолчанию группы безопасности сети имеют правила разрешения . Добавив базовый план правил запрета, вы можете применить минимальный уровень доступа. После настройки создайте правило deny all для каждого входящего и исходящего трафика с приоритетом 4096. Это последний доступный пользовательский приоритет, что означает, что у вас по-прежнему есть оставшаяся область для настройки разрешенных действий.

Для этого в группе безопасности сети перейдите в правила безопасности исходящего трафика и нажмите кнопку "Добавить". Укажите следующие сведения.

• Источник: Любой
• Диапазоны исходных портов: *
• Назначение: Любое
• Служба: настраиваемая
• Диапазоны портов назначения: *
• Протокол: Любой
• Действие: Запретить
• Приоритет: 4096
• Имя: DenyAllOutbound
• Описание. Запрещает весь исходящий трафик, если только не разрешено.

Рассмотрим пример.

Повторите этот процесс с правилами входящего трафика, изменив имя и описание соответствующим образом.

На вкладке Правила безопасности для входящего трафика отображается значок предупреждения на правиле. Рассмотрим пример.

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

Это сообщение дает следующие два предупреждения:

• Azure Load Balancers по умолчанию не сможет получить доступ к ресурсам с помощью этой группы безопасности сети.
• Другие ресурсы в этой виртуальной сети по умолчанию не смогут получить доступ к ресурсам с помощью этой группы безопасности сети.

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

Если у вас есть определенные исходящие управляемые подключения, например контроллеры домена служб Active Directory (AD DS), частные виртуальные машины DNS или определенные внешние веб-сайты, они должны контролироваться здесь.

Альтернативные правила отказа в доступе

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

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

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

Развертывание правил для конкретного приложения

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

Используйте процесс "Управление группами безопасности сети: создание правила безопасности" для добавления правил в группы безопасности сети.

Чтобы защитить этот сценарий, добавьте следующие правила:

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

С помощью этих правил вы определили шаблон подключения "Нулевое доверие" для одного уровня приложений. Этот процесс можно повторить по мере необходимости для дополнительных потоков.

Планирование трафика управления в виртуальной сети

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

Общие сведения о полной эталонной архитектуре см. в статье "Применение принципов нулевого доверия к Azure IaaS".

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

Планирование развертываний

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

Развертывание ведения журнала потоков группы безопасности сети

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

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

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

Шаг 5. Защита входящего трафика и исходящего трафика для служб PaaS Azure

В этом разделе содержатся два шага, необходимых для защиты входящего трафика и исходящего трафика для служб PaaS:

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

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

Развертывание частных конечных точек для входящего трафика

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

При развертывании частных конечных точек настройте их следующим образом:

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

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

Для базы данных SQL Azure управляйте правилами брандмауэра IP-адресов на уровне сервера. Убедитесь, что доступ к общедоступной сети установлен в положение Отключить из панели сети в портале Azure.

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

Развертывание интеграции виртуальной сети для исходящего трафика

Помимо частных конечных точек для входящего трафика, включите интеграцию виртуальной сети. Каждый план Службы приложений может включать интеграцию с VNet, и при этом выделяется целая подсеть для Службы приложений. Дополнительные сведения см. в статье "Интеграция приложения с виртуальной сетью Azure".

Чтобы настроить вашу службу приложений, см. статью «Включение интеграции VNet в службе приложений Azure». Убедитесь, что вы помещаете его в подсеть, назначенную для исходящего трафика.

Рекомендации по DNS

В рамках использования частных конечных точек включите разрешение DNS ресурсов на их новые частные IP-адреса. Для получения инструкций по реализации этого различными способами см. конфигурацию DNS частного конечного узла.

Шаг 6. Безопасный доступ к виртуальной сети и приложению

Защита доступа к виртуальной сети и приложениям включает:

• Защита трафика в среде Azure в приложении
• Использование многофакторной проверки подлинности (MFA) и политик условного доступа для доступа пользователей к приложениям.

На следующей схеме показаны оба режима доступа в эталонной архитектуре.

Безопасный трафик в среде Azure для виртуальной сети и приложения

Большая часть работы трафика безопасности в среде Azure уже завершена. Сведения о настройке безопасных подключений между ресурсами хранилища и виртуальными машинами см. в статье "Применение принципов нулевого доверия к хранилищу Azure".

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

Использование политик MFA и условного доступа для доступа пользователей к приложениям

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

Во-первых, если приложение еще не интегрировано с Microsoft Entra ID, см. типы приложений для платформы удостоверений Microsoft.

Затем добавьте приложение в область действия политик доступа к идентификации и устройствам.

При настройке MFA с условным доступом и связанными политиками используйте рекомендуемый набор политик для нулевого доверия в качестве руководства. К ним относятся политики начальной точки , которые не требуют управления устройствами. В идеале устройства, которые обращаются к вашим виртуальным машинам, должны быть управляемыми, и вы можете внедрить уровень Enterprise, который рекомендуется для нулевого доверия. Дополнительные сведения см. в разделе "Общие политики нулевого доверия для управления идентификацией и доступом к устройствам".

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

Шаг 7. Включение расширенного обнаружения угроз и защиты

Виртуальная сеть, созданная в Azure, может быть защищена Microsoft Defender для облака так как другие ресурсы из ИТ-среды, работающей в Azure или локальной среде, также могут быть защищены.

Как упоминалось в других статьях данной серии, Defender для облачных решений — это инструмент управления позициями облачной безопасности (CSPM) и защиты облачных рабочих нагрузок (CWP), который предлагает рекомендации по безопасности, оповещения и расширенные функции, такие как адаптивная защита сети, чтобы помочь вам в процессе улучшения облачной безопасности.

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

Существуют планы Defender для облака, которые обеспечивают расширенную защиту рабочих нагрузок, включающую рекомендации по адаптивному усилению защиты сети для улучшения существующих правил группы безопасности сети. Рассмотрим пример.

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

Рекомендуемое обучение

• Защита ресурсов Azure с помощью управления доступом на основе ролей Azure (Azure RBAC)
• Настройка Azure Monitor и управление ими
• Настройка групп безопасности сети
• Проектирование и реализация сетевой безопасности
• Проектирование и реализация частного доступа к службам Azure

Дальнейшие шаги

Дополнительные статьи о применении принципов нулевого доверия к Azure см. в следующих статьях:

• Для Azure IaaS:
  • Обзор
  • Служба хранилища Azure
  • Виртуальные машины
  • Спицевые виртуальные сети
  • Виртуальные сети концентратора
• Виртуальный рабочий стол Azure
• Виртуальная глобальная сеть Azure
• Приложения IaaS в Amazon Web Services
• Microsoft Sentinel и Microsoft Defender XDR

Ссылки

• Профилактический подход к безопасности на основе модели "Никому не доверяй"
• Защита сетей с помощью модели "Никому не доверяй"
• Сеть для веб-приложений с Брандмауэром Azure и Шлюзом приложений, действующая по принципу “Никому не доверяй”
• Политики посадочной зоны Azure
• Общее удостоверение нулевого доверия и устройство между политиками
• Что собой представляет частная конечная точка?
• Конфигурация DNS частной конечной точки
• Интеграция приложения с виртуальной сетью Azure
• Использование частных конечных точек для приложений службы приложений
• Подключение к серверу SQL Azure с помощью частной конечной точки Azure