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

Azure Monitor のデータは、Microsoft マネージド キーを使用して暗号化されます。 独自の暗号化キーを使用して、ワークスペース内のデータと保存済みクエリを保護できます。 Azure Monitor のカスタマー マネージド キーを使用すると、ログへのアクセス制御をより柔軟に管理できます。 構成が完了すると、リンクされたワークスペースに取り込まれた新しいデータは、Azure Key Vault または Azure Key Vault マネージド "HSM" に格納されているキーで暗号化されます。

構成前に制限事項と制約を確認してください。

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

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

Azure Monitor により、Microsoft マネージド キー (MMK) を使用して、すべてのデータおよび保存されたクエリが保存時に暗号化されるようになります。 Azure Key Vault で独自のキーを使ってデータを暗号化して、キーのライフサイクルを制御し、データへのアクセスを取り消すことができます。 Azure Monitor での暗号化の使用は、Azure Storage の暗号化での運用方法とまったく同じです。

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

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

Log Analytics 専用クラスター の価格モデルには、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 キー コンテナーに対する認証を行います。

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

  • システム割り当てマネージド ID の方がシンプルで、ID の type が "SystemAssigned" に設定されている場合、クラスターの作成時に自動的に作成されます。 後でこの ID を使用して、ラップおよびラップ解除操作に必要な Key Vault へのストレージ アクセス権を付与できます。
  • クラスターの作成前にキー コンテナーでアクセス許可を付与すると、ユーザー割り当てマネージド ID を使ってクラスター作成時にカスタマー マネージド キーを構成できます。

カスタマー マネージド キーの構成は、新しいクラスター、またはワークスペースにリンクされてデータを取り込んでいる既存のクラスターに適用できます。 リンクされたワークスペースに取り込まれた新しいデータはユーザーのキーで暗号化され、構成前に取り込まれた古いデータは Microsoft キーで暗号化されたままになります。 クエリはカスタマー マネージド キーの構成の影響を受けず、新旧のデータ全体に対してシームレスに実行されます。 いつでも、クラスターからワークスペースのリンクを解除できます。 リンク解除後に取り込まれた新しいデータは Microsoft キーで暗号化され、クエリは新旧のデータ全体に対してシームレスに実行されます。

重要

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

Screenshot of customer-managed key overview.

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

暗号化キー操作

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

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

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

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

カスタマー マネージド キーのプロビジョニング手順

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

現在、カスタマー マネージド キーの構成は Azure portal でサポートされておらず、プロビジョニングは PowerShellCLI、または REST の要求を使用して実行できます。

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

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

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

Screenshot of soft delete and purge protection settings.

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

クラスターの作成

クラスターでは、Azure Key Vault でのデータ暗号化にマネージド ID が使用されます。 "折り返す" 操作と "折り返しを解除する" 操作のために Key Vault へのアクセスを許可するクラスターを作成する場合は、SystemAssigned への type ID プロパティを構成します。

システム割り当てマネージド ID に関するクラスターの ID 設定

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

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

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

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

  1. 制御する Azure RBAC を割り当てる (推奨)

    ロールの割り当てを追加するには、ユーザー アクセス管理者所有者などの Microsoft.Authorization/roleAssignments/write およびMicrosoft.Authorization/roleAssignments/delete アクセス許可が必要です。

    Azure portal で Key Vault を開き、[設定][アクセス構成] をクリックし、[Azure ロールベースのアクセス制御] オプションを選択します。 次に、「アクセス制御 (IAM)」と入力し、Key Vault Crypto Service Encryption ユーザー ロールの割り当てを追加します。

    Screenshot of Grant Key Vault RBAC permissions.

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

    Azure portal で Key Vault を開き、[アクセス ポリシー] をクリックし、[Vault アクセス ポリシー] を選択してから、[+ アクセス ポリシーの追加] をクリックして、次の設定でポリシーを作成します。

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

    Screenshot of Grant Key Vault access policy permissions.

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

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

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

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

重要

  • キーの交換は自動にすることも、明示的なキーの更新を必須とすることもできます。クラスターでキー識別子の詳細を更新する前に、「キーの交換」を参考に、自分に適した手法を判断してください。
  • クラスターの更新では、同じ操作に ID とキー識別子の詳細の両方を含めることをしないでください。 両方の更新が必要な場合、更新は 2 つの連続する操作で行ってください。

Screenshot of Grant Key Vault permissions.

クラスターの KeyVaultProperties を、キー識別子の詳細で更新します。

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

該当なし

重要

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

この操作を実行するには、ワークスペースおよびクラスターに対する "書き込み" 権限が必要です。 それには、Microsoft.OperationalInsights/workspaces/writeMicrosoft.OperationalInsights/clusters/write が含まれます。

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

キーの失効

重要

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

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

キーの交換

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

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

キー ローテーション操作後も、すべてのデータにアクセスできます。 データは常にアカウント暗号化キー ("AEK") で暗号化されます。これは、Key Vault の新しいキー暗号化キー ("KEK") バージョンで暗号化されます。

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

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

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

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

Screenshot of Workbook save.

Note

