次の方法で共有

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 VaultManaged HSM で独自のキーを使用してデータを暗号化します。 カスタマー マネージド キー機能は 、専用クラスター で使用でき、より高いレベルの保護と制御を提供します。

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

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

重要

専用クラスターには、1 日あたり 100 GB 以上のコミットメント レベル価格モデルが使用されます。

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

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

クラスターは、システム割り当て ID とユーザー割り当て ID の 2 種類をサポートしますが、シナリオに応じて 1 つの ID をクラスターで定義できます。

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

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

重要

カスタマー マネージド キー機能はリージョン単位で機能します。 Azure Key Vault、専用クラスター、リンクされたワークスペースは、同じリージョンに存在している必要がありますが、サブスクリプションは異なっていてもかまいません。

カスタマー マネージド キーの概要のスクリーンショット。

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

暗号化キーの種類

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

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

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

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

必要なアクセス許可

専用クラスターのカスタマー マネージド キーをプロビジョニングおよび管理するために必要なクラスター関連のアクションを実行するには、次のアクセス許可が必要です。

アクション 必要な権限またはロール
専用クラスターを作成する Microsoft.Resources/deployments/* と Microsoft.OperationalInsights/clusters/write アクセス許可
たとえば、Log Analytics コントリビュータ組み込みロールによって提供される
クラスターのプロパティを変更する Microsoft.OperationalInsights/clusters/write アクセス許可。たとえば、Log Analytics 共同作成者組み込みロールによって提供されます
ワークスペースをクラスターにリンクする Microsoft.OperationalInsights/clusters/write、Microsoft.OperationalInsights/workspaces/write、Microsoft.OperationalInsights/workspaces/linkedservices/write のアクセス許可。これは、たとえば、Log Analytics 共同作成者の組み込みロールによって付与されます。
ワークスペースのリンク状態を確認する ワークスペースに対する Microsoft.OperationalInsights/workspaces/read アクセス許可。たとえば、Log Analytics 閲覧者組み込みロールによって提供されます
クラスターを取得する、またはクラスターのプロビジョニング状態を確認する Microsoft.OperationalInsights/clusters/read 権限は、たとえば、Log Analytics 閲覧者組み込みロールによって付与されるものです。
クラスター内のコミットメント レベルまたは billingType を更新する Microsoft.OperationalInsights/clusters/write アクセス許可。たとえば、Log Analytics 共同作成者組み込みロールによって提供されます
必要なアクセス許可を付与する */write アクセス許可を持つ所有者または共同作成者ロール、または アクセス許可を持つ Microsoft.OperationalInsights/*
クラスターからワークスペースのリンクを解除する Microsoft.OperationalInsights/workspaces/linkedServices/delete アクセス許可。たとえば、Log Analytics 共同作成者組み込みロールによって提供されます
専用クラスターを削除する Microsoft.OperationalInsights/clusters/delete アクセス許可。たとえば、Log Analytics 共同作成者組み込みロールによって提供されます

顧客管理キーの設定手順

専用クラスターでカスタマー マネージド キーを構成するには、次の手順に従います。

  1. Azure Key Vault KEK の作成または割り当て (キーの格納)
  2. 専用クラスターのマネージド ID の種類を Key Vault アクセスに一致させる
  3. マネージド ID に Key Vault のアクセス許可を付与する
  4. キー識別子の詳細を使用して専用クラスターを更新する
  5. 専用クラスター のプロビジョニングを確認する
  6. ワークスペースを専用クラスターにリンクする

Azure Key Vault KEK の作成または割り当て (キーの格納)

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

専用クラスターが存在するリージョン、または専用クラスターが存在する予定のリージョンで、既存の Azure Key Vault を作成または使用します。 ログの暗号化に使用するキーを Azure Key Vault に生成またはインポートします。 Azure Monitor でキーとデータへのアクセスを保護するには、Azure Key Vault を回復可能として構成する必要があります。 この構成は、Key Vault のプロパティで確認できます。 ソフト削除と消去防止の両方を有効にします。

重要

有効期限が近づいているキーなどの Azure Key Vault イベントに効果的に応答するには、 Azure Event Grid 経由で通知を設定します。 キーの有効期限が切れると、インジェストとクエリは影響を受けませんが、クラスター内のキーを更新することはできません。 解決するには、次の手順を実行します。

  1. Azure portal の [ JSON ビュー] で、クラスターの概要ページで使用されているキーを特定します。
  2. Azure Key Vault でキーの有効期限を延長します。
  3. 常に最新バージョンを自動的に使用するように、クラスターをアクティブなキー (できればバージョン値) で''。

ソフト削除と削除保護の設定のスクリーンショット。

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

専用クラスターのマネージド ID の種類を Key Vault アクセスに一致させる

専用クラスターでは、マネージド ID を使用して Key Vault KEK にアクセスし、データを暗号化します。 専用クラスターのマネージド ID の種類は、データの暗号化と暗号化解除の操作を可能にするために、Key Vault ロールの割り当て ID と一致する必要があります。

クラスターの作成時にidentityまたはtypeするように SystemAssignedUserAssigned プロパティを構成します。

たとえば、システム割り当てマネージド ID を持つクラスターを作成するための要求本文に追加する値を次に示します。

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

注

インジェストやクエリを中断することなく、クラスターの作成後に ID の種類を変更できます。次の点に注意してください。

  • クラスターの ID とキーを同時に更新することはできません。 2 つの連続する操作で更新します。
  • SystemAssignedをUserAssignedに更新する場合は、Key Vault UserAssign ID を付与してから、専用クラスター内のidentityを更新します。
  • UserAssignedをSystemAssignedに更新する場合は、Key Vault SystemAssigned ID を付与してから、専用クラスター内のidentityを更新します。

専用クラスターの作成の詳細については、「専用クラスターの 作成と管理」を参照してください。

マネージド ID に Key Vault のアクセス許可を付与する

Key Vault には、専用クラスターと基になるストレージへのアクセスを許可する 2 つのアクセス許可モデルがあります。Azure ロールベースのアクセス制御 (Azure RBAC - 推奨) と Vault アクセス ポリシー (レガシ) です。

  1. Azure RBAC の割り当て (推奨)

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

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

    Key Vault RBAC アクセス許可の付与のスクリーンショット。

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

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

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

    Key Vault アクセス ポリシーの権限を付与する手順のスクリーンショット。

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

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

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

この手順では、AEK、wrap、unwrapに使用するキーとバージョンを使用して、専用クラスター ストレージを更新します。

重要

  • キーのローテーションは、自動または明示的なキー バージョンごとに行うことができます。 専用クラスターのキー識別子の詳細を更新する前に、適切なアプローチを決定するには、キーの ローテーション に関するページを参照してください。
  • 専用クラスターの更新では、ID とキー識別子の両方の詳細を同じ操作に含めてはなりません。 両方を更新する必要がある場合、更新は 2 つの連続する操作である必要があります。
  • CMK の有効化または変更のみを行う場合は、CLI ではなく REST API を使用してください。 専用クラスター更新 CLI は、そのプロパティがコマンドで使用されていない場合でも、容量に更新を送信します。 この更新により、30 日間の変更しきい値または 500 GB のコミットメント レベルの最小チェックがトリガーされます。

Key Vault アクセス許可の付与のスクリーンショット。

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

操作は非同期であり、完了するまでに時間がかかることがあります。

該当なし

専用クラスター のプロビジョニングを確認する

ワークスペースをクラスターにリンクする前に、クラスターのプロビジョニング状態が Succeeded されていることを確認します。 プロビジョニング前にワークスペースをリンクしてデータを取り込んだ場合、取り込まれたデータは削除され、復旧できません。

「キー識別子の詳細を使用して 専用クラスターを更新 する」セクションで詳しく説明されているように、CLI、PowerShell、または REST API を使用してプロビジョニング状態を確認します。

重要

この手順は、クラスターのプロビジョニング後にのみ実行します。 プロビジョニング前にワークスペースをリンクしてデータを取り込んだ場合、取り込まれたデータは削除され、復旧できません。

ワークスペースをリンクするには、「 専用クラスターの作成と管理」の手順に従います。

キーの失効

重要

  • データへのアクセスを取り消すには、キーを無効にするか、Key Vault のアクセス ポリシーを削除します。
  • クラスターの identitytype を None に設定すると、データへのアクセスも取り消されますが、サポートに連絡しないと元に戻すことができないため、この方法は使用しないでください。

クラスターのストレージは、キーのアクセス許可の変更を常に考慮し、キーが無効になっているか、アクセス ポリシーが削除された場合、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 ストレージ アカウントにコンテンツを保存するを選択するときに、自分のキーで暗号化されたブック クエリを独自のストレージ アカウントに格納できます。

ブックの保存のスクリーンショット。

注

クエリは、カスタマー マネージド キーの構成に関係なく、Microsoft キー (MMK) を使用して暗号化されたままになります。Azure ダッシュボード、Azure Logic App、Azure Notebooks、Automation Runbook。

ストレージ アカウントを保存されたクエリにリンクすると、サービスによって保存されたクエリとログ検索アラート クエリがストレージ アカウントに格納されます。 ストレージ アカウントの 保存時の暗号化ポリシーを制御することで、保存されたクエリとログ検索アラートをカスタマー マネージド キーで保護できます。 そのストレージ アカウントに関連付けられているコストは、お客様が担当します。

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

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

保存されたクエリ用にリンクされたストレージ アカウントを構成する

保存されたクエリと関数のストレージ アカウントをリンクして、保存されたクエリをストレージ アカウントに保持します。

注

この操作により、保存されたクエリと関数がワークスペースからストレージ アカウント内のテーブルに削除されます。 保存されたクエリのストレージ アカウントのリンクを解除して、保存されたクエリと関数をワークスペースに戻すことができます。 操作後に保存されたクエリまたは関数が Azure portal に表示されない場合は、ブラウザーを更新します。

該当なし

構成後、保存された新しい 検索 クエリがストレージに保存されます。

ログ検索アラート クエリ用にリンクされたストレージ アカウントを構成する

保存されたログ アラート クエリにカスタマー マネージド キーを設定する前の考慮事項

  • アラート クエリは、ストレージ アカウントに BLOB として保存されます。
  • トリガーされたログ検索アラートには、検索結果やアラート クエリは含まれません。 アラート ディメンションを使用して、発生したアラートのコンテキストを取得します。
  • キーで暗号化されたクエリと関数を保持するには、カスタマー マネージド キーを使用してリンクされたストレージ アカウントを構成します。 この操作は、ストレージ アカウントの作成以降に実行できます。

"アラート" 用のストレージ アカウントをリンクして、ストレージ アカウント内に "ログ検索アラート" クエリを保持します。

該当なし

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

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

Lockbox を使用すると、カスタマー サポート契約中にデータにアクセスするための Microsoft エンジニア要求を承認または拒否できます。

Log Analytics 専用クラスターでは、サブスクリプション レベルでデータにアクセスするためのアクセス許可を付与する Lockbox がサポートされています。

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

考慮事項と制限

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

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

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

  • 30 日間で、特定のワークスペースに対して最大 2 つのワークスペース リンク操作を実行できます。

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

  • クラスターの更新では、ID とキー識別子の両方の詳細を同じ操作に含めることはできません。 両方を更新するには、2 つの連続する操作を使用します。

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

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

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

  • クラスターを作成し、"リージョン名はクラスターの 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 に戻ります。

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

関連コンテンツ

  • Last updated on