Применение принципов нулевого доверия к периферийной виртуальной сети в Azure
Сводка. Чтобы применить принципы нулевого доверия к периферийной виртуальной сети в Azure, необходимо использовать контроль доступа на основе ролей (RBAC), изолировать подсети и виртуальные машины (группы ресурсов, группы безопасности сети и группы безопасности приложений), защитить трафик и ресурсы в виртуальных сетях и приложениях виртуальных машин, а также включить расширенное обнаружение угроз, оповещение и защиту.
Эта статья поможет применить принципы нулевого доверия к периферийной виртуальной сети (VNet) для рабочих нагрузок IaaS в Azure следующим образом:
| Принцип нулевого доверия | Определение | Встречалась |
|---|---|---|
| Прямая проверка | Всегда выполняйте аутентификацию и авторизацию на основе всех доступных точек данных. | Используйте группы безопасности приложений, чтобы убедиться, что отдельные сетевые адаптеры имеют разрешения для обмена данными по определенным каналам. |
| Использование доступа с минимальными привилегиями | Ограничьте доступ пользователей с помощью технологий JIT/JEA, а также адаптивных политик на основе рисков и средств защиты данных. | Не включите доступ 3389/RDP по умолчанию на любом канале. Используйте правильные разрешения роли для контекста периферийной связи. |
| Предполагайте наличие бреши в системе безопасности | Минимизируйте радиус поражения и возможность доступа к сегменту. Используйте сквозное шифрование и аналитику для обеспечения видимости, обнаружения угроз и усиления защиты. | Ограничить ненужный обмен данными между ресурсами. Убедитесь, что вы сможете войти в группы безопасности сети и что у вас есть правильная видимость аномального трафика. Отслеживайте изменения групп безопасности сети. |
Эта статья является частью серии статей, демонстрирующих применение принципов нулевого доверия в среде в Azure, которая включает в себя периферийную виртуальную сеть, в которой размещена рабочая нагрузка на основе виртуальных машин. Дополнительные сведения см. в разделе "Принципы применения нулевого доверия к Azure IaaS".
Эталонная архитектура
На следующей схеме показана общая эталонная архитектура для рабочих нагрузок на основе IaaS.
На схеме:
- Периферийная виртуальная сеть включает компоненты для поддержки приложения IaaS, состоящего из виртуальных машин.
- Приложение IaaS — это трехуровневое приложение, состоящее из двух виртуальных машин для каждого уровня: интерфейсного интерфейса, приложения и данных.
- Каждый уровень содержится в выделенной подсети с выделенной группой безопасности сети.
- Каждая роль виртуальной машины назначается группе безопасности приложений, соответствующей ее роли.
- Доступ к приложению предоставляется через Шлюз приложений, содержащийся в собственной подсети.
Приложение, показанное в эталонной архитектуре, соответствует стилю архитектуры уровня N
На следующей схеме показаны компоненты группы ресурсов для периферийной виртуальной сети в подписке Azure, отдельной от подписки для виртуальной сети концентратора.
На схеме все компоненты периферийной виртуальной сети содержатся в выделенной группе ресурсов:
- Одна виртуальная сеть
- Одна Шлюз приложений Azure (Приложение GW), включая Брандмауэр веб-приложений (WAF)
- Три группы безопасности сети, по одному для каждого уровня приложений
- Три группы безопасности приложений, по одному для каждого уровня приложений
Что такое в этой статье
Принципы нулевого доверия применяются к архитектуре от уровня клиента и каталога до назначения виртуальных машин группам безопасности приложений. В следующей таблице описаны рекомендации по защите этой архитектуры.
| Шаг | Задача | Применены принципы нулевого доверия |
|---|---|---|
| 1 | Используйте управление доступом на основе ролей Microsoft Entra (RBAC) или настройте пользовательские роли для сетевых ресурсов. | Использование доступа с минимальными привилегиями |
| 2 | Изоляция инфраструктуры в собственной группе ресурсов. | Предполагайте наличие бреши в системе безопасности |
| 3 | Создайте группу безопасности сети для каждой подсети. | Использование минимально привилегированного доступа Предполагайте наличие бреши в системе безопасности |
| 4 | Создайте группу безопасности приложений для каждой роли виртуальной машины. | Проверка явным образом Использование минимально привилегированного доступа Предполагайте наличие бреши в системе безопасности |
| 5 | Защита трафика и ресурсов в виртуальной сети: |
Проверка явным образом Использование минимально привилегированного доступа Предполагайте наличие бреши в системе безопасности |
| 6 | Безопасный доступ к виртуальной сети и приложению. | Использование минимально привилегированного доступа Предполагайте наличие бреши в системе безопасности |
| 7 | Включите расширенное обнаружение угроз, оповещение и защиту. | Предполагайте наличие бреши в системе безопасности |
Шаг 1. Использование Microsoft Entra RBAC или настройка пользовательских ролей для сетевых ресурсов
Встроенные роли Microsoft Entra RBAC можно использовать для сетевых участник. Однако другим подходом является использование пользовательских ролей. Не требуется полный доступ к сетевым ресурсам, предоставляемым ролью участника сети Microsoft Entra RBAC, но требуется больше разрешений, чем другие распространенные роли. Пользовательскую роль можно использовать для область доступа только к необходимым.
Один из простых способов реализации заключается в развертывании пользовательских ролей, найденных в эталонной архитектуре целевой зоны Azure.
Конкретная роль — настраиваемая роль управления сетями имеет следующие разрешения:
- Чтение всех в область
- Любые действия с поставщиком сети
- Любые действия с поставщиком поддержки
- Любые действия с поставщиком ресурсов
Эту роль можно создать с помощью скриптов для пользовательских ролей или с помощью идентификатора Microsoft Entra с помощью процесса, описанного в пользовательских ролях Azure — Azure RBAC.
Шаг 2. Изоляция инфраструктуры в собственной группе ресурсов
Изолируя сетевые ресурсы от вычислительных ресурсов, данных или ресурсов хранилища, вы снижаете вероятность возникновения разрешений. Кроме того, гарантируя, что все связанные ресурсы находятся в одной группе ресурсов, можно сделать одно назначение безопасности и улучшить управление ведением журнала и мониторингом этих ресурсов.
Вместо того, чтобы ресурсы периферийной сети были доступны в нескольких контекстах в общей группе ресурсов, создайте для него выделенную группу ресурсов. Эталонная архитектура, которую поддерживает эта статья, иллюстрирует эту концепцию.
На рисунке ресурсы и компоненты в эталонной архитектуре делятся на выделенные группы ресурсов для виртуальных машин, учетных записей хранения, ресурсов концентратора виртуальной сети и периферийных ресурсов виртуальной сети.
С помощью выделенной группы ресурсов можно назначить пользовательскую роль с помощью следующего процесса: руководство. Предоставление пользователю доступа к ресурсам Azure с помощью портал Azure — Azure RBAC.
Дополнительные рекомендации:
- Ссылка на группу безопасности для роли вместо именованных лиц.
- Управление доступом к группе безопасности с помощью шаблонов управления корпоративными удостоверениями.
Если вы не используете политики, которые применяют перенаправление журналов в группах ресурсов, настройте его в журнале действий для группы ресурсов: перейдите к журналам > действий экспорта журналов действий, а затем нажмите кнопку "Добавить параметр диагностики".
На экране параметра диагностики выберите все категории журналов (особенно безопасность) и отправьте их в соответствующие источники ведения журнала, например рабочую область Log Analytics для наблюдения или учетную запись хранения для долгосрочного хранения.
Демократизация подписки
Несмотря на то, что вы не связаны напрямую с сетью, следует запланировать подписку RBAC аналогичным образом. Помимо логического изоляции ресурсов по группе ресурсов, следует также изолировать подписку на основе бизнес-областей и владельцев портфеля. Подписка в качестве единицы управления должна быть узко область.
Дополнительные сведения о демократизации подписок см . в принципах проектирования целевой зоны Azure — Cloud Adoption Framework.
Вы настраиваете диагностика из категории "Безопасность" параметра диагностики в Azure Monitor, как показано здесь.
Ознакомьтесь с диагностическими Параметры, чтобы понять, как просматривать эти журналы и оповещать их.
Шаг 3. Создание группы безопасности сети для каждой подсети
Группы безопасности сети Azure используются для фильтрации сетевого трафика между ресурсами Azure в виртуальной сети Azure. Рекомендуется применить группу безопасности сети к каждой подсети, которая применяется через политику Azure по умолчанию при развертывании целевых зон Azure. В этой группе содержатся правила безопасности, которые разрешают или запрещают исходящий и входящий сетевой трафик нескольких типов ресурсов Azure. Для каждого правила можно указать источник и назначение, порт и протокол.
Для многоуровневого приложения на основе виртуальных машин рекомендуется создать выделенную группу безопасности сети (NSG на следующем рисунке) для каждой подсети, на котором размещена роль виртуальной машины.
На схеме:
- Каждый уровень приложения размещается в выделенной подсети, такой как интерфейсный уровень, уровень приложений и уровень данных.
- Группа безопасности сети настроена для каждой из этих подсетей.
Настройка групп безопасности сети по-другому, чем показано на рисунке, может привести к неправильной настройке некоторых или всех групп безопасности сети и может создавать проблемы при устранении неполадок. Кроме того, это может затруднить мониторинг и ведение журнала.
Создайте группу безопасности сети с помощью этого процесса: создание, изменение или удаление группы безопасности сети Azure
Ознакомьтесь с группами безопасности сети, чтобы понять, как их можно использовать для защиты среды.
Шаг 4. Создание группы безопасности приложений для каждой роли виртуальной машины
Группы безопасности приложений позволяют настроить сетевую безопасность как естественное расширение в структуре приложения. Это позволяет группировать виртуальные машины и определять политики безопасности сети на основе таких групп. Вы можете повторно использовать политику безопасности в нужном масштабе без обслуживания явных IP-адресов вручную. Платформа сама обрабатывает явные IP-адреса и множество наборов правил, позволяя вам сосредоточиться на бизнес-логике.
В рабочей нагрузке определите определенные роли виртуальной машины. Затем создайте группу безопасности приложений для каждой роли. В эталонной архитектуре представлены три группы безопасности приложений.
На схеме:
- Для поддержки этого приложения создаются три группы безопасности приложений, по одному для каждого уровня: интерфейсный интерфейс, приложение и данные.
- Каждая виртуальная машина назначается соответствующей группе безопасности приложений для своей роли (красный текст на схеме).
Дополнительные сведения о группах безопасности приложений и их назначении виртуальным машинам см. в обзоре групп безопасности приложений Azure.
Примечание.
Если вы используете подсистемы балансировки нагрузки, использование IP-адреса подсистемы балансировки нагрузки в группах безопасности сети требуется, так как группы безопасности приложений не могут область подсистему балансировки нагрузки.
Шаг 5. Защита трафика и ресурсов в виртуальной сети
В этом разделе рассматриваются следующие рекомендации.
- Развертывание базовых правил запрета для групп безопасности сети
- Развертывание определенных правил для групп безопасности приложений
- Планирование трафика управления в виртуальной сети
- Развертывание ведения журнала потоков группы безопасности сети
Развертывание базовых правил запрета для групп безопасности сети
Ключевым элементом нулевого доверия является использование минимального уровня доступа. По умолчанию группы безопасности сети имеют разрешенные правила. Добавив базовый план правил запрета, вы можете применить минимальный уровень доступа.
После подготовки создайте правило запрета во всех правилах для входящего и исходящего трафика с приоритетом 4096. Это последний пользовательский приоритет, который означает, что оставшиеся область для настройки действий Allow.
В группе безопасности сети перейдите к правилам безопасности исходящего трафика и нажмите кнопку "Добавить". Укажите следующие сведения.
- Источник: Любой
- Диапазоны исходных портов: *
- Назначение: Любое
- Служба: настраиваемая
- Диапазоны портов назначения: *
- Протокол: Любой
- Действие: Запретить
- Приоритет: 4096
- Имя: DenyAllOutbound
- Описание. Запрещает весь исходящий трафик, если только не разрешено.
Рассмотрим пример.
Повторите этот процесс с правилами входящего трафика, изменив имя и описание соответствующим образом. Вы заметите, что на вкладке правил безопасности для входящего трафика отображается предупреждение правила, как показано здесь.
Если щелкнуть правило и прокрутить вниз, вы увидите дополнительные сведения, как показано здесь.
Это сообщение дает следующие два предупреждения:
- Azure Load Balancers по умолчанию не сможет получить доступ к ресурсам с помощью этой группы безопасности сети.
- Другие ресурсы в этой виртуальной сети по умолчанию не смогут получить доступ к ресурсам с помощью этой группы безопасности сети.
Для нашей цели в нулевом доверии это то, как это должно быть. Это означает, что только потому, что что-то находится в этой виртуальной сети, не означает, что он имеет немедленный доступ к вашим ресурсам. Для каждого шаблона трафика необходимо создать правило явно, разрешающее его, и это необходимо сделать с минимальным количеством разрешений. Таким образом, если у вас есть определенные исходящие подключения для управления, например для контроллеров домена домен Active Directory служб (AD DS), частных DNS-виртуальных машин или определенных внешних веб-сайтов, их необходимо контролировать здесь.
Альтернативные правила запрета
Если вы используете Брандмауэр Azure для управления исходящими подключениями, то вместо того, чтобы запретить исходящий трафик, вы можете оставить все исходящие подключения открытыми. В рамках реализации Брандмауэр Azure вы настроите таблицу маршрутов, которая отправляет маршрут по умолчанию (0.0.0.0.0/0/0) в брандмауэр, который обрабатывает трафик за пределами виртуальной сети.
Затем можно создать запрет на весь исходящий трафик виртуальной сети или разрешить все исходящие (но безопасные элементы с их правилами входящего трафика).
Дополнительные сведения о таблицах Брандмауэр Azure и маршрутизации, чтобы понять, как их можно использовать для дальнейшего повышения безопасности среды.
Правила управления виртуальными машинами
Чтобы настроить виртуальные машины с поддержкой входа Microsoft Entra Login, Anti-Malware и автоматических обновлений, необходимо разрешить следующие исходящие подключения. Многие из них являются полным доменным именем, то есть для правил FQDN требуется либо Брандмауэр Azure, либо вы создадите более сложный план. рекомендуется Брандмауэр Azure.
Исходящие подключения:
- На порту 443:
- enterpriseregistration.windows.net
- settings-win.data.microsoft.com
- sls.update.microsoft.com
- v10.events.data.microsoft.com
- login.microsoftonline.com
- pas.windows.net
- 169.254.169.254
- Через порт 80:
- ctldl.windowsupdate.com
- www.msftconnecttest.com
- На порту 123:
- 40.119.6.228
- На порту 1688:
- 40.83.235.53
Развертывание определенных правил для групп безопасности приложений
Определите шаблоны трафика с минимальным количеством разрешений и только после явно разрешенных путей. Ниже приведен пример схемы использования групп безопасности приложений для определения шаблонов сетевого трафика в группах безопасности сети для периферийной виртуальной сети, которая используется вместе с центральной виртуальной сетью. Это рекомендуемая конфигурация.
В качестве другого примера ниже приведена конфигурация автономной виртуальной сети, в которой Брандмауэр веб-приложений помещается в подсеть Шлюз приложений периферийной виртуальной сети.
Вам нужны следующие правила группы безопасности сети:
- Разрешение интернет-трафика в подсеть APP GW (HTTPS 443).
- Разрешение трафика из подсети APP GW на виртуальные машины переднего уровня (HTTPS 433).
- Разрешение трафика с виртуальных машин переднего уровня на подсистему балансировки нагрузки уровня приложения (HTTPS 443).
- Разрешение трафика из подсистемы балансировки нагрузки уровня приложения на виртуальные машины уровня приложений (HTTPS 443).
- Разрешение трафика с виртуальных машин уровня приложения на подсистему балансировки нагрузки уровня данных (SQL 1433).
- Разрешение трафика из подсистемы балансировки нагрузки уровня данных на виртуальные машины уровня данных (SQL 1433).
- Разрешение трафика между виртуальными машинами уровня данных (SQL 1433)
Сначала настройте шаблон SQL, а затем повторите процесс с оставшимися уровнями. В следующих разделах приведены конфигурации правил, ограничивающих сетевой трафик для одного уровня приложений.
Правило 5. Разрешить трафик из виртуальных машин уровня приложений в подсистему балансировки нагрузки уровня данных (SQL 1433)
В группе безопасности сети для подсети уровня приложений перейдите к правилам безопасности для входящего трафика и нажмите кнопку "Добавить". Заполните список следующим образом:
- Источник: группа безопасности приложений
- Группы безопасности исходного приложения: выберите группу безопасности приложений уровня бизнеса
- Диапазоны исходных портов: 1433 (иногда исходный трафик может поступать из разных портов, и если этот шаблон возникает, можно добавить диапазоны исходных портов в *, чтобы разрешить любой исходный порт. Целевой порт является более значительным, и некоторые рекомендации всегда используются * для исходного порта)
- Назначение: IP-адреса.
- Диапазоны IP-адресов назначения или CIDR: явный IP-адрес подсистемы балансировки нагрузки
- Здесь необходимо использовать явный IP-адрес, так как вы не можете связать подсистему балансировки нагрузки с группой безопасности приложений.
- Вы можете запланировать схему IP-адресов или развернуть подсистему балансировки нагрузки и ссылаться на IP-адрес, который он назначен.
- Служба: MS SQL
- Диапазоны портов назначения: он автоматически заполняется для порта 1433
- Протокол: этот параметр автоматически выбирается для TCP
- Действие: Разрешить
- Приоритет: значение от 100 до 4096. Вы можете начать с 105.
- Имя: Allow-App-Tier-to-Data-LB-Inbound
- Описание. Разрешает входящий доступ из подсистемы балансировки нагрузки уровня данных на виртуальные машины уровня приложений.
После завершения появится синий значок для информационных оповещений в правиле. Щелкнув правило, появится следующее сообщение:
- "Правила, использующие группы безопасности приложений, могут применяться только в том случае, если группы безопасности приложений связаны с сетевыми интерфейсами в одной виртуальной сети".
Рассмотрим пример.
Правило применяется только в том случае, если эта группа безопасности приложений используется в этой сети.
Наконец, в той же группе безопасности сети перейдите к правилам безопасности исходящего трафика и нажмите кнопку "Добавить". Заполните список, аналогичный примеру, изменив входящий трафик на исходящий.
Правило 6. Разрешить трафик из подсистемы балансировки нагрузки уровня данных на виртуальные машины уровня данных (SQL 1433)
В группе безопасности сети для подсети уровня данных перейдите к правилам безопасности для входящего трафика и нажмите кнопку "Добавить". Заполните список следующим образом:
- Источник: IP-адрес
- Исходный IP-адрес: IP-адрес подсистемы балансировки нагрузки
- Диапазоны исходных портов: 1433
- Назначение: группа безопасности приложений
- Целевые группы безопасности приложений: выберите группу безопасности приложений уровня данных
- Служба: MS SQL
- Диапазоны портов назначения: он автоматически заполняется для порта 1433.
- Протокол. Этот протокол автоматически выбирается для TCP.
- Действие: Разрешить
- Приоритет: значение от 100 до 4096. Вы можете начать с 105.
- Имя: Allow-SQL-LB-to-SQL-VMs-Inbound
- Описание. Разрешает входящий доступ к виртуальным машинам уровня данных на основе SQL из подсистемы балансировки нагрузки уровня данных.
В той же группе безопасности сети перейдите к правилам безопасности исходящего трафика и нажмите кнопку "Добавить". Заполните список, как показано в примере, изменив входящий трафик на исходящий.
Правило 7. Разрешить трафик между виртуальными машинами уровня данных (SQL 1433)
В группе безопасности сети для подсети уровня данных перейдите к правилам безопасности для входящего трафика и нажмите кнопку "Добавить". Заполните список следующим образом:
- Источник: группа безопасности приложений.
- Целевые группы безопасности приложений: выберите группу безопасности приложений уровня данных
- Диапазоны исходных портов: 1433
- Назначение: группы безопасности приложений
- Целевые группы безопасности приложений: выберите группу безопасности приложений уровня данных
- Служба: MS SQL
- Диапазоны портов назначения: он автоматически заполняется для порта 1433.
- Протокол. Этот протокол автоматически выбирается для TCP.
- Действие: Разрешить
- Приоритет: значение от 100 до 4096. Вы можете начать с 105.
- Имя: Allow-SQL-VM-to-SQL-VM-Inbound
- Описание. Разрешает входящий доступ между виртуальными машинами уровня данных на основе SQL.
В той же группе безопасности сети перейдите к правилам безопасности исходящего трафика и нажмите кнопку "Добавить". Заполните список в качестве предыдущего списка, изменив входящий трафик на исходящий.
С помощью этих трех правил вы определили шаблон подключения "Нулевое доверие" для одного уровня приложений. Этот процесс можно повторить по мере необходимости для дополнительных потоков.
Планирование трафика управления в виртуальной сети
Помимо конкретного трафика приложения, необходимо запланировать трафик управления. Однако трафик управления обычно происходит за пределами периферийной виртуальной сети. Требуются дополнительные правила. Во-первых, вам потребуется понять определенные порты и источники, из которым будет поступать трафик управления. Как правило, весь трафик управления должен передаваться из брандмауэра или другого NVA, расположенного в центральной сети для периферийных устройств.
Ознакомьтесь с полной эталонной архитектурой в статье "Принципы применения нулевого доверия к Azure IaaS".
Это зависит от конкретных потребностей управления. Однако правила брандмауэра (модуль) и правила в группе безопасности сети должны использоваться для явного разрешения подключений на стороне платформы и в сетевой сети рабочей нагрузки.
Развертывание ведения журнала потоков группы безопасности сети
Даже если ваша группа безопасности сети блокирует ненужный трафик, не означает, что ваши цели выполнены. Необходимо по-прежнему наблюдать за трафиком, происходящим за пределами явных шаблонов, чтобы узнать, происходит ли атака.
Чтобы включить ведение журнала потоков группы безопасности сети, можно выполнить инструкцию по журналу потока сетевого трафика в виртуальную машину и с виртуальной машины , созданной в существующей группе безопасности сети.
Примечание.
- Учетная запись хранения должна соответствовать руководству по учетной записи хранения Zero Trust.
- При необходимости доступ к журналам должен быть ограничен.
- Они также должны передаваться в Log Analytics и Sentinel по мере необходимости.
Шаг 6. Безопасный доступ к виртуальной сети и приложению
Защита доступа к виртуальной сети и приложению включает:
- Защита трафика в среде Azure в приложении.
- Использование многофакторной проверки подлинности и политик условного доступа для доступа пользователей к приложению.
На следующей схеме показаны оба этих режима доступа в эталонной архитектуре.
Безопасный трафик в среде Azure для виртуальной сети и приложения
Большая часть работы трафика безопасности в среде Azure уже завершена. Безопасные подключения между ресурсами хранилища и виртуальными машинами настраиваются в принципах применения нулевого доверия к хранилищу Azure.
Сведения о защите доступа от ресурсов концентратора к виртуальной сети см. в статье "Применение принципов нулевого доверия к центральной виртуальной сети в Azure".
Использование многофакторной проверки подлинности и политик условного доступа для доступа пользователей к приложению
В этой статье принципы применения нулевого доверия к виртуальным машинам рекомендуется защищать запросы доступа непосредственно к виртуальным машинам с многофакторной проверкой подлинности и условным доступом. Эти запросы, скорее всего, от администраторов и разработчиков. Следующим шагом является защита доступа к приложению с помощью многофакторной проверки подлинности и условного доступа. Это относится ко всем пользователям, которые обращаются к приложению.
Во-первых, если приложение еще не интегрировано с идентификатором Microsoft Entra, см. типы приложений для платформа удостоверений Майкрософт.
Затем добавьте приложение в область политик доступа к удостоверениям и устройствам.
При настройке многофакторной проверки подлинности с условным доступом и связанными политиками используйте рекомендуемый набор политик для нулевого доверия в качестве руководства. К ним относятся политики начальной точки, которые не требуют управления устройствами. В идеале устройства, обращающиеся к виртуальным машинам, управляются, и вы можете реализовать уровень Enterprise, который рекомендуется для нулевого доверия. Дополнительные сведения см. в разделе "Общие политики удостоверений нулевого доверия" и политик доступа к устройствам.
На следующей схеме показаны рекомендуемые политики для нулевого доверия.
Шаг 7. Включение расширенного обнаружения угроз и защиты
Виртуальная сеть, созданная в Azure, уже может быть защищена Microsoft Defender для облака (MDC), так как другие ресурсы из ИТ-среды, работающей в Azure или локальной среде, также могут быть защищены.
Как упоминание в других статьях из этой серии, Microsoft Defender для облака — это средство управления постурами Cloud Security (CSPM) и Cloud Workload Protection (CWP), которое предлагает Рекомендации безопасности, оповещения и расширенные функции, такие как адаптивная защита сети, чтобы помочь вам в процессе разработки Cloud Security. Чтобы лучше визуализировать, где Defender для облака вписывается в более широкий ландшафт безопасности Майкрософт, см. статью "Эталонные архитектуры кибербезопасности Майкрософт".
В этой статье подробно не рассматриваются Microsoft Defender для облака, но важно понимать, что Microsoft Defender для облака работает на основе политик Azure и журналов, входящих в рабочую область Log Analytics. После включения подписок с периферийной виртуальной сетью и связанными ресурсами вы сможете просмотреть рекомендации по улучшению их состояния безопасности. Вы можете отфильтровать эти Рекомендации дальше по тактике MITRE, группе ресурсов и т. д. Рассмотрите возможность приоритета разрешения Рекомендации, которые оказывают большее влияние на оценку безопасности вашей организации.
Ниже приведен пример на портале Microsoft Defender для облака.
Если вы решили подключить один из планов Defender для облака, которые предлагают расширенную защиту рабочих нагрузок, он включает адаптивную защиту сети Рекомендации для улучшения существующих правил группы безопасности сети. Рассмотрим пример.
Вы можете принять рекомендацию, выбрав "Применить", создав новое правило группы безопасности сети или изменив существующее.
Рекомендуемое обучение
- Защита ресурсов Azure с помощью управления доступом на основе ролей Azure (Azure RBAC)
- Настройка Azure Monitor и управление ими
- Настройка групп безопасности сети
- Проектирование и реализация сетевой безопасности
- Безопасный доступ к приложениям с помощью служб удостоверений Azure
Дополнительные сведения о безопасности в Azure см. в каталоге Майкрософт:
Безопасность в Azure | Microsoft Learn
Next Steps
Дополнительные статьи о применении принципов нулевого доверия к Azure см. в следующих статьях:
- Обзор Azure IaaS
- Виртуальный рабочий стол Azure
- Виртуальная глобальная сеть Azure
- Приложения IaaS в Amazon Web Services
- Microsoft Sentinel и XDR в Microsoft Defender
Технические иллюстрации
На этом плакате представлено одностраничное представление компонентов Azure IaaS в качестве эталонных и логических архитектур, а также шаги по обеспечению того, чтобы эти компоненты имели принципы "никогда не доверять, всегда проверяйте" применяемые принципы модели нулевого доверия.
| Позиция | Description |
|---|---|
 PDF | Visio Обновлено за март 2024 г. |
Используйте эту иллюстрацию вместе с этой статьей: общие сведения о применении принципов нулевого доверия к Azure IaaS Связанные руководства по решению |
На этом плакате представлены эталонные и логические архитектуры и подробные конфигурации отдельных компонентов Нулевого доверия для Azure IaaS. Используйте страницы этого плаката для отдельных ИТ-отделов или специальностей или с версией файла Microsoft Visio, настройте схемы для вашей инфраструктуры.
| Позиция | Description |
|---|---|
 PDF | Visio Обновлено за март 2024 г. |
Используйте эти схемы вместе со статьями, начинающиеся здесь: применение принципов нулевого доверия к azure IaaS Связанные руководства по решению |
Дополнительные технические иллюстрации см . здесь.
Ссылки
- Профилактический подход к безопасности на основе модели "Никому не доверяй"
- Защита сетей с помощью модели "Никому не доверяй"
- Сеть нулевого доверия для веб-приложений с Брандмауэр Azure и Шлюз приложений — Центр архитектуры Azure
- Политики целевой зоны Azure
- Общие политики удостоверений и устройств с нулевым доверием
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по