次のシナリオでは、カスタマー マネージド キーの構成に関係なく、Microsoft キー ("MMK") でクエリの暗号化が維持されます (Azure ダッシュボード、Azure Logic App、Azure Notebooks、Automation Runbooks)。

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

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

  • ワークスペースとストレージ アカウントに対する "書き込み" 権限が必要です。
  • ストレージ アカウントは、カスタマー マネージド キーの暗号化を使い、Log Analytics ワークスペースと同じリージョンに作成してください。 保存されたクエリはテーブル ストレージに格納され、暗号化できるのはストレージ アカウントの作成時のみなので、これは重要です。
  • クエリ パックに保存されたクエリは、カスタマー マネージド キーを使って暗号化されていません。 クエリを保存する場合は、代わりに [レガシ クエリとして保存] を選び、カスタマー マネージド キーを使って保護します。
  • ストレージ内の保存済みクエリはサービスの成果物と見なされ、その形式は変更される可能性があります。
  • クエリ用のストレージ アカウントをリンクすると、ワークスペースから既存の保存クエリが削除されます。 必要な保存済みクエリは、この構成前にコピーしてください。 PowerShell を使用して、保存済みクエリを表示できます。
  • クエリ用のストレージ アカウントをリンクすると、クエリ 'history' と 'pin to dashboard' はサポートされません。
  • 1 つのストレージ アカウントを、保存されたクエリとログ検索アラート クエリのどちらのワークスペースに対してもリンクすることができます。
  • ログ検索アラートは BLOB ストレージ内に保存され、カスタマー マネージド キーによる暗号化は、ストレージ アカウントの作成時またはそれ以降に構成することができます。
  • 発生したログ検索アラートには、検索結果もアラート クエリも含まれません。 発生したアラートの背景を取得する目的でアラート ディメンションを使用できます。

保存済みクエリ用に BYOS を構成する

クエリ用のストレージ アカウントをリンクして、ストレージ アカウントに保存済みクエリを保持します。

該当なし

構成が完了すると、新しい保存された検索条件クエリがストレージに保存されます。

ログ検索アラート クエリ用に BYOS を構成する

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

該当なし

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

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

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

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

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

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

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

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

制限と制約

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

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

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

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

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

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

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

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

    • クラスターを作成したときに、"リージョン名ではクラスターの二重暗号化がサポートされていません" というエラーが表示された場合でも、REST 要求本文に "properties": {"isDoubleEncryptionEnabled": false} を追加すると、二重暗号化なしでクラスターを作成できます。
    • クラスターの作成後に、二重暗号化の設定を変更することはできません。

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

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

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

    • 論理的な削除
    • 論理的な削除の後でもシークレットやコンテナーの強制削除を防ぐには、消去保護を有効にする必要があります。
  • Azure Key Vault、クラスター、ワークスペースは、同じリージョンかつ同じ Microsoft Entra テナント内に存在している必要がありますが、サブスクリプションは異なっていても構いません。

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

  • Key Vault がプライベート リンク (VNet) に配置されている場合は、ユーザー割り当てマネージド ID を持つカスタマー マネージド キーを使用できません。 このシナリオでは、システム割り当てマネージド ID を使用できます。

  • 検索ジョブ非同期クエリ は、現在、カスタマー マネージド キーのシナリオではサポートされていません。

トラブルシューティング

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

    • 通常の操作 - ストレージは一時的に "AEK" をキャッシュし、定期的に Key Vault に戻って折り返しを解除します。

    • Key Vault 接続エラー - ストレージは、可用性の問題が発生している間キーをキャッシュに残して、一時的なエラー (タイムアウト、接続エラー、"DNS" の問題) を処理します。これにより、中断と可用性の問題が解決されます。 クエリ機能と取り込み機能は中断されることなく続行されます。

  • Key Vault へのアクセス レート - Azure クラスター ストレージが折り返しと折り返しの解除のために Key Vault にアクセスする頻度は、6 秒から 60 秒です。

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

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

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

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

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

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

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

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

  • エラー メッセージ

    クラスターの更新

    • 400 — Cluster is in deleting state. (400 — クラスターは削除中の状態です。) 非同期操作が進行中です。 更新操作を実行する前に、クラスターでの操作が完了している必要があります。
    • 400 — KeyVaultProperties is not empty but has a bad format. (400 — KeyVaultProperties は空ではありませんが、形式が無効です。) キー識別子の更新に関するセクションを参照してください。
    • 400 — Failed to validate key in Key Vault. (400 — Key Vault 内のキーの検証に失敗しました。) 必要なアクセス許可がないことが原因である可能性があります。または、キーが存在しません。 Key Vault でキーとアクセス ポリシーを設定したことを確認してください。
    • 400 — Key is not recoverable. (400 — キーは回復不能です。) Key Vault に論理的な削除と消去保護を設定する必要があります。 Key Vault のドキュメントを参照してください
    • 400 — Operation cannot be executed now. (400 — 現在、操作を実行できません。) 非同期操作が完了するまで待ってから、もう一度お試しください。
    • 400 — Cluster is in deleting state. (400 — クラスターは削除中の状態です。) 非同期操作が完了するまで待ってから、もう一度お試しください。

    クラスターの取得

    • 404 - Cluster not found, the cluster might have been deleted. (404 - クラスターが見つかりません。クラスターは削除された可能性があります。) クラスターをその名前で作成しようとし、競合が発生した場合、そのクラスターは削除プロセスにあります。

次の手順