Безопасность DNS и частное разрешение имен

В этой статье объясняется, как проектировать систему DNS для сетей Azure с помощью частных DNS-зон, Azure DNS Private Resolver и средств управления безопасностью DNS. Он охватывает шаблоны разрешения частных имен, гибридное перенаправление DNS, интеграцию DNS частной конечной точки и защиту от угроз уровня DNS.

Описание этой статьи

DNS является основой сетевого взаимодействия: любое соединение начинается с запроса на разрешение имени. В Azure архитектура DNS определяет, как рабочие нагрузки находят друг друга в виртуальных сетях, как системы локальной инфраструктуры разрешают имена, размещённые в Azure, и как частные конечные точки становятся доступными по полным доменным именам (FQDN). Кроме разрешения, DNS также является поверхностью атаки. Туннелирование DNS, кража и запросы к вредоносным доменам представляют реальные угрозы, требующие элементов управления безопасностью уровня DNS.

В этой статье рассматриваются три проблемы DNS:

  • Разрешение частных имен: Как виртуальные машины, контейнеры и службы платформы разрешают имена в Azure без предоставления DNS-запросов общедоступному Интернету.
  • Гибридная переадресация DNS: как локальные сети разрешают частные имена Azure и как рабочие нагрузки Azure разрешают локальные имена.
  • Безопасность DNS: Как заблокировать вредоносные запросы DNS, предотвратить утечку DNS и включить фильтрацию сети на основе полного доменного имени.

Кто нуждается в этой статье

Ознакомьтесь с этой статьей, если вы:

  • Разверните частные конечные точки (если применимо к вашему сценарию) и необходимо, чтобы рабочие нагрузки правильно разрешали privatelink.* зоны DNS.
  • Эксплуатация гибридных сред, в которых локальные системы должны разрешать частные DNS-имена Azure (или наоборот).
  • Используете Брандмауэр Azure и вам нужна фильтрация на основе FQDN в сетевых правилах.
  • Хотите заблокировать DNS-запросы на известные вредоносные домены на уровне разрешения.
  • Управление средами с несколькими виртуальными сетями, где централизованное разрешение DNS упрощает операции.
  • Планирование архитектуры DNS для топологий концентраторов с общими службами.

Основной акцент — миграция по модели lift-and-shift: Сохранить существующую схему именования DNS во время миграции. Используйте двунаправленную переадресацию запросов между локальной DNS-инфраструктурой и Azure, настройте условные серверы переадресации для разрешения имён по схеме split-horizon и размещайте частные имена Azure в зонах Частная зона DNS, чтобы приложения сохраняли текущую конфигурацию DNS.

Модернизация фокуса: Централизованное разрешение имен при переплатформе рабочих нагрузок. Используйте Azure DNS private Resolver с наборами правил пересылки для гибридного разрешения, интегрировать Частная зона DNS зоны с частными конечными точками для служб PaaS и включить прокси-сервер DNS Брандмауэр Azure таким образом, чтобы правила на основе FQDN и разрешение DNS совместно использовали один кэшированный путь.

Ориентация на мультиоблачную среду: Спланируйте переключение DNS между облаками до переноса рабочих нагрузок. Используйте Azure DNS Private Resolver для межоблачного разрешения имен, настройте условную переадресацию с помощью AWS Route 53 Resolver или Google Cloud DNS и снизьте значения TTL перед переключением, чтобы уменьшить риск использования устаревшего кэша.

Azure службы и функции

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

Служба или компонент Purpose Ключевая возможность Когда использовать
Azure DNS (общедоступные зоны) Авторитетное размещение для общедоступных доменных имен Глобальная сеть anycast, интеграция Azure RBAC, записи псевдонимов для ресурсов Azure Вы владеете общедоступным доменом и хотите размещать записи DNS в Azure с высоким уровнем доступности.
Частные зоны DNS Azure Разрешение имен в виртуальных сетях без публичного доступа связывание VNet, автоматическая регистрация имен узлов ВМ, размещение зоны Private Link Внутреннее разрешение имен для рабочих нагрузок Azure. Требуется для интеграции DNS частной конечной точки.
Частный резолвер DNS Azure Перенаправление DNS между Azure и внешними сетями Конечная точка входящего трафика (локальное разрешение → Azure), конечная точка исходящего трафика (Azure → локальная пересылка), наборы правил пересылки Гибридные среды нуждаются в двунаправленном разрешении DNS без развертывания пользовательских виртуальных машин DNS.
Брандмауэр Azure DNS-прокси Централизованный перехват DNS-запросов для фильтрации по FQDN Кэширует ответы DNS, поддерживает правила сети на основе FQDN, предоставляет единую точку DNS для спицевых виртуальных сетей Вы развертываете Брандмауэр Azure, и вам нужна фильтрация FQDN в сетевых правилах. Требуется для последовательного разрешения полного доменного имени (FQDN).
Политика безопасности DNS Защита от угроз на уровне DNS Блокирует разрешение известных вредоносных доменов на основе канала анализа угроз Microsoft Вы хотите предотвратить подключение рабочих нагрузок к доменам распространения вредоносных программ и команд и управления ими.

