Microsoft AZ-500: Архитектура сетевой безопасности — Руководство по подготовке

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Часть Microsoft Azure Security Engineer Associate AZ-500 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Архитектура сетевой безопасности Azure обеспечивает подключение с минимальными привилегиями, исходит из предположения о компрометации и использует непрерывный мониторинг. Она сочетает в себе микросегментацию внутри виртуальных сетей, плоскости управления с отслеживанием состояния для трафика «восток-запад» и исходящего трафика, защиту на периметре для конечных точек, доступных из интернета, и частный доступ к PaaS. Надежные архитектуры отдают приоритет доступу с учетом идентификационных данных на уровне приложений, сохраняя при этом строгие сетевые границы, явную маршрутизацию и проверяемую телеметрию.

Средства управления и сегментация виртуальной сети

Подсети — это первая граница сегментации. Размещайте рабочие нагрузки с одинаковым уровнем доверия, жизненным циклом и политиками в одной подсети; разделяйте уровни (веб, приложения, данные), чтобы можно было применять независимые политики и маршруты. Избегайте плоских «общих» подсетей, в которых смешиваются инструменты администрирования, jump-хосты и бизнес-нагрузки; они усложняют политики и увеличивают радиус поражения (blast radius).

Группы безопасности сети (NSG) применяют фильтрацию с отслеживанием состояния на уровнях L3–L4 для каждой подсети или сетевого интерфейса (NIC). Правила для входящего и исходящего трафика оцениваются по приоритету (сначала меньшее число), с неявным правилом DenyAll в конце. NSG отслеживают состояние: ответы на разрешенные потоки допускаются автоматически, поэтому вам редко понадобятся правила для эфемерных портов. С точки зрения эксплуатации, привязывайте NSG к подсетям для общего контроля, а затем уточняйте правила на критически важных сетевых интерфейсах. Всегда документируйте владельца, назначение и срок действия для любых «временных» разрешающих правил.

Группы безопасности приложений (ASG) позволяют ссылаться на группы ВМ по имени, а не по IP-адресу, поэтому правила остаются действительными при масштабировании и смене IP-адресов. Объединяйте ВМ в ASG на основе ролей (например, asg-web, asg-app) и формулируйте политики вида «asg-web → asg-app по TCP 443». Это уменьшает разрастание правил и операционные расхождения (operational drift).

Действующие правила безопасности являются результатом объединения NSG, примененных как к сетевому интерфейсу, так и к его подсети. Применяется наиболее конкретное совпадающее правило разрешения/запрета (по приоритету). Проверяйте правила с помощью «Effective security rules» на портале или через Network Watcher IP flow verify, чтобы выявить конфликтующие записи до окон развертывания.

Теги служб (Service tags, например, AzureLoadBalancer, Storage, Sql, Internet, VirtualNetwork) поддерживаются Microsoft и объединяют большие, динамические диапазоны IP-адресов в стабильные цели для правил. Отдавайте предпочтение тегам служб перед ручным ведением списков IP-адресов, чтобы избежать сбоев при ротации IP-адресов служб. Например, ограничьте исходящий трафик до Storage и Sql, запретив при этом широкий доступ в Интернет.

Микросегментация и принцип нулевого доверия (Zero Trust) реализуются путем:

Применения NSG с политикой «запрещено по умолчанию» и открытия только явных, минимально необходимых путей.
Использования ASG для кодирования назначения рабочих нагрузок.
Ограничения исходящего трафика с помощью тегов служб или фильтрации на основе FQDN через Azure Firewall.
Принудительного применения правила «нет публичных IP-адресов на серверах» и маршрутизации всего исходящего трафика через контролируемую точку проверки.

Пример: создайте правило NSG, разрешающее трафик от веб-уровня к уровню приложений по TLS с использованием ASG, и явно запретите весь остальной трафик с более высоким приоритетом, чем у неявного запрета, чтобы задокументировать намерение.

az network nsg rule create \
  --resource-group rg-sec \
  --nsg-name nsg-app \
  --name allow-web-to-app-443 \
  --priority 200 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web \
  --destination-asgs asg-app \
  --destination-port-ranges 443

Службы сетевой безопасности и защита периметра

Azure Firewall — это полностью управляемый высокодоступный межсетевой экран с централизованной политикой и отслеживанием состояния. Используйте его для:

Контроля трафика «восток-запад» и исходящего трафика, когда возможностей NSG недостаточно (доменные имена, проверка TLS).
DNAT для ограниченного входящего доступа, когда Application Gateway не подходит.
Централизованного сбора логов и аналитики угроз.

