Microsoft Azureのカスタマー ロックボックス

Microsoftの担当者やサブプロセッサーが行うほとんどの運用やサポートは、顧客データへのアクセスを必要としません。 Microsoftがそのようなアクセスを要求する稀な場合には、Customer Lockbox for Microsoft Azureが組織が顧客のデータアクセスリクエストをレビューし、承認または拒否するインターフェースを提供します。 Microsoftは、顧客からのサポートチケットやMicrosoftが特定した問題に対応する場合、Microsoftエンジニアが顧客データにアクセスする必要がある場合にCustomer Lockboxを使用します。

この記事では、Microsoft Azureのカスタマー ロックボックスを有効にする方法と、後でレビューと監査のために要求を開始、追跡、および格納する方法について説明します。

サポートされているサービス

現在、Microsoft Azureのカスタマー ロックボックスでは、次のサービスがサポートされています。

• Azure API Management
• Azure App Service
• Azure AI 検索
• 鋳造ツール
• Azure Chaos Studio
• Azure Communications Gateway
• Azure Container Registry
• Azure Data Box
• Azure Data Explorer
• Azure Data Factory
• Azure エネルギー業界向けデータ マネージャー
• Azure Database for MySQL
• Azure Database for MySQL フレキシブル サーバー
• Azure Database for PostgreSQL
• Azure Edge Zone プラットフォームのストレージ
• Azure Energy
• Azure Functions
• Azure HDInsight
• Azure Health Bot
• Azureのインテリジェント レコメンデーション
• Azure Information Protection
• Azure Kubernetes Service
• Azure ロードテスト (クラウドネイティブ テスト)
• Azure Logic Apps
• Azure Monitor (ログ アナリティクス)
• Azure Red Hat OpenShift
• Azure Spring Apps
• Azure SQL Database
• Azure SQL Managed Instance
• Azure Storage
• Azure サブスクリプションの転送
• Azure Synapse Analytics
• Commerce AI (インテリジェントな推奨事項)
• DevCenterまたはDevBox
• ElasticSan
• Kusto (ダッシュボード)
• マイクロソフト Azure 証明
• Microsoft Entra の診断データ
• OpenAI
• Spring Cloud
• 統一ビジョンサービス
• Azureでの仮想マシン

Microsoft Azureのカスタマー ロックボックスを有効にする

管理モジュールからMicrosoft AzureのCustomer Lockboxを有効にしてください。

Workflow

次の手順では、Microsoft Azure要求のカスタマー ロックボックスの一般的なワークフローの概要を示します。

1. 組織の誰かがAzureワークロードに問題を抱えています。

2. この担当者は、問題のトラブルシューティングを行っても解決できない場合、Azure portal からサポート チケットを作成します。 チケットは、Azureカスタマー サポート エンジニアに割り当てられます。

3. Azureサポートエンジニアがサービスリクエストを確認し、問題解決のための次のステップを決定します。

4. サポートエンジニアが標準ツールやサービス生成データで問題を解決できない場合は、ジャストインタイム(JIT)アクセスサービスを利用して権限の昇格を申請することが次のステップです。 問題はAzure DevOps チームにエスカレートされるため、この要求は元のサポート エンジニアまたは別のエンジニアから行うことができます。

5. Azureエンジニアがアクセスリクエストを送信した後、ジャストインタイムサービスは以下の要素を考慮してリクエストを評価します。

   • リソースのスコープ。
   • リクエスターが孤立したアイデンティティであるか、多要素認証を使用しているかのどちらかです。
   • 許可レベル。 JITルールに基づき、この要請にはMicrosoft内部承認者の承認も含まれる場合があります。 例えば、アプローはカスタマーサポートリードやDevOpsマネージャーかもしれません。

6. 要求に顧客データへの直接アクセスが必要な場合、カスタマー ロックボックス要求が開始されます。

   要求が [Customer Notified]\(お客様に通知済み\) 状態になり、アクセスを許可する前のお客様の承認待ちになります。

7. 特定のカスタマー ロックボックス要求に対するお客様の組織の承認者は、次のように決定されます。

   • サブスクリプション限定のリクエスト(サブスクリプション内の特定のリソースへのアクセスを求めるリクエスト)の場合、関連するサブスクリプション上のオーナーロールまたはAzureのカスタマーロックボックスApprover for Subscriptionの役割を持つユーザー。
   • テナントスコープ要求(Microsoft Entraテナントへのアクセス要求)の場合、テナント上でグローバル管理者の役割を持つユーザー。

   Note

   Microsoft Azureのカスタマー ロックボックスが要求の処理を開始する前に、ロールの割り当てを行う必要があります。 Microsoft AzureのCustomer Lockboxは、特定のリクエスト処理を開始した後に割り当てられたロール割り当てを認識しません。 この要件のため、所有者の役割でPIM適格な割り当てを使用するには、顧客ロックボックスリクエストを開始する前にユーザーが役割を有効化しなければなりません。 PIM適格ロールの有効化についての詳細は、「PIMでMicrosoft Entraロールを有効化」または「PIMでAzureリソースロールを有効化」をご覧ください。

   現在、Microsoft AzureのCustomer Lockboxでは、管理グループにスコープされた役割割り当てはサポートされていません。

8. 顧客組織では、指定されたロックボックス承認者(所有者、Microsoft Entraグローバル管理者、またはAzure顧客ロックボックスサブスクリプション承認者)がMicrosoftから保留中のアクセスリクエストに関する通知メールを受け取ります。 また、AzureのLockbox代替メール通知機能を使って、Azureアカウントがメール対応でない場合や、サービスプリンシパルがロックボックスの承認者として定義されている場合に、ロックボックス通知を受け取るための代替メールアドレスを設定することもできます。

   例:保留

9. メール通知には、カスタマー ロックボックス ブレードの [Administration]\(管理\) モジュールへのリンクが記載されます。 指定された承認者は、Azure ポータルにサインインして、組織がMicrosoft Azureのカスタマー ロックボックスに対して持っている保留中の要求を表示します。 リクエストは顧客キューに4日間残ります。 この時間が経過すると、アクセス要求は自動的に期限切れになり、Microsoft のエンジニアにはアクセスが許可されません。

10. 保留中の要求の詳細を確認するには、指定された承認者は 保留中の要求 から Customer Lockbox 要求を選択できます:

11. 指定された承認者は、元のユーザーが作成したサポートチケットリクエストを表示するために サービスリクエストID を選択できます。 この情報は、Microsoft サポートが関与している理由と、報告された問題の履歴のコンテキストを提供します。 例えば:保留中の

12. 指定された承認者は要求を確認し、[承認] または [拒否] を選択します。 選考結果:

    • 承認: Microsoft エンジニアには、メール通知および Azure ポータルに表示される要求の詳細で指定された期間、アクセス権が付与されます。
    • 却下:Customer LockboxはMicrosoftエンジニアによる上位アクセスリクエストを拒否し、それ以上の対応を取らない。

    監査のために、このワークフローで実行されたアクションは [Customer Lockbox request logs]\(カスタマー ロックボックス要求ログ\) に記録されます。

監査ログ

Customer Lockbox for Azureの監査ログは、サブスクリプション限定リクエストの場合はアクティビティログに、テナントスコープリクエストの場合はMicrosoft Entra監査ログに書き込みます。

サブスクリプションスコープリクエスト - アクティビティログ

Azure ポータルの [Customer Lockbox for Microsoft Azure] ブレードで、Activity Logs を選択して、カスタマー ロックボックス要求に関連する監査情報を表示します。 また、対象のサブスクリプションの [サブスクリプションの詳細] ブレードで [アクティビティ ログ] を表示することもできます。 どちらの場合も、以下のように特定の操作を抽出するようにフィルター処理を行うことができます。

• [Deny Lockbox Request]\(ロックボックス要求を拒否する\)
• [Create Lockbox Request]\(ロックボックス要求を作成する\)
• [Approve Lockbox Request]\(ロックボックス要求を承認する\)
• [Lockbox Request Expiry]\(ロックボックス要求の有効期限\)

例

テナントを対象とした要求 - 監査ログ

テナント範囲限定のCustomer Lockboxリクエストに対して、Access ReviewsサービスはMicrosoft Entra監査ログにログエントリを書き込みます。 これらのログエントリには、以下のような活動が含まれます:

• 要求の作成
• 要求の承認
• 要求の拒否

Service = Access Reviews と Activity = one of the above activities をフィルター処理できます。

例

Microsoft クラウド セキュリティ ベンチマークとのMicrosoft Azure統合のためのカスタマー ロックボックス

Microsoftは、Microsoftクラウドセキュリティベンチマークにおいて、顧客ロックボックスの適用可能性をカバーする新しい基準管理(PA-8:クラウドプロバイダーサポートのためのアクセスプロセスの決定)を導入しました。 ベンチマークを使って、サービスに対する顧客ロックボックスの適用性を確認してください。

除外

Customer Lockboxは以下のシナリオでリクエストを発生させません:

• 標準的な運用手順に該当しない緊急シナリオで、オンライン サービスへのアクセスを復元したり、顧客データの破損や損失を防いだり、セキュリティや不正使用のインシデントを調査したりするために、Microsoft から緊急の措置が必要になります。 例えば、大規模なサービス障害やセキュリティインシデントが発生した場合、予期せぬまたは予測不可能な状況下でサービスを復旧または回復するために即時対応が必要です。 こうした「ブレイクグラス」イベントは稀で、ほとんどの場合、解決のために顧客データへのアクセスを必要としません。 コア オンライン サービスの顧客データへの Microsoft のアクセスを制御する制御とプロセスは、NIST 800-53 に準拠し、SOC 2 監査を通じて検証されます。 詳細については、Microsoft AzureのCustomer Lockboxに関するAzureセキュリティベースラインをご覧ください。
• Microsoft のエンジニアは、トラブルシューティングの一環としてAzure プラットフォームにアクセスし、誤って顧客データに公開されます。 たとえば、Azure ネットワーク チームは、ネットワーク デバイスでパケット キャプチャを行うトラブルシューティングを実行します。 このようなシナリオでは、実質的な量の顧客データへのアクセスはほとんど得られません。 さらに、顧客管理キーを活用してデータを保護しましょう。これは一部のAzureサービスで利用可能なものです。 詳細については、Azureのキー管理をご覧ください。

外部からの法的データ要求も顧客ロックボックスの要求をトリガーしません。 詳細については、Microsoft Trust Center の 政府機関によるデータの要求についての説明を参照してください。

次のステップ

カスタマー ロックボックス ブレードの [管理] モジュールからカスタマー ロックボックスを有効にします。 開発者レベル以上のAzure サポートプランを持つすべての顧客は、Customer Lockbox for Microsoft Azureを使用できます。

• Microsoft Azure のカスタマー ロックボックスの代替メール通知
• Microsoft Azureのカスタマー ロックボックスに関する FAQ