Обеспечить защиту службы поиска с искусственным интеллектом Azure

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

В качестве архитектора решений необходимо настроить элементы управления безопасностью в трех доменах:

• Network security: управление входящим и исходящим трафиком в search service.
• Аутентификация и авторизация: Определите, как, кто и что может получить доступ к вашей поисковой службе и данным.
• Data protection: реализация шифрования, управление доступом и мониторинг.

Общие сведения о шаблонах сетевого трафика

Прежде чем настроить сетевую безопасность, ознакомьтесь с тремя шаблонами сетевого трафика в Azure AI Search:

• Входящий трафик: запросы от клиентов к вашей поисковой службе, такие как запросы, индексирование и операции управления. Этот трафик настраивается клиентами.

• Outbound traffic: запросы от Search Service к внешним ресурсам, таким как индексаторы, которые подключаются к источникам данных, векторизаторы и пользовательские навыки. Этот трафик настраивается клиентами.

• Внутренний трафик: вызовы между службами через магистральную сеть Майкрософт. Этот трафик управляется корпорацией Майкрософт и не настраивается клиентами. Дополнительные сведения см. в разделе "Внутренняя защита трафика".

Настройка безопасности сети

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

• Создание правил брандмауэра IP-адресов
• Создание частной конечной точки
• Присоединитесь к периметру безопасности сети

Создание правил IP-брандмауэра

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

Когда использовать: базовые сценарии защиты, в которых необходимо ограничить доступ к известным IP-адресам.

How to get started: см. раздел Настройка сетевого доступа и правила брандмауэра для Azure AI Search.

Создание частной конечной точки

Создайте частную конечную точку для Azure AI Search, чтобы разрешить клиентам виртуальной сети безопасно получать доступ к данным в индексе поиска через Private Link. Частная конечная точка использует IP-адрес из адресного пространства виртуальной сети.

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

Когда следует использовать: сценарии высокой безопасности, требующие полной сетевой изоляции от общедоступного Интернета.

How to get started: см. раздел Создание частной конечной точки для Azure AI Search.

Подключение к периметру безопасности сети

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

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

Когда использовать: решения, использующие несколько ресурсов PaaS в Azure, которым требуется скоординированная защита границ сети.

How to get started:

• Начните с присоединения Azure AI Search к периметру безопасности сети. См. Добавьте службу поиска в периметр безопасности сети.

• Добавьте связанные службы, такие как Azure OpenAI, Azure Storage и Azure Monitor в тот же периметр.

Настройка проверки подлинности и авторизации

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

(Рекомендуется) Включите управление доступом на основе ролей

Используйте проверку подлинности Microsoft Entra, чтобы установить вызывающий объект, а не запрос в качестве удостоверения, прошедшего проверку подлинности. Назначения ролей Azure определяют авторизацию, предоставляя централизованное управление удостоверениями, условные политики доступа и комплексные аудиты.

Порядок работы для управления доступом ролевого базирования:

1. Включите управление доступом на основе ролей. Настройте службу поиска для принятия аутентификации через Microsoft Entra ID вместо ключей API (или в дополнение к ключам API). См. Включение или отключение управления доступом на основе ролей в Azure AI Search.

2. Назначение ролей пользователям и группам: Предоставьте доступ с минимальными привилегиями, используя встроенные роли (участник службы поиска, участник данных индекса поиска и читатель данных индекса поиска), чтобы контролировать, кто может управлять индексами и выполнять запросы к ним. См. раздел Подключение к Azure AI Search с использованием ролей.

3. Подключите приложение с помощью удостоверений: аутентификация без ключей API, используя DefaultAzureCredential, который поддерживает управляемые удостоверения, учетные данные разработчика и другие потоки на основе токенов. См. раздел Подключите ваше приложение к службе Azure AI Search с помощью идентификаций.

Настройка проверки подлинности ключа API

При проверке подлинности на основе ключей каждый запрос должен включать в себя ключ API администратора или API запросов, чтобы доказать, что это происходит из доверенного источника. Этот подход подходит для сред разработки, обратной совместимости с существующими приложениями или сценариев, где Microsoft Entra ID недоступны.

Рабочий процесс проверки подлинности на основе ключей:

1. Предоставьте ключ API в каждом запросе: ключи администратора предоставляют полный доступ ко всем операциям. Ключи запросов предоставляют доступ только для чтения к коллекции документов индекса. См. раздел Connect to Azure AI Search using keys.

2. Смена ключей администратора по расписанию: снижение риска компрометации ключей путем регулярной генерации ключей администратора. Службы поиска поддерживают два административных ключа для ротации без простоя. См. раздел "Повторное создание ключей администратора".

Авторизовать операции на уровне управления

Операции плоскости управления (создание, настройка и удаление служб) авторизуются через управление доступом на основе ролей в Azure Resource Manager — той же модели, которая используется во всех службах Azure. Ключи API не применяются к операциям управляющей плоскости. Три встроенные роли Azure управляют доступом.

Рабочий процесс для авторизации операций плоскости управления:

1. Назначение административных ролей. Используйте встроенные роли Azure (владелец, участник и читатель), чтобы предоставить доступ с минимальными привилегиями и управлять тем, кто может создавать, настраивать или удалять поисковые службы. См . раздел "Назначение ролей для администрирования службы".

2. Применение блокировок ресурсов: Предотвращение случайного удаления процессов поиска в рабочей среде путем применения CanNotDelete или ReadOnly блокировки. См. Блокировка ресурсов Azure для защиты инфраструктуры.

Авторизация операций канала данных

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

Предоставьте доступ к отдельным индексам

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

Решения, требующие безопасности на индексном уровне, см. в шаблоны проектирования для мультитенантных приложений SaaS и Azure AI Search.

Настройка исходящих подключений

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

Рекомендуется использовать управляемое удостоверение

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

Рабочий процесс использования управляемого удостоверения:

1. Настройка управляемого удостоверения для службы поиска: Выберите между управляемым удостоверением, назначаемым системой, и удостоверением, назначаемым пользователем. См. раздел Настройка службы поиска для подключения с использованием управляемой идентификации.

2. Подключитесь к внешним ресурсам с помощью служебной учетной записи: поддерживаемые подключения включают Azure Storage, Azure Cosmos DB, Azure SQL Database, SQL Managed Instance и Azure Functions.

Безопасный доступ к внешним данным

Настройте безопасные подключения на основе защиты внешних ресурсов:

• исключения для брандмауэра поисковой службы: разрешите трафик индексатора через брандмауэры источника данных, добавив исходящие IP-адреса поисковой службы в белые списки. Ознакомьтесь с документом Настройка правил IP-брандмауэра для разрешения подключений индексатора из Azure AI Search.

• Create shared private links: подключение индексаторов к источникам данных, защищенным Azure Private Link без предоставления трафика в общедоступный Интернет. См. раздел Установка исходящих подключений через общую частную ссылку.

• Использовать исключение доверенной службы для одного региона хранилища: включите доступ индексатора к защищённым учетным записям Azure Storage в одном регионе без настройки брандмауэра. Ознакомьтесь с созданием соединений индексатора с Azure Storage как доверенной службой.

• Настройка правил экземпляра ресурсов. Предоставьте определенным службам поиска доступ к учетным записям Azure Storage, защищенным правилами сети. См. Предоставить доступ к экземплярам ресурсов Azure.

• Подключение к частным конечным точкам SQL Managed Instance: Доступ к базам данных SQL Managed Instance через частные конечные точки при сохранении сетевой изоляции. См. Создание общей частной ссылки для управляемого экземпляра SQL с помощью Azure AI Search.

Безопасные подключения для внешней обработки ИИ

Исходящие запросы для обогащения и векторизации ИИ требуют особого внимания:

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

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

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

Настройка безопасности на уровне документа

Настройте детализированные разрешения на уровне документа от приема данных до выполнения запроса. Эта возможность необходима для создания безопасных агентских систем ИИ, обеспечивающих привязку данных, приложений RAG и корпоративных поисковых решений, требующих проверки полномочий на уровне документа. Дополнительные сведения см. в разделе Управление доступом на уровне документа.

Использование меток конфиденциальности (предварительная версия)

Настройте индексатор для автоматического обнаружения меток чувствительности Microsoft Purview во время индексирования и применения управления доступом на основе меток при выполнении запросов. Дополнительные сведения см. в разделе "Метки конфиденциальности".

Настройка шифрования данных

Azure AI Search шифрует все данные автоматически с помощью ключей, управляемых Корпорацией Майкрософт. Сведения о встроенном шифровании см. в разделе "Шифрование данных".

Для расширенной защиты данных можно реализовать следующие элементы управления шифрованием.

(Необязательно) Добавление шифрования ключей, управляемых клиентом

Добавьте дополнительный уровень шифрования для индексов и карт синонимов, управляя собственными ключами шифрования в Azure Key Vault. Ключи, управляемые клиентом (CMK), предназначены для организаций с требованиями, предусматривающими контроль клиента над ключами шифрования или возможность их отзыва. См. раздел Настройка ключей, управляемых клиентом, для шифрования данных в Azure AI Search.

Вы также можете настроить следующие параметры:

• Configure cross-tenant CMK: поддержка сценариев с несколькими клиентами, в которых ключи хранятся в другом клиенте Microsoft Entra, отличном от службы, используемой для поиска. См. Настройку ключей, управляемых клиентом, в разных арендаторах.

• Найдите зашифрованные объекты: определите, какие индексы и карты синонимов используют шифрование CMK. См. раздел "Поиск зашифрованных объектов и сведений".

Индексируйте зашифрованное содержимое BLOB

Настройте индексатор для обработки содержимого из Azure Blob Storage, зашифрованного в состоянии покоя, что отличается от шифрования индекса поиска с использованием CMK. См. раздел Tutorial: Индекс и обогащение зашифрованных BLOB-объектов.

(Необязательно) Включение конфиденциальных вычислений

Конфиденциальные вычисления защищает данные в процессе использования от несанкционированного доступа, включая Microsoft, с помощью аппаратной аттестации и шифрования. Этот тип вычислений настраивается только во время создания службы. См. раздел "Выбор типа вычислений".

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

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

Включение мониторинга и ведения журнала

Включите ведение журнала и мониторинг для вашей поисковой службы, чтобы отслеживать операции, обнаруживать аномалии и поддерживать аудит безопасности. Сведения о том, что Azure AI Search логирует по умолчанию, см. в разделе .

• Включить журналирование диагностики: записывайте операции для аудита безопасности и обнаружения аномалий, отправляя журналы в Azure Monitor, Центры событий или Azure Storage. См. Настройка диагностического ведения журнала для Azure AI Search.

• Мониторинг запросов: отслеживание действий поисковых запросов, задержки и регулирования для обнаружения необычных шаблонов. См. Мониторинг запросов в Azure AI Search.

• Мониторинг операций индексатора: отслеживание действий индексирования, ошибок и операций обновления данных. См. Отслеживание состояния индексатора и результатов в Azure AI Search.

• Настройка оповещений для аномальной активности: создание правил для пиковых объемов запросов, неудачных попыток проверки подлинности и необычных шаблонов доступа. См. раздел Создание или изменение правила оповещения на основе метрик.

• Создайте визуализацию журналов с помощью Power BI: постройте панели мониторинга для анализа активности поисковых служб и выявления тенденций безопасности. См. Visualize Azure AI Search логи и метрики с помощью Power BI.

Поддержание соответствия требованиям

Сведения о сертификации в соответствии с Azure AI Search и модели совместной ответственности см. в разделе Соответствие и сертификации.

Использование Azure Policy

• Просмотр встроенных определений политик. Используйте Azure Policy для аудита и применения конфигураций безопасности, таких как ведение журнала диагностики и использование частной конечной точки. См. контроль соответствия нормативным требованиям Azure Policy для Azure AI Search.

• Назначьте политику ведения журнала ресурсов: автоматически определите службы поиска, отсутствующие журналы диагностики, и исправьте конфигурацию. См. обзор Azure Policy.

• Создание настраиваемых политик: определение требований безопасности для конкретной организации и их применение во всех службах поиска. См. раздел Tutorial: создание определения настраиваемой политики.

Применение тегов ресурсов

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

Контрольный список безопасности

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

Сетевая безопасность:

• [ ] Настроенные правила брандмауэра IP, частная конечная точка или периметр безопасности сети
• [ ] Ограниченный входящий доступ для известных клиентов или сетей
• [ ] Настройка безопасных исходящих подключений с помощью управляемых удостоверений

Проверка подлинности и авторизация:

• [ ] Включено управление доступом на основе ролей
• [ ] Назначены соответствующие роли пользователям и приложениям
• [ ] Реализовано расписание смены ключей администратора (при использовании ключей)
• [ ] Настроенные разрешения на уровне индекса (при необходимости)

Защита данных:

• [ ] Настройка контроля доступа на уровне документа (если требуется)
• [ ] Настроенные метки конфиденциальности (если применимо)
• [ ] Реализовано шифрование CMK (при необходимости)
• [ ] Оценены требования к конфиденциальным вычислениям (если применимо)

Мониторинг и соответствие:

• [ ] Включено ведение журнала диагностики
• [ ] Настройка мониторинга и оповещений для выявления аномальных действий
• [ ] Примененные теги ресурсов для управления
• [ ] Назначена политика Azure для журналирования ресурсов
• [ ] Просмотр сертификатов соответствия требованиям

Связанный контент

• Данные, конфиденциальность и встроенные средства защиты в Azure AI Search
• Принципы безопасности Azure
• Совместная ответственность в облаке