Группы коллекций правил содержат коллекции правил (сетевые, приложений, NAT) с приоритетами, которые определяют порядок их оценки. Внутри группы сначала оцениваются коллекции с более низким приоритетом; правила сопоставляются по наиболее конкретным критериям. Держите правила DNAT в отдельной группе с наивысшим приоритетом оценки, чтобы детерминированно перехватывать входящий трафик.

Сетевые правила фильтруют по 5 параметрам (IP/порт/протокол).
Правила приложений фильтруют по FQDN, категориям URL (в версии Premium) и могут использовать теги FQDN.
Правила NAT преобразуют публичные адреса/порты в частные для входящих сценариев.

Фильтрация на основе аналитики угроз блокирует известные вредоносные IP-адреса/домены. Запускайте в режиме оповещения (Alert) во время начальной настройки, а затем переключайтесь в режим блокировки (Deny) после устранения ложных срабатываний.

Функции Premium добавляют:

Проверку TLS с расшифровкой исходящего и входящего трафика, что обеспечивает видимость на уровне L7 и работу IDPS.
Систему обнаружения и предотвращения вторжений (IDPS) с сигнатурами и приоритизацией уязвимостей.
Фильтрацию URL и веб-категории для гранулярного контроля исходящего трафика.
Расширенные элементы управления сертификатами и политиками TLS.

С точки зрения эксплуатации, изолируйте межсетевой экран в выделенной подсети (AzureFirewallSubnet), направляйте на него весь интернет-трафик с помощью UDR (определяемых пользователем маршрутов) и включите Зоны доступности (Availability Zones). Используйте Политики межсетевого экрана (Firewall Policy), а не классические правила, для масштабируемого администрирования, наследования и разделения сред Dev/Test с общей базовой политикой.

Межсетевой экран для веб-приложений (WAF) защищает от атак на уровне L7 (SQLi, XSS).

В Application Gateway WAF защищает региональные приложения со сквозным шифрованием TLS и политиками для каждого сайта; он терминирует TLS-соединение клиента и опционально повторно шифрует трафик к бэкенду.
В Azure Front Door WAF защищает глобально распределенные приложения на периметре сети с интегрированным CDN, защитой от ботов и гео-контролем.

Создавайте политики WAF и связывайте их со шлюзами, прослушивателями или маршрутами. Сначала выберите режим обнаружения (Detection) для настройки, а затем режим предотвращения (Prevention) для блокировки. Используйте управляемые наборы правил (OWASP 3.x) и добавляйте пользовательские правила для ограничения скорости запросов или диапазонов IP-адресов. Настраивайте исключения (например, для определенных полей JSON или заголовков), чтобы уменьшить количество ложных срабатываний, не ослабляя общую защиту.

Защита от распределенных атак типа «отказ в обслуживании» (DDoS):

Уровень Basic — это постоянно включенная защита на уровне платформы, но она не предлагает телеметрию по отдельным ресурсам или настройку методов противодействия.
DDoS Protection: Уровень Network Protection добавляет адаптивную настройку для каждого публичного IP-адреса, автоматическое противодействие атакам, аналитику атак, оповещения, кредит на защиту от затрат и доступ к команде быстрого реагирования на DDoS (DDoS Rapid Response).

Включите Network Protection в виртуальных сетях, где размещены публичные IP-адреса (SKU Standard). Используйте телеметрию (метрики, диагностические логи) для наблюдения за векторами атак, жизненным циклом противодействия и его эффективностью. Проектируйте архитектуру так, чтобы защищаемые ресурсы находились за балансировщиками нагрузки или Application Gateway для поглощения объемных атак, и минимизируйте прямой доступ к ним из публичной сети. Сочетайте WAF и DDoS для создания эшелонированной защиты.

Частный доступ, гибридное подключение и маршрутизация

Private Link и частные конечные точки (private endpoints) предоставляют частный IP-доступ из вашей VNet к службам PaaS. Частная конечная точка — это сетевой интерфейс (NIC) в вашей подсети, сопоставленный с ресурсом PaaS; трафик остается в магистральной сети Microsoft. Этапы настройки:

Отключите публичный доступ к сети на ресурсе PaaS, чтобы предотвратить обход.
Разверните частные зоны DNS (например, privatelink.blob.core.windows.net) и свяжите их с VNet для бесшовного разрешения имен.
Управляйте утверждениями централизованно; рассмотрите возможность изоляции подписок/клиентов с помощью рабочего процесса ручного утверждения.

