Поделиться через

Ключи Azure Monitor, управляемые пользователем

Azure Monitor шифрует данные с помощью ключей, управляемых Корпорацией Майкрософт. Вы можете использовать собственный ключ шифрования для защиты данных в рабочих областях. Используя управляемые клиентом ключи в Azure Monitor, вы управляете жизненным циклом ключа шифрования и доступом к журналам. После настройки клиентских ключей, новые данные, поступающие в связанные рабочие области, шифруются с использованием вашего ключа в Azure Key Vault или Azure Key Vault Managed HSM (аппаратный модуль безопасности).

Общие сведения о ключе, управляемом клиентом

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

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

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

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

Данные, используемые за последние 14 дней или недавно используемые в запросах, хранятся в горячем кэше (SSD-сервере) для повышения эффективности запросов. Azure Monitor шифрует данные SSD с помощью ключей, управляемых корпорацией Майкрософт, независимо от того, настроены ли ключи, управляемые клиентом, но ваш контроль доступа к SSD соответствует отзыву ключей.

Внимание

Выделенные кластеры используют модель ценообразования уровня обязательств, начиная с 100 ГБ в день.

Как работают управляемые клиентом ключи в Azure Monitor

Azure Monitor использует управляемое удостоверение для предоставления доступа к ключу в Azure Key Vault. Идентификация кластеров Log Analytics поддерживается на уровне кластера. Чтобы предоставить ключи, управляемые клиентом, в нескольких рабочих областях, выделенный ресурс кластера Log Analytics служит промежуточным идентификатором между вашим Key Vault и рабочими областями Log Analytics. Хранилище кластера использует управляемое удостоверение, связанное с кластером, для аутентификации в Azure Key Vault с помощью Microsoft Entra ID.

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

  • Управляемое удостоверение, назначаемое системой, проще и создается автоматически вместе с кластером, когда вы устанавливаете identitytype на SystemAssigned. Используйте это удостоверение, чтобы предоставить хранилищу кластера доступ к Key Vault для шифрования и расшифровки данных.
  • Назначаемое пользователем управляемое удостоверение позволяет настроить ключи, управляемые клиентом, во время создания кластера, когда вы устанавливаете identitytype в UserAssigned, и предоставить ему разрешения в хранилище ключей до создания кластера.

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

Внимание

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

Снимок экрана: обзор ключа, управляемого клиентом.

  1. Хранилище ключей
  2. Ресурс кластера Log Analytics с управляемым удостоверением с разрешениями для Key Vault — удостоверение распространяется на базовое выделенное хранилище кластера.
  3. Выделенный кластер
  4. Рабочие области, связанные с выделенным кластером

Типы ключей шифрования

Шифрование данных хранилища использует три типа ключей:

  • KEK — ключ шифрования ключей (управляемый клиентом ключ)
  • AEK — ключ шифрования учетной записи
  • DEK — ключ шифрования данных

Применяются следующие правила:

  • Хранилище кластера имеет уникальный ключ шифрования для каждой учетной записи хранения, которая называется AEK.
  • AEK создает ключи DEK, которые шифруют каждый блок данных, записанных на диск.
  • При настройке управляемого клиентом KEK в кластере хранилище кластера отправляет запросы wrap и unwrap в Key Vault для шифрования и расшифровки AEK.
  • Ваш KEK никогда не покидает Хранилище ключей. Если вы храните ключ в управляемом HSM в Azure Key Vault, он никогда не покидает это оборудование.
  • Служба хранилища Azure использует управляемое удостоверение, связанное с кластером, для проверки подлинности. Он обращается к Azure Key Vault с помощью идентификатора Microsoft Entra.

Необходимые разрешения

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

Действие Необходимые разрешения или роли
Создание выделенного кластера Microsoft.Resources/deployments/* и Microsoft.OperationalInsights/clusters/write разрешения
Например, в соответствии с базовой ролью участника Log Analytics, предоставляемой системой
Изменение свойств кластера Microsoft.OperationalInsights/clusters/writeразрешения, предоставляемые встроенной ролью Участника Log Analytics, например,
Связывание рабочих областей с кластером Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/writeи Microsoft.OperationalInsights/workspaces/linkedservices/write разрешения, предоставляемые встроенной ролью Участника Log Analytics, например
Проверка состояния связывания рабочей области Microsoft.OperationalInsights/workspaces/readразрешения на рабочую область, предоставляемые встроенной роли Log Analytics Reader, например
Получить информацию о кластерах или проверить состояние обеспечения кластера Microsoft.OperationalInsights/clusters/readразрешения, предоставляемые встроенной ролью Log Analytics Reader, например,
Обновление уровня обязательств или типа выставления счетов в кластере Microsoft.OperationalInsights/clusters/writeразрешения, предоставляемые встроенной ролью Участника Log Analytics, например,
Предоставление необходимых разрешений Роль владельца или участника с разрешениями */write, или встроенная роль Участник Log Analytics, которая имеет разрешения Microsoft.OperationalInsights/*.
Отсоединение рабочей области от кластера Microsoft.OperationalInsights/workspaces/linkedServices/deleteразрешения, предоставляемые встроенной ролью Участника Log Analytics, например,
Удаление выделенного кластера Microsoft.OperationalInsights/clusters/deleteразрешения, предоставляемые встроенной ролью Участника Log Analytics, например,

Действия по подготовке ключей, управляемых клиентом

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

  1. Создайте или назначьте KEK Azure Key Vault (хранение ключа)
  2. Сопоставьте типы управляемых удостоверений выделенного кластера с доступом к Key Vault
  3. Предоставьте разрешения Key Vault управляемому удостоверению
  4. Обновление выделенного кластера с подробными сведениями об идентификаторе ключа
  5. Проверка предоставления выделенного кластера
  6. Связывание рабочих областей с выделенным кластером

Создание или назначение ключа KEK для Хранилища ключей Azure

Портфель продуктов для управления ключами Azure перечисляет хранилища и управляемые аппаратные модули безопасности (HSM), доступные для использования.

Создайте или используйте существующий Azure Key Vault в регионе, где существует выделенный кластер или где планируется его расположение. Создайте или импортируйте ключ в Azure Key Vault для шифрования журналов. Чтобы защитить ключ и доступ к данным в Azure Monitor, необходимо настроить Azure Key Vault в качестве восстанавливаемого. Эту конфигурацию можно проверить в свойствах в Key Vault. Включите параметр мягкое удаление и защиту от удаления.

Внимание

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

  1. Определите ключ, используемый на странице обзора кластера на портале Azure в представлении JSON.
  2. Расширение срока действия ключа в Azure Key Vault.
  3. Обновите кластер с активным ключом, предпочтительно со значением ''версии, чтобы всегда использовать последнюю версию автоматически.

Снимок экрана: параметры мягкого удаления и защиты от удаления.

Эти параметры можно обновить в Key Vault с помощью интерфейса командной строки и PowerShell:

Сопоставьте типы управляемых удостоверений выделенного кластера для доступа к Key Vault

Выделенные кластеры используют управляемое удостоверение для доступа к KEK Key Vault для шифрования данных. Тип управляемого удостоверения выделенного кластера должен совпадать с назначенным удостоверением роли Key Vault, чтобы разрешить операции шифрования и расшифровки данных.

identity type Задайте для свойства SystemAssigned значение или UserAssigned при создании кластера.

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

{
  "identity": {
    "type": "SystemAssigned"
    }
}

Примечание.

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

  • Вы не можете одновременно обновить удостоверение и ключ для кластера. Обновите их в двух последовательных операциях.
  • При обновлении SystemAssigned до UserAssigned, предоставьте удостоверение UserAssigned в Key Vault, а затем обновите в выделенном кластере.
  • При обновлении UserAssigned до SystemAssigned, предоставьте удостоверение SystemAssigned в Key Vault, а затем обновите в выделенном кластере.

Дополнительные сведения о создании выделенного кластера см. в статье "Создание выделенного кластера" и управление ими.

Предоставление разрешений Key Vault управляемому удостоверению

Key Vault имеет две модели разрешений для предоставления доступа к выделенному кластеру и базовому хранилищу: управление доступом на основе ролей Azure (Azure RBAC, рекомендуется) и политики доступа Key Vault (устаревшая версия).

  1. Назначьте Azure RBAC (рекомендуется)

    Чтобы добавить назначения ролей, необходимо иметь роль с Microsoft.Authorization/roleAssignments/writeMicrosoft.Authorization/roleAssignments/delete разрешениями, такими как администратор доступа пользователей или владелец.

    1. Откройте Key Vault на портале Azure и выберите параметры>конфигурации>доступа Azure на основе ролей и применить.
    2. Выберите "Перейти к управлению доступом (IAM) и добавьте назначение роли Пользователь шифрования сервиса криптографии Key Vault.
    3. Выберите управляемая идентичность на вкладке "Участники" и выберите подписку и идентичность в качестве участника.

    Снимок экрана: разрешения RBAC для Key Vault.

  2. Назначьте политику доступа к хранилищу (устаревшая версия)

    Откройте Key Vault на портале Azure и выберите Политики доступа>Политика доступа хранилища>+ Добавить политику доступа, чтобы создать политику с этими параметрами:

    • Разрешения ключа — выберите "Получить>ключ оболочки " и "Отменить ключ".
    • Выберите субъект в зависимости от типа удостоверения, используемого в кластере (системное или назначаемое пользователем управляемое удостоверение)
      • Управляемая идентичность, назначенная системой: введите имя кластера или идентификатор кластера
      • Управляемое удостоверение, назначенное пользователем: введите имя удостоверения

    Снимок экрана: предоставление разрешений политики доступа Key Vault.

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

Обновление выделенного кластера с подробными сведениями об идентификаторе ключа

Для всех операций в кластере требуется разрешение на действие Microsoft.OperationalInsights/clusters/write. Роли владельца или участника, которые включают */write операцию, могут предоставить это разрешение. Роль участника Log Analytics, включающая действие Microsoft.OperationalInsights/*, также предоставляет это разрешение.

На этом шаге обновляется выделенное хранилище кластера с ключом и версией для AEKwrap и unwrap.

Внимание

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

Снимок экрана: предоставление разрешений Key Vault.

Обновите сведения об идентификаторе ключа в кластере KeyVaultProperties.

Эта операция выполняется асинхронно и может потребовать много времени.

Н/П

Проверка подготовки выделенного кластера

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

Проверьте состояние предоставления с помощью CLI, PowerShell или REST API, как описано в разделе "Обновление выделенного кластера с подробными сведениями об идентификаторе ключа".

Внимание

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

Чтобы связать рабочую область, см. статью "Создание выделенного кластера и управление ими".

Отзыв ключа

Внимание

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

Хранилище кластера всегда учитывает изменения разрешений ключей и становится недоступным в течение часа или раньше, если ключ отключен или политика доступа удалена. Новые данные, загруженные в связанные рабочие области, удаляются и не подлежат восстановлению. Данные недоступны в этих рабочих областях, и запросы завершаются ошибкой. Ранее загруженные данные сохраняются до тех пор, пока кластер и ваши рабочие области не будут удалены. Политика хранения данных управляет недоступными данными и очищает их при достижении периода хранения. Данные, полученные за последние 14 дней или недавно использовавшиеся в запросах, хранятся в оперативном кэше (с поддержкой SSD) для повышения эффективности запросов. Данные на SSD удаляются при операции отзыва ключей и становятся недоступными. Хранилище кластера пытается периодически обращаться к Key Vault для операций с wrap и unwrap. После активации ключа и успешного выполнения unwrap, данные SSD загружаются из выделенного хранилища кластера. Функция приема данных и запросов возобновляется в течение 30 минут.

Смена ключей

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

  • Авторотация — обновление "keyVaultProperties" в кластере и опущение "keyVersion" свойства или присвоение ему значения ''. Хранилище автоматически использует последнюю версию ключа.
  • Явное обновление версии ключа – обновите свойства в "keyVaultProperties" и обновите версию ключа в свойстве "keyVersion". Для смены ключей в кластере необходимо явно обновить соответствующее свойство "keyVersion". Дополнительные сведения см. в разделе "Обновление кластера с сведениями об идентификаторе ключа". Если вы создаете новую версию ключа в Key Vault, но не обновляете ключ в кластере, хранилище кластера продолжает использовать предыдущий ключ. Если вы отключите или удалите старый ключ перед обновлением нового ключа в кластере, введите состояние отзыва ключей .

Все данные остаются доступными во время и после операции смены ключей. Кластер всегда шифрует данные с помощью ключа шифрования учетной записи (AEK), который шифруется с помощью новой версии ключа шифрования ключей (KEK) в Key Vault.

Управляемый клиентом ключ для сохраненных запросов и оповещений поиска по журналам

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

Примечание.

Запросы остаются зашифрованными с помощью ключа Майкрософт (MMK) в следующих сценариях независимо от конфигурации управляемых клиентом ключей: панелей мониторинга Azure, приложения логики Azure, записных книжек Azure и Runbook службы автоматизации.

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

Рекомендации перед настройкой управляемого клиентом ключа для сохраненных запросов

  • Вам нужны разрешения на запись в рабочей области и учетной записи хранения.
  • Учетная запись хранения должна быть StorageV2 и в том же регионе, что и рабочая область Log Analytics.
  • При связывании учетной записи хранения для сохраненных запросов служба удаляет существующие сохраненные запросы и функции из рабочей области, чтобы обеспечить конфиденциальность. Если вам нужны эти запросы, скопируйте существующие сохраненные запросы и функции перед конфигурацией. Сохраненные запросы можно просматривать с помощью PowerShell или при экспорте шаблона в разделе автоматизации в рабочей области.
  • Запросы, сохраненные в пакете запросов , не хранятся в связанной учетной записи хранения и не могут быть зашифрованы с помощью управляемого клиентом ключа. Рекомендуется сохранить как устаревший запрос для защиты запросов с помощью ключа, управляемого клиентом.
  • Сохраненные запросы и функции в связанной учетной записи хранения являются артефактами службы, а их формат может измениться.
  • Журнал запросов и закрепление на панели мониторинга не поддерживаются при связывании учетной записи хранения для сохраненных запросов.
  • Вы можете связать один или отдельный аккаунт хранения для сохранённых запросов и запросов для оповещений поиска в журналах.
  • Чтобы сохранить запросы и функции, зашифрованные с помощью ключа, настройте связанную учетную запись хранения с помощью управляемого клиентом ключа. Выполните эту операцию при создании учетной записи хранения или позже.

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

Свяжите учетную запись хранения, чтобы сохранить сохраненные запросы и функции в учетной записи хранения.

Примечание.

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

Н/П

Управляемый клиентом ключ для рабочих книг

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

Выберите «Сохранить содержимое в учетной записи хранения Azure» в операции сохранения книги.

Снимок экрана: сохранение рабочей книги.

Рекомендации перед настройкой управляемого клиентом ключа для сохраненных запросов оповещений журнала

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

Настройка связанной учетной записи хранения для запросов оповещений поиска по журналам

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

Н/П

Защищенное хранилище

Используя блокировку, вы можете утвердить или отклонить запросы инженера Майкрософт для доступа к данным во время взаимодействия с поддержкой клиентов.

Выделенные кластеры Log Analytics поддерживают блокировку, которая предоставляет разрешение на доступ к данным на уровне подписки.

Дополнительные сведения см. в статье "Блокировка клиента" для Microsoft Azure.

Рекомендации и ограничения

  • Вы можете создать до пяти активных кластеров в каждом регионе и подписке.

  • В каждом регионе и подписке может быть до семи зарезервированных кластеров (активные или недавно удаленные).

  • Вы можете связать до 1000 рабочих областей Log Analytics с кластером.

  • Вы можете выполнять до двух операций связывания рабочей области в определенной рабочей области в течение 30-дневного периода.

  • Перемещение кластера в другую группу ресурсов или подписку в настоящее время не поддерживается.

  • Обновления кластера не должны включать как идентификационную информацию, так и идентификатор ключа в одной операции. Чтобы обновить оба, используйте две последовательные операции.

  • В настоящее время Lockbox недоступен в Китае.

  • Lockbox не применяется к таблицам с планом вспомогательной таблицы.

  • Двойное шифрование настраивается автоматически для кластеров, созданных начиная с октября 2020 года в поддерживаемых регионах. Можно проверить, настроен ли кластер для двойного шифрования, отправив GET запрос в кластере и убедившись, что isDoubleEncryptionEnabled это значение true для кластеров с поддержкой двойного шифрования.

  • Если вы создаете кластер и получаете ошибку, "region-name не поддерживает двойное шифрование для кластеров", вы по-прежнему можете создать кластер без двойного шифрования, добавив "properties": {"isDoubleEncryptionEnabled": false} в текст запроса REST.

  • После создания кластера невозможно изменить параметры двойного шифрования.

  • Операция восстановления разрешена для удаленной рабочей области, которая по-прежнему связана с кластером. Это возможно только в период мягкого удаления. Восстановление возвращает состояние рабочей области в прежнее и сохраняет ее связь с кластером.

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

  • Необходимо настроить Azure Key Vault в качестве восстанавливаемого. Эти свойства по умолчанию не включены, и их следует настроить с помощью интерфейса командной строки или PowerShell:

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

  • Настройка параметра identitytype для кластера на значение None также лишает вас доступа к данным, однако этот подход не рекомендуется, так как его нельзя отменить без обращения в службу поддержки. Рекомендуемый способ отмены доступа к данным — отзыв ключа.

  • Вы не можете использовать управляемый клиентом ключ с назначаемого пользователем управляемого удостоверения, если Key Vault находится в Private-Link (виртуальной сети). Используйте системно назначаемое управляемое удостоверение в этом сценарии.

Устранение неполадок

  • Поведение в зависимости от доступности Key Vault:

    • Во время обычной операции приема выделенное хранилище кластера кэширует AEK в течение короткого периода времени и периодически возвращается в Key Vault unwrap .

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

  • Частота доступа к Key Vault — частота, с которой хранилище кластера обращается к Key Vault для операций wrap и unwrap, составляет от 6 до 60 секунд.

  • Если вы обновляете кластер, пока он находится в состоянии подготовки или обновления, обновление завершается ошибкой.

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

  • Рабочая область не может быть связана с кластером, если она уже связана с другим кластером.

  • Если вы создаете кластер и указываете KeyVaultProperties сразу, операция может завершиться ошибкой, пока идентификатор не будет назначен кластеру и не получит доступ к Key Vault.

  • Если вы обновляете существующий кластер с KeyVaultProperties и Get, а политика доступа к ключу отсутствует в Key Vault, операция завершается ошибкой.

  • Если не удается развернуть кластер, убедитесь, что Azure Key Vault, кластер и связанные рабочие пространства находятся в одном регионе. Они могут находиться в разных подписках.

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

  • Некоторые операции выполняются долго и могут занять некоторое время, включая создание кластера, обновление ключа кластера и удаление кластера. Вы можете проверить состояние операции, отправив GET запрос в кластер или рабочую область и наблюдая за ответом. Например, несвязанная рабочая область не имеет clusterResourceId под features.

  • Сообщения об ошибках

    Обновление кластера

    • 400 — кластер находится в состоянии удаления. Выполняется асинхронная операция. Перед выполнением операции обновления кластер должен завершить операцию.
    • 400 — KeyVaultProperties не пуст, но имеет неправильный формат. См. раздел об обновлении идентификатора ключа.
    • 400— не удалось проверить ключ в Key Vault. Это может быть связано с отсутствием разрешений или ключа. Убедитесь, что задали ключ и политику доступа в Key Vault.
    • 400 — ключ не может быть восстановлен. Key Vault необходимо настроить для мягкого удаления и защиты от окончательной очистки. См. документацию по Key Vault.
    • 400 — операция не может быть выполнена сейчас. Дождитесь завершения асинхронной операции и повторите попытку.
    • 400 — кластер находится в состоянии удаления. Дождитесь завершения асинхронной операции и повторите попытку.

    Получение кластера

    • 404 — кластер не найден. Возможно, кластер удален. Если вы пытаетесь создать кластер с таким именем и получить конфликт, кластер находится в процессе удаления.

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

  • Last updated on