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

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

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

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

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

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

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

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

Внимание

Выделенные кластеры используют модель ценообразования уровня обязательств, начиная с 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, и предоставить этому удостоверению разрешения в Key Vault до создания кластера.

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

Внимание

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

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

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

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

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

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

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

Защита операционных ключей

Модель шифрования, используемая выделенными кластерами Log Analytics, соответствует принципам шифрования envelope. Управляемые клиентом ключи, хранящиеся в Azure Key Vault или управляемом HSM, защищают ключи шифрования уровня обслуживания (AEK), используемые кластером. Эти ключи уровня обслуживания не сохраняются в хранилище в самом кластере.

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

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

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

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

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

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

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

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

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

Создайте или назначьте KEK для Azure Key Vault (ключ для хранения)

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

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

Внимание

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

Чтобы добавить назначения ролей, необходимо иметь роль с разрешениями Microsoft.Authorization/roleAssignments/write и Microsoft.Authorization/roleAssignments/delete, такими как User Access Administrator или Owner.
1. Откройте Key Vault на портале Azure и выберите Settings>Access configuration>Azure управление доступом на основе ролей и Apply.
2. Выберите Перейти к управлению доступом (IAM) и добавьте назначение роли Пользователь шифрования службы криптографии Key Vault.
3. Выберите управляемая идентичность на вкладке "Участники" и выберите подписку и идентичность в качестве участника.
Назначьте политику доступа к хранилищу (устаревшая версия)

Откройте хранилище ключей (Key Vault) в портале Azure и выберите Политики доступа>Политика доступа к хранилищу>+ Добавить политику доступа, чтобы создать политику с указанными параметрами.
- Разрешения ключей — Выберите "Получить>" и "Распаковка ключа".
- Выберите субъект в зависимости от типа удостоверения, используемого в кластере (назначаемое системой или пользователем управляемое удостоверение)
  - Для управляемого удостоверения, назначаемого системой, введите имя кластера или идентификатор субъекта кластера.
  - Для управляемого идентификатора, назначаемого пользователем введите имя идентификатора.
Разрешение Get необходимо, чтобы убедиться, что ваш Key Vault настроен как восстанавливаемый для защиты вашего ключа и доступа к данным вашего Azure Monitor.

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

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

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

Внимание

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

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

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

Tip

При передаче пустой строки "" для --key-version кластер всегда использует последнюю версию ключа в Key Vault и после смены ключа не требуется обновлять кластер.

В следующем примере для Azure CLI используется команда az monitor log-analytics cluster update.

# Set variables
resourceGroupName="<ResourceGroupName>"
clusterName="<ClusterName>"
keyVaultName="<KeyVaultName>"
keyName="<KeyName>"

# Build the Key Vault URI
keyVaultUri="https://$keyVaultName.vault.azure.net"

# Update the cluster with a customer-managed key
az monitor log-analytics cluster update \
  --resource-group "$resourceGroupName" \
  --name "$clusterName" \
  --key-vault-uri "$keyVaultUri" \
  --key-name "$keyName" \
  --key-version ""

Примечание.

команды Azure CLI используют конечную точку Azure Resource Manager из текущего контекста CLI, поэтому management.azure.com не требуется указывать в синтаксисе команды.

Tip

При передаче пустой строки "" для -KeyVersion кластер всегда использует последнюю версию ключа в Key Vault и после смены ключа не требуется обновлять кластер.

В следующем примере Azure PowerShell показано использование командлета Update-AzOperationalInsightsCluster.

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$clusterName = "<ClusterName>"
$keyVaultName = "<KeyVaultName>"
$keyName = "<KeyName>"

# Build the Key Vault URI
$keyVaultUri = "https://$keyVaultName.vault.azure.net"

# Define parameters for Update-AzOperationalInsightsCluster
$updateAzOperationalInsightsClusterParams = @{
    ResourceGroupName = $resourceGroupName
    ClusterName       = $clusterName
    KeyVaultUri       = $keyVaultUri
    KeyName           = $keyName
    KeyVersion        = ''
}

# Update the cluster with a customer-managed key
Update-AzOperationalInsightsCluster @updateAzOperationalInsightsClusterParams

Примечание.

командлеты Azure PowerShell используют конечную точку Azure Resource Manager из текущего контекста Az, поэтому management.azure.com не требуется указывать в синтаксисе командлета.

В следующем примере REST используются кластеры — операция обновления REST API.

PATCH https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/clusters/{ClusterName}?api-version=2025-07-01
Authorization: Bearer {AccessToken}
Content-Type: application/json

{
  "properties": {
    "keyVaultProperties": {
      "keyVaultUri": "https://<KeyVaultName>.vault.azure.net",
      "keyName": "<KeyName>",
      "keyVersion": ""
    }
  }
}

Ответ.

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

Ответ на запрос GET при завершении обновления ключа: 202 (принято) и заголовок

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

Примечание.

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

В следующем примере Bicep используется тип ресурса Microsoft.OperationalInsights clusters.

param clusterName string = '<ClusterName>'
param azureRegion string = '<AzureRegion>'
param keyVaultName string = '<KeyVaultName>'
param keyName string = '<KeyName>'

var keyVaultUri = 'https://${keyVaultName}.vault.azure.net'

resource logAnalyticsCluster 'Microsoft.OperationalInsights/clusters@2025-07-01' = {
  name: clusterName
  location: azureRegion
  properties: {
    keyVaultProperties: {
      keyVaultUri: keyVaultUri
      keyName: keyName
      keyVersion: ''
    }
  }
}

Примечание.

Развертывания шаблонов ARM (JSON) являются операциями создания или обновления, а не частичными операциями PATCH. Включите все необходимые существующие свойства кластера, которые не нужно изменять.

В следующем примере ARM (JSON) используется тип ресурса Microsoft.OperationalInsights clusters.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "clusterName": {
      "type": "string",
      "defaultValue": "<ClusterName>"
    },
    "azureRegion": {
      "type": "string",
      "defaultValue": "<AzureRegion>"
    },
    "keyVaultName": {
      "type": "string",
      "defaultValue": "<KeyVaultName>"
    },
    "keyName": {
      "type": "string",
      "defaultValue": "<KeyName>"
    }
  },
  "variables": {
    "keyVaultUri": "[format('https://{0}.vault.azure.net', parameters('keyVaultName'))]"
  },
  "resources": [
    {
      "type": "Microsoft.OperationalInsights/clusters",
      "apiVersion": "2025-07-01",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('azureRegion')]",
      "properties": {
        "keyVaultProperties": {
          "keyVaultUri": "[variables('keyVaultUri')]",
          "keyName": "[parameters('keyName')]",
          "keyVersion": ""
        }
      }
    }
  ]
}

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

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

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

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

Внимание

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

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

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

Отзыв ключа

Внимание

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

Важно различать преднамеренный отзыв ключей и временные нарушения подключения к Key Vault.

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

Смена ключей

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

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

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

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

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

Примечание.

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

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

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

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

Примечание.

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

В следующем примере Azure CLI используется команда az monitor log-analytics workspace linked-storage create.

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
storageAccountName="<StorageAccountName>"

# Get the subscription ID from the current Azure CLI context
subscriptionId=$(az account show --query id --output tsv)

# Build the full resource ID for the storage account
storageAccountId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Storage/storageAccounts/$storageAccountName"

# Link the storage account to the workspace for custom log queries
az monitor log-analytics workspace linked-storage create \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --type Query \
  --storage-accounts "$storageAccountId"

Примечание.

В следующем примере Azure PowerShell используется командлет New-AzOperationalInsightsLinkedStorageAccount.

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$storageAccountName = "<StorageAccountName>"

# Get the subscription ID from the current Azure PowerShell context
$subscriptionId = (Get-AzContext).Subscription.Id

# Build the full resource ID for the storage account
$storageAccountId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Storage/storageAccounts/$storageAccountName"

# Define parameters for New-AzOperationalInsightsLinkedStorageAccount
$newAzOperationalInsightsLinkedStorageAccountParams = @{
    ResourceGroupName = $resourceGroupName
    WorkspaceName     = $workspaceName
    DataSourceType    = "Query"
    StorageAccountId  = $storageAccountId
}

# Link the storage account to the workspace for custom log queries
New-AzOperationalInsightsLinkedStorageAccount @newAzOperationalInsightsLinkedStorageAccountParams

Примечание.

В следующем примере REST используется операция создания или обновления REST API связанных учетных записей хранения .

PUT https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{WorkspaceName}/linkedStorageAccounts/Query?api-version=2025-07-01
Authorization: Bearer {AccessToken}
Content-Type: application/json

{
  "properties": {
    "storageAccountIds": [
      "/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Storage/storageAccounts/<StorageAccountName>"
    ]
  }
}

В следующем примере Bicep используется тип ресурса Microsoft.OperationalInsights workspaces/linkedStorageAccounts.

param subscriptionId string = '<SubscriptionId>'
param resourceGroupName string = '<ResourceGroupName>'
param workspaceName string = '<WorkspaceName>'
param storageAccountName string = '<StorageAccountName>'

var storageAccountId = '/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.Storage/storageAccounts/${storageAccountName}'

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2025-07-01' existing = {
  name: workspaceName
}

resource linkedStorageAccount 'Microsoft.OperationalInsights/workspaces/linkedStorageAccounts@2025-07-01' = {
  parent: logAnalyticsWorkspace
  name: 'Query'
  properties: {
    storageAccountIds: [
      storageAccountId
    ]
  }
}

В следующем примере ARM (JSON) используется тип ресурса Microsoft.OperationalInsights workspaces/linkedStorageAccounts.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "subscriptionId": {
      "type": "string",
      "defaultValue": "<SubscriptionId>"
    },
    "resourceGroupName": {
      "type": "string",
      "defaultValue": "<ResourceGroupName>"
    },
    "workspaceName": {
      "type": "string",
      "defaultValue": "<WorkspaceName>"
    },
    "storageAccountName": {
      "type": "string",
      "defaultValue": "<StorageAccountName>"
    }
  },
  "variables": {
    "storageAccountId": "[format('/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}', parameters('subscriptionId'), parameters('resourceGroupName'), parameters('storageAccountName'))]"
  },
  "resources": [
    {
      "type": "Microsoft.OperationalInsights/workspaces/linkedStorageAccounts",
      "apiVersion": "2025-07-01",
      "name": "[format('{0}/Query', parameters('workspaceName'))]",
      "properties": {
        "storageAccountIds": [
          "[variables('storageAccountId')]"
        ]
      }
    }
  ]
}

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

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

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

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

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

В следующем примере Azure CLI используется команда az monitor log-analytics workspace linked-storage create.

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
storageAccountName="<StorageAccountName>"

# Get the subscription ID from the current Azure CLI context
subscriptionId=$(az account show --query id --output tsv)

# Build the full resource ID for the storage account
storageAccountId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Storage/storageAccounts/$storageAccountName"

# Link the storage account to the workspace for alerts
az monitor log-analytics workspace linked-storage create \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --type Alerts \
  --storage-accounts "$storageAccountId"

Примечание.

В следующем примере Azure PowerShell используется командлет New-AzOperationalInsightsLinkedStorageAccount.

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$storageAccountName = "<StorageAccountName>"

# Get the subscription ID from the current Azure PowerShell context
$subscriptionId = (Get-AzContext).Subscription.Id

# Build the full resource ID for the storage account
$storageAccountId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Storage/storageAccounts/$storageAccountName"

# Define parameters for New-AzOperationalInsightsLinkedStorageAccount
$newAzOperationalInsightsLinkedStorageAccountParams = @{
    ResourceGroupName = $resourceGroupName
    WorkspaceName     = $workspaceName
    DataSourceType    = "Alerts"
    StorageAccountId  = $storageAccountId
}

# Link the storage account to the workspace for alerts
New-AzOperationalInsightsLinkedStorageAccount @newAzOperationalInsightsLinkedStorageAccountParams

Примечание.

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

PUT https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{WorkspaceName}/linkedStorageAccounts/Alerts?api-version=2025-07-01
Authorization: Bearer {AccessToken}
Content-Type: application/json

{
  "properties": {
    "storageAccountIds": [
      "/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Storage/storageAccounts/<StorageAccountName>"
    ]
  }
}

В следующем примере Bicep используется тип ресурса Microsoft.OperationalInsights workspaces/linkedStorageAccounts.

param subscriptionId string = '<SubscriptionId>'
param resourceGroupName string = '<ResourceGroupName>'
param workspaceName string = '<WorkspaceName>'
param storageAccountName string = '<StorageAccountName>'

var storageAccountId = '/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.Storage/storageAccounts/${storageAccountName}'

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2025-07-01' existing = {
  name: workspaceName
}

resource linkedStorageAccount 'Microsoft.OperationalInsights/workspaces/linkedStorageAccounts@2025-07-01' = {
  parent: logAnalyticsWorkspace
  name: 'Alerts'
  properties: {
    storageAccountIds: [
      storageAccountId
    ]
  }
}

В следующем примере ARM (JSON) используется тип ресурса Microsoft.OperationalInsights workspaces/linkedStorageAccounts.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "subscriptionId": {
      "type": "string",
      "defaultValue": "<SubscriptionId>"
    },
    "resourceGroupName": {
      "type": "string",
      "defaultValue": "<ResourceGroupName>"
    },
    "workspaceName": {
      "type": "string",
      "defaultValue": "<WorkspaceName>"
    },
    "storageAccountName": {
      "type": "string",
      "defaultValue": "<StorageAccountName>"
    }
  },
  "variables": {
    "storageAccountId": "[format('/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}', parameters('subscriptionId'), parameters('resourceGroupName'), parameters('storageAccountName'))]"
  },
  "resources": [
    {
      "type": "Microsoft.OperationalInsights/workspaces/linkedStorageAccounts",
      "apiVersion": "2025-07-01",
      "name": "[format('{0}/Alerts', parameters('workspaceName'))]",
      "properties": {
        "storageAccountIds": [
          "[variables('storageAccountId')]"
        ]
      }
    }
  ]
}

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

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

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

Дополнительные сведения см. в разделе Customer Lockbox для Microsoft Azure.

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

Поведение при доступности Key Vault. Дополнительные сведения о том, как кластер обрабатывает временные сбои Key Vault по сравнению с преднамеренной отменой ключа, см. в статье Отзыв ключа. Кластер кэширует AEK на короткое время и обращается к Key Vault периодически 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 2026-06-11

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

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

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

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

Защита операционных ключей

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

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

Создайте или назначьте KEK для Azure Key Vault (ключ для хранения)

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

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

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

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

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

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

Отзыв ключа

Смена ключей

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

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

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

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

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

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

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

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

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

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

Обратная связь

Дополнительные ресурсы