основные понятия зоны Частная зона DNS

Частные зоны DNS обеспечивают разрешение имен для связанных виртуальных сетей без публикации записей в Интернете. Основные варианты поведения:

  • Связывание виртуальной сети: Вы можете связать частную зону DNS с несколькими виртуальными сетями. Все ресурсы в связанных виртуальных сетями могут разрешать записи в зоне.
  • Автоматическая регистрация: При включении ссылки виртуальной сети Azure автоматически создает записи для виртуальных машин, развернутых в этой виртуальной сети. Azure удаляет записи при освобождении или удалении виртуальных машин. Автоматическая регистрация работает только для виртуальных машин (только для основной сетевой карты). Виртуальная сеть может автоматически зарегистрировать только одну частную зону DNS, но можно связать несколько виртуальных сетей с одной зоной.
  • DNS для частной конечной точки: Службам Azure, доступ к которым осуществляется через частные конечные точки, требуются определённые зоны DNS privatelink (например, privatelink.blob.core.windows.net для Хранилище BLOB-объектов Azure). Без нужной зоны клиенты определяют общедоступный IP-адрес, а не адрес частной конечной точки.

Архитектура приватного DNS-резолвера

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

Схема, показывающая процесс гибридного разрешения DNS из локальной инфраструктуры через входящую конечную точку Azure DNS Private Resolver в частную зону DNS и к IP-адресу Private Endpoint.

Резолвер использует два типа конечных точек:

  • Конечная точка для входящего трафика: Предоставляет IP-адрес, на который локальные DNS-серверы могут направляться как условный сервер пересылки. Azure DNS обрабатывает запросы, направленные на этот IP-адрес (включая связанные с ним зоны частного DNS). Требуется выделенная подсеть, делегированная Microsoft.Network/dnsResolvers.
  • Исходящая конечная точка: Позволяет рабочим нагрузкам Azure перенаправлять DNS-запросы на локальные DNS-серверы, другим облачным провайдерам или внешние резолверы. Кроме того, требуется выделенная подсеть. Наборы правил переадресации, связанные с исходящей конечной точкой, определяют, какие суффиксы доменов следует перенаправлять и какие целевые DNS-серверы следует использовать.

Important

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

Как выбрать

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

Дерево принятия решений

  1. Вы используете частные конечные точки?

    • Да → Разверните частные зоны DNS с соответствующими именами privatelink.* зон. Свяжите зоны с виртуальными сетями, которым необходимо разрешать адреса частных конечных точек.

  2. Нужно ли локальным системам разрешать частные имена Azure?

    • Да, → развернуть частный сопоставитель DNS с конечной точкой входящего трафика. Настройте локальные DNS-серверы с условными серверами пересылки, указывающими на IP-адрес входящей конечной точки.

  3. Нужно ли рабочим нагрузкам Azure разрешать имена в локальной среде?

    • Да, → развернуть частный сопоставитель DNS с исходящей конечной точкой. Создание наборов правил пересылки для локальных суффиксов домена (например, corp.contoso.com).

  4. Вы развертываете Брандмауэр Azure и вам нужна фильтрация FQDN в сетевых правилах?

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

  5. Запретить DNS-запросы известным вредоносным доменам?

    • Да → Включить политику безопасности DNS с использованием канала аналитики угроз Microsoft в целевых виртуальных сетях.

Распространенные шаблоны

Рисунок Components Сценарий использования
Только разрешение частного конечного объекта Частные зоны DNS + ссылки виртуальной сети Облачные рабочие нагрузки, обращающиеся к службам PaaS через частные конечные точки. Гибридное подключение отсутствует.
Гибридное двунаправленное разрешение Частные зоны DNS + частный распознаватель DNS (входящий + исходящий) Локальная инфраструктура разрешает частные имена Azure; Azure разрешает имена Active Directory в локальной среде.
Централизованный DNS концентратора Частный распознаватель DNS в виртуальной сети хаба и наборы правил пересылки, связанные со спицами Топология «ступица-спицы», в которой весь DNS-трафик направляется через центральный узел для централизованного журналирования и управления.
Dns с помощью брандмауэра Брандмауэр Azure DNS-прокси + зоны Частная зона DNS Среды, использующие брандмауэр для фильтрации FQDN. Брандмауэр перехватывает DNS, обеспечивая согласованное разрешение полных доменных имён в IP-адреса для сетевых правил.
Полный стек безопасности Все предыдущие параметры, а также политика безопасности DNS Корпоративные среды, требующие гибридного разрешения, фильтрации FQDN и защиты от угроз на уровне DNS.

