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

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

Просмотрите ограничения и ограничения перед настройкой .

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

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

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

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

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

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

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

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

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

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

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

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

Операция с ключами шифрования

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

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

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

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

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

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

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

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

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

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

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

• обратимое удаление
• Защита от очистки защищает секрет и данные хранилища от принудительного удаления даже после обратимого удаления.

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

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

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

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

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

Предоставление разрешений Key Vault

В Key Vault есть две модели разрешений для предоставления доступа к кластеру и хранилищу на основе подложек — управление доступом на основе ролей Azure (Azure RBAC) и политики доступа к Хранилищу (устаревшая версия).

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

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

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

   

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

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

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

   

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

Указание в кластере новых сведений об идентификаторе ключа

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

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

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

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

az account set --subscription cluster-subscription-id

az monitor log-analytics cluster update --no-wait --name "cluster-name" --resource-group "resource-group-name" --key-name "key-name" --key-vault-uri "key-uri" --key-version "key-version"

$clusterResourceId = az monitor log-analytics cluster list --resource-group "resource-group-name" --query "[?contains(name, "cluster-name")].[id]" --output tsv
az resource wait --created --ids $clusterResourceId --include-response-body true

Select-AzSubscription "cluster-subscription-id"

Update-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name" -KeyVaultUri "key-uri" -KeyName "key-name" -KeyVersion "key-version" -AsJob

# Check when the job is done when `-AsJob` was used
Get-Job -Command "New-AzOperationalInsightsCluster*" | Format-List -Property *

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/clusters/cluster-name?api-version=2022-10-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://key-vault-name.vault.azure.net",
      "keyName": "key-name",
      "keyVersion": ""
  },
  "sku": {
    "name": "CapacityReservation",
    "capacity": 100
  }
}

{
  "identity": {
    "type": "SystemAssigned",
    "tenantId": "tenant-id",
    "principalId": "principal-id"
  },
  "sku": {
    "name": "capacityreservation",
    "capacity": 100
  },
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://key-vault-name.vault.azure.net",
      "keyName": "key-name",
      "keyVersion": ""
      },
    "provisioningState": "Succeeded",
    "clusterId": "cluster-id",
    "billingType": "Cluster",
    "lastModifiedDate": "last-modified-date",
    "createdDate": "created-date",
    "isDoubleEncryptionEnabled": false,
    "isAvailabilityZonesEnabled": false,
    "capacityReservationProperties": {
      "lastSkuUpdate": "last-sku-modified-date",
      "minCapacity": 100
    }
  },
  "id": "/subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.OperationalInsights/clusters/cluster-name",
  "name": "cluster-name",
  "type": "Microsoft.OperationalInsights/clusters",
  "location": "cluster-region"
}

Связывание рабочей области с кластером

Для выполнения этой операции необходимо иметь разрешения на запись как для рабочей области, так и для кластера. Он включает элементы Microsoft.OperationalInsights/workspaces/write и Microsoft.OperationalInsights/clusters/write.

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

Отзыв ключа

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

Смена ключей

Смена ключей имеет два режима.

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

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

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

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

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

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

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

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

• У вас должны быть разрешения на запись в рабочую область и в учетную запись хранения.
• Обязательно создайте учетную запись хранения в том же регионе, что и рабочая область Log Analytics, с шифрованием ключей, управляемым клиентом. Это важно, так как сохраненные запросы хранятся в хранилище таблиц, и его можно шифровать только при создании учетной записи хранения.
• Запросы, сохраненные в пакете запросов, не шифруются с помощью ключа, управляемого клиентом. Выберите " Сохранить как устаревший запрос " при сохранении запросов, чтобы защитить их с помощью ключа, управляемого клиентом.
• Сохранение запросов в хранилище считается артефактами службы, а их формат может измениться.
• Связывание учетной записи хранения для запросов удаляет существующие запросы из рабочей области. Копирование сохраняет запросы, необходимые перед этой конфигурацией. Сохраненные запросы можно просмотреть с помощью PowerShell.
• Запросы типа "Журнал" и "Закрепить на панели мониторинга" не поддерживаются при связывании учетной записи хранения для запросов.
• Вы можете связать одну учетную запись хранения с рабочей областью для сохраненных запросов и запросов оповещений поиска журналов.
• Оповещения поиска журналов сохраняются в хранилище BLOB-объектов и шифрование ключей, управляемых клиентом, можно настроить при создании учетной записи хранения или более поздней версии.
• Оповещения поиска по журналам не содержат результатов поиска или запроса оповещений. Чтобы получить контекст для сработавших оповещений, можно использовать измерения оповещений.

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

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

az account set --subscription "storage-account-subscription-id"

$storageAccountId = '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage name>'

az account set --subscription "workspace-subscription-id"

az monitor log-analytics workspace linked-storage create --type Query --resource-group "resource-group-name" --workspace-name "workspace-name" --storage-accounts $storageAccountId

Select-AzSubscription "StorageAccount-subscription-id"

$storageAccountId = (Get-AzStorageAccount -ResourceGroupName "resource-group-name" -Name "storage-account-name").id

Select-AzSubscription "workspace-subscription-id"

New-AzOperationalInsightsLinkedStorageAccount -ResourceGroupName "resource-group-name" -WorkspaceName "workspace-name" -DataSourceType Query -StorageAccountIds $storageAccountId

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Query?api-version=2020-08-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "dataSourceType": "Query", 
    "storageAccountIds": 
    [
      "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>"
    ]
  }
}

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

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

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

az account set --subscription "storage-account-subscription-id"

$storageAccountId = '/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage name>'

az account set --subscription "workspace-subscription-id"

az monitor log-analytics workspace linked-storage create --type ALerts --resource-group "resource-group-name" --workspace-name "workspace-name" --storage-accounts $storageAccountId

Select-AzSubscription "StorageAccount-subscription-id"

$storageAccountId = (Get-AzStorageAccount -ResourceGroupName "resource-group-name" -Name "storage-account-name").id

Select-AzSubscription "workspace-subscription-id"

New-AzOperationalInsightsLinkedStorageAccount -ResourceGroupName "resource-group-name" -WorkspaceName "workspace-name" -DataSourceType Alerts -StorageAccountIds $storageAccountId

PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Alerts?api-version=2020-08-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "dataSourceType": "Alerts", 
    "storageAccountIds": 
    [
      "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>"
    ]
  }
}

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

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

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

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

См. дополнительные сведения о защищенном хранилище для Microsoft Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • При нормальных операциях. Служба хранилища кэширует АЕК в течение короткого периода времени и возвращается к Key Vault для периодической распаковки.

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

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

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

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