Проектирование настройки Приватный канал Azure

  • Статья

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

Как описано в статье "Использование Приватный канал Azure для подключения сетей к Azure Monitor, настройка приватного канала влияет на трафик ко всем ресурсам Azure Monitor. Это особенно верно для ресурсов Application Insights. Это также влияет не только на сеть, подключенную к частной конечной точке, но и ко всем другим сетям, которые используют одинаковые DNS.

Самый простой и самый безопасный подход:

  1. Создайте одно приватное подключение с одной частной конечной точкой и одной Приватный канал области Azure Monitor (AMPLS). Если сети пиринговые, создайте частное подключение к общей (или концентратор) виртуальной сети.
  2. Добавьте все ресурсы Azure Monitor, такие как компоненты Application Insights, рабочие области Log Analytics и конечные точки сбора данных в AMPLS.
  3. Блокируйте исходящий трафик сети, насколько это возможно.

Если вы не можете добавить все ресурсы Azure Monitor в AMPLS, вы по-прежнему можете применить приватную ссылку к некоторым ресурсам, как описано в разделе "Управление применением частных ссылок к сетям". Мы не рекомендуем этот подход, так как он не предотвращает кражу данных.

Планирование на основе топологии сети

Рассмотрим топологию сети в процессе планирования.

Основополагающий принцип: избегайте переопределения DNS с помощью одной AMPLS

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

На следующей схеме виртуальная сеть 10.0.1.x подключается к AMPLS1, которая создает записи DNS, которые сопоставляют конечные точки Azure Monitor с IP-адресами из диапазона 10.0.1.x. Позже виртуальная сеть 10.0.2.x подключается к AMPLS2, которая переопределяет те же записи DNS, сопоставляя те же глобальные или региональные конечные точки с IP-адресами из диапазона 10.0.2.x. Так как эти виртуальные сети не пиринговые, первая виртуальная сеть теперь не достигает этих конечных точек.

Чтобы избежать этого конфликта, создайте для каждой службы DNS только один объект AMPLS.

Схема с переопределением DNS в нескольких виртуальных сетях.

Звездообразные сети

Сети концентраторов и периферийных сетей должны использовать один набор приватного канала в главной сети, а не в каждой периферийной виртуальной сети.

Схема, на которую показана приватная связь с концентратором и периферийной связью.

Примечание.

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

Одноранговые (пиринговые) сети

Пиринг сети используется в различных топологиях, отличных от концентратора и периферийных узлов. Такие сети могут совместно использовать IP-адреса друг друга и, скорее всего, совместно использовать один и тот же DNS. В таких случаях создайте одну частную ссылку в сети, доступной для других сетей. Избегайте создания нескольких частных конечных точек и объектов AMPLS, так как в конечном итоге применяется только последний набор в DNS.

Изолированные сети

Если сети не пиринговые, необходимо также разделить DNS для использования частных ссылок. После этого создайте отдельную частную конечную точку для каждой сети и отдельный объект AMPLS. Объекты AMPLS могут связываться с теми же рабочими областями или компонентами или различными.

Локальное тестирование: редактирование файла hosts на компьютере вместо DNS

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

  • Настройте приватный канал, но при подключении к частной конечной точке выберите не автоматически интегрироваться с DNS (шаг 5b).
  • Настройте соответствующие конечные точки в файлах hosts на компьютерах. Чтобы просмотреть конечные точки Azure Monitor, которые нуждаются в сопоставлении, ознакомьтесь с параметрами DNS конечной точки.

Мы не рекомендуем использовать этот подход для рабочих сред.

