Проектирование конфигурации Приватный канал Azure Monitor
При создании области Приватный канал Azure Monitor (AMPLS) доступ к ресурсам Azure Monitor ограничивается только сетями, подключенными к частной конечной точке. В этой статье приводятся рекомендации по проектированию конфигурации приватного канала Azure Monitor и других аспектов, которые необходимо учитывать, прежде чем фактически реализовать его с помощью руководства по настройке приватного канала для Azure Monitor.
Ограничения AMPLS
Объекты AMPLS имеют следующие ограничения:
- Виртуальная сеть может подключаться только к одному объекту AMPLS. Это означает, что объект AMPLS должен предоставлять доступ ко всем ресурсам Azure Monitor, к которым должен иметь доступ виртуальная сеть.
- Объект AMPLS может подключаться до 300 рабочих областей Log Analytics и до 1000 компонентов Application Insights.
- Ресурс Azure Monitor может подключаться к пяти AMPLS.
- Объект AMPLS может подключаться до 10 частных конечных точек.
Планирование на основе топологии сети
В следующих разделах описывается планирование конфигурации приватного канала Azure Monitor на основе топологии сети.
Избегайте переопределения 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.
Звездообразные сети
Сети концентраторов и периферийных сетей должны использовать один набор приватного канала в главной сети, а не в каждой периферийной виртуальной сети.
Вы можете создать отдельные частные каналы для периферийных виртуальных сетей, чтобы разрешить каждой виртуальной сети доступ к ограниченному набору ресурсов мониторинга. В этом случае можно создать выделенную частную конечную точку и AMPLS для каждой виртуальной сети. Кроме того, необходимо убедиться, что они не используют одни и те же зоны DNS, чтобы избежать переопределения DNS.
Одноранговые (пиринговые) сети
С пирингом сети сети могут совместно использовать IP-адреса друг друга и, скорее всего, совместно использовать один и тот же DNS. В этом случае создайте одну приватную ссылку в сети, доступной для других сетей. Избегайте создания нескольких частных конечных точек и объектов AMPLS, так как применяется только последний набор в DNS.
Изолированные сети
Если сети не пиринговые, необходимо также разделить DNS для использования частных ссылок. Затем можно создать отдельную частную конечную точку для каждой сети и отдельный объект AMPLS. Объекты AMPLS могут связываться с теми же рабочими областями или компонентами или различными.
Выбор режима доступа
Режимы доступа к приватным каналом позволяют управлять тем, как частные каналы влияют на сетевой трафик. Выбранное значение имеет решающее значение для обеспечения непрерывного и непрерывного сетевого трафика.
Режимы доступа могут применяться ко всем сетям, подключенным к AMPLS или к определенным сетям, подключенным к нему. Режимы доступа задаются отдельно для приема и запросов. Например, можно задать режим "Только приватные" для приема данных, а режим "Открытый" — для запросов.
Внимание
Прием Log Analytics использует конечные точки, относящиеся к ресурсам, поэтому он не соответствует режимам доступа AMPLS. Чтобы убедиться, что запросы приема Log Analytics не могут получить доступ к рабочим областям из AMPLS, установите сетевой брандмауэр для блокировки трафика на общедоступные конечные точки независимо от режимов доступа AMPLS.
Режим доступа только приватного доступа
Этот режим позволяет виртуальной сети обращаться только к ресурсам приватного канала в AMPLS. Это самый безопасный вариант и предотвращение кражи данных путем блокировки трафика из AMPLS в ресурсы Azure Monitor.
Режим открытия доступа
Этот режим позволяет виртуальной сети обращаться как к ресурсам приватного канала, так и к ресурсам, не в AMPLS (если они принимают трафик из общедоступных сетей). Режим открытого доступа не предотвращает утечку данных, но он по-прежнему предлагает другие преимущества приватных каналов. Трафик к ресурсам приватного канала отправляется через частные конечные точки перед проверкой и затем отправляется через магистраль Майкрософт. Открытый режим полезен для смешанного режима, где некоторые ресурсы доступны публично и другие пользователи, к ним обращаются через приватный канал. Это также может быть полезно во время постепенного процесса подключения.
Внимание
При выборе режима доступа следует соблюдать осторожность. Использование режима доступа только приватного доступа блокирует трафик к ресурсам, не в AMPLS во всех сетях, которые совместно используют один и тот же DNS независимо от подписки или клиента. Если вы не можете добавить все ресурсы Azure Monitor в AMPLS, начните с добавления ресурсов и применения режима открытого доступа. Переключитесь в режим "Только частный" для обеспечения максимальной безопасности только после добавления всех ресурсов Azure Monitor в AMPLS.
Настройка режимов доступа для определенных сетей
Режимы доступа, заданные для ресурса AMPLS, влияют на все сети, но эти параметры можно переопределить для определенных сетей.
На следующей схеме сеть VNet1 использует режим "Открытый", а сеть VNet2 — режим "Только приватные". Запросы из виртуальной сети1 могут достигать рабочей области 1 и компонента 2 по приватной ссылке. Запросы могут достигать компонента 3, только если он принимает трафик из общедоступных сетей. Запросы VNet2 не могут достичь компонента 3.
Управление сетевым доступом к ресурсам AMPLS
Компоненты Azure Monitor можно задать для следующих компонентов:
- Принятие или блокировка приема данных из общедоступных сетей (сетей, не подключенных к ресурсу AMPLS).
- Принятие или блокировка запросов из общедоступных сетей (сетей, не подключенных к ресурсу AMPLS).
Эта детализация позволяет задать доступ для каждой рабочей области в соответствии с вашими потребностями. Например, вы можете принимать прием только через сети, подключенные к приватным каналом, но по-прежнему принимать запросы из всех сетей, общедоступных и частных.
Примечание.
Блокировка запросов из общедоступных сетей означает, что клиенты, такие как компьютеры и пакеты SDK за пределами подключенного AMPLS, не могут запрашивать данные в ресурсе. Эти данные включают в себя журналы, метрики и поток динамических метрик. Блокировка запросов из общедоступных сетей влияет на все возможности, которые выполняют эти запросы, такие как книги, панели мониторинга, аналитические сведения в портал Azure и запросы, выполняемые вне портал Azure.
Ниже перечислены исключения для этого сетевого доступа:
- Журналы диагностики. Журналы и метрики, отправленные в рабочую область из параметра диагностики, выполняются через безопасный частный канал Майкрософт и не контролируются этими параметрами.
- Пользовательские метрики или гостевые метрики Azure Monitor. Пользовательские метрики, отправленные агентом Azure Monitor, не контролируются контроллерами домена и не могут быть настроены по закрытым ссылкам.
Примечание.
Запросы, отправленные через API Resource Manager, не могут использовать приватные ссылки Azure Monitor. Эти запросы могут получить доступ только в том случае, если целевой ресурс разрешает запросы из общедоступных сетей.
Следующие возможности, как известно, выполняют запросы через API Resource Manager:
- Соединитель LogicApp
- Update Management solution (Решение для управления обновлениями)
- Решение для отслеживания изменений
- Аналитика виртуальных машин
- Аналитика контейнеров
- Панель "Сводка рабочей области Log Analytics" (нерекомендуемая) (на панели мониторинга решений)
Примечания
Application Insights
- Добавьте ресурсы, в которые размещаются отслеживаемые рабочие нагрузки, в приватную ссылку. Например, см. статью "Использование частных конечных точек для веб-приложения Azure".
- Интерфейсы потребления, не связанные с порталом, также должны выполняться в частной виртуальной сети, включающей отслеживаемые рабочие нагрузки.
- Предоставьте собственную учетную запись хранения для поддержки частных ссылок для отладчика и .NET Profiler.
Примечание.
Чтобы полностью защитить Application Insights на основе рабочей области, заблокируйте доступ к ресурсу Application Insights и базовой рабочей области Log Analytics.
Управляемая служба Prometheus
- Приватный канал параметры приема создаются с помощью AMPLS и параметров конечных точек сбора данных (DCEs), ссылающихся на рабочую область Azure Monitor, используемую для хранения метрик Prometheus.
- Приватный канал параметры запроса выполняются непосредственно в рабочей области Azure Monitor, используемой для хранения метрик Prometheus и не обрабатываются с помощью AMPLS.
Следующие шаги
- Узнайте, как настроить приватный канал.
- Узнайте о частном хранилище для пользовательских журналов и ключей, управляемых клиентом.
- Узнайте о Приватный канал для автоматизации.