Общие сведения о безопасности для поиска ИИ Azure
В этой статье описываются функции безопасности в службе "Поиск ИИ Azure", которые защищают данные и операции.
Поток данных (шаблоны сетевого трафика)
Azure AI служба размещается в Azure и обычно обращается к клиентским приложениям через общедоступные сетевые подключения. Хотя этот шаблон является преобладающим, это не единственный шаблон трафика, который вам нужно заботиться. Понимание всех точек входа, а также исходящего трафика является необходимым фоном для защиты сред разработки и рабочей среды.
Поиск azure AI содержит три основных шаблона сетевого трафика:
- Входящие запросы, отправляемые клиентом в службу поиска (основной шаблон).
- Исходящие запросы, отправляемые службой поиска в другие службы в Azure и на других платформах.
- Внутренние запросы между службами по защищенной магистральной сети Майкрософт.
Входящий трафик
Входящие запросы, предназначенные для конечной точки службы поиска, включают:
- Создание, чтение, обновление или удаление объектов в службе поиска
- Загрузка индекса с помощью документов поиска
- Запрос индекса
- Активация индексатора или выполнения набора навыков
ИНТЕРФЕЙСы REST API описывают полный диапазон входящих запросов, обрабатываемых службой поиска.
Как минимум, все входящие запросы должны проходить проверку подлинности с помощью одного из следующих вариантов:
- Проверка подлинности на основе ключей (по умолчанию). Входящий запрос предоставляет допустимый ключ API.
- Управление доступом на основе ролей Авторизация осуществляется через удостоверения Microsoft Entra и назначения ролей в службе поиска.
Кроме того, можно добавить функции безопасности сети для дальнейшего ограничения доступа к конечной точке. Вы можете создать правила входящего трафика в брандмауэре IP-адресов или создать частные конечные точки, которые полностью экранирует службу поиска из общедоступного Интернета.
Внутренний трафик
Внутренние запросы защищены и управляются корпорацией Майкрософт. Вы не можете настроить или контролировать эти подключения. Если вы блокируете доступ к сети, никаких действий в вашей части не требуется, так как внутренний трафик не настраивается клиентом.
Внутренний трафик состоит из следующих элементов:
- Вызовы между службами для таких задач, как проверка подлинности и авторизация через идентификатор Microsoft Entra, ведение журнала ресурсов, отправленные в Azure Monitor, и подключения к частной конечной точке, использующие Приватный канал Azure.
- Запросы, сделанные в API служб искусственного интеллекта Azure для встроенных навыков.
- Запросы, сделанные в модели машинного обучения, поддерживающие семантический рейтинг.
Исходящий трафик
Исходящие запросы можно защитить и управлять ими. Исходящие запросы исходят из службы поиска в другие приложения. Обычно эти запросы выполняются индексаторами для индексирования на основе текста, обогащения ИИ на основе навыков и векторизации во время запроса. Исходящие запросы включают операции чтения и записи.
Ниже приведен полный список исходящих запросов, для которых можно настроить безопасные подключения. Служба поиска выполняет запросы от собственного имени и от имени индексатора или пользовательского навыка.
| Операция | Сценарий |
|---|---|
| Индексаторы | Подключение внешним источникам данных для получения данных. Дополнительные сведения см. в разделе "Индексатор доступа к содержимому, защищенному сетевой безопасностью Azure". |
| Индексаторы | Подключение служба хранилища Azure для сохранения хранилищ знаний, кэшированных обогащений, сеансов отладки. |
| Настраиваемые навыки | Подключение функций Azure, веб-приложений Azure или других приложений, использующих внешний код, размещенный вне службы. Запрос на внешнюю обработку отправляется во время выполнения набора навыков. |
| Индексаторы и интегрированная векторизация | Подключение в Azure OpenAI и развернутую модель внедрения или через настраиваемый навык для подключения к предоставленной модели внедрения. Служба поиска отправляет текст в внедренные модели для векторизации во время индексирования. |
| Векторизаторы | Подключение в Azure OpenAI или другие модели внедрения во время запроса, чтобы преобразовать текстовые строки пользователя в векторы для поиска векторов. |
| Служба "Поиск" | Подключение в Azure Key Vault для ключей, управляемых клиентом, для шифрования и расшифровки конфиденциальных данных. |
Исходящие подключения можно сделать с помощью полного доступа ресурса строка подключения, включающего ключ или имя для входа в базу данных, или управляемое удостоверение, если вы используете идентификатор Microsoft Entra и доступ на основе ролей.
Чтобы получить доступ к ресурсам Azure за брандмауэром, создайте правила входящего трафика в других ресурсах Azure, которые допускают запросы службы поиска.
Чтобы получить доступ к ресурсам Azure, защищенным Приватный канал Azure, создайте общую приватную ссылку, которую индексатор использует для подключения.
Исключение для служб поиска и хранилища в одном регионе
Если служба хранилища Azure и поиск по искусственному интеллекту Azure находятся в одном регионе, сетевой трафик направляется через частный IP-адрес и происходит через магистральную сеть Майкрософт. Так как используются частные IP-адреса, нельзя настроить брандмауэры IP-адресов или частную конечную точку для безопасности сети.
Настройте однорегионные подключения с помощью любого из следующих подходов:
Безопасность сети
Безопасность сети защищает ресурсы от несанкционированного доступа или атаки путем применения элементов управления к сетевому трафику. Поиск ИИ Azure поддерживает сетевые функции, которые могут быть вашей передней линией защиты от несанкционированного доступа.
Входящий трафик через брандмауэры IP-адресов
Служба поиска подготавливается с общедоступной конечной точкой, которая позволяет получить доступ с помощью общедоступного IP-адреса. Чтобы ограничить трафик через общедоступную конечную точку, создайте правило брандмауэра для входящего трафика, которое допускает запросы с определенного IP-адреса или диапазона IP-адресов. Все клиентские подключения должны выполняться через разрешенный IP-адрес, иначе подключение будет отклонено.
С помощью портала можно настроить доступ к брандмауэру.
Кроме того, можно использовать REST API управления. Начиная с API версии 2020-03-13, вы можете с помощью параметра IpRule ограничить доступ к службе, определив IP-адреса, по отдельности или в пределах диапазона, которые будут предоставлять доступ к службе поиска.
Входящий трафик к частной конечной точке (сетевая изоляция, интернет-трафик отсутствует)
Для более строгой безопасности можно установить частную конечную точку для поиска ИИ Azure, чтобы клиент в виртуальной сети безопасно получать доступ к данным в индексе поиска по Приватный канал.
Частная конечная точка использует IP-адрес из диапазона адресов виртуальной сети для подключений к службе поиска. Сетевой трафик между клиентом и службой поиска передается через виртуальную сеть и приватный канал в магистральной сети Майкрософт, что позволяет избежать рисков, связанных с использованием общедоступного Интернета. Виртуальная сеть обеспечивает безопасный обмен данными между ресурсами с локальной сетью, а также Интернетом.
Хотя это решение является наиболее безопасным, использование дополнительных служб является добавленной стоимостью, поэтому убедитесь, что у вас есть четкое представление о преимуществах перед погружением. Дополнительные сведения о расценках см. на странице цен. Дополнительные сведения о том, как эти компоненты работают вместе, см. в этом видео. Вариант частной конечной точки начинает рассматриваться в видео с временной метки 05:48. Инструкции по настройке конечной точки см. в статье "Создание частной конечной точки для поиска ИИ Azure".
Проверка подлинности
После того как запрос будет принят в службу поиска, он по-прежнему должен пройти проверку подлинности и авторизацию, которая определяет, разрешен ли запрос. Поиск ИИ Azure поддерживает два подхода:
Проверка подлинности Microsoft Entra устанавливает вызывающий объект (а не запрос) в качестве удостоверения, прошедшего проверку подлинности. Назначение роли Azure определяет авторизацию.
Проверка подлинности на основе ключей выполняется с помощью запроса (а не вызывающего приложения или пользователя) с помощью ключа API, где ключ представляет собой строку, состоящую из случайно созданных чисел и букв, которые свидетельствуют о том, что запрос получен из надежного источника. Эти ключи требуются для каждого запроса. Отправка допустимого ключа представляет собой доказательство того, что запрос исходит от доверенной сущности.
Вы можете использовать оба метода проверки подлинности или отключить подход , недоступный в службе поиска.
Авторизация
Поиск ИИ Azure предоставляет модели авторизации для управления службами и управления содержимым.
Авторизация управления службами
Управление ресурсами авторизовано с помощью управления доступом на основе ролей в клиенте Microsoft Entra.
В службе "Поиск ИИ Azure" Resource Manager используется для создания или удаления службы, управления ключами API, масштабирования службы и настройки безопасности. Таким образом, назначения ролей Azure определяют, кто может выполнять эти задачи независимо от того, используют ли они портал, PowerShell или REST API управления.
Три основные роли (владелец, участник, читатель) применяются к администрированию службы поиска. Назначения ролей можно сделать с помощью любой поддерживаемой методологии (портал, PowerShell и т. д.) и соблюдаться на уровне службы.
Примечание.
Используя механизмы Azure, работающие на уровне всей платформы, можно заблокировать подписку или ресурс, чтобы предотвратить случайное или несанкционированное удаление службы поиска пользователями с правами администратора. Дополнительные сведения см. в статье Блокировка ресурсов для предотвращения случайного удаления.
Авторизация доступа к содержимому
Управление содержимым относится к объектам, созданным и размещенным в службе поиска.
Для авторизации на основе ролей используйте назначения ролей Azure, чтобы установить доступ для чтения и записи к операциям.
Для авторизации на основе ключей ключ API и квалифицированная конечная точка определяют доступ. Конечной точкой может быть сама служба, коллекция индексов, конкретный индекс, коллекция документов или конкретный документ. При связывании конечной точки операция (например, запрос на создание или обновление) и тип ключа (администратора или запроса) авторизуют доступ к содержимому и операциям.
Ограничение доступа к индексам
С помощью ролей Azure можно задать разрешения для отдельных индексов до тех пор, пока это сделано программным способом.
Используя ключи, любой пользователь с ключом администратора в службе может читать, изменять или удалять любой индекс в той же службе. Для защиты от случайного или вредоносного удаления индексов внутренний контроль над ресурсами кода является решением для отмены нежелательного удаления или изменения индекса. Служба "Поиск ИИ Azure" имеет отработку отказа в кластере, чтобы обеспечить доступность, но она не хранит или не выполняет собственный код, используемый для создания или загрузки индексов.
Для решений с многотенантностью, требующих границ безопасности на уровне индекса, обычно используется для обработки изоляции индекса на среднем уровне в коде приложения. Дополнительные сведения об использовании мультитенантного варианта см. в шаблонах конструктора для мультитенантных приложений SaaS и поиска ИИ Azure.
Ограничение доступа к документам
Разрешения пользователей на уровне документа, также известные как безопасность на уровне строк, не поддерживаются в службе "Поиск ИИ Azure". Если вы импортируете данные из внешней системы, которая обеспечивает безопасность на уровне строк, например Azure Cosmos DB, эти разрешения не будут передаваться с данными в качестве индексируемого поиска ИИ Azure.
Если вам требуется доступ к содержимому в результатах поиска, существует способ применения фильтров, которые включают или исключают документы на основе удостоверения пользователя. Это обходное решение добавляет строковое поле в источник данных, представляющее группу или удостоверение пользователя, которое можно сделать фильтруемым в индексе. В следующей таблице описаны два подхода к обрезке результатов поиска несанкционированного содержимого.
| Подход | Description |
|---|---|
| Security filters for trimming results in Azure Search (Фильтры безопасности для обрезки результатов Поиска Azure) | Документирует базовый рабочий процесс для реализации управления доступом на основе удостоверений пользователей. Описывает добавление удостоверений безопасности в индекс, а также объясняет фильтрацию этого поля для усечения результатов запрещенного содержимого. |
| Обрезка безопасности на основе удостоверений Microsoft Entra | В этой статье описаны действия по получению удостоверений из идентификатора Microsoft Entra, одной из бесплатных служб на облачной платформе Azure. |
Место расположения данных
При настройке службы поиска выберите расположение или регион, определяющий, где хранятся и обрабатываются данные клиента. Поиск azure AI не будет хранить данные клиентов за пределами указанного региона, если только вы не настроите функцию, которая зависит от другого ресурса Azure, и этот ресурс подготовлен в другом регионе.
В настоящее время единственным внешним ресурсом, на который записывает служба поиска, является служба хранилища Azure. Учетная запись хранения — это учетная запись хранения, которую вы предоставляете, и она может находиться в любом регионе. Служба поиска будет записывать данные в служба хранилища Azure, если используется любой из следующих функций: кэш обогащения, сеанс отладки, хранилище знаний.
Исключения обязательств по размещению данных
Имена объектов будут храниться и обрабатываться вне выбранного региона или расположения. Клиенты не должны размещать конфиденциальные данные в полях имен или создавать приложения, предназначенные для хранения конфиденциальных данных в этих полях. Эти данные отображаются в журналах телеметрии, используемых корпорацией Майкрософт для поддержки службы. Имена объектов включают имена индексов, индексаторов, источников данных, наборов навыков, ресурсов, контейнеров и хранилища ключей.
Журналы телеметрии хранятся в течение одного с половиной года. В течение этого периода корпорация Майкрософт может получить доступ к именам объектов и ссылаться на нее в следующих условиях:
Диагностика проблемы, улучшение функции или исправление ошибки. В этом сценарии доступ к данным является внутренним только без стороннего доступа.
Во время поддержки эти сведения могут использоваться для быстрого решения проблем и эскалации группы продуктов при необходимости
Защита данных
На уровне хранилища встроено шифрование данных для всего управляемого службой содержимого, которое сохраняется на диск, включая индексы, сопоставления синонимов и определения индексаторов, источников данных и когнитивных навыков. Шифрование, управляемое службой, применяется как к долгосрочному хранилищу данных, так и к временному хранилищу данных.
При необходимости можно добавить ключи, управляемые клиентом (CMK), для дополнительного шифрования индексированного содержимого для двойного шифрования неактивных данных. Для служб, созданных после 1 августа 2020 года, шифрование CMK распространяется на краткосрочные данные на временных дисках.
Передаваемые данные
В службе "Поиск ИИ Azure" шифрование начинается с подключений и передач. Для служб поиска в общедоступном Интернете поиск Azure ai прослушивает порт HTTPS 443. Все подключения клиентов к службе используют шифрование TLS 1.2. Более ранние версии (1.0 или 1.1) не поддерживаются.
Неактивные данные
Для данных, которые обрабатываются внутренне службой поиска, существуют модели шифрования данных, описанные в следующей таблице. Некоторые функции, такие как хранилище знаний, добавочное обогащение и индексирование на основе индексатора, выполняют чтение или запись в структурах данных в других службах Azure. Службы с зависимостью от служба хранилища Azure могут использовать функции шифрования этой технологии.
| Модель | Ключи | Требования | Ограничения | Применяется к |
|---|---|---|---|---|
| Шифрование на стороне сервера | Ключи, управляемые Майкрософт | Нет (встроенная функция) | Нет, доступной на всех уровнях во всех регионах, для содержимого, созданного после 24 января 2018 г. | Содержимое (индексы и карты синонимов) и определения (индексаторы, источники данных, наборы навыков), на дисках данных и временных дисках |
| Шифрование на стороне сервера | ключей, управляемых клиентом | Azure Key Vault | Доступно на платных уровнях, в определенных регионах, для содержимого, созданного после 1 августа 2020 г. | Содержимое (индексы и сопоставления синонимов) на дисках данных |
| полное шифрование на стороне сервера | ключей, управляемых клиентом | Azure Key Vault | Доступно на платных уровнях во всех регионах в службах поиска после 13 мая 2021 года. | Содержимое (индексы и сопоставления синонимов) на дисках данных и временных дисках |
Ключи, управляемые службой
Шифрование, управляемое службой, — это внутренняя операция Майкрософт, использующая 256-разрядное шифрование AES. Он происходит автоматически для всех индексов, включая добавочные обновления для индексов, которые не полностью зашифрованы (созданы до января 2018 г.).
Шифрование, управляемое службой, применяется ко всему содержимому в долгосрочном и краткосрочном хранилище.
Ключи, управляемые клиентом (CMK)
Для управляемых клиентом ключей требуется другая оплачиваемая служба Azure Key Vault, которая может находиться в другом регионе, но в той же подписке, что и поиск в Azure AI.
Поддержка CMK была развернута на двух этапах. Если вы создали службу поиска на первом этапе, шифрование CMK было ограничено долгосрочным хранилищем и определенными регионами. Службы, созданные на втором этапе после мая 2021 г., могут использовать шифрование CMK в любом регионе. В рамках развертывания второй волны содержимое шифруется как в долгосрочном, так и в краткосрочном хранилище. Дополнительные сведения о поддержке CMK см. в полном двойном шифровании.
Включение шифрования CMK увеличит размер индекса и снизит производительность запросов. На основе наблюдений на сегодняшний день вы можете ожидать увеличения в 30–60 процентов запросов, хотя фактическая производительность будет отличаться в зависимости от определения индекса и типов запросов. Из-за негативного влияния на производительность рекомендуется включить только эту функцию для индексов, которые действительно требуют его. Дополнительные сведения см. в статье "Настройка ключей шифрования, управляемых клиентом" в службе "Поиск ИИ Azure".
Администрирование безопасности
Управление ключами API
Использование проверки подлинности на основе ключей API означает, что у вас должен быть план повторного создания ключа администратора через определенные интервалы времени в соответствии с рекомендациями по безопасности Azure. В каждой службе поиска может быть не более двух ключей администратора. Дополнительные сведения о защите ключей API и управлении ими см. в разделе Создание ключей API и управление ими.
Журналы действий и ресурсов
Поиск по искусственному интеллекту Azure не регистрирует удостоверения пользователей, поэтому вы не можете ссылаться на журналы для получения сведений о конкретном пользователе. Однако эта служба регистрирует операции создания, чтения, обновления и удаления, которые вы можете сопоставить с другими журналами, чтобы понять суть конкретных действий.
Используя оповещения и инфраструктуру ведения журналов в Azure, вы можете улавливать всплески количества запросов или другие действия, которые отклоняются от ожидаемых рабочих нагрузок. Дополнительные сведения о настройке журналов см. в разделах Сбор и анализ данных журналов и Мониторинг запросов.
Соответствие требованиям и сертификаты
Поиск ИИ Azure участвует в регулярных аудитах и сертифицирован по многим глобальным, региональным и отраслевым стандартам как для общедоступного облака, так и для Azure для государственных организаций. Чтобы получить полный список, загрузите технический документ Предложение для соответствия требованиям Microsoft Azure со страницы официальных отчетов аудита.
Для соответствия требованиям можно использовать Политика Azure для реализации рекомендаций по обеспечению высокого уровня безопасности в microsoft cloud security benchmark. Microsoft Cloud Security Benchmark — это коллекция рекомендаций по безопасности, кодифицированных в элементы управления безопасностью, которые сопоставляются с ключевыми действиями, которые следует предпринять для устранения угроз для служб и данных. В настоящее время существует 12 элементов управления безопасностью, включая сетевую безопасность, ведение журнала и мониторинг и защиту данных.
Политика Azure — это возможность, встроенная в Azure, которая помогает управлять соответствием для нескольких стандартов, включая тест производительности облачной безопасности Майкрософт. Для известных эталонных показателей Политика Azure предоставляет встроенные определения, которые предоставляют как критерии, так и практический ответ, который устраняет несоответствие.
Для поиска по искусственному интеллекту Azure в настоящее время существует одно встроенное определение. Это для ведения журнала ресурсов. Вы можете назначить политику, которая идентифицирует службы поиска, которые отсутствуют в журнале ресурсов, а затем включите его. Дополнительные сведения см. в Политика Azure элементах управления соответствием нормативным требованиям для поиска ИИ Azure.
Смотреть этот видеоролик
Просмотрите это динамичное видео с обзором архитектуры безопасности и каждой категории компонентов.