Microsoft Cloud for Sovereignty でカスタマー マネージド暗号化キーを使用した暗号化
Microsoft Cloud for Sovereignty の実装を計画している顧客は、データ主権要件を満たすためにデータ暗号化機能を使用すする必要がある場合があります。 厳格なデータ主権要件を持つ顧客は、クラウドでキー管理を実装する計画を策定する必要があります。 この記事では、クラウド アーキテクト、暗号化システムの所有者、その他の技術的な意思決定者が、Azure にプラットフォーム レベルの暗号化を実装するための計画を作成するためのガイドを示します。 プラットフォーム レベルでの暗号化を計画するには、通常、キー管理要件の特定、テクノロジの選択、使用する Azure サービスの設計と構成の選択が含まれます。 このプロセスには、次の 3 つのドメインにわたって技術的な意思決定を行うことが含まれます。
- キー管理要件を定義する: 機密の顧客データと機密の暗号マテリアルを保護するために、組織は何をする必要がありますか?
- 顧客データを保護するためのデータ暗号化機能を選択する: Azure で顧客データをいつ、どこで、どのように暗号化する必要がありますか?
- 顧客キーを保護するキー管理ソリューションを選択する: Azure で顧客データの暗号化に使用されるデータ暗号化キーを保護するには、どのキー ストアを使用する必要がありますか?
キー管理の要件を定義する
キー管理の要件には、使用される暗号化サービスに関する技術要件や、パフォーマンス、セキュリティ、および主権に関連する運用要件が含まれる場合があります。 Azure ワークロードのデータをいつ、どのように暗号化するかを決定するための推奨される開始点は、組織のデータ分類システムです。 特定のシステムやソリューションではなく、暗号化要件をデータ分類に合わせることで、組織はワークロード移行計画中に最適な暗号化レベルをより柔軟に選択できるようになります。
データ分類に基づいて暗号化要件を設定することにより、階層型アプローチも可能になります。これにより、重要度の低いワークロードはより単純なソリューションを利用できる一方で、より高いレベルの固有リスクを伴うワークロードには最も複雑な構成を確保することができます。 このアプローチの例としては、開発環境のストレージ アカウントを暗号化するために Microsoft が管理するキーの使用を許可し、運用環境のストレージ アカウントには顧客が管理する暗号化キーを使用することを要求することが考えられます。
組織は、暗号化要件がデータ分類にどのように関連しているかを明確に理解した後、利用を計画している Azure サービスの機能選択のプロセスを開始できます。 これらの機能の一部は、同様の オンプレミスの システムとは異なる動作をする可能性があるため、組織は Azure での暗号化の仕組みを理解し、暗号化ソリューションを設計するための推奨事項とベスト プラクティスを確認することが推奨されます。 次の記事は、顧客が行う必要がある技術的な選択の一部について追加の視点を提供するもので、組織のクラウド キー管理目標についての会話を開始するための有用な出発点となります。
データ暗号化機能を選択する
多くの Azure サービスでは、顧客の介入なしに、Azure によって完全に生成、保存、管理されるキーを使用した暗号化が可能です。 これらのプラットフォーム マネージド キーは、組織がわずかな運用オーバーヘッドで暗号化を実装するのに役立ちます。 ただし、厳格なデータ主権要件を持つお客様は、特定の Azure サービスに保存されている機密データを保護するために、特定のプラットフォーム暗号化機能を選択する必要がある場合があります。
機密性の高いデータの場合、一般的に使用される Azure サービスの多くでは、顧客がカスタマー マネージド キー (CMK) を使用して二重暗号化を実装できます。 Azure サービスにカスタマー マネージド キーを実装すると、顧客はそれらのサービスに保存されているデータを不正アクセスから保護できます。
Azure にカスタマー マネージド キーを実装すると、ワークロードのコストと複雑さが増加する可能性があるため、組織はワークロードとデータ分類レベルごとにこの機能の必要性を評価することをお勧めします。 カスタマー マネージド キーを必要とするワークロードとデータ型にのみ実装すると、機密データを処理しないワークロードの運用オーバーヘッドを削減できます。
カスタマー マネージド キーが必要な場合は、それぞれの Azure サービスごとにキーを構成する必要があります。 組織は、これらの機能を実装するための組織全体の標準と反復可能な設計パターンを確立することで、展開または移行の計画作業を効率化できます。 次の記事では、Azure で保存データの暗号化を構成する方法について詳しく説明します。
一般的に使用される Azure サービスを構成して、カスタマー マネージド キーを使用して保存データを暗号化する方法を学びます。
- ストレージ アカウントでの CMK の使用
- AMD Confidential VM を使用した Confidential Computing での CMK の使用
- 仮想マシン マネージド ディスクでの CMK の使用
- Azure SQL DB での CMK の使用
- Azure Cosmos DB での CMK の使用
- Azure Monitor での CMK の使用
鍵管理ソリューションを選択する
カスタマー マネージド キーによる二重暗号化などの機能は、Azure サービスで維持される顧客データの保護に役立ちますが、クラウドベースのキー管理ソリューションは、機密データの暗号化に使用される暗号化キーやその他の暗号マテリアルの保護に役立ちます。 厳格なデータ主権要件を持つお客様は、保証のニーズとワークロードのリスク プロファイルに基づいて、適切なキー管理ソリューションを選択する必要があります。
機密データを処理するワークロードにより、Azure Managed HSM などのソリューションが提供する追加保証からメリットを得ることができる場合があります。これには、保存された暗号マテリアルを保護するための追加のセキュリティ制御を備えた、FIPS-140-2 レベル 3 の検証済みハードウェア セキュリティ モジュールが含まれます。
次の記事では、お客様が特定のシナリオに適したキー ストアを選択するために使用できるガイダンスを提供します。 また、顧客が暗号化ソリューションの一部として使用する暗号化サービスを Microsoft がどのように管理するかに関する情報も提供します。
キー管理の運用モデル
Azure Key Vault は、Azure Key Vault の Standard/Premium レベルを使用しているか、Azure Key Vault Managed HSM を使用しているかに応じて、さまざまな方法でロールベースのアクセス制御を実装します。 アクセスの制御におけるこれらの違いは、組織が機能を使用する方法に影響を与える可能性があります。 このセクションでは、これらの違いについて説明し、組織がクラウド キー管理の運用プロセスを設計する方法にその違いがもたらす影響について説明します。
FIPS-140 レベル 3 の検証のコンプライアンス制約
FIPS-140 レベル 3 の検証では、ID ベースのオペレーター識別が必要です。 これらの保護手段は、Azure の Key Vault サービスをサポートする基盤となる HSM ハードウェアに展開され、検証されます。 その結果、Azure Key Vault の RBAC 機能は、基盤となるハードウェアの RBAC 機能に依存します。
Azure Key Vault のマネージド HSM は、ハードウェア レベルで実装されているローカル RBAC の割り当てを活用し、セキュリティ ドメインのスコープ (たとえば、HSM 全体) またはキーごとにロールの割り当てを可能にします。 つまり、まだ存在しないキーには権限を割り当てることができないため、キーの作成にはセキュリティ ドメイン全体に対する管理権限が必要になります。 この設計の影響として、mHSM インスタンスにキーを保存する必要があるユーザーは、そのセキュリティ ドメインに保存されているすべてのキーに対する完全な権限を持っているか、セキュリティ ドメインに対する必要な権限を持つ中央チームにキーを要求する必要があります。 これは、アプリケーションごとに個別のキー コンテナーを作成することを推奨する Azure Key Vault のガイダンス から方向転換していることを表しています。
Azure Key Vault のマネージド HSM でのキー管理操作
キー管理の運用プロセスを開発するには、顧客は、ソリューション アーキテクチャの一部として Azure Key Vault マネージド HSM が必要かどうかを判断する必要があります。 マネージド HSM の使用を計画している組織は、まず、管理操作と暗号化操作の両方に使用されるアクセスの制御モデルに精通し、ロールベースのアクセス制御がどのように割り当てられるかを理解する必要があります。
マネージド HSM のアクセス制御の詳細については、以下をご覧ください。
Azure Key Vault HSM の使用を計画している組織は、マネージド HSM の組み込み RBAC ロールと許可された操作 の一覧を確認し、特に次の操作シナリオに対処する計画を立てる必要があります。
- マネージド HSM で新しいキーを作成する
- コントロール プレーンを使用した既存のキーの管理操作 (キーの更新やキーのローテーションなど)
- アプリケーションまたはサービスごとの既存のキーのデータ プレーン使用
現在、新しいキーを作成するための権限を割り当てる唯一の方法は、キーのローテーションや削除などの他の権限も含まれる Crypto User などのロールを割り当てることです。 その結果、アプリケーション チーム メンバーにマネージド HSM で独自のキーを作成するために必要な権限を付与すると、そのユーザーは HSM 内のすべてのキーに対する管理権限も持つことになるため、最小権限の原則に違反する可能性があります。 この問題は、キー作成要求を促進できる昇格された権限を持つ一元化されたチームを導入するか、マネージド HSM REST API を活用する IT サービスマネジメント プロセスを通じて新しいキー作成要求を促進できる自動化を導入することで解決できます。