Добавление Microsoft Foundry в периметр безопасности сети

Используйте периметр безопасности сети (NSP), чтобы ограничить доступ плоскости данных к ресурсу Microsoft Foundry и сгруппировать его с другими защищенными ресурсами PaaS. NSP позволяет:

  • Применяйте правила доступа для входящих и исходящих подключений вместо широкой публичной доступности.
  • Уменьшение риска кражи данных путем хранения трафика в пределах логической границы.
  • Централизованно регистрируют решения о доступе к сети между связанными ресурсами.

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

Важно

Поддержка периметра безопасности сети для Microsoft Foundry доступна в рамках общедоступной предварительной версии в соответствии с дополнительными условиями использования. Ознакомьтесь с ограничениями и рекомендациями перед началом работы.

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

На схеме показан ресурс Foundry внутри границы NSP. Правила для входящего доступа фильтруют трафик из внешних источников, а правила исходящего доступа контролируют исходящий трафик в службы за пределами периметра.

Необходимые условия

  • Подписка Azure, в которой можно создавать ресурсы периметра безопасности сети и управлять ими. Как минимум, используйте учетную запись с ролью владельца, участника или участника сети (или настраиваемой роли с эквивалентными разрешениями).
  • Ресурс Foundry.
  • Периметр безопасности сети (NSP) и профиль.
  • Если вы используете автоматизацию с помощью Azure CLI, настоятельно рекомендуется использовать версию Azure CLI 2.75.0 или более позднюю.
  • Если вы хотите запросить журналы доступа, необходимо использовать рабочую область Log Analytics.

Полный набор необходимых действий и разрешений (профилей, связей, правил доступа, параметров диагностики) см. в разделе разрешения RBAC Azure, необходимые для периметра безопасности сети.

Проверка настройки (Azure CLI)

Выполните эту команду, чтобы убедиться, что доступно расширение nsp Azure CLI и можно запросить метаданные NSP.

az extension add --name nsp --upgrade
az network perimeter associable-resource-type list --output table

Команда возвращает список типов ресурсов, которые можно связать с NSP. Найдите Microsoft.CognitiveServices/accounts в выходных данных, чтобы убедиться, что ресурсы Foundry поддерживают ассоциацию NSP. Если вы видите ошибку проверки подлинности, выполните вход с помощью az login и повторите попытку.

Справочник: az network perimeter associable-resource-type list

Присоедините ресурс Foundry

Присоединение на портале

  1. Откройте портал Azure и перейдите к ресурсу периметра безопасности сети.
  2. Выберите связанные ресурсы (или ресурсы в зависимости от итерации пользовательского интерфейса). >Добавьте или свяжите их.
  3. Выберите целевой профиль, выберите ресурс Foundry, задайте режим доступа (начните с обучения) и подтвердите.

Снимок экрана портала и подробное пошаговое руководство см. в статье Assign an Azure OpenAI account to a network security периметр. Тот же поток портала применяется к ресурсам платформы Foundry.

Подключение к Azure CLI

az network perimeter association create \
	--name MyAssociation \
	--perimeter-name MyPerimeter \
	--resource-group MyResourceGroup \
	--access-mode Learning \
	--private-link-resource "{id:<FOUNDRY_RESOURCE_ARM_ID>}" \
	--profile "{id:<NSP_PROFILE_ARM_ID>}"

Эта команда связывает ресурс Foundry с профилем в режиме обучения, чтобы просмотреть журналы доступа перед применением правил доступа.

Справочник: az network perimeter association create

Инструкции по интерфейсу командной строки (для автоматизации) и полного создания см. в кратких руководствах по NSP (CLI или PowerShell):

Проверьте связь, выполнив следующую команду:

az network perimeter association show \
	--name MyAssociation \
	--perimeter-name MyPerimeter \
	--resource-group MyResourceGroup

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

Выбор режима доступа

Начните в режиме обучения, чтобы наблюдать за потенциальными отказами. Переключитесь в режим "Принудительно" после определения необходимых правил для входящего и исходящего трафика. Дополнительные сведения см. в режимах доступа NSP.

Общие сведения о взаимодействии publicNetworkAccess

  • Режим обучения: publicNetworkAccess по-прежнему контролирует доступ при оценке логов.
  • Принудительный режим: правила NSP имеют приоритет; publicNetworkAccess фактически переопределяется разрешёнными входящими правилами.

Изменение режима доступа

На портале найдите запись ассоциации для ресурса Foundry и выберите Изменить режим доступа. Для автоматизации используйте az network perimeter association update.

Справочник: az network perimeter association update

Включение ведения журнала

Настройте параметры диагностики в ресурсе NSP для отправки allLogs в Log Analytics, хранилище или Центры событий.

Подробные инструкции см. в журналах диагностики периметра безопасности сети.

Важно