С помощью режимов доступа к приватным каналом можно управлять тем, как частные каналы влияют на сетевой трафик. Эти параметры могут применяться к объекту AMPLS (для влияния на все подключенные сети) или к конкретным сетям, подключенным к нему.

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

  • Только приватный: позволяет виртуальной сети обращаться только к ресурсам приватного канала (ресурсам в AMPLS). Это самый безопасный режим работы. Он предотвращает утечку данных, блокируя трафик из AMPLS в ресурсы Azure Monitor. Схема, показывющая режим доступа только для частных AMPLS.
  • Открытие. Позволяет виртуальной сети обращаться как к ресурсам приватного канала, так и к ресурсам, не в AMPLS (если они принимают трафик из общедоступных сетей). Режим открытого доступа не предотвращает утечку данных, но он по-прежнему предлагает другие преимущества приватных каналов. Трафик к ресурсам приватного канала отправляется через частные конечные точки, проверяется и отправляется через магистраль Майкрософт. Открытый режим полезен для смешанного режима работы (доступ к некоторым ресурсам публично и другим по закрытой ссылке) или во время постепенного подключения. Схема, показывющая режим открытого доступа AMPLS. Режимы доступа задаются отдельно для приема и запросов. Например, можно задать режим "Только приватные" для приема данных, а режим "Открытый" — для запросов.

При выборе режима доступа следует соблюдать осторожность. Использование режима доступа только приватного доступа блокирует трафик к ресурсам, не в AMPLS во всех сетях, использующих один и тот же DNS, независимо от подписки или клиента. Исключением является запросы приема Log Analytics, которые описаны. Если вы не можете добавить все ресурсы Azure Monitor в AMPLS, начните с добавления ресурсов и применения режима открытого доступа. Переключитесь в режим "Только частный" для обеспечения максимальной безопасности только после добавления всех ресурсов Azure Monitor в AMPLS.

Сведения о конфигурации и примеры см. в разделе "Использование API" и командной строки.

Примечание.

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

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

Режимы доступа, заданные для ресурса AMPLS, влияют на все сети, но эти параметры можно переопределить для определенных сетей.

На следующей схеме сеть VNet1 использует режим "Открытый", а сеть VNet2 — режим "Только приватные". Запросы из виртуальной сети1 могут достигать рабочей области 1 и компонента 2 по приватной ссылке. Запросы могут достигать компонента 3, только если он принимает трафик из общедоступных сетей. Запросы VNet2 не могут достичь компонента 3. Схема, показывая режимы смешанного доступа.

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

Для AMPLS существуют следующие ограничения.

  • Виртуальная сеть может подключаться только к одному объекту AMPLS. Это означает, что объект AMPLS должен предоставлять доступ ко всем ресурсам Azure Monitor, к которым должен иметь доступ виртуальная сеть.
  • Объект AMPLS может подключаться к 300 рабочим областям Log Analytics и 1000 компонентам Application Insights.
  • Ресурс Azure Monitor (компонент рабочей области или компонент Application Insights или конечная точка сбора данных) может подключаться к пяти AMPLS.
  • Объект AMPLS может подключаться к 10 частным конечным точкам в большинстве случаев.

Примечание.

Ресурсы AMPLS, созданные до 1 декабря 2021 г., поддерживают только до 50 ресурсов.

Рассмотрим схему ниже.

  • Каждая виртуальная сеть подключается только к одному объекту AMPLS.
  • AMPLS A подключается к двум рабочим областям и одному компоненту Application Insights с помощью двух возможных рабочих областей Log Analytics и одного из возможных компонентов Application Insights, к которым он может подключиться.
  • Рабочая область 2 подключается к AMPLS A и AMPLS B с помощью двух из пяти возможных подключений AMPLS.
  • AMPLS B подключен к частным конечным точкам двух виртуальных сетей (VNet2 и VNet3), используя два из двух возможных подключений к частной конечной точке.

Схема с ограничениями AMPLS.

Контроль сетевого доступа к ресурсам

Для рабочих областей Log Analytics и компонентов Application Insights можно задать следующее:

  • Принятие или блокировка приема данных из общедоступных сетей (сетей, не подключенных к ресурсу AMPLS).
  • Принятие или блокировка запросов из общедоступных сетей (сетей, не подключенных к ресурсу AMPLS).

