次の方法で共有


Microsoft Cloud for Sovereignty ベースライン機密ポリシーの規制コンプライアンスの組み込みイニシアティブの詳細

次の記事では、Azure Policy 規制コンプライアンスの組み込みイニシアティブ定義が、Microsoft Cloud for Sovereignty のベースライン機密ポリシー内のコンプライアンス ドメインコントロールにどのようにマップされるかについて詳細に説明します。 このコンプライアンス標準の詳細については、Microsoft Cloud for Sovereignty のベースライン機密ポリシーに関するページを参照してください。 "所有権" を理解するには、「ポリシーの種類」と「クラウドでの共有責任」を参照してください。

以下のマッピングは、Microsoft Cloud for Sovereignty のベースライン機密ポリシー コントロールに対するものです。 コントロールの多くは、Azure Policy のイニシアチブ定義で実装されています。 完全なイニシアチブ定義を確認するには、Azure portal で [ポリシー] を開き、 [定義] ページを選択します。 次に、[プレビュー]: Sovereignty ベースライン - 機密ポリシーの規制コンプライアンスの組み込みイニシアティブを見つけて選択します。

重要

以下の各コントロールは、1 つ以上の Azure Policy 定義に関連します。 これらのポリシーは、コントロールに対するコンプライアンスの評価に役立つ場合があります。ただし、多くの場合、コントロールと 1 つ以上のポリシーとの間には、一対一での一致、または完全な一致はありません。 そのため、Azure Policy での準拠では、ポリシー定義自体のみが示されています。これによって、コントロールのすべての要件に完全に準拠していることが保証されるわけではありません。 また、コンプライアンス標準には、現時点でどの Azure Policy 定義でも対応されていないコントロールが含まれています。 したがって、Azure Policy でのコンプライアンスは、全体のコンプライアンス状態の部分的ビューでしかありません。 このコンプライアンス標準に対するコンプライアンス ドメイン、コントロール、Azure Policy 定義の間の関連付けは、時間の経過と共に変わる可能性があります。 変更履歴を表示するには、GitHub のコミット履歴に関するページを参照してください。

SO.1 - データ所在地

承認されたリージョンを使うように Azure 製品をデプロイして構成する必要があります。

ID: MCfS Sovereignty のベースライン ポリシー SO.1 所有権: 共有

名前
(Azure portal)
説明 効果 Version
(GitHub)
許可される場所 このポリシーでは、リソースをデプロイするときに組織が指定できる場所を制限できます。 geo コンプライアンス要件を強制するために使用されます。 リソース グループ Microsoft.AzureActiveDirectory/b2cDirectories や、「グローバル」リージョンを使用するリソースを除外します。 deny 1.0.0
リソース グループが許可される場所 このポリシーでは、組織がリソース グループを作成できる場所を制限できます。 geo コンプライアンス要件を強制するために使用されます。 deny 1.0.0
Azure Cosmos DB が許可されている場所 このポリシーでは、Azure Cosmos DB リソースをデプロイするときに組織が指定できる場所を制限できます。 geo コンプライアンス要件を強制するために使用されます。 [parameters('policyEffect')] 1.1.0

SO.3 - カスタマー マネージド キー

可能な場合にはカスタマー マネージド キーを使うように Azure 製品を構成する必要があります。

ID: MCfS Sovereignty のベースライン ポリシー SO.3 所有権: 共有

