Azure Monitor のカスタマー マネージド キー

Azure Monitor のデータは、Microsoft マネージド キーを使用して暗号化されます。 独自の暗号化キーを使用して、ワークスペースのデータを保護できます。 Azure Monitor のカスタマー マネージド キーでは、暗号化キーのライフサイクルを制御し、ログにアクセスできます。 構成後、リンクされたワークスペースに取り込まれた新しいデータは、 Azure Key Vault または Azure Key Vault Managed HSM (ハードウェア セキュリティ モジュール) のキーで暗号化されます。

カスタマー マネージド キーの概要

保存時のデータ暗号化は、組織の一般的なプライバシーおよびセキュリティ要件です。 保存時の暗号化は Azure で完全に管理できます。または、暗号化および暗号化キーを厳密に管理するさまざまなオプションを使用できます。

Azure Monitor により、Microsoft マネージド キー (MMK) を使用して、すべてのデータおよび保存されたクエリが保存時に暗号化されるようになります。 Azure Monitor での暗号化の使用は、Azure Storage の暗号化での運用方法とまったく同じです。

アクセス データを取り消す機能を使用してキーのライフサイクルを制御するには、 Azure Key Vault または Azure Key Vault Managed HSM で独自のキーを使用してデータを暗号化します。 カスタマー マネージド キー機能は 、専用クラスター で使用でき、高度な保護と制御を提供します。

専用クラスターに取り込まれたデータは、2 回暗号化されます。Microsoft マネージド キーまたはカスタマー マネージド キーを使用してサービス レベルで一度暗号化され、2 つの異なる暗号化アルゴリズムと 2 つの異なるキーを使用してインフラストラクチャ レベルで一度暗号化されます。 二重暗号化では、暗号化アルゴリズムまたはキーのいずれかが侵害されるシナリオから保護されます。 専用クラスターを使用し、ロックボックスでデータを保護することもできます。

過去 14 日間に取り込まれたデータと、クエリで最近使用されたデータは、クエリ効率を高めるホットキャッシュ (SSD バックアップ) に保持されます。 SSD データは、カスタマー マネージド キーを構成しているかどうか関係なく、Microsoft マネージド キーで暗号化されますが、SSD アクセスに対する制御はキーの失効に従います。

Azure Monitor でのカスタマー マネージド キーのしくみ

Azure Monitor は、マネージド ID を使用して Azure Key Vault のキーにアクセス権を付与します。 Log Analytics クラスターの ID はクラスター レベルでサポートされます。 複数のワークスペースでカスタマー マネージド キーを使用できるように、Log Analytics クラスター リソースは、キー コンテナーと Log Analytics ワークスペース間の中間 ID 接続として機能します。 クラスターのストレージは、クラスターに関連付けられているマネージド ID を使用して、Microsoft Entra ID 経由で Azure キー コンテナーに対する認証を行います。

クラスターでは、システム割り当てとユーザー割り当ての 2 つのマネージド ID の種類がサポートされていますが、シナリオに応じて単一の ID をクラスターで定義できます。

• identitytypeが SystemAssigned に設定されている場合、システム割り当てマネージド ID の方がシンプルになり、クラスターで自動的に生成されます。 この ID は、後でデータの暗号化と復号化のために Key Vault に対するストレージ アクセス権を付与するために使用されます。
• ユーザー割り当てマネージド ID を使用すると、クラスターの作成時、identitytype を UserAssigned に設定するときに、カスタマー マネージド キーを構成できます。また、クラスターの作成前にお使いのキー コンテナーでそれにアクセス許可を付与できます。

新しいクラスター、またはデータを取り込むリンクされたワークスペースを使用して既存の専用クラスターでカスタマー マネージド キーを構成します。 クラスターからのワークスペースのリンク解除は、いつでも行うことができます。 リンクされたワークスペースに取り込まれた新しいデータはユーザーのキーで暗号化され、古いデータは Microsoft マネージド キーで暗号化されたままになります。 この構成では、インジェストやクエリが中断されることはなく、クエリは新旧のデータ間でシームレスに実行されます。 クラスターからワークスペースのリンクを解除すると、取り込まれた新しいデータが Microsoft マネージド キーで暗号化されます。

1. 鍵保管庫
2. Key Vault へのアクセス許可を持つマネージド ID を持つ Log Analytics クラスター リソース - ID は、基になる専用クラスター ストレージに伝達されます
3. 専用クラスター
4. 専用クラスターにリンクされているワークスペース

暗号化キーの種類

ストレージ データの暗号化には、次の 3 種類のキーが関係します。

• KEK - キー暗号化キー (ユーザーのカスタマー マネージド キー)
• AEK - アカウント暗号化キー
• DEK - データ暗号化キー

次の規則が適用されます。

• クラスター ストレージには、 AEK と呼ばれるすべてのストレージ アカウントに対して一意の暗号化キーがあります。
• AEK は、ディスクに書き込まれる各データ ブロックの暗号化に使用されるキーである DEKを派生させるために使用されます。
• クラスターでカスタマー マネージド KEK を構成すると、クラスター ストレージは、wrap の暗号化と暗号化解除のために Key Vault に対してunwrap要求と要求を実行します。
• KEK が Key Vault から離れることはありません。 Azure Key Vault Managed HSM にキーを格納すると、そのキーはそのハードウェアを離れることは決してありません。
• Azure Storage は、認証用クラスターに関連付けられているマネージド ID を使用します。 これは Microsoft Entra ID 経由で Azure Key Vault にアクセスします。

顧客管理キーの設定手順

1. Azure Key Vault の作成とキーの格納
2. 専用クラスターの作成
3. Key Vault へのアクセス許可の付与
4. キー識別子の詳細を使用した専用クラスターの更新
5. ワークスペースのリンク

カスタマー マネージド キーの構成では、ID とキー識別子の詳細の設定はサポートされていません。 PowerShell、CLI、または REST 要求を使用して、これらの操作を実行します。

必要なアクセス許可

クラスター関連のアクションを実行するには、次のアクセス許可が必要です。

暗号化キー ("KEK") の格納

Azure Key Management 製品のポートフォリオには、使用できるコンテナーとマネージド HSM がリスト表示されています。

クラスターが計画されているリージョンで、Azure キー コンテナーを作成するか、既存のものを使います。 キー コンテナーで、ログの暗号化に使うキーを生成するかインポートします。 キーと Azure Monitor のデータへのアクセスを保護するには、Azure Key Vault を回復可能として構成する必要があります。 この構成は Key Vault のプロパティで確認できます。 [論理的な削除] と [Purge protection](消去保護) の両方を有効にしてください。

これらの設定は、CLI と PowerShell を使用して Key Vault で更新できます。

• 論理的な削除
• 消去保護は、論理的な削除の後もシークレットやコンテナーを強制的な削除から保護します

クラスターの作成

クラスターでは、Azure Key Vault でのデータ暗号化にマネージド ID が使用されます。 データの暗号化と復号化の操作のためにお使いのキー コンテナーにアクセスできるようにするには、identity時に typeSystemAssigned プロパティを UserAssigned または に構成します。

たとえば、システム割り当てマネージド ID の要求本文にこれらのプロパティを追加します。

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

専用クラスターに関する記事で示されている手順に従います。

Key Vault アクセス許可を付与する

Key Vault には、クラスターと基になるストレージへのアクセス権を付与するために、Azure ロールベースのアクセス制御 (Azure RBAC) と Vault アクセス ポリシーの 2 つのアクセス許可モデルがあります。

1. あなたが制御している Azure RBAC を割り当てる (推奨)

   ロールの割り当てを追加するには、Microsoft.Authorization/roleAssignments/writeやMicrosoft.Authorization/roleAssignments/deleteなど、 と のアクセス許可を持つロールが必要です。

   1. Azure portal で Key Vault を開き、 設定>Access 構成>Azure ロールベースのアクセス制御 と 適用を選択します。
   2. [アクセス制御 (IAM) に移動する] を選んで、キー コンテナー暗号化サービス暗号化ユーザー ロールの割り当てを追加します。
   3. [メンバー] タブで [ マネージド ID ] を選択し、ID のサブスクリプションとメンバーとしての ID を選択します。

   

2. コンテナー アクセス ポリシーを割り当てる (レガシ)

   Azure portal でキー コンテナーを開き、[アクセス ポリシー]>[コンテナーのアクセス ポリシー]>[+ アクセス ポリシーの追加] を選択し、次の設定でポリシーを作成します。

   • [キーのアクセス許可]: [取得]>[キーを折り返す] と [キーの折り返しを解除] を選びます。
   • クラスターで使用される ID の種類に応じてプリンシパルを選択します (システムまたはユーザー割り当てマネージド ID)
     • システム割り当てマネージド ID - クラスター名またはクラスター プリンシパル ID を入力します
     • ユーザー割り当てのマネージド ID - ID 名を入力してください

   

   [取得] アクセス許可は、キーを保護し、Azure Monitor データへのアクセスを保護するために、Key Vault が回復可能として構成されていることを確認するために必要です。