Такая детализация позволяет настроить доступ в соответствии с вашими потребностями в каждой рабочей области. Например, вы можете принимать прием только через подключенные к приватным каналом сети (то есть определенные виртуальные сети), но по-прежнему принимать запросы из всех сетей, общедоступных и частных.

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

Примечание.

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

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

Сведения о конфигурации см. в разделе "Настройка флагов доступа к ресурсам".

Исключения

Обратите внимание на следующие исключения.

Журналы диагностики

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

Пользовательские метрики или гостевые метрики Azure Monitor

Пользовательские метрики (предварительная версия), собранные и отправленные через агент Azure Monitor, не контролируются конечными точками сбора данных. Они не могут быть настроены по закрытым ссылкам.

Azure Resource Manager

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

Примечание.

Запросы, отправленные через API Resource Manager, не могут использовать приватные ссылки Azure Monitor. Эти запросы могут проходить только в том случае, если целевой ресурс разрешает запросы из общедоступных сетей (устанавливается через область сетевой изоляции или с помощью интерфейса командной строки).

Следующие возможности, как известно, выполняют запросы через API Resource Manager:

  • Соединитель LogicApp
  • Update Management solution (Решение для управления обновлениями)
  • Решение для отслеживания изменений
  • Аналитика виртуальных машин
  • Аналитика контейнеров
  • Панель "Сводка рабочей области Log Analytics" (нерекомендуемая) (на панели мониторинга решений)

Рекомендации по Application Insights

Примечание.

Чтобы полностью защитить Application Insights на основе рабочей области, необходимо заблокировать доступ к ресурсу Application Insights и базовой рабочей области Log Analytics.

Рекомендации по Log Analytics

Обратите внимание на следующие рекомендации по Log Analytics.

Загрузка пакетов решений Log Analytics

Для скачивания пакетов решений агентам Log Analytics требуется доступ к глобальной учетной записи хранения. Настройки приватного канала, созданные с 19 апреля 2021 г. (или начиная с июня 2021 г. в национальных облаках Azure), могут получить доступ к хранилищу пакетов решений агентов по закрытой ссылке. Эта возможность возможна с помощью зоны DNS, созданной для blob.core.windows.net.

Если настройка приватного канала была создана до 19 апреля 2021 г., она не достигнет хранилища пакетов решений по закрытой ссылке. Для этого можно выполнить следующие действия:

  • Повторно создайте AMPLS и частную конечную точку, подключенную к ней.

  • Разрешите агентам доступ к учетной записи хранения через общедоступную конечную точку, добавив следующие правила в список разрешений брандмауэра:

    Облачная среда Ресурс агента Порты Направление
    Azure Public scadvisorcontent.blob.core.windows.net 443 Исходящие
    Azure для государственных организаций usbn1oicore.blob.core.usgovcloudapi.net 443 Исходящие
    Microsoft Azure под управлением 21Vianet mceast2oicore.blob.core.chinacloudapi.cn 443 Исходящие

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

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

Автоматизация

Если вы используете решения Log Analytics, для которых требуется учетная запись служба автоматизации Azure (например, управление обновлениями, Отслеживание изменений или инвентаризация), следует также создать приватную ссылку для учетной записи службы автоматизации. Дополнительные сведения см. в разделе Безопасное подключение сетей к службе автоматизации Azure с помощью Приватного канала Azure.

Примечание.

Некоторые продукты и портал Azure могут запрашивать данные с помощью Resource Manager. В этом случае они не смогут запрашивать данные по приватному каналу, если к Resource Manager не применяются параметры приватного канала. Чтобы преодолеть это ограничение, вы можете настроить ресурсы для приема запросов из общедоступных сетей, как описано в разделе "Управление доступом к сети" к ресурсам. (Прием может быть ограничен сетями приватного канала.) Мы определили следующие продукты и рабочие области запросов с помощью Resource Manager:

  • Соединитель LogicApp
  • Update Management solution (Решение для управления обновлениями)
  • Решение для отслеживания изменений
  • Панель "Сводка рабочей области" (нерекомендуемая) на портале (на панели мониторинга решений)
  • Аналитика виртуальных машин
  • Аналитика контейнеров

