Microsoft AZ-700: Сетевая безопасность — Руководство по подготовке

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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

Контроль сетевого доступа: проектирование NSG и ASG, маршрутизация и пиринг

Группы безопасности сети (NSG) остаются основным и недорогим механизмом для фильтрации входящего и исходящего трафика для подсетей и сетевых интерфейсов (NIC). NSG работают с отслеживанием состояния, могут ссылаться на теги служб (например, Internet, Storage) и поддерживают группы безопасности приложений (ASG) для группировки сетевых интерфейсов виртуальных машин и масштабирования обслуживания правил для больших парков ВМ. Применяйте NSG на уровне подсети для общей сегментации и на уровне сетевого интерфейса для специфичных исключений на хосте; помните, что оцениваются оба уровня, и применяется наиболее строгий результирующий набор правил. Распространенные ошибки включают игнорирование правил по умолчанию (системные правила запрета/разрешения с высокими приоритетами), неправильный порядок приоритетов (приоритеты правил NSG варьируются от 100 до 4096; системные по умолчанию имеют приоритет 65 000+), а также предположение, что NSG предоставляют функции IDS/антивируса — они не проверяют содержимое пакетов. При пиринге виртуальных сетей NSG по-прежнему управляют трафиком между ними, но определяемые пользователем маршруты (UDR) могут переопределять системные маршруты и непреднамеренно приводить к потере трафика, если следующий переход (например, на Azure Firewall) недоступен в данном контексте. При проектировании необходимо найти компромисс между стоимостью и простотой NSG/ASG и видимостью и расширенными возможностями централизованного брандмауэра: NSG дешевы и производительны для грубой фильтрации; используйте управляемый брандмауэр для централизованного ведения журналов, управления DNAT/NAT и политик на уровне приложений.

Контроль периметра и внутреннего трафика (east-west): Azure Firewall, DNAT, правила приложений и IDPS

Azure Firewall предоставляет управляемый брандмауэр периметра с отслеживанием состояния, поддерживающий DNAT, SNAT и правила на уровне приложений. Размещайте его в выделенной подсети AzureFirewallSubnet и используйте таблицы маршрутизации, чтобы направлять внутренний (east-west) трафик в архитектуре «звезда» через брандмауэр для проверки. Используйте коллекции правил DNAT для публикации внутренних служб: укажите диапазоны источников, IP-адрес назначения, порты назначения и транслированный IP-адрес:порт. Коллекции правил приложений позволяют разрешать доступ по FQDN для HTTP/S (например, *.microsoft.com), что избавляет от необходимости поддерживать хрупкие списки разрешенных IP-адресов. Для глубокой проверки пакетов и инспекции зашифрованного трафика Azure Firewall Premium добавляет механизм IDPS и проверку TLS, что сопряжено с более высокой стоимостью, операционной сложностью управления сертификатами и потенциальными задержками. Сторонние виртуальные сетевые модули (NVA) остаются хорошим выбором, если вам требуются специализированные сигнатуры или особые характеристики производительности. Решения по масштабированию и отказоустойчивости включают использование автомасштабирования брандмауэра (v2) или развертываний, избыточных между зонами, в сравнении с фиксированными экземплярами: автомасштабирование снимает ограничения по пропускной способности, но стоит дороже. Отслеживайте метрики и журналы брандмауэра в Log Analytics, чтобы выявлять исчерпание портов DNAT/SNAT и при необходимости корректировать порядок правил и количество общедоступных IP-адресов.

Azure Firewall Standard: фильтрация на уровнях L3–L7 с отслеживанием состояния, NAT/DNAT, правила для приложений и сети, управляемая служба с опциями автомасштабирования и встроенным ведением журналов.
Azure Firewall Premium: включает функции Standard, а также IDPS, проверку TLS, расширенный анализ угроз и фильтрацию URL-адресов; имеет более высокую стоимость и требует управления сертификатами/ключами для проверки TLS.

Защита на уровне приложений, Private Link и DDoS

Защищайте веб-приложения на границе сети с помощью WAF и распределенных граничных служб. Application Gateway WAF_v2 предоставляет региональный WAF с интеграцией в VNet и идеально подходит, когда внутренние службы являются частными (App Service с ASE или виртуальные машины). Azure Front Door (на границе сети) обеспечивает глобальную балансировку нагрузки и WAF на границе CDN, снижая задержки для клиентов по всему миру; выбирайте Front Door для глобальной отказоустойчивости и Application Gateway для региональной защиты частных внутренних служб. Защиту от DDoS-атак (базовый уровень включен по умолчанию) следует обновить до DDoS Protection Standard, если на общедоступных IP-адресах размещены важные службы; он автоматически профилирует трафик и смягчает объемные атаки для ресурсов в защищенной виртуальной сети. Для частного доступа Private Link/Private Endpoints предоставляют частный IP-адрес в вашей VNet для служб платформы, устраняя их доступность из общедоступной сети. Распространенные ошибки включают в себя: забыть отключить публичный доступ к ресурсу PaaS, неправильная настройка интеграции с частной зоной DNS (необходимо владеть и сопоставлять зоны privatelink или настраивать серверы условной пересылки), а также ожидание, что граничные WAF смогут достичь частных конечных точек без регионального прокси; часто небольшой, защищенный обратный прокси-сервер (Application Gateway или Firewall) в подсети периметра маршрутизирует трафик от Front Door к частной конечной точке.

Операционные средства контроля: ведение журналов, политики, мониторинг и распространенные ловушки для инженеров

Операционная гигиена часто является отличительным признаком между безопасными и хрупкими сетевыми инфраструктурами. Включите NSG Flow Logs (v2) и диагностику Azure Firewall для централизованно управляемой рабочей области Log Analytics и интегрируйте их с Azure Monitor и Sentinel для аналитики, поиска угроз и оповещений. Используйте Traffic Analytics для агрегированного анализа топологии, выявления основных источников трафика и аномалий потоков; помните, что для Traffic Analytics требуется, чтобы Network Watcher и рабочая область Log Analytics находились в одном регионе. Для гибридных подключений Network Performance Monitor (NPM) и Connection Monitor обеспечивают периодический мониторинг задержки, джиттера и состояния пути, что помогает подтверждать соблюдение SLA для ExpressRoute и SD-WAN. Применяйте защитные механизмы с помощью Azure Policy: требуйте наличия Azure Firewall в центрах, запрещайте создание общедоступных IP-адресов для ресурсов, предназначенных только для частного доступа, и проводите аудит диапазонов приоритетов правил NSG или правил без тегов. Распространенные ловушки включают приоритет маршрутов (UDR переопределяет системные маршруты), исчерпание портов SNAT при множестве исходящих подключений через один общедоступный IP-адрес (устраняется добавлением общедоступных IP-адресов или использованием автомасштабирования брандмауэра) и требования к именованию подсетей (для Firewall должна существовать подсеть AzureFirewallSubnet). Решения о выборе между отказоустойчивостью и стоимостью принимаются итеративно: централизуйте проверку для обеспечения прозрачности, но локализуйте для путей, чувствительных к задержкам, и используйте автомасштабирование/зональную избыточность там, где рабочие нагрузки являются критически важными.

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

Сценарий: Компания Contoso Ltd. использует сеть Azure по топологии «центр-периферия», охватывающую два региона, с центральной VNet, содержащей зональный Azure Firewall и общие службы. Филиалы подключаются через SD-WAN BGP к региональным центрам. Несколько веб-приложений PaaS используют частные конечные точки в периферийных VNet.

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

Рекомендуемый подход:

Разверните Azure Front Door Standard/Premium в качестве глобальной общедоступной точки входа и подключите региональный Application Gateway в каждом центре в качестве частного источника (private origin) или используйте Front Door Premium с конфигурацией безопасного частного источника, где это поддерживается.
Разместите Application Gateway v2 в подсети центральной VNet (выделенной для каждого AGW) и настройте его для перенаправления трафика на частную конечную точку App Service через пиринг VNet; включите WAF_v2 на Application Gateway и свяжите с ним управляемую политику WAF.
Маршрутизируйте весь исходящий трафик из периферийных сетей через центральный Azure Firewall Premium (в подсети AzureFirewallSubnet), используя UDR в периферийных сетях; включите правила DNAT для необходимых преобразований входящего трафика и правила приложений для исходящего трафика по FQDN; включите IDPS и проверку TLS в редакции Premium для анализа зашифрованного трафика.
Централизуйте журналы в рабочей области Log Analytics, включите NSG Flow Logs и Traffic Analytics, активируйте DDoS Protection Standard на общедоступных IP-адресах центра и обеспечьте соблюдение архитектуры с помощью Azure Policy (требование наличия Firewall, запрет публичного сетевого доступа к PaaS).

Обоснование: Front Door обеспечивает глобальную доступность и низкую задержку, Application Gateway с WAF_v2 защищает частные бэкенды, а Azure Firewall Premium предоставляет централизованную проверку, DNAT и IDPS как для исходящего, так и для входящего трафика. Централизованное ведение журналов и применение политик обеспечивают прозрачность и соответствие требованиям, сохраняя при этом частный доступ к конечным точкам PaaS.

← Azure DNS и разрешение имен · Все домены · Балансировка нагрузки и управление трафиком →

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