キー識別子の詳細を使用してクラスターを更新する

クラスター上のすべての操作には、Microsoft.OperationalInsights/clusters/write アクションのアクセス許可が必要です。 アクセス許可は、*/write アクションを含む所有者または共同作成者によって、または Microsoft.OperationalInsights/* アクションを含む Log Analytics 共同作成者ロールによって付与されます。

この手順では、AEK、wrap、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": ""
  },
  "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"
}

ワークスペースをクラスターにリンクする

専用クラスターに関する記事で示されている手順に従います。

クラスターからワークスペースのリンクを解除する

専用クラスターに関する記事で示されている手順に従います。

キーの失効

クラスターのストレージでは、キーのアクセス許可の変更が1時間以内、またはそれより早く常に反映され、ストレージは一時的に利用できなくなります。 リンクされたワークスペースに取り込まれた新しいデータは削除され、回復できません。 これらのワークスペースではデータにアクセスできないので、クエリは失敗します。 クラスターおよびワークスペースが削除されていない限り、以前に取り込まれたデータはストレージに残ります。 データ保持ポリシーは、アクセスできないデータを管理し、保持期間に達すると消去します。 過去 14 日間に取り込まれたデータと、クエリで最近使用されたデータも、クエリ効率を高めるホットキャッシュ (SSD ベース) に保持されます。 SSD 上のデータは、キー失効操作で削除され、アクセスできなくなります。 クラスター ストレージは、 wrap と unwrap の操作のために Key Vault に定期的に到達しようとします。 キーが有効になり、 unwrap が成功すると、SSD データがストレージから再読み込みされます。 データ インジェストとクエリ機能は、30 分以内に再開されます。

キーのローテーション

キーの交換には、次の 2 つのモードがあります。

• 自動交換 - クラスター内の "keyVaultProperties" プロパティを更新して、"keyVersion" プロパティを省略するか、"" に設定します。 ストレージには、最新のキー バージョンが自動的に使われます。
• 明示的なキー バージョンの更新 - "keyVaultProperties" プロパティを更新し、"keyVersion" プロパティのキー バージョンを更新します。 キーの交換には、クラスター内の "keyVersion" プロパティの明示的な更新が必要です。 詳細については、「キー識別子の詳細を使用してクラスターを更新する」を参照してください。 Key Vault で新しいキー バージョンを生成しても、そのキーをクラスターで更新していない場合、クラスター ストレージでは以前のキーが引き続き使われます。 クラスターの新しいキーを更新する前に古いキーを無効にしたり削除したりすると、キー失効状態になります。

キーの交換操作の最中とその後も、すべてのデータに引き続きアクセスできます。 データは常にアカウント暗号化キー (AEK) で暗号化されます。これは、Key Vault の新しいキー暗号化キー (KEK) バージョンで暗号化されます。

保存されたクエリおよびログ検索アラート用のカスタマー マネージド キー

Log Analytics で使用されるクエリ言語は表現力が豊かで、コメントまたはクエリ構文に機密情報を含めることができます。 組織によっては、このような情報をカスタマー マネージド キー ポリシーによって保護する必要があり、キーで暗号化された状態でクエリを保存する必要があります。 Azure Monitor を使用すると、ワークスペースとリンクした場合に、保存されたクエリとログ検索アラートをキーで暗号化して、独自のストレージ アカウント内に保存することができます。

ワークブック用のカスタマー マネージド キー

「保存されたクエリおよびログ検索アラート用のカスタマー マネージド キー」で言及した考慮事項を踏まえて、Azure Monitor を使用すると、ブックの '保存' 操作で [内容を Azure Storage アカウントに保存する] を選択した場合に、ブック クエリをキーで暗号化して、独自のストレージ アカウントに保存することができます。

保存されたクエリのストレージ アカウントをリンクすると、サービスは保存されたクエリとログ検索アラート クエリをストレージ アカウント内に保存します。 ストレージ アカウントの保存時の暗号化ポリシーを制御すると、カスタマー マネージド キーを使用して、保存されたクエリとログ検索アラートを保護することができます。 ただし、そのストレージ アカウントに関連するコストについてはお客様の負担になります。

クエリにカスタマー マネージド キーを設定する前の考慮事項

• ワークスペースとストレージ アカウントに対する "書き込み" 権限が必要です。
• ストレージ アカウントは、Log Analytics ワークスペースと同じリージョン内の StorageV2 である必要があります。 クエリのストレージ アカウントをリンクすると、プライバシーのために既存の保存クエリと Functions がワークスペースから削除されます。 構成の前に、既存の保存済みクエリと関数をコピーします。 PowerShell を使用して、保存済みクエリを表示できます。
• クエリ パックに保存されたクエリは、リンクされたストレージ アカウントに格納されず、カスタマー マネージド キーを使用して暗号化することはできません。 カスタマー マネージド キーを使用してクエリを保護するには 、レガシ クエリとして保存 することをお勧めします。
• ストレージにクエリと関数を保存すると、サービス成果物と見なされ、その形式が変更される可能性があります。
• クエリ用のストレージ アカウントをリンクすると、クエリ 'history' と 'pin to dashboard' はサポートされません。
• 保存されたクエリとログ検索アラート クエリに対して、単一または個別のストレージ アカウントをリンクできます。
• ログ検索アラートは 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>"
    ]
  }
}

構成が完了すると、新しいアラート クエリがストレージに保存されます。

カスタマー ロックボックス

お客様は、ロックボックスを使用して、サポート リクエストへの対応時の Microsoft のエンジニアによる顧客データへのアクセス要求を承認または拒否できます。

ロックボックスは Azure Monitor の専用クラスターに用意されており、データにアクセスするアクセス許可はサブスクリプション レベルで付与されます。

詳細については、「Microsoft Azure 用カスタマー ロックボックス」を参照してください。

カスタマー マネージド キーの操作

カスタマー マネージド キーは専用クラスター上で指定されます。これらの操作については専用クラスターに関する記事を参照してください。

• リソース グループ内のすべてのクラスターを取得する
• サブスクリプション内のすべてのクラスターを取得する
• クラスターの "容量予約" を更新する
• クラスターの billingType を更新する
• クラスターからワークスペースのリンクを解除する
• クラスターを削除する

制限と制約

• 各リージョンとサブスクリプションには、最大 5 つのアクティブ クラスターを作成できます。

• 各リージョンとサブスクリプションには、最大 7 つの予約済みクラスター (アクティブまたは最近削除されたもの) が存在できます。

• 1 つのクラスターには、最大 1,000 の Log Analytics ワークスペースをリンクできます。

• 特定のワークスペースでは、30 日間に最大 2 つのワークスペース リンク操作が許可されます。

• 別のリソース グループまたはサブスクリプションへのクラスターの移動は、現時点ではサポートされていません。

• クラスターの更新では、同じ操作に ID とキー識別子の詳細の両方を含めることはしないようにする必要があります。 両方の更新が必要な場合、更新は 2 つの連続する操作で行ってください。

• ロックボックスは、現在、中国では使用できません。

• 補助 テーブル プランを持つテーブルには、ロックボックスは適用されません。

• 二重暗号化は、サポートされているリージョンで 2020 年 10 月以降に作成されたクラスターに対して自動的に構成されます。 クラスターで GET 要求を送信し、二重暗号化が有効になっているクラスターに対して isDoubleEncryptionEnabled 値が true されていることを確認することで、クラスターが二重暗号化用に構成されているかどうかを確認できます。

  • クラスターを作成し、"region-name doesn't support Double Encryption for clusters"(リージョン名はクラスターの Double Encryption をサポートしていません)" というエラーが発生した場合でも、REST 要求本文に "properties": {"isDoubleEncryptionEnabled": false} を追加することで、二重暗号化なしでクラスターを作成できます。
  • クラスターの作成後に、二重暗号化の設定を変更することはできません。

• リンクされたワークスペースは、クラスターにリンクされている間は削除できます。 論理的な削除期間中にワークスペースを回復することにした場合、以前の状態に戻り、クラスターへのリンクは維持されます。

• カスタマー マネージド キーの暗号化は、構成後に新しく取り込まれたデータに適用されます。 構成より前に取り込まれたデータは、Microsoft キーで暗号化されたままになります。 カスタマー マネージド キーの構成の前後に取り込まれたデータのクエリは、シームレスに実行できます。

• Azure Key Vault は、回復可能として構成する必要があります。 これらのプロパティは既定では有効になっておらず、CLI または PowerShell を使用して構成する必要があります。
  

  • 論理的な削除。
  • 論理的な削除の後でもシークレットとコンテナーの強制的な削除を防ぐには、消去保護を有効にする必要があります。

• Azure Key Vault、クラスター、ワークスペースは、同じリージョンかつ同じ Microsoft Entra テナント内に存在している必要がありますが、サブスクリプションは異なっていても構いません。

• クラスターの identitytype を None に設定すると、データへのアクセスも失効しますが、サポートに連絡しない限り取り消すことができないため、この方法はお勧めできません。 データへのアクセスを失効させる方法としては、キーの失効をお勧めします。

• Key Vault が Private-Link (仮想ネットワーク) 内にある場合、ユーザー割り当てマネージド ID でカスタマー マネージド キーを使用することはできません。 このシナリオでは、システム割り当てマネージド ID を使用します。

トラブルシューティング

• Key Vault の可用性ごとの動作:

  • 通常の操作では、ストレージは一時的に AEK をキャッシュし、定期的に Key Vault に戻って unwrap を行います。

  • Key Vault の接続エラー — ストレージは、タイムアウト、接続エラー、DNS の問題などの一時的なエラーを処理し、可用性の問題が発生している間にキーをキャッシュに保持することで、短時間の中断や可用性の問題を克服します。 クエリ機能と取り込み機能は中断されることなく続行されます。

• Key Vault のアクセス率 - wrap および unwrap 操作のためにクラスター ストレージが Key Vault にアクセスする頻度は、6 ~ 60 秒です。

• クラスターをプロビジョニング状態または更新状態の間に更新すると、更新は失敗します。

• クラスターの作成時に競合エラーが発生した場合、同じ名前のクラスターが過去 14 日間に削除され、その名前が予約されている可能性があります。 削除されたクラスター名は、削除後 14 日後に使用できるようになります。

• ワークスペースが別のクラスターにリンクされている場合、クラスターへのワークスペースのリンクは失敗します。

• クラスターを作成して KeyVaultProperties をすぐに指定すると、ID がクラスターに割り当てられ、Key Vault に付与されるまで操作が失敗する可能性があります。

• 既存のクラスターを KeyVaultProperties で更新し、キー アクセス ポリシー Get Key Vault に存在しない場合、操作は失敗します。

• クラスターのデプロイに失敗した場合は、Azure Key Vault、クラスター、およびリンクされているワークスペースが同じリージョンにあることを確認してください。 異なるサブスクリプションが存在する可能性があります。

• Key Vault でキーをローテーションし、クラスター内の新しいキー識別子の詳細を更新しない場合、クラスターは以前のキーを使用し続け、データにアクセスできなくなります。 クラスター内の新しいキー識別子の詳細を更新して、データ インジェストとクエリ機能を再開します。 キーバージョンを '' 表記で更新して、ストレージで常に最新のキー バージョンが自動的に使用されるようにします。

• クラスターの作成、クラスター キーの更新、クラスターの削除など、一部の操作は実行時間が長く、完了するまでに時間がかかる場合があります。 クラスターまたはワークスペースに GET 要求を送信して操作の状態を確認し、応答を確認できます。 たとえば、リンクされていないワークスペースには、clusterResourceIdの下にfeaturesがありません。

• エラー メッセージ

  クラスターの更新

  • 400 - クラスターは削除中の状態です。 非同期操作が進行中です。 更新操作を実行する前に、クラスターでの操作が完了している必要があります。
  • 400 - KeyVaultProperties は空ではありませんが、形式が正しくありません。 キー識別子の更新に関するセクションを参照してください。
  • 400 - Key Vault 内のキーの検証に失敗しました。 必要なアクセス許可がないことが原因である可能性があります。または、キーが存在しません。 Key Vault でキーとアクセス ポリシーを設定したことを確認してください。
  • 400 - Key を回復できません。 Key Vault に論理的な削除と消去保護を設定する必要があります。 Key Vault のドキュメントを参照してください
  • 400 - 現在、操作を実行できません。 非同期操作が完了するまで待ってから、もう一度お試しください。
  • 400 - クラスターは削除中の状態です。 非同期操作が完了するまで待ってから、もう一度お試しください。

  クラスターの取得

  • 404 - クラスターが見つかりません。クラスターが削除されている可能性があります。 クラスターをその名前で作成しようとして、競合が発生した場合、そのクラスターは削除プロセスにあります。

次のステップ

• Log Analytics 専用クラスターの課金について理解します
• Log Analytics ワークスペースの適切な設計について学習します