名前
(Azure portal)
説明 効果 Version
(GitHub)
[プレビュー]: Azure Recovery Services コンテナーでは、バックアップ データを暗号化するために、カスタマー マネージド キーを使用する必要がある カスタマー マネージド キーを使用して、バックアップ データの保存時の暗号化を管理します。 既定では、顧客データはサービス マネージド キーを使用して暗号化されますが、規制コンプライアンス標準を満たすには、一般にカスタマー マネージド キーが必要です。 カスタマー マネージド キーを使用すると、自分が作成して所有する Azure Key Vault キーを使用してデータを暗号化できます。 ローテーションや管理など、キーのライフサイクルを完全に制御し、責任を負うことになります。 詳細については、https://aka.ms/AB-CmkEncryption をご覧ください。 Audit、Deny、Disabled 1.0.0-preview
Azure Kubernetes Service クラスターのオペレーティング システムとデータ ディスクは両方とも、カスタマー マネージド キーで暗号化する必要がある カスタマー マネージド キーを使用して OS とデータ ディスクを暗号化することで、キー管理をより細かく制御し、柔軟性を高めることができます。 これは、さまざまな規制や業界のコンプライアンス標準での一般的な要件です。 Audit、Deny、Disabled 1.0.1
HPC Cache アカウントでは、暗号化にカスタマー マネージド キーを使用する必要がある カスタマー マネージド キーを使用して、Azure HPC Cache の保存時の暗号化を管理します。 既定では、顧客データはサービス マネージド キーを使用して暗号化されますが、規制コンプライアンス標準を満たすには、一般にカスタマー マネージド キーが必要です。 カスタマー マネージド キーを使用すると、自分が作成して所有する Azure Key Vault キーを使用してデータを暗号化できます。 ローテーションや管理など、キーのライフサイクルを完全に制御し、責任を負うことになります。 Audit, Disabled, Deny 2.0.0
マネージド ディスクはプラットフォーム マネージドおよびカスタマー マネージド キーの両方を使用して二重暗号化する必要がある セキュリティに対する要件が高く、特定の暗号化アルゴリズム、実装、または侵害されたキーに関連するリスクを懸念しているお客様は、プラットフォーム マネージド暗号化キーを使用してインフラストラクチャ レイヤーに異なる暗号化アルゴリズムまたはモードを使用することにより、暗号化の追加レイヤーを設けることを選ぶことができます。 二重暗号化を使用するには、ディスク暗号化セットが必要です。 詳細については、https://aka.ms/disks-doubleEncryption をご覧ください。 Audit、Deny、Disabled 1.0.0
MySQL サーバーでは保存データを暗号化するためにカスタマー マネージド キーを使用する必要がある カスタマー マネージド キーを使用して、MySQL サーバーの保存時の暗号化を管理します。 既定では、データはサービス マネージド キーを使用して保存時に暗号化されますが、規制コンプライアンス標準を満たすには、一般にカスタマー マネージド キーが必要です。 カスタマー マネージド キーを使用すると、自分が作成して所有する Azure Key Vault キーを使用してデータを暗号化できます。 ローテーションや管理など、キーのライフサイクルを完全に制御し、責任を負うことになります。 AuditIfNotExists、Disabled 1.0.4
PostgreSQL サーバーでは保存データを暗号化するためにカスタマー マネージド キーを使用する必要がある カスタマー マネージド キーを使用して、PostgreSQL サーバーの保存時の暗号化を管理します。 既定では、データはサービス マネージド キーを使用して保存時に暗号化されますが、規制コンプライアンス標準を満たすには、一般にカスタマー マネージド キーが必要です。 カスタマー マネージド キーを使用すると、自分が作成して所有する Azure Key Vault キーを使用してデータを暗号化できます。 ローテーションや管理など、キーのライフサイクルを完全に制御し、責任を負うことになります。 AuditIfNotExists、Disabled 1.0.4
Queue Storage では暗号化にカスタマー マネージド キーを使用する必要がある カスタマー マネージド キーを使用して、より柔軟に Queue Storage をセキュリティで保護します。 カスタマー マネージド キーを指定すると、データを暗号化するキーへのアクセスを保護および制御するために、そのキーが使用されます。 カスタマー マネージド キーを使用すると、キー暗号化キーのローテーションを制御したり、データを暗号的に消去したりするための追加機能が提供されます。 Audit、Deny、Disabled 1.0.0
SQL マネージド インスタンスでは保存データを暗号化するためにカスタマー マネージド キーを使用する必要がある 独自キーを使用して Transparent Data Encryption (TDE) を実装すると、TDE 保護機能の透明性および制御が強化され、HSM で保護された外部サービスによるセキュリティが向上し、職務の分離が促進されます。 この推奨事項は、関連するコンプライアンス要件を持つ組織に適用されます。 Audit、Deny、Disabled 2.0.0
SQL サーバーでは保存データを暗号化するためにカスタマー マネージド キーを使用する必要がある 独自キーを使用して Transparent Data Encryption (TDE) を実装すると、TDE 保護機能の透明性および制御が強化され、HSM で保護された外部サービスによるセキュリティが向上し、職務の分離が促進されます。 この推奨事項は、関連するコンプライアンス要件を持つ組織に適用されます。 Audit、Deny、Disabled 2.0.1
ストレージ アカウントの暗号化スコープでは保存データを暗号化するためにカスタマー マネージド キーを使用する必要がある ストレージ アカウントの暗号化スコープの保存データを管理するには、カスタマー マネージド キーを使用します。 カスタマー マネージド キーを使用すると、自分で作成して所有する Azure Key Vault キーを使用してデータを暗号化できます。 ローテーションや管理など、キーのライフサイクルを完全に制御し、責任を負うことになります。 ストレージ アカウントの暗号化スコープの詳細については、https://aka.ms/encryption-scopes-overview を参照してください。 Audit、Deny、Disabled 1.0.0
ストレージ アカウントでは、暗号化にカスタマー マネージド キーを使用する必要がある カスタマー マネージド キーを使用して、より柔軟に BLOB とファイル ストレージ アカウントをセキュリティで保護します。 カスタマー マネージド キーを指定すると、データを暗号化するキーへのアクセスを保護および制御するために、そのキーが使用されます。 カスタマー マネージド キーを使用すると、キー暗号化キーのローテーションを制御したり、データを暗号的に消去したりするための追加機能が提供されます。 Audit、Disabled 1.0.3
Table Storage では暗号化にカスタマー マネージド キーを使用する必要がある カスタマー マネージド キーを使用して、より柔軟に Table Storage をセキュリティで保護します。 カスタマー マネージド キーを指定すると、データを暗号化するキーへのアクセスを保護および制御するために、そのキーが使用されます。 カスタマー マネージド キーを使用すると、キー暗号化キーのローテーションを制御したり、データを暗号的に消去したりするための追加機能が提供されます。 Audit、Deny、Disabled 1.0.0

SO.4 - Azure Confidential Computing

可能な場合には Azure Confidential Computing の SKU を使うように Azure 製品を構成する必要があります。

ID: MCfS Sovereignty のベースライン ポリシー SO.4 所有権: 共有

名前
(Azure portal)
説明 効果 Version
(GitHub)
許可されるリソースの種類 このポリシーでは、組織でデプロイできるリソースの種類を指定できるようになります。 このポリシーの影響を受けるのは、'tags' と 'location' をサポートするリソースの種類のみです。 すべてのリソースを制限するには、このポリシーを複製し、'mode' を 'All' に変更してください。 deny 1.0.0
許可されている仮想マシン サイズ SKU このポリシーでは、組織でデプロイできる仮想マシン サイズ SKU のセットを指定できます。 拒否 1.0.1

次のステップ

Azure Policy に関するその他の記事: