Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Вы можете повысить безопасность вашего агента в Azure SRE Agent двумя способами: с помощью соответствующих разрешений управления доступом на основе ролей (RBAC) и за счет интеграции с виртуальной сетью (VNet).
Если вы предоставите управляемой идентичности агента соответствующие разрешения RBAC, агент сможет выполнять действия в вашей инфраструктуре, обращаться к вашим базам данных и выполнять команды в ваших кластерах. RBAC — это основная граница безопасности, которая управляет тем, что может сделать агент.
Интеграция виртуальной сети добавляет дополнительный уровень защиты, управляя тем, где агент может отправлять трафик. Без этой интеграции исходящий трафик от агента передается через общедоступный Интернет. При этом каждый исходящий вызов направляется через виртуальную сеть Azure и существующую инфраструктуру сетевой безопасности.
В этой статье объясняется, почему управление на уровне сети имеет значение для корпоративных развертываний, как работает интеграция виртуальной сети и как выбрать правильный режим управления сетями для рабочей нагрузки.
Почему важно управлять сетью
По умолчанию агент может получить доступ к любой конечной точке в Интернете. Для рабочих нагрузок разработки и тестирования это поведение приемлемо. Для корпоративных развертываний в производственной среде этот уровень доступа создает ненужные риски.
Два риска управляют требованием предприятия для сетевых элементов управления:
Утечка данных: агент с доступом к конфиденциальным внутренним данным и неограниченным доступом к Интернету может создать путь для выхода из организации.
Внедрение запроса: вредоносное содержимое в общедоступном Интернете можно создать для управления поведением агента. Агент без ограничений, получающий внешний контент, уязвим для атак с внедрением посредством таких ответов.
Поместите агент в виртуальную сеть для более эффективного контроля над его поведением.
Как работает интеграция виртуальной сети
Интеграция виртуальной сети подключает агент SRE к существующей виртуальной сети. Когда агент выполняет исходящий вызов, трафик проходит через сетевую инфраструктуру, а не через общедоступный Интернет.
После настройки интеграции виртуальной сети трафик агента:
- Отображается в сетевых журналах для аудита и мониторинга.
- Проходит через брандмауэры уровня 4 и уровня 7.
- Учитывает конфигурацию пользовательской системы доменных имен (DNS).
- Соответствует вашим корпоративным политикам безопасности и правилам исходящего сетевого трафика.
После соединения агента SRE с виртуальной сетью он работает с теми же правилами, что и любая другая рабочая нагрузка в этой сети, включая проверку брандмауэра, разрешение DNS и ведение журнала трафика.
Important
Интеграция виртуальной сети управляет только исходящим трафиком.
Режимы сетевого управления
Агент SRE предлагает три режима управления сетью. Выберите режим, соответствующий вашему режиму безопасности и рабочему контексту.
| Режим | Description | лучше всего подходит для |
|---|---|---|
| Неограниченный | Нет ограничений сети. Агент может получить доступ к любой конечной точке Интернета. | Разработка, тестирование и нечувствительные рабочие нагрузки. |
| Ограничено | Список разрешённых URL с использованием подстановочных знаков определяет, к каким конечным точкам агент может обращаться. | Управление на уровне узла без полной маршрутизации виртуальной сети. |
| виртуальная сеть Azure | Весь исходящий трафик, не относящийся к платформе, направляется через вашу виртуальную сеть (VNet), с применением ваших правил DNS и брандмауэра. | Промышленные развертывания, требующие контроля исходящего трафика и соблюдения требований аудита. |
Выбор режима управления сетью для рабочей нагрузки
Используйте следующие критерии для выбора режима:
Azure виртуальной сети: выберите этот режим, если рабочая нагрузка обрабатывает конфиденциальные или регулируемые данные, требует полного аудита исходящей сетевой активности или должна соответствовать корпоративным политикам безопасности. Этот режим рекомендуется для промышленных корпоративных развертываний.
Ограничение. Выберите этот режим, если вы хотите ограничить определенные внешние назначения без маршрутизации всего трафика через виртуальную сеть. Этот режим хорошо работает, если требуется частичный контроль без дополнительных затрат на полную конфигурацию виртуальной сети.
Неограниченно. Выберите этот режим, если рабочая нагрузка является краткосрочной средой разработки или тестирования без доступа к конфиденциальным данным. Этот режим используется по умолчанию.
Чтобы выбрать режим, откройте агент на портале Azure и выберите "Параметры>рабочей области". Переключение между режимами в работающем агенте. Параметры сохраняются при смене режима.
Как работает режим Azure виртуальной сети
В режиме виртуальной сети Azure исходящий трафик принимает один из двух путей:
Виртуальная сеть. По умолчанию весь исходящий трафик, отличный от платформы, проходит через делегированную подсеть в виртуальной сети. Применяются правила NSG, политики брандмауэра, настраиваемые DNS и сетевые журналы. Агент подвергается тем же элементам управления, что и любая другая рабочая нагрузка в этой подсети. Он может получить доступ только к тем ресурсам, к которым может получить доступ подсеть, и ни к чему больше.
Агент может получать доступ к ресурсам за закрытыми конечными точками, внутренним службам и локальным системам, подключённым через ExpressRoute или VPN, если это разрешено вашими сетевыми маршрутами и правилами.
Сеть инфраструктуры агента SRE Azure. Службы платформы, от которых зависит агент (оркестрация, конечные точки моделей, телеметрия), всегда проходят через управляемую инфраструктуру Microsoft. Эти службы не настраиваются. Некоторые возможности агента, такие как установка пакетов, доступ к репозиторию кода и удалённые серверы MCP, требуют доступа к общедоступным сервисам. Чтобы использовать эти возможности в режиме Azure виртуальной сети, включите соответствующий переключатель. Если переключатель отключен, эта функция недоступна, если только ваша VNet не может маршрутизировать трафик к этим службам напрямую (например, с помощью правил брандмауэра на основе FQDN). Дополнительные сведения см. в Azure SRE Agent infra network.
Сводка по маршрутизации трафика
| Тип трафика | Путь | Конфигурируемый? |
|---|---|---|
| Инфраструктура Azure (Log Analytics, App Insights, AKS, базы данных, Key Vaults) | Ваша виртуальная сеть | Yes. По умолчанию маршрутизируется через виртуальную сеть. |
| Локальные системы (ExpressRoute / VPN) | Ваша виртуальная сеть | Yes. Доступно, если это позволяет маршрутизация в вашей сети. |
| Службы платформы (оркестрация, конечные точки модели, телеметрия) | инфраструктура агента SRE Azure | No. Всегда направляется через управляемую инфраструктуру. |
| Реестры пакетов (PyPI, npm, NuGet, apt) | Сеть инфраструктуры агента SRE (переключатель включён) или ваша VNet (правило FQDN) | Yes. Переключатель для каждого реестра или пакеты для предварительной установки |
| Репозитории кода (GitHub, GHE, Azure DevOps) | Сеть инфраструктуры агента SRE (переключатель включён) или ваша VNet (правило FQDN) | Yes. Переключатель для каждого поставщика |
| Удаленные серверы MCP | Сеть инфраструктуры агента SRE (переключатель включён) или ваша VNet (правило FQDN) | Yes. Одиночный переключатель |
| Дополнительные имена хостов | Сеть инфраструктуры агента SRE (для хостов из списка) | Yes. Настраиваемый список |
| Трафик подключения | Общедоступный Интернет | No. В этой предварительной версии не маршрутизируется через виртуальную сеть. |
| Входящий трафик (частная конечная точка) | Не поддерживаются | No. Только исходящий трафик в этой предварительной версии. |
Настройка режима Azure виртуальной сети
Требования к подсети
для режима виртуальной сети Azure требуется выделенная подсеть в виртуальной сети:
- Размер: /28 или больше. A /28 поддерживает одновременные сеансы одного агента. Размер до /26 для больших флотов или емкости всплеска.
-
Делегирование: подсеть должна быть делегирована
Microsoft.App/environments. - Регион. Подсеть должна находиться в том же регионе, что и ресурс агента SRE.
- Выделенная: эту подсеть нельзя использовать совместно с другими службами.
Настройка режима Azure виртуальной сети
- Перейдите в Настройки>Конфигурация рабочего пространства>Сеть.
- Выберите Azure VNet в качестве режима исходящего подключения.
- Выберите "Обзор подсетей".
- Выберите подписку, группу ресурсов, виртуальную сеть и подсеть , которая соответствует требованиям подсети.
- Нажмите Сохранить.
- Протестируйте агент на типовом инциденте, чтобы убедиться, что он может получить доступ к нужным ресурсам.
инфраструктура агента SRE Azure
Некоторые возможности агента зависят от общедоступных служб, которые трудно внести в список разрешённых по IP-адресам. В режиме Azure VNet эти возможности требуют либо включения переключателя инфраструктурной сети (который направляет эту категорию трафика через инфраструктурную сеть агента Azure SRE), либо правил брандмауэра на основе FQDN в вашей VNet, которые разрешают этот трафик напрямую. См. сводку по маршрутизации трафика для полного списка категорий и путей.
Если вы отключите переключатель, и виртуальная сеть не может связаться со службой, эта возможность недоступна.
Note
Вы можете применить Политика Azure, чтобы ограничить или отключить переключатели инфракрасной сети, гарантируя, что ни какой оператор не может маршрутизировать трафик за пределами виртуальной сети.
Предустановленные пакеты
Предустановите пакеты в базовом образе диска песочницы, чтобы они были доступны при каждом запуске агента. Эта функция полезна, если инструменты или скрипты зависят от определенных пакетов, которые не включены в среду песочницы по умолчанию.
Чтобы настроить предварительно установленные пакеты, выполните приведенные действия.
Откройте агент на портале Azure и выберите Settings>Workspace configuration.
Перейдите на вкладку "Пакеты ".
Введите имя пакета, выберите диспетчер пакетов (pip или NuGet) и при необходимости укажите версию.
Нажмите кнопку +Добавить пакет.
Note
Пакеты NuGet должны быть инструментами .NET CLI (например, dotnet-ef). Невозможно установить пакеты библиотек глобально.
Элементы управления обхода виртуальной сети
При включении режима Azure VNet раздел В сети инфраструктуры на странице конфигурации рабочей области позволяет маршрутизировать категории трафика за пределами вашей виртуальной сети через общедоступный Интернет. Если вы не включите ни один из этих элементов управления, весь трафик агента будет маршрутизироваться через вашу виртуальную сеть.
Не каждая внешняя служба предоставляет тег службы Azure. GitHub, например, не является службой Azure и не предоставляет тег службы. Если вашему агенту требуется доступ к GitHub, то при использовании брандмауэра 4-го уровня на основе IP-адресов единственный вариант — поддерживать список IP-адресов провайдера в актуальном состоянии. Эти списки часто меняются, и брандмауэр, который не обновляется своевременно, нарушает работу агента.
То же самое верно для нескольких крупных общедоступных служб, таких как PyPI, npm, NuGet и реестры контейнеров. Эти службы работают с большими, часто меняющимися глобальными диапазонами IP-адресов, и они не охватываются тегами службы Azure.
Переключатели обхода позволяют агенту получать доступ к этим хостам через исходящий канал платформы. Ваша сетевая команда обновляет правила брандмауэра или переходит на брандмауэр, который поддерживает фильтрацию по именам узлов или полным доменным именам узлов (FQDN). Примерами являются Брандмауэр Azure Premium с правилами FQDN или сетевое виртуальное устройство, поддерживающее проверку TLS.
Рассматривайте средства обхода как временное решение, а не как постоянную замену фильтрации исходящего трафика с учетом имени узла.
Доступны следующие элементы управления:
| Управление | Description |
|---|---|
| Доступ к серверу протокола контекста модели (MCP) | При включении трафик сервера MCP направляется через общедоступный Интернет вместо виртуальной сети. |
| Доступ к диспетчеру пакетов | При включении трафик диспетчера пакетов (PyPI, npm, NuGet) направляется через общедоступный Интернет вместо виртуальной сети. |
| Репозитории кода | Выберите, для каких поставщиков репозиториев кода (GitHub, GitHub Enterprise, Azure DevOps) трафик будет направляться через общедоступный Интернет, а не через виртуальную сеть. |
| Дополнительные хосты | Введите дополнительные имена хостов или шаблоны с подстановочными знаками (например, github.com, *.example.com, raw.contoso.io), чтобы направлять трафик через общедоступный Интернет вместо вашей виртуальной сети. Настроенные пакеты автоматически разрешают собственные узлы. |
Рекомендации по системе управления
Доступ к этим элементам управления ограничен пользователями с ролью администратора агента SRE. Создание агента SRE в корпоративной среде является важным актом управления, так как организации обычно требуют существенного утверждения для развертывания служб в рабочей среде. Средства управления обходом — это один из аспектов более широкого подхода к корпоративному управлению, который включает управляемые идентификаторы, учетные данные On-Behalf-Of (OBO) и разрешения RBAC. Агент может выполнять только те действия, которые разрешены его правами, а сетевая конфигурация определяет, куда направляется этот трафик.
Что происходит, когда сеть блокирует вызов
Если исходящий запрос отклоняется правилом NSG или не имеет маршрута, агент видит ту же сетевую ошибку, что и любая рабочая нагрузка в этой подсети. Агент сообщает о сбое в результатах расследования (например, «Не удалось подключиться к рабочей области Log Analytics: превышено время ожидания подключения») и продолжает работу с инструментами и данными, которые ему доступны. Если критически важный источник данных недоступен, исследование является неполным, и агент сообщает об этом условии.
Ограничения
Следующие ограничения применяются во время предварительной версии.
Только исходящий трафик: интеграция с виртуальной сетью управляет только исходящим трафиком. Входящие подключения к агенту из частной сети не поддерживаются.
Коннекторы не маршрутизируются через виртуальную сеть: маршрутизация трафика коннекторов через виртуальную сеть не поддерживается. Коннекторы также доступны в предварительной версии. Во время предварительной версии трафик соединителя направляется через общедоступный Интернет. Дополнительные сведения см. в статье Соединители агента SRE.
Для команд kubectl для частных кластеров требуется управляемое удостоверение: когда агент достигает частного сервера API Azure Kubernetes Service (AKS) через интеграцию с виртуальной сетью, команды kubectl выполняются через поток вызова команды AKS.
Этот поток поддерживает управляемое удостоверение агента, но не передает учетные данные пользователя по модели On-Behalf-Of (OBO).
Команда также имеет операционные ограничения, включая 60-секундное время ожидания API Azure Resource Manager и ограничение в 512 КБ выходных данных. Длительные операции kubectl или операции с большим объёмом вывода могут быть обрезаны или завершиться с ошибкой.
Если вам нужна поддержка OBO для kubectl или выполнение операций, превышающих эти ограничения, оставьте сервер API AKS общедоступным и используйте неограниченный или ограниченный режим.
Note
Серверы MCP и ресурсы Azure внутри VNet доступны, как и ожидается, если IP-адрес и конфигурация тега службы указаны правильно.
Коннекторы также доступны в предварительной версии. Во время предварительной версии трафик соединителя направляется через общедоступный Интернет, а не через виртуальную сеть. Дополнительные сведения см. в статье Соединители агента SRE.