Конечные точки служб (Service endpoints) расширяют идентификатор вашей подсети на ресурсы PaaS через их публичные IP-адреса, позволяя брандмауэру PaaS ограничивать доступ к определенным подсетям. Они не создают частные IP-адреса, поэтому исходящий трафик проходит через публичную границу, но остается в сети Microsoft. Используйте политики конечных точек служб, чтобы разрешать доступ только к утвержденным учетным записям хранения. Для контейнеризированных рабочих нагрузок на виртуальных машинах IaaS убедитесь, что используется Azure CNI, чтобы IP-адреса подов/контейнеров были из подсети; в противном случае конечная точка службы не распознает источник, и доступ может быть невозможен.

Стратегия разрешения DNS:

Для Private Link убедитесь, что ваш путь разрешения DNS преобразует FQDN службы PaaS в IP-адрес частной конечной точки. Используйте частные зоны Azure DNS, условные пересылки (conditional forwarders) на локальном DNS или Azure DNS Private Resolver для гибридной пересылки.
Поддерживайте четкие авторитетные сопоставления split-horizon, чтобы избежать периодического разрешения имен через публичный DNS.

Гибридное подключение:

VPN Gateway: для подключений site-to-site используйте VPN на основе маршрутов (route-based) с IKEv2 и надежными шифрами. Используйте BGP для динамического обмена маршрутами, что упрощает расширение и отказоустойчивость. Применяйте VPN NAT при наличии пересекающихся адресных пространств. Для принудительного туннелирования анонсируйте маршрут 0.0.0.0/0 с локальной площадки через BGP или примените UDR, отправляющие 0/0 на виртуальное устройство (virtual appliance); при необходимости обеспечьте маршрут-исключение для частных диапазонов PaaS.
ExpressRoute: обеспечивает частное подключение; шифрование не является встроенной функцией. Используйте MACsec (для ExpressRoute Direct) или запускайте IPsec поверх ER для обеспечения конфиденциальности. Используйте BGP-комьюнити и фильтры маршрутов для пиринга Microsoft. Поддерживайте режим active-active с ECMP между каналами для повышения отказоустойчивости. Для принудительного туннелирования принимайте маршруты по умолчанию с локальной площадки и убедитесь, что конфликтующие UDR не создают “черных дыр” для интернет-трафика.

Пользовательские маршруты (UDR), NVA и приоритет:

Выбор маршрута использует сначала самое длинное совпадение префикса (longest prefix match), затем источник: UDR > BGP > системный маршрут. Неправильно примененные UDR 0/0 могут создавать “черные дыры” для обратного трафика; проверяйте это с помощью функции next-hop в Network Watcher.
Для NVA включите IP-пересылку (IP forwarding) на сетевых интерфейсах и разместите их за подсистемой балансировки нагрузки или Gateway Load Balancer для прозрачной и масштабируемой вставки. В управляемых сценариях отдавайте предпочтение Azure Firewall; когда требуются специфические функции от сторонних поставщиков, проектируйте высокую доступность (HA) с использованием нескольких зон доступности и балансировки нагрузки с проверками работоспособности (health probes).

Безопасное администрирование, мониторинг и телеметрия

Безопасное административное подключение:

Azure Bastion обеспечивает подключение по RDP/SSH через TLS из портала или нативного клиента, не раскрывая публичные IP-адреса виртуальных машин. Используйте SKU Standard для масштабирования, подключений на основе IP и предоставления общего доступа к сеансам по ссылкам. Ограничивайте доступ к Bastion с помощью RBAC и Just-in-Time.
JIT-доступ (Just-in-Time) к ВМ (часть Defender for Cloud) закрывает порты управления в NSG и открывает их по запросу на ограниченное время, с подтверждением и ограничением по IP-адресу источника. Комбинируйте с Bastion для создания архитектуры без публичных IP и для точного аудита действий.

Network Watcher предоставляет средства для операционной проверки и анализа инцидентов:

Журналы потоков NSG (v2) записываются в хранилище и могут быть отправлены в Traffic Analytics в Log Analytics для получения информации об основных источниках трафика, разрешенных/запрещенных потоках и их географии.
Connection troubleshoot активно тестирует сквозное подключение и сообщает, где именно заблокирован путь (NSG, UDR, DNS, брандмауэр).
Захват пакетов можно запускать по требованию или по оповещениям; используйте кольцевые буферы для экономии места в хранилище и захвата трафика только с нужных портов.
Проверки Effective routes и IP flow verify отображают решения о маршрутизации, принимаемые в реальном времени с учетом UDR, BGP и NSG; автоматизируйте эти проверки в рамках предварительных тестов в CI/CD.

Быстрое включение журналов потоков NSG и аналитики:

az network watcher flow-log configure \
  --resource-group rg-sec \
  --nsg nsg-app \
  --enabled true \
  --traffic-analytics true \
  --storage-account saflowlogs \
  --workspace /subscriptions/<sub>/resourceGroups/rg-la/providers/Microsoft.OperationalInsights/workspaces/la-workspace

Практический сценарий

Компания Starbucks модернизирует платформу управления заказами, перенося ее в Azure. Цели безопасности: отсутствие публичных IP-адресов на уровнях приложений и данных, строгий контроль исходящего трафика, глобальная защита веб-приложений и операционная видимость.

Создайте три подсети в каждом регионе: web, app, data, каждая со своей NSG и ASG, соответствующими роли.

Обоснование: Микросегментация на основе подсетей с использованием ASG реализует потоки с минимальными привилегиями (web→app 443, app→data 1433) и уменьшает радиус поражения. Раздельные NSG для каждого уровня предотвращают случайное связывание политик.

Разверните Azure Front Door Standard/Premium с политикой WAF в режиме Prevention, используя правила OWASP 3.x и пользовательские правила для ограничения скорости запросов и геоблокировок.

Обоснование: Глобальная пограничная защита поглощает объемный трафик, блокирует распространенные атаки L7 до того, как они достигнут региона, и снижает задержку с помощью anycast. Политики WAF на границе сети обеспечивают единообразное применение правил во всех регионах.

Разместите Application Gateway с WAF v2 в каждом регионе перед уровнем web; терминируйте TLS на App Gateway и повторно шифруйте трафик к бэкенду.

Обоснование: Региональная маршрутизация L7 и WAF дополняют Front Door, позволяя использовать mTLS для каждого приложения на бэкенде, привязку сеансов на основе cookie и развертывания blue/green, сохраняя при этом возможность инспекции трафика.

Включите защиту от DDoS: Network Protection на VNet, содержащих публичные IP-адреса Application Gateway.

Обоснование: Адаптивное смягчение атак для каждого IP, телеметрия и защита затрат снижают риск объемных атак, нацеленных на региональные точки входа. Применение на уровне VNet гарантирует, что все текущие и будущие публичные IP-адреса будут защищены без настройки каждого ресурса в отдельности.

Разверните Azure Firewall Premium в защищенном хабе; направьте весь исходящий трафик из подсетей app и data на него с помощью UDR. Включите инспекцию TLS и IDPS для исходящего трафика и настройте правила приложений, разрешающие доступ только к необходимым FQDN.

Обоснование: Централизованный контроль исходящего трафика с расшифровкой и обнаружением на основе сигнатур предотвращает связь с командными центрами (C&C) и эксфильтрацию данных. Правила приложений проще в обслуживании по сравнению с правилами на основе IP и соответствуют принципу Zero Trust для исходящего трафика.

Используйте Private Link для Azure SQL и Storage; отключите публичный доступ к сети и настройте частные зоны DNS, связанные со всеми VNet. Для контейнеризированных рабочих нагрузок используйте Azure CNI.

Обоснование: Приватные конечные точки (private endpoints) сохраняют пути данных в магистральной сети Azure и устраняют их доступность извне. Частный DNS обеспечивает бесшовное разрешение имен. Azure CNI гарантирует, что IP-адреса подов назначаются из подсети, что обеспечивает корректную работу Private Link и конечных точек служб.

Настройте ExpressRoute с двумя каналами в режиме active-active и анонсируйте локальные маршруты с помощью BGP; включите IPsec поверх ER для чувствительного трафика. Изначально не анонсируйте маршрут 0.0.0.0/0; сначала проведите пилотное принудительное туннелирование в промежуточной подсети.

Обоснование: ER обеспечивает предсказуемое частное подключение; многоуровневое шифрование защищает потоки с высокой степенью конфиденциальности. Контролируемое внедрение принудительного туннелирования предотвращает случайную блокировку доступа в интернет и позволяет проверить маршруты-исключения.

Предоставьте административный доступ через Azure Bastion и примените JIT-доступ (Just-in-Time) ко всем ВМ; удалите все публичные IP-адреса с серверов.

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

Включите журналы потоков NSG и Traffic Analytics, настройте отправку диагностических данных Firewall и WAF в Log Analytics и установите оповещения о срабатывании защиты от DDoS и всплесках блокировок WAF.

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

Внедрите Azure Policy для запрета публичных IP-адресов на сетевых интерфейсах (NIC), требования NSG для всех подсетей и аудита VNet без включенной защиты от DDoS; интегрируйте проверки политик в CI/CD.

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

← Управление удостоверениями и доступом · Все домены · Безопасность вычислительных ресурсов →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →