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

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

  • Статья

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

Действие Необходимые разрешения или роли
Создание выделенного кластера 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, например

Хранение ключа шифрования (KEK)

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

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

Внимание

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

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

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

Создание кластера

Кластеры используют управляемое удостоверение для шифрования данных в Key Vault. Настройте свойство identitytype на SystemAssigned или UserAssigned при создании кластера, чтобы разрешить доступ к вашему хранилищу ключей (Key Vault) для операций шифрования и расшифровки данных.

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

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

Примечание.

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

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

Выполните процедуру, показанную в статье о выделенном кластере.

Предоставьте разрешения 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.

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

Н/П

Внимание

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

Выполните процедуру, показанную в статье "Выделенные кластеры".

Выполните процедуру, показанную в статье "Выделенные кластеры".

Отзыв ключа

Внимание

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

Хранилище кластера всегда учитывает изменения разрешений ключей в течение часа или раньше, и в результате хранилище становится недоступным. Новые данные, загруженные в связанные рабочие области, удаляются и не подлежат восстановлению. Данные недоступны в этих рабочих областях, и запросы завершаются ошибкой. Ранее полученные данные остаются в хранилище, пока вы не удалите кластер и рабочие области. Политика хранения данных управляет недоступными данными и очищает их при достижении периода хранения. Данные, полученные за последние 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 позволяет хранить сохраненные запросы и оповещения поиска журналов, зашифрованные вашим ключом, в собственной учетной записи хранения, когда они связаны с вашей рабочей областью.

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

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

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

Примечание.

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

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

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

  • У вас должны быть разрешения на запись в рабочей области и учетной записи хранения.
  • Обязательно создайте учетную запись хранения в том же регионе, что и рабочая область Log Analytics, с шифрованием ключей, управляемым клиентом. Это важно, так как сохраненные запросы хранятся в хранилище таблиц, и его можно шифровать только при создании учетной записи хранения.
  • Запросы, сохраненные в пакете запросов, не шифруются с помощью ключа, управляемого клиентом. Выберите " Сохранить как устаревший запрос " при сохранении запросов, чтобы защитить их с помощью ключа, управляемого клиентом.
  • Сохраненные запросы в хранилище считаются артефактами службы, и их формат может измениться.
  • Связывание учетной записи хранения для запросов удаляет существующие сохраняемые запросы из вашей рабочей области. Функция "Копия" сохраняет запросы, которые необходимы перед этой конфигурацией. Сохраненные запросы можно просмотреть с помощью PowerShell.
  • Запросы 'history' и 'pin to dashboard' не поддерживаются при подключении учетной записи хранения для запросов.
  • Вы можете связать одну учетную запись хранения с рабочей областью для сохраненных запросов и запросов оповещений поиска журналов.
  • Оповещения поиска журналов сохраняются в хранилище Blob и шифрование с использованием ключей, управляемых клиентом, можно настроить при создании учетной записи хранения или позже.
  • Оповещения, вызванные поиском по журналам, не содержат результатов поиска или запроса для оповещения. Используйте измерения оповещений для получения контекста для запущенных оповещений.

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

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

Н/П

После настройки любой новый сохраненный поисковый запрос будет сохранен в хранилище.

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

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

Не применимо

После настройки любой новый запрос оповещения будет сохранен в хранилище.

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

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

Lockbox предоставлен в выделенном кластере в Azure Monitor, где разрешения на доступ к данным предоставляются на уровне подписки.

Узнайте больше о Customer Lockbox для Microsoft Azure.

Операции с ключами, управляемыми клиентом

Ключ, управляемый клиентом, предоставляется в выделенном кластере, и эти операции описаны в статье о выделенном кластере.

  • Получите все кластеры в группе ресурсов
  • Получите все кластеры в рамках подписки
  • Обновление резервирования мощности в кластере
  • Обновление billingType в кластере
  • Отсоединение рабочей области от кластера
  • Удаление кластера

Пределы и ограничения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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