複数の場所の要件を満たすように Azure ランディング ゾーン アーキテクチャを変更する
多くの業界の組織は、データ所在地、データ セキュリティ、データ主権の要件など、規制要件の対象となります。 一部の組織では、複数の地域の場所で競合する規制に準拠する必要があります。 この場合、適用されるすべての規制に従って、Azure ランディング ゾーンのアーキテクチャを変更する必要があります。
たとえば、規制 A と規制 B という 2 つの競合する規制が存在する可能性があります。規制 A では国または地域 A でのデータ所在地が必要になる場合があり、規制 B では国または地域 B でのデータ所在地が必要になる場合があります。
このような規制上の競合は、次の場合に適用されることがあります。
多国籍企業や非政府組織 (NGO) などの多国籍組織は、事業を行う国または地域の現地の規制に準拠する必要があります。
複数の場所にある組織にソリューションを提供する独立系ソフトウェア ベンダー (ISV) は、ソリューションが各場所の現地の規制に準拠している必要があります。
各国または地域の現地規制に準拠する必要がある多国籍組織にソリューションを提供する ISV。
1 セットの規制要件のみを満たす必要がある場合は、「要件を満たすように Azure ランディング ゾーン アーキテクチャを調整する」を参照してください。
規制に関する考慮事項
規制要件は、通常、データ保護、データ所在地、データ転送、分離、または人員のクリアランスに関連します。 これらの要件は、複数の地域の場所の間で競合する可能性があります。 たとえば、欧州連合 (EU) 規制では ヨーロッパの国におけるデータ所在地が必要になる場合があります。一方、イギリスの規制では、イギリスでのデータ所在地が必要な場合があります。
規制によってポリシー制御が競合する場合は、それに応じて Azure ランディング ゾーンのアーキテクチャとポリシーの割り当てを調整する必要があります。 詳細については、この記事の「変更が必要なシナリオ」セクションを参照してください。
複数の規制が適用される場合、次の場合には Azure ランディング ゾーン アーキテクチャを変更する必要はありません。
複数の規制で同じ Azure Policy の割り当てが必要になります。
ある規則の制御は、別の規則のスーパーセットです。 スーパーセット コントロールは、両方の規制に自動的に適用されます。
複数の規制のコントロールは重複しません。 複数のコントロール セットを実装する場合、1 つの実装ですべての規制がカバーされます。 Azure Policy の割り当ては補完的です。
多くの規制が、異なった種類の実装を持ちます。 規制の観点から見れば、選択した実装は関係ありません。 たとえば、それぞれ異なる承認モデルを持つ 2 つの規制がある場合、両方の承認モデルが許容されます。 組織に最適な実装を選択できます。
ヒント
ポリシーの割り当てと例外または除外を可能な限り少なくするように努める必要があります。
ISV に関する考慮事項
3 つの ISV 用デプロイ モデルがあります。
ピュア サービスとしてのソフトウェア (SaaS): ISV は、サービスとしてのソリューションを提供します。
顧客がデプロイしたモデル: お客様は、独自の環境でソリューションをデプロイします。
デュアルデプロイ SaaS: このモデルは、顧客がデプロイしたモデルとピュア SaaS モデルを組み合わせたモデルです。
ピュア SaaS モデルでは、ISV は顧客に代わってコンプライアンスを管理する責任を負います。 ISV は、顧客に対して、また場合によっては監査担当者または規制当局に対して、コンプライアンスを実証する必要があります。 SaaS モデルを使用する場合、アーキテクチャは競合する可能性のある複数の規制の対象になる可能性があります。 ISV は、これらのさまざまな規制のコンプライアンスを管理する必要があります。 詳細については、この記事の「変更が必要なシナリオ」セクションを参照してください。
顧客がデプロイしたモデルでは、顧客がコンプライアンスの管理を担当します。 このモデルでは、ISV がランディング ゾーンを変更する必要はありません。 ただし、ソリューションは、ポリシー制御やカスタム ポリシーを含め、顧客がデプロイするランディング ゾーンにデプロイされます。
ヒント
ISV は、特定のコンプライアンス要件でポリシー イニシアチブをターゲットにして、ソリューションをテストできます。 このプラクティスは、顧客がコンプライアンス要件を満たすために使用するポリシーとの競合の可能性を最小限に抑えるのに役立ちます。
デュアルデプロイ SaaS モデルでは、顧客がデプロイしたモデル、およびピュア SaaS モデルに関するすべての考慮事項が当てはまります。
多国籍組織に関する考慮事項
多国籍組織は、さまざまな構造を使用して IT ガバナンスを整理します。
分散構造: IT 機能は、各地域の場所にローカルに管理されます。
一元化された構造: IT 機能は、一元化された場所 (通常は組織の本社) から管理されます。
ハイブリッド構造: グローバル IT 機能は一元的に提供され、ローカルでのみ必要な IT 機能は各地域の場所で管理されます。
分散化されたシナリオでは、ローカルの IT チームがコンプライアンスの管理を担当し、それに応じてランディング ゾーンを調整できます。
一元化されたシナリオでは、中央 IT チームがコンプライアンスの管理を担当し、多国籍組織が運営するすべての地域の場所のローカル コンプライアンス要件をソリューションが満たしていることを確認する必要があります。 さまざまな地域の場所のコンプライアンス要件が競合する際には、ランディング ゾーンの変更が必要になる場合があります。
ハイブリッドシナリオでは、分散シナリオと一元化シナリオの両方に関する考慮事項が当てはまります。 一元化された組織は、ローカル組織が自分の環境にデプロイする必要があるソリューションを提供します。 また、一元化された組織は、これらのソリューションがローカル組織のすべてのランディング ゾーンでのデプロイをテストします。
変更が必要なシナリオ
さまざまなデプロイに割り当てられているポリシー セットが競合している場合は、ランディング ゾーンの変更が必要になる場合があります。 複数のソリューションまたは 1 つのソリューションを、さまざまな地域の場所やデータ分類で使用可能にする必要がある場合があります。
必要な変更の量は、規制が要求する分離レベルによって異なります。 規制の条件が多いほど、ランディング ゾーンを多く変更する必要があります。 たとえば、クリアされた担当者、さまざまな ID プロバイダーまたはディレクトリ、個別の管理インフラストラクチャ、または個別の接続インフラストラクチャなどの条件が規制で必要とされる場合、ランディング ゾーンには広範な変更が必要です。 規制で必要なのがアプリケーションと接続インフラストラクチャの分離のみの場合は、ランディング ゾーンに必要なのは最小限の変更だけです。
Microsoft Entra テナント
ほとんどのシナリオ (多国籍シナリオを含む) では、1 つの Microsoft Entra テナントを使用することをおすすめします。 ただし、複数の Microsoft Entra テナントのほうがよい、または複数の Microsoft Entra テナントが必要となる、次のようなシナリオもあります。
企業向け Microsoft Entra テナントを SaaS Microsoft Entra テナント から分離してセキュリティを強化し、製品と事業運営の間に明確な境界を作成する必要がある場合。
競合する規制が適用され、さまざまな規制体制に個別の Microsoft Entra テナントが必要な場合。 たとえば、規制には、Microsoft Entra テナント、もしくは個別のテナントを必要とするデータ所在地の要件からの完全な分離が必要なクリアランスおよび国籍の要件がある場合があります。 一般的なシナリオとしては、SaaS ソリューションの分離インスタンスをデプロイする必要がある ISV や、同じソリューションの分離インスタンスをデプロイする必要がある多国籍組織などがあります。
複数の Microsoft Entra テナント間で共同作業を行う場合は、重要な課題とニーズのプランを慎重に立てる必要があります。 運用要件または規制要件を満たすために必要な Microsoft Entra テナントの最小数のみを作成します。 管理グループと Azure ロールベースのアクセス制御 (RBAC) を使用して、次のセクションで説明されるように、1 つのテナントのもとでサブスクリプションとリソースへのアクセスを制御できます。
ヒント
ランディング ゾーン用に選択した Microsoft Entra テナントは、アプリケーション レベルの認証には影響しません。 選択したテナントに関係なく、他の ID プロバイダーも使用できます。 公共部門の顧客や規制対象業界の顧客の場合、エンドユーザー ID は、通常、政府所有または認定 ID プロバイダーなどの承認済み ID プロバイダーと統合するときに提供されます。
次の図は、Microsoft Entra テナントの整理に使用できるオプションを示しています。
ヒント
規制要件を満たす複数の Microsoft Entra テナントがある場合は、例の図の contoso-ops-us.com のように、特定の規制ではなく地域の場所に基づいた名前をテナントに付けます。
詳細については、Azure ランディング ゾーンと複数の Microsoft Entra テナント と Azure ランディング ゾーンの ISV に関する考慮事項 を参照してください。
管理グループ
厳密な分離を実現するための個別の Microsoft Entra テナントがない場合は、1 つの Microsoft Entra テナントに複数の Azure ランディング ゾーンをデプロイする必要があります。 管理グループ階層を調整して、競合する規制の要件に対応させることができます。
分離する一連の規制ごとに、完全なランディング ゾーン アーキテクチャをデプロイできます。 このモデルでは必要なカスタマイズは最小限で、デプロイに既存の自動化を利用できます。
Note
この図では、すべての管理グループが表示されるわけではありません。
プラットフォーム管理グループを共有する
規制によって許可されている場合は、プラットフォーム管理グループを共有できます。 分離する必要がある一連の規制ごとに、ランディング ゾーン管理グループの下に個別の管理グループを作成できます。 適切なポリシーを各アプリケーション管理グループに割り当てることができます。 アプリケーションランディングゾーンは、プラットフォーム管理グループの下にある管理グループを共有します。 アプリケーション管理グループ内のリソースは、サブスクリプションまたはリソース グループで区切ることもできます。
この管理グループ階層は、競合する規制でアプリケーションを分離するためのシンプルでコスト効率の高い設計です。 ただし、この設計では、接続、ID/セキュリティ、および管理のプラットフォーム管理グループは、同じポリシー セットを共有する必要があります。 規制によって、接続インフラストラクチャ、ID サービス、キー管理サービス、または環境全体が管理されるインフラストラクチャの共有に制限が課される場合は、プラットフォーム管理グループごとに異なるポリシー セットが必要になる場合があります。
ID とセキュリティを分離する
規制によって ID とキー管理インフラストラクチャを共有できない場合は、プラットフォーム管理グループを分割できます。 接続と管理の管理グループを共有プラットフォーム管理グループに保持し、各規制セットに関連付けられている ID およびセキュリティ管理グループを持ちます。
この管理グループ階層は、プラットフォーム管理グループを部分的にレプリケートする必要があるため、完全に共有されたプラットフォーム管理グループよりもはるかに複雑です。 複雑さを制限するために、各規制セットと共有環境の階層全体をデプロイし、余分な管理グループを無視または削除できます。
接続を分離する
多くの規制には、特定の地域の場所でのデータの処理と格納に関連する要件があり、ユーザーがアプリケーションに接続する方法に関する要件はほとんどありません。 これらの規制については、前のアーキテクチャに示すように接続管理を共有できます。 複数のリージョンでインフラストラクチャを複製しなければならないような規制はありませんが、待機時間削減のために必要な場合があります。 割り当てられたポリシーは、複数のリージョンでのインフラストラクチャの複製をサポートしている必要があります。
規制で接続要件が競合している場合は、それぞれの規制セットに関連付けられた接続管理グループを作成できます。 この構造は、ID とセキュリティ管理グループを各規制セットに関連付ける前のアーキテクチャに似たものです。
接続性と ID とセキュリティに関する規制が競合する場合は、次の設計を使用できます。