Примеры зоны DNS частной конечной точки

В следующей таблице перечислены распространенные службы Azure и их необходимые имена зон Частная зона DNS.

Служба Azure имя приватной зоны DNS
Хранилище BLOB-объектов Azure (Азур Блоб Сторадж) privatelink.blob.core.windows.net
База данных SQL Azure privatelink.database.windows.net
Azure Key Vault privatelink.vaultcore.azure.net
Файлы Azure privatelink.file.core.windows.net
Реестр контейнеров Azure (Реестр контейнеров Azure) privatelink.azurecr.io
Azure Cosmos DB (API SQL) privatelink.documents.azure.com

Note

Полный список имен частных DNS-зон для всех служб Azure см. в разделе Конфигурация DNS для частной конечной точки Azure.

Prerequisites

Прежде чем внедрить безопасность DNS и разрешение частных имен, убедитесь, что у вас есть:

  • Виртуальная сеть: Все функции DNS работают в виртуальных сетях или между ними. См. Виртуальные сети и подсети для получения основных рекомендаций. (F1)
  • Сетевое подключение для гибридных сценариев: Для входящих конечных точек частного сопоставителя DNS требуется доступность сети из локальной сети (ExpressRoute или VPN) в виртуальную сеть сопоставителя.
  • Выделенные подсети для частного распознавателя DNS: Для каждой конечной точки (входящей и исходящей) требуется отдельная подсеть, делегированная Microsoft.Network/dnsResolvers. Запланируйте по крайней мере /28 для каждой подсети конечной точки.
  • Развернутые частные конечные точки (при использовании зон Private Link): Частные зоны DNS для имен privatelink.* имеют смысл только при наличии частных конечных точек. Сведения о развертывании см. в разделе Частный доступ к PaaS с помощью частных конечных точек. (C5)
  • Брандмауэр Azure развернут (при использовании DNS-прокси): для функции DNS-прокси требуется существующий экземпляр Брандмауэр Azure. См. Брандмауэр Azure и проверку трафика. (S1)
  • Разрешения: роль "Участник зоны DNS" для управления частными DNS-зонами. Участник сети для развертывания частного сопоставителя DNS.

Вопросы безопасности

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

Риски кражи DNS

Туннелирование DNS кодирует данные в DNS-запросах для получения информации с помощью неограниченного протокола. Так как большинство сетей разрешают исходящие DNS (UDP/TCP 53), злоумышленники используют DNS в качестве скрытого канала. Чтобы устранить этот риск, выполните указанные ниже действия.

  • Включение Брандмауэр Azure DNS-прокси и маршрутизация всего ТРАФИКА DNS через брандмауэр. Брандмауэр регистрирует все запросы DNS, что делает туннелирование обнаруживаемым с помощью аналитики.
  • Применение политики безопасности DNS для блокировки разрешения доменов, связанных с известными средствами эксфильтрации данных и инфраструктурой командования и управления.
  • Мониторинг шаблонов запросов DNS в Azure Monitor для аномалий, таких как необычные длинные метки поддомена, большие тома запросов к одному домену или запросы к недавно зарегистрированным доменам.

Политика безопасности DNS

Политика безопасности DNS с аналитикой угроз Microsoft блокирует DNS-разрешение известных вредоносных доменов на уровне виртуальной сети (VNet). Когда рабочий процесс пытается выполнить разрешение домена, помеченного Центр Майкрософт по реагированию на угрозы (MSRC), политика блокирует это разрешение до установления какого-либо сетевого соединения. Этот элемент управления работает независимо от Брандмауэр Azure и не требует изменений в конфигурации отдельных рабочих нагрузок.

Ключевые характеристики:

  • Использует канал Microsoft Threat Intelligence, получаемый от MSRC.
  • Работает на уровне разрешения DNS: блокирует запрос, а не трафик.
  • Применяется к каждой виртуальной сети: включите для всех виртуальных сетей, содержащих рабочие нагрузки, которым требуется доступ к Интернету.
  • Отличается от фильтрации полного доменного имени брандмауэра: политика безопасности DNS блокирует вредоносные домены глобально без необходимости развертывания брандмауэра.

DNS-прокси брандмауэра и фильтрация FQDN

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

При включении DNS-прокси:

  • Настройте периферийные виртуальные машины для использования частного IP-адреса брандмауэра в качестве DNS-сервера.
  • Брандмауэр разрешает запросы от имени клиентов и кэширует результаты (положительный кэш до 1 часа, отрицательный кэш до 30 минут).
  • Сопоставления FQDN и IP-адресов обновляются каждые 15 секунд. Брандмауэр удаляет устаревшие записи через 15 минут.
  • Правила приложений (L7) используют индикацию имени сервера (SNI) для сопоставления с полным доменным именем (FQDN) и не требуют DNS-прокси. Для разрешения FQDN правила сети (L4) требуют DNS-прокси.
  • Фильтрация полного доменного имени в правилах сети поддерживает только точные совпадения домена. Подстановочные шаблоны не поддерживаются в FQDN сетевых правил. Используйте правила приложения для сопоставления полного доменного имени с подстановочными знаками.

Note

Если все настроенные вышестоящие DNS-серверы становятся недоступными, DNS-прокси Брандмауэр Azure не переключается на альтернативный DNS-резолвер. Разрешение DNS завершается ошибкой до тех пор, пока не будет восстановлен по крайней мере один вышестоящий DNS-сервер. Предусмотрите резервирование DNS-сервера в вашей upstream-конфигурации.

Caution

Если вы включите DNS-прокси, но не настраиваете клиентские виртуальные машины для использования брандмауэра в качестве DNS-сервера, правила сети на основе FQDN не будут работать правильно. Клиенты и брандмауэр могут разрешать разные IP-адреса для одного полного доменного имени, что приводит к непредвиденным падениям трафика.

Ограничения DNSSEC

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

Рекомендации по проектированию

Фокус проектирования DNS для лифта и смены

  • Настройте двустороннюю пересылку DNS-запросов между локальными DNS-серверами и Azure DNS Private Resolver.
  • Используйте условные перенаправления, чтобы локальные запросы для имен, размещенных Azure, разрешались в Azure, а запросы Azure для локальных имен разрешаются через существующую инфраструктуру DNS.
  • Создайте частные зоны DNS для каждой службы Azure, которую используют перенесённые рабочие нагрузки, особенно для служб, использующих Частную конечную точку.
  • Сохранение поведения DNS приложения во время миграции с помощью записей псевдонимов или сопоставлений CNAME вместо изменения параметров сопоставителя клиента.

Модернизация фокуса на проектировании DNS

  • Централизуйте разрешение DNS в центральной сети с помощью Azure DNS Private Resolver и наборов правил пересылки, общих для периферийных виртуальных сетей.
  • Свяжите зоны частного DNS для каждой службы PaaS, использующей Private Endpoint, чтобы перенесённые на новую платформу рабочие нагрузки автоматически разрешали имена privatelink.
  • Включите DNS-прокси в Брандмауэр Azure, чтобы сетевые правила на основе FQDN и разрешение DNS для рабочих нагрузок использовали единый кэшируемый путь разрешения.
  • Используйте автоматическую регистрацию и Azure RBAC в зонах Частная зона DNS, чтобы уменьшить управление записями вручную при внедрении инфраструктуры как кода.

Фокус проектирования DNS в нескольких облаках

  • Используйте Azure DNS Private Resolver в качестве контрольной точки перенаправления для межоблачного разрешения имен.
  • Настройте условное DNS-перенаправление между службой Azure Private DNS, AWS Route 53 Resolver и Google Cloud DNS для каждого приватного пространства имен, которое должно разрешаться во всех средах.
  • Планирование перехода DNS на этапах: снижение значений TTL, проверка путей пересылки, изменение записей CNAME или A, мониторинг задержки запросов и поведения кэша.
  • Применяйте DNSSEC в авторитетных зонах там, где подключённые платформы его поддерживают, и документируйте случаи, когда частные пути разрешения не проверяют DNSSEC.

Узнать больше

Дальнейшие действия

Tip

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

Далее в пути лифта и смены:

Управление исходящим интернет-трафиком: централизация всех исходящих подключений через Брандмауэр Azure и отключение исходящего доступа по умолчанию.

Далее в пути модернизации:

Настройте мониторинг рабочей среды: включите Наблюдатель за сетями и Network Монитор производительности, чтобы обеспечить готовность к работе в рабочей среде с первого дня.

Следующий этап вашего мультиоблачного пути:

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

  • Last updated on