Если ресурс Foundry находится внутри периметра безопасности сети в режиме Enforced, диагностические журналы на клиентских ресурсах (рабочей области Log Analytics, учетной записи для хранения данных или Концентратора событий) фильтруются только по правилам NSP, если запрос использует аутентификацию через Microsoft Entra ID (AAD). Запросы с аутентификацией через ключи API не содержат утверждения о периметре NSP, поэтому журнальный трафик в эти назначения не блокируется NSP. Чтобы обеспечить полное соответствие NSP для ведения журнала диагностики, используйте проверку подлинности Entra ID.

Интерпретация журналов

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

Примеры полей журнала, которые можно фильтровать, такие как MatchedRule или Profile, см. в разделе Добавление службы Azure OpenAI в периметр сетевой безопасности.

Определение правил доступа

В профиле выберите:

  • Правила для входящего трафика: диапазоны IP-адресов или источники(управляемая идентификация).
  • Правила исходящего трафика: назначения FQDN, необходимые за пределами совместно расположенных ресурсов периметра.

Действия по созданию правил (снимки экрана портала, параметры CLI, примеры):

Неявное доверие. Ресурсы внутри одного NSP могут достигать друг друга при проверке подлинности запросов с помощью управляемого удостоверения или назначения ролей. Вам нужны явные правила только для внешних источников, назначений или шаблонов ключей API.

Правила для входящего трафика

Выберите диапазон IP -адресов (CIDR) или область подписки. Предпочитайте подписку и управляемое удостоверение для внутреннего трафика между службами. Используйте диапазон IP только в том случае, если доступ на основе проверки личности невозможен.

Правила исходящего трафика

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

Распространенные полные доменные имена для правил исходящего трафика Foundry:

  • *.openai.azure.com — конечные точки модели
  • *.blob.core.windows.net — хранилище
  • *.search.windows.net — индексы поиска

Примечание

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

Проверка перед применением

  1. Изначально оставайтесь в режиме обучения; проверьте журналы доступа для запретов, влияющих на необходимый трафик.
  2. Добавляйте или уточняйте входящие и исходящие правила.
  3. Переключитесь в режим принудительного применения.
  4. Откройте Microsoft Foundry и выполните тестирование модели или чата. Успешное завершение указывает на то, что необходимый трафик разрешен.
  5. При блокировке вернитесь в режим обучения или добавьте правила и повторите попытку.

Устранение неполадок

  • Если интерфейс портала не отображает ресурс Foundry как ассоциируемый, убедитесь, что в вашем регионе поддерживается ассоциация Foundry с NSP и просмотрите поддерживаемые типы ресурсов: понятия периметра безопасности сети.
  • Если после включения диагностики журналы не отображаются, убедитесь, что вы выбрали allLogs и что ваш пункт назначения поддерживается: журналы диагностики для периметра безопасности сети.
  • Если режим обучения выглядит корректно, но режим принудительного выполнения блокирует доступ, вернитесь в режим обучения и добавьте минимальные правила для входящего и исходящего трафика, необходимые для вашего сценария: руководство Azure OpenAI NSP.
  • Если управляемое удостоверение не может достичь совместно расположенных ресурсов, убедитесь, что оба ресурса находятся в одном NSP и что назначения ролей верны.
  • Если журналы не отображаются сразу после включения диагностики, разрешите до 15 минут распространения диагностических данных в рабочую область Log Analytics.

Проверка ограничений и рекомендаций

  • NSP управляет трафиком на уровне плоскости данных. Операции плоскости управления могут по-прежнему выполняться, если не ограничены отдельно.
  • Используйте управляемое удостоверение (назначаемое системой или пользователем) с соответствующими назначениями ролей для любого доступа к источнику данных (например, Хранилище BLOB-объектов Azure, используемый для пакетных входных и выходных данных).
  • Размещайте зависимые службы (Azure OpenAI, служба хранилища Azure, Поиск с использованием ИИ Azure и т. д.) в том же центре обслуживания NSP, если требуется взаимный доступ с минимальными правилами разрешения исходящего трафика.
  • Экспорт журнала диагностики в места назначения клиента (Log Analytics, хранилище, концентратор событий) учитывает правила NSP только при использовании проверки подлинности Microsoft Entra ID. Запросы, прошедшие проверку подлинности ключа API, обходят фильтрацию журналов NSP. Переключитесь на Entra ID проверку подлинности для полного покрытия трафика ведения журнала.

Дополнительные сведения см. в концепциях периметра безопасности сети.

Просмотр конфигурации и управление ими

Используйте REST или CLI для аудита и согласования:

Используйте версию 2024-10-01 API или последнюю версию, показанную в справочнике REST при выполнении скриптов. Всегда проверяйте текущую версию API в ссылке перед скриптами.

Связанное содержимое

  • Last updated on