Рекомендации по управляемому prometheus

  • Приватный канал параметры приема выполняются с помощью AMPLS и параметров конечных точек сбора данных ,которые ссылаются на рабочую область Azure Monitor, используемую для хранения метрик Prometheus.
  • Приватный канал параметры запроса выполняются непосредственно в рабочей области Azure Monitor, используемой для хранения метрик Prometheus и не обрабатываются с помощью AMPLS.

Требования

Обратите внимание на следующие требования.

Размер сетевой подсети

Минимальный размер подсети для протокола IPv4 равен /27, (согласно определениям подсети CIDR). Хотя виртуальные сети Azure могут быть меньше /29, Azure резервирует пять IP-адресов. Для настройки приватного канала Azure Monitor требуется не менее 11 IP-адресов, даже если вы подключаетесь к одной рабочей области. Просмотрите параметры DNS конечной точки для списка конечных точек приватного канала Azure Monitor.

Агенты

Чтобы обеспечить безопасный прием данных в рабочих областях Log Analytics, нужно использовать последние версии агентов для Windows и Linux. Более старые версии не могут отправлять данные мониторинга в частную сеть.

Агенты Azure Monitor для Windows

Агент Windows Azure Monitor версии 1.1.1.0 или более поздней версии (с помощью конечных точек сбора данных).

Агенты Azure Monitor для Linux

Агент Linux Azure Monitor версии 1.10.5.0 или более поздней версии (с помощью конечных точек сбора данных).

Агент Windows Log Analytics (не рекомендуется)

Используйте агент Log Analytics версии 10.20.18038.0 или более поздней.

Агент Linux Log Analytics (не рекомендуется)

Используйте агент версии 1.12.25 или более поздней. Если вы не можете, выполните следующие команды на виртуальной машине:

$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -X
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <workspace key>

Портал Azure

Чтобы использовать интерфейсы портала Azure Monitor, такие как Application Insights, Log Analytics и конечные точки сбора данных, необходимо разрешить доступ к расширениям портал Azure и Azure Monitor в частных сетях. Добавьте теги службы AzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty и AzureFrontdoor.Frontend в группу безопасности сети.

Программный доступ

Чтобы использовать REST API, Azure CLI или PowerShell с Azure Monitor в частных сетях, добавьте теги службы AzureActiveDirectory и AzureResourceManager в брандмауэр.

Скачивание пакета SDK Application Insights из сети доставки содержимого

Упакуйте код JavaScript в сценарий, чтобы браузер не пытался скачать код из CDN. Пример представлен на сайте GitHub.

Параметры DNS для браузера

Если вы подключаетесь к ресурсам Azure Monitor через приватный канал, трафик к этим ресурсам должен пройти через частную конечную точку, настроенную в вашей сети. Чтобы включить частную конечную точку, обновите параметры DNS, как описано в разделе Подключение к частной конечной точке. Некоторые браузеры используют собственные параметры DNS вместо заданных вами. Браузер может попытаться подключиться к общедоступным конечным точкам Azure Monitor и полностью обойти приватный канал. Убедитесь, что параметры браузера не переопределяют или кэшируют старые параметры DNS.

Ограничение запросов: оператор externaldata

  • Оператор externaldata не поддерживается через приватный канал, так как он считывает данные из учетных записей хранения, но не гарантирует, что доступ к хранилищу осуществляется в частном порядке.
  • Прокси-сервер Azure Data Explorer (прокси-сервер ADX) позволяет запросам журналов запрашивать Azure Data Explorer. Прокси-сервер ADX не поддерживается по приватной ссылке, так как он не гарантирует, что доступ к целевому ресурсу осуществляется в частном порядке.

Следующие шаги