Общие сведения о безопасности для поиска ИИ Azure

В этой статье описываются функции безопасности в службе "Поиск ИИ Azure", которые защищают данные и операции.

Поток данных (шаблоны сетевого трафика)

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

Поиск azure AI содержит три основных шаблона сетевого трафика:

• Входящие запросы, сделанные пользователем или клиентом в службу поиска (преобладающий шаблон)
• Исходящие запросы, отправляемые службой поиска в другие службы в Azure и на других платформах.
• Внутренние запросы между службами по защищенной магистральной сети Майкрософт.

Входящий трафик

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

• Создание, чтение, обновление или удаление индексов и других объектов в службе поиска
• Загрузка индекса с помощью документов поиска
• Запрос индекса
• Активация индексатора или выполнения набора навыков

ИНТЕРФЕЙСы REST API описывают полный диапазон входящих запросов, обрабатываемых службой поиска.

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

• Проверка подлинности на основе ключей (по умолчанию). Входящий запрос предоставляет допустимый ключ API.
• Управление доступом на основе ролей Авторизация осуществляется через удостоверения Microsoft Entra и назначения ролей в службе поиска.

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

Внутренний трафик

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

Внутренний трафик состоит из следующих элементов:

• Вызовы между службами для таких задач, как проверка подлинности и авторизация через идентификатор Microsoft Entra, ведение журнала ресурсов, отправленные в Azure Monitor, и подключения к частной конечной точке, использующие Приватный канал Azure.
• Запросы, сделанные в API служб искусственного интеллекта Azure для встроенных навыков
• Запросы, сделанные в модели машинного обучения, поддерживающие семантический рейтинг.

Исходящий трафик

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

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

Исходящие подключения можно сделать с помощью полного доступа ресурса строка подключения, включающего ключ или имя для входа в базу данных, или управляемое удостоверение, если вы используете идентификатор 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, чтобы установить доступ для чтения и записи к операциям.

• Для авторизации на основе ключей ключ API и квалифицированная конечная точка определяют доступ. Конечной точкой может быть сама служба, коллекция индексов, конкретный индекс, коллекция документов или конкретный документ. При связывании конечной точки операция (например, запрос на создание) и тип ключа (администратор или запрос) разрешают доступ к содержимому и операциям.

Ограничение доступа к индексам

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

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

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

Ограничение доступа к документам

Разрешения пользователей на уровне документа, также известные как безопасность на уровне строк, не поддерживаются в службе "Поиск ИИ Azure". Если вы импортируете данные из внешней системы, которая обеспечивает безопасность на уровне строк, например Azure Cosmos DB, эти разрешения не будут передаваться с данными в качестве индексируемого поиска ИИ Azure.

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

Место расположения данных

При настройке службы поиска вы выбираете регион, определяющий, где хранятся и обрабатываются данные клиента. Каждый регион существует в географическом регионе (географическом регионе), который часто включает несколько регионов (например, Швейцария — это география, содержащая Швейцарию северную и западную Швейцарию). Поиск ИИ Azure может реплицировать данные в другой регион в том же регионе для обеспечения устойчивости и высокой доступности. Служба не будет хранить или обрабатывать данные клиента за пределами указанного географического расположения, если вы не настроите функцию, которая зависит от другого ресурса Azure, и этот ресурс подготовлен в другом регионе.

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

• кэш обогащения
• сеанс отладки
• хранилище знаний

Дополнительные сведения об местонахождении данных см. в статье о местонахождении данных в Azure.

Исключения обязательств по размещению данных

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

Журналы телеметрии хранятся в течение одного с половиной года. В течение этого периода корпорация Майкрософт может получить доступ к именам объектов и ссылаться на нее в следующих условиях:

• Диагностика проблемы, улучшение функции или исправление ошибки. В этом сценарии доступ к данным является внутренним только без стороннего доступа.

• Во время поддержки эти сведения могут использоваться для быстрого решения проблем и эскалации группы продуктов при необходимости

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

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

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

Передаваемые данные

Для подключений к службам поиска через общедоступный Интернет служба поиска Azure прослушивает порт HTTPS 443.

Служба "Поиск ИИ Azure" поддерживает tls 1.2 и 1.3 для шифрования каналов между клиентами:

• TLS 1.3 — это значение по умолчанию для новых клиентских операционных систем и версий .NET.
• TLS 1.2 — это значение по умолчанию в старых системах, но вы можете явно задать TLS 1.3 в запросе клиента.

Более ранние версии TLS (1.0 или 1.1) не поддерживаются.

Дополнительные сведения см. в разделе поддержки TLS в платформа .NET Framework.

Неактивные данные

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

Ключи, управляемые службой

Шифрование, управляемое службой, — это внутренняя операция Майкрософт, использующая 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.

Смотреть этот видеоролик

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

См. также

• Основы обеспечения безопасности в Azure
• Безопасность в Azure
• Microsoft Defender для облака