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

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

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

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

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

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

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

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

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

REST API описывают все входящие запросы, которые обрабатывает служба поиска.

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы получить доступ к ресурсам Azure, защищенным с помощью Azure Private Link, создайте общую приватную ссылку, которую индексатор использует для подключения.

Исключение для служб поиска и хранилища в одном регионе

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

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

• Исключение доверенного сервиса
• Правила экземпляра ресурса

Безопасность сети

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

Входящий трафик через брандмауэры IP-адресов

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

Для настройки доступа к брандмауэру можно использовать портал Azure.

Кроме того, можно использовать REST API управления. Начиная с API версии 2020-03-13, вы можете с помощью параметра IpRule ограничить доступ к службе, определив IP-адреса, по отдельности или в пределах диапазона, которые будут предоставлять доступ к службе поиска.

Входящий трафик к частной конечной точке (сетевая изоляция, интернет-трафик отсутствует)

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

Частная конечная точка использует 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 AI" имеет механизм отказоустойчивости в кластере, чтобы гарантировать доступность, но она не хранит и не выполняет ваш фирменный код, используемый для создания или загрузки индексов.

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

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

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

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

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

При настройке службы поиска вы выбираете регион, определяющий, где хранятся и обрабатываются данные клиента. Каждый регион существует в географии (Гео), которая часто включает несколько регионов (например, Швейцария — это география, содержащая северную Швейцарию и западную Швейцарию). Служба поиска ИИ 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 могут использовать функции шифрования этой технологии.

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

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

Шифрование, управляемое службой, — это внутренняя операция Майкрософт, использующая 256-разрядное шифрование AES. Он происходит автоматически для всех индексов, включая добавочные обновления для индексов, которые не полностью зашифрованы (созданы до января 2018 г.).

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

Ключи, управляемые клиентом (CMK)

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

Ключи, управляемые пользователем, требуют другой платной службы Azure Key Vault, которая может находиться в другом регионе, но в рамках того же клиента Azure, что и функция поиска в Azure AI.

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

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

  • Западная часть США 2
  • Восточная часть США
  • Центрально-южная часть США
  • Правительство США (штат Вирджиния)
  • Правительство США (штат Аризона)

• Второй выпуск 13 мая 2021 г. добавил шифрование временных дисков и расширенное шифрование CMK для всех поддерживаемых регионов.

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

Включение шифрования CMK увеличит размер индекса и снизит производительность запросов. На основе наблюдений к настоящему времени вы можете ожидать увеличения времени выполнения запросов на 30–60 процентов, хотя фактическая производительность будет варьироваться в зависимости от структуры индекса и типов запросов. Из-за негативного влияния на производительность рекомендуется включить только эту функцию для индексов, которые действительно требуют его. Дополнительные сведения см. в статье "Настройка ключей шифрования, управляемых клиентом" в службе "Поиск ИИ Azure".

Администрирование безопасности

Управление ключами API

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

Журналы действий и ресурсов

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

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

Соответствие требованиям и сертификаты

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

Для соответствия требованиям можно использовать Политика Azure для реализации рекомендаций по обеспечению высокого уровня безопасности в microsoft cloud security benchmark. Microsoft Cloud Security Benchmark — это коллекция рекомендаций по безопасности, кодифицированных в элементы управления безопасностью, которые сопоставляются с ключевыми действиями, которые следует предпринять для устранения угроз для служб и данных. В настоящее время существует 12 элементов управления безопасностью, включая сетевую безопасность, ведение журнала и мониторинг и защиту данных.

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

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

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

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

См. также

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