Ключи 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 соответствует отзыву ключей.

Как работают управляемые клиентом ключи в 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.

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 .

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

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

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

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

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

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

• Мягкое удаление
• Защита от очистки предотвращает принудительное удаление секрета и хранилища даже после мягкого удаления

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

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

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

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

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

Предоставьте разрешения 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. Выберите управляемое удостоверение на вкладке "Участники" и выберите подписку для удостоверения и удостоверения в качестве участника.

   

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

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

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

   

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

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

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

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

Обновите сведения об идентификаторе ключа в кластере 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=2023-09-01
Authorization: Bearer <token> 
Content-type: application/json
 
{
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://key-vault-name.vault.azure.net",
      "keyName": "key-name",
      "keyVersion": ""
    }
  }
}

{
  "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"
}

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

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

Отключить рабочую область от кластера

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

Отзыв ключа

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

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

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

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

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

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

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>"
    ]
  }
}

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

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

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

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

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

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>"
    ]
  }
}

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

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

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

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

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

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