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

Включение ключей, управляемых клиентом (CMK), добавляет дополнительную безопасность поверх неактивных ключей по умолчанию при использовании ключей, управляемых Microsoft. Когда вы активируете CMK, вы управляете ключами шифрования, используемыми для защиты ваших данных, включая возможность:

• Вращение ключей по расписанию, задаваемому клиентом
• Отключение или отмена ключей для блокировки доступа к зашифрованным содержимым (кэшированные ключи могут сохраняться до 60 минут).
• Аудит использования ключа с помощью ведения журнала Azure Key Vault

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

• Azure Key Vault

• Azure Key Vault управляемый HSM (аппаратный модуль безопасности). Управляемый модуль HSM Azure Key Vault — это проверенный HSM уровня 140-2 FIPS 3. Чтобы перейти с Azure Key Vault на HSM, обновите ключи и выберите управляемый HSM для хранения.

В этой статье объясняется, как настроить CMK для дополнительной защиты зашифрованных данных в Поиск с использованием ИИ Azure.

Настройка CMK для объектов Поиск с использованием ИИ Azure

Объекты с зашифрованными данными, которые можно настроить с помощью ключа, управляемого клиентом (CMK), включают индексы, списки синонимов, индексаторы, источники данных, векторизаторы и наборы навыков. Расшифровка требует много вычислительных ресурсов, поэтому шифрование применяется только к конфиденциальному содержимому.

Шифрование выполняется поверх:

• Все содержимое в индексах и списках синонимов.

• Конфиденциальное содержимое в индексаторах, источниках данных, наборах навыков и векторизаторах. Конфиденциальное содержимое относится к строкам подключения, описаниям, удостоверениям, ключам и входным данным пользователя. Например, наборы навыков имеют ключи Foundry Tools, а некоторые навыки принимают входные данные пользователей, такие как пользовательские сущности. В обоих случаях ключи и входные данные пользователя шифруются. Также шифруются все ссылки на внешние ресурсы (например, источники данных Azure или Azure модели OpenAI).

Добавление управляемого клиентом ключа к объекту должно произойти при создании объекта. Важно помнить:

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

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

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

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

• Если требуется CMK в службе поиска, задайте политику применения.

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

Включение CMK на уровне обслуживания для новых объектов по умолчанию (предварительная версия)

Начиная с выпуска 2026-03-01-preview, вы можете настроить управляемый клиентом ключ на уровне службы service-level в самой службе Поиск с использованием ИИ Azure. Эта функция позволяет настроить ключ один раз на уровне обслуживания и применить его ко всем вновь созданным объектам по умолчанию. Это гарантирует защиту всех конфиденциальных данных в службе поиска с помощью ключа, который вы управляете, без необходимости указывать ключевые сведения при каждом создании объекта.

Включение CMK на уровне сервиса означает следующее:

• Все объекты new, созданные в службе Поиск с использованием ИИ Azure, автоматически используют управляемый клиентом ключ по умолчанию, поэтому больше не нужно явно указывать сведения о ключе шифрования при каждом создании объекта.

• Эта функция является необязательной, и вы можете продолжать настраивать CMK на основе каждого объекта. Вы также можете переопределить ключ уровня обслуживания для отдельных объектов и изменить ключ уровня обслуживания независимо, что позволяет использовать разные ключи для различных объектов по мере необходимости.

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

Предварительные условия

• Поиск с использованием ИИ Azure на платном уровне (Базовый или более высокий, в любом регионе).

• Azure Key Vault и хранилище ключей с поддержкой мягкого удаления и защитой от очистки. Или Управляемый модуль HSM в Azure Key Vault. Этот ресурс может находиться в любой подписке и у другого арендатора. В этих инструкциях предполагается наличие одного арендатора. Для конфигурации между арендаторами см. Настройка ключей, управляемых заказчиком, в разных арендаторах.

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

  Чтобы назначать роли, вы должны быть подписаны как Owner, User Access Administrator, Role-based контроль доступа Administrator или быть назначены в пользовательскую роль с разрешениями Microsoft.Authorization/roleAssignments/write.

Шаг 1. Создание ключа шифрования

Используйте Azure Key Vault или Azure Key Vault управляемый модуль HSM для создания ключа. шифрование Поиск с использованием ИИ Azure поддерживает ключи RSA размером 2048, 3072 и 4096. Дополнительные сведения о поддерживаемых типах ключей см. в статье Общие сведениях о ключах.

Перед началом работы рекомендуется ознакомиться с этими советами .

Обязательные операции: оболочка, распаковка, шифрование и расшифровка.

Шаг 2. Создание субъекта безопасности

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

Используйте управляемое удостоверение и роли. Вы можете использовать управляемое системой удостоверение или управляемое пользователем удостоверение. Управляемое удостоверение позволяет службе поиска проходить проверку подлинности через Microsoft Entra ID без хранения учетных данных (ApplicationID или ApplicationSecret) в коде. Жизненный цикл этого типа управляемого удостоверения привязан к жизненному циклу службы поиска, который может иметь только одно управляемое удостоверение, назначаемое системой. Дополнительные сведения о работе управляемых удостоверений см. в разделе Что такое управляемые удостоверения для ресурсов Azure.

Шаг 3. Предоставление разрешений

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

Контроль доступа на основе ролей рекомендуется вместо модели разрешений политики доступа. Для получения дополнительных сведений или действий по миграции начните с Azure управления доступом на основе ролей (Azure RBAC) и политик доступа (устаревшая версия).

1. Перейдите в хранилище ключей на портале Azure.

2. Выберите Управление доступом (IAM) и выберите "Добавить назначение ролей".

3. Выберите роль:

   • В Azure Key Vault выберите пользователя шифрования Key Vault Crypto Service.
   • В управляемой HSM выберите пользователя шифрования службы криптошифрования.

4. Выберите управляемые удостоверения, выберите участников и выберите управляемое удостоверение службы поиска. Если вы тестируете локально, назначьте эту роль себе, а также.

5. Выберите Проверить и Назначить.

Подождите несколько минут, пока назначение роли вступит в силу.

Шаг 4. Добавление сведений ключа шифрования в объекты Поиск с использованием ИИ Azure

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

Можно настроить новые объекты поиска с ключом, управляемым клиентом, на уровне обслуживания или на уровне объекта. При настройке CMK на уровне обслуживания один и тот же ключ по умолчанию применяется ко всем вновь созданным объектам в службе, если только не указан другой ключ уровня объекта для переопределения по умолчанию уровня обслуживания.

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

Чтобы настроить CMK на объекте, используйте портал Azure, Search Service REST API или Azure SDK.

Настройка CMK на уровне обслуживания (предварительная версия)

Чтобы включить конфигурацию CMK уровня обслуживания, рекомендуется использовать Search Management REST API или пакет Azure SDK, который был обновлен для поддержки версии Search Management REST API 2026-03-01-preview или более поздней. Эта функция еще не поддерживается на портале Azure. Включение CMK на уровне обслуживания не добавляет шифрование к существующим объектам, но по умолчанию применяет один и тот же ключ ко всем вновь созданным объектам в службе, если только вы не укажете другой ключ уровня объекта для переопределения по умолчанию уровня обслуживания.

PATCH https://management.azure.com/subscriptions/{{subscription-id}}/resourceGroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service}}?api-version=2026-03-01-preview
Authorization: Bearer {{token}}
Content-Type: application/json

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
      "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
      "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
      "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>"
    }
  }
}

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
      "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
      "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
      "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
      "identity": {
        "@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
        "userAssignedIdentity": "/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<your-managed-identity-name>"
      }
    }
  }
}

{
  "encryptionWithCmk": {
    "serviceLevelEncryptionKey": {
          "keyVaultUri": "<YOUR-KEY-VAULT-URI>",
          "keyVaultKeyName": "<YOUR-ENCRYPTION-KEY-NAME>",
          "keyVaultKeyVersion": "<YOUR-ENCRYPTION-KEY-VERSION>",
          "accessCredentials": {
                  "applicationId": "<YOUR-APPLICATION-ID>",
                  "applicationSecret": "<YOUR-APPLICATION-SECRET>"
      }       
    }
  }
}

Шаг 5. Тестирование шифрования

Чтобы проверить работу шифрования, отмените ключ шифрования, запросите индекс (он должен быть неиспользуемым), а затем восстановите ключ шифрования.

Используйте портал Azure для этой задачи. Убедитесь, что у вас есть назначение роли, которое предоставляет доступ на чтение к ключу.

1. На странице Azure Key Vault выберите Objects>Keys.

2. Выберите созданный ключ и нажмите кнопку "Удалить".

3. На странице Поиск с использованием ИИ Azure выберите Search management>Indexes.

4. Выберите индекс и используйте обозреватель поиска для выполнения запроса. Вы должны обнаружить ошибку.

5. Вернитесь на страницу Azure Key Vault Objects>Keys.

6. Выберите " Управление удаленными ключами".

7. Выберите ключ и нажмите кнопку "Восстановить".

8. Вернитесь к индексу в Поиск с использованием ИИ Azure и повторно запустите запрос. Результаты поиска должны отображаться. Если вы не видите немедленные результаты, подождите минуту и повторите попытку.

Настройка политики для принудительного применения соответствия CMK

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

Назначить политику

1. На портале Azure перейдите к встроенной политике и выберите Assign.

   • AuditIfExists

   • Запретить

   Ниже приведен пример политики AuditIfExists на портале Azure:

   

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

3. Примите или измените значения по умолчанию. Выберите Проверить и создать, а затем выберите Создать.

Включение принудительного применения политик CMK

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

Создание соответствующей службы поиска

Для новых служб поиска создайте их с параметром SearchEncryptionWithCmk, установленным в Enabled.

Ни портал Azure, ни средства командной строки (Azure CLI и Azure PowerShell) изначально не предоставляют это свойство, но вы можете использовать Management REST API для подготовки службы поиска с определением политики CMK.

### Create a search service (provide an existing resource group)
@resource-group = my-rg
@search-service-name = my-search
PUT https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resource-group}}/providers/Microsoft.Search/searchServices/{{search-service-name}}?api-version=2025-05-01 HTTP/1.1
     Content-type: application/json
     Authorization: Bearer {{token}}

    {
        "location": "North Central US",
        "sku": {
            "name": "basic"
        },
        "properties": {
            "replicaCount": 1,
            "partitionCount": 1,
            "hostingMode": "default",
            "encryptionWithCmk": {
                "enforcement": "Enabled"
        }
      }
    }

Обновление существующей службы поиска

Для существующих служб поиска, которые теперь не соответствуют требованиям, исправьте их с помощью команды Services — Update API или Azure CLI az resource update. Исправление служб восстанавливает возможность обновления свойств службы поиска.

PATCH https://management.azure.com/subscriptions/<your-subscription-Id>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Search/searchServices/<your-search-service-name>?api-version=2025-05-01

{
  "properties": {
      "encryptionWithCmk": {
          "enforcement": "Enabled"
      }
  }
}

az resource update --name SEARCH-SERVICE-PLACEHOLDER --resource-group RESOURCE-GROUP-PLACEHOLDER --resource-type searchServices --namespace Microsoft.Search --set properties.encryptionWithCmk.enforcement=Enabled

"encryptionWithCmk": {
      "encryptionComplianceStatus": "NonCompliant",
      "enforcement": "Enabled"
    }
...

Смена или обновление ключей шифрования

Используйте следующие инструкции, чтобы повернуть ключи или перейти от Azure Key Vault к аппаратной модели безопасности (HSM).

Для смены ключей используйте возможности авторотации Azure Key Vault. Если вы используете автоповорот, не указывайте версию ключа в определениях объектов. Используется последний ключ, а не определенная версия.

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

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

Ключи кэшируются в течение 60 минут. Помните это при тестировании и ротации ключей.

1. Определите ключ, используемый индексом или сопоставлением синонимов.

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

3. Обновите свойства encryptionKey в индексе или сопоставлении синонимов, указав новые значения. Только объекты, изначально созданные с этим свойством, могут быть обновлены для использования другого значения.

4. Отключите или удалите предыдущий ключ в хранилище ключей. Проконтролируйте доступ к ключу и удостоверьтесь, что используется новый ключ.

По соображениям производительности служба поиска кэширует ключ на несколько часов. Если вы отключите или удалите ключ без предоставления нового, запросы продолжают работать на временной основе до истечения срока действия кэша. Однако после того как служба поиска больше не сможет расшифровать содержимое, вы получите следующее сообщение: "Access forbidden. The query key used might have been revoked - please retry."

советы по Key Vault

• Если вы не знакомы с Azure Key Vault, ознакомьтесь с этим кратким руководством, чтобы узнать о основных задачах: Set и получить секрет из Azure Key Vault с помощью PowerShell.

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

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

• Включите защиту очистки и обратимое удаление в хранилище ключей. Из-за характера шифрования с помощью ключей, управляемых клиентом, никто не сможет получить данные, если ключ Azure Key Vault удален. Чтобы предотвратить потерю данных, вызванную случайным удалением ключей Key Vault, необходимо включить защиту обратимого удаления и очистки в key vault. Обратимое удаление включено по умолчанию, поэтому при намеренном отключении проблемы будут возникать только проблемы. Защита очистки не включена по умолчанию, но требуется для шифрования с помощью CMK в Поиск с использованием ИИ Azure.

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

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

Работа с зашифрованным содержимым

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

Рекомендуется включить ведение журнала при настройке хранилища ключей.

1. Создайте рабочую область Log Analytics.

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

3. Выберите аудит или allLogs для категории, присвойте параметру диагностики имя, а затем сохраните его.

Следующие шаги

Если вы не знакомы с архитектурой безопасности Azure, ознакомьтесь с документацией по безопасности Azure и, в частности, этой статье: