マルチテナント ソリューションにおけるガバナンスとコンプライアンスのアーキテクチャ アプローチ
Azure の使用が成熟するにつれて、クラウド リソースのガバナンスを検討することが重要です。 ガバナンスには、テナントのデータの格納方法と管理方法、および Azure リソースの整理方法が含まれます。 また、規制、法律、または契約上義務付けられている標準に従う必要がある場合もあります。 この記事では、マルチテナント ソリューションでガバナンスとコンプライアンスを検討する方法について説明します。 また、これらの懸念をサポートする主要な Azure プラットフォーム機能の一部も提案します。
主な考慮事項と要件
リソースの分離
テナントの分離要件を満たすように Azure リソースを構成してください。 Azure リソースを分離する方法のガイダンスについては、「マルチテナント ソリューションでの Azure リソースの編成」を参照してください。
データ管理
テナントの代わりにデータを格納する場合は、満たす必要がある要件や義務がある可能性があります。 テナントの観点からは、多くの場合、データの所有権と制御が必要です。 テナントのデータを分離、格納、アクセス、集計する方法を検討します。 ソリューションの動作に影響を与える可能性のあるテナントの期待と要件を明らかにします。
隔離
テナントのデータを分離する方法を理解するために、マルチテナント ソリューションのストレージとデータの アーキテクチャアプローチ を確認します。 テナントに独自のデータ暗号化キーを使用するための要件があるかどうかを検討します。
どの分離方法を実装する場合でも、テナントがデータの監査を要求できるように準備します。 テナントのデータが保持される可能性があるすべてのデータ ストアを文書化することをお勧めします。 一般的なデータ ソースは次のとおりです。
- ソリューションの一部としてデプロイされたデータベースとストレージ アカウント。
- ID システム。多くの場合、テナント間で共有されます。
- ログ:
- データ ウェアハウス。
主権
格納または処理されるテナントのデータの物理的な場所に制限があるかどうかを理解します。 あなたのテナントは、特定の地理的な場所にデータを格納することが必要になる場合があります。 また、特定の場所にデータを格納 "しない" ように求められる場合もあります。 これらの要件は一般的に法律に基づいていますが、文化的価値と規範に基づくこともできます。
データ所在地と主権の詳細については、「ホワイト ペーパー Microsoft Azure リージョンでのデータ所在地とデータ保護の有効化」を参照してください。
保存するデータへのテナントのアクセス
テナントは、ユーザーの代わりに保存するデータへの直接アクセスを要求する場合があります。 たとえば、独自のデータ レイクにデータを取り込むことができます。
これらの要求に応答する方法を計画します。 テナントのデータが共有データ ストアに保持されているかどうかを検討します。 その場合は、テナントが他のテナントのデータにアクセスしないようにする方法を計画します。
バレット キー パターンを使用するなど、この要件に合わせて設計した場合を除き、データベースまたはストレージ アカウントへの直接アクセスを提供しないでください。 統合のために API または自動データ エクスポート プロセスを作成することを検討してください。
テナントのシステムと外部システムとの統合の詳細については、「テナント統合とデータ アクセスのアーキテクチャアプローチ
テナントのデータへのアクセス
テナントの要件によって、データまたはリソースを操作できる担当者が制限されるかどうかを検討します。 たとえば、多くの異なる顧客が使用する SaaS ソリューションを構築するとします。 政府機関は、自分の国/地域の市民のみがソリューションのインフラストラクチャとデータへのアクセスを許可することを要求する場合があります。 機密性の高い顧客ワークロードに対して個別の Azure リソース グループ、サブスクリプション、または管理グループを使用することで、この要件を満たすことができます。 これらのリソースを操作する特定のユーザー グループに対して、厳密にスコープが設定された Azure ロールベースのアクセス制御 (RBAC) ロールの割り当てを適用できます。
複数のテナントからのデータの集計
複数のテナントのデータを結合または集計する必要があるかどうかを検討します。 たとえば、集計されたデータを分析するか、他のテナントに適用できる機械学習モデルをトレーニングしますか? テナントがデータを使用する方法を理解していることを確認します。 集計データまたは匿名化データの使用を含めます。
コンプライアンス要件
コンプライアンス標準を満たす必要があるかどうかを理解することが重要です。 コンプライアンス要件は、次のようないくつかの状況で導入される場合があります。
- お客様またはテナントは、特定の業界内で作業します。 たとえば、いずれかのテナントが医療業界で働いている場合は、HIPAA 標準に準拠する必要がある場合があります。
- お客様またはテナントは、地域の法律に準拠する必要がある地理的または地政学的なリージョンに配置されています。 たとえば、いずれかのテナントがヨーロッパにある場合は、一般データ保護規則 (GDPR)に準拠する必要があります。
- 侵害のリスクを軽減するために、サイバー保険ポリシーを購入します。 Cyberinsurance プロバイダーでは、標準に従い、ポリシーを有効にするために特定の制御を適用することが必要になる場合があります。
重要
コンプライアンスは、Microsoft、お客様、およびテナント間の共同責任です。
Microsoft は、Microsoft のサービスが特定のコンプライアンス標準のセットを満たしていることを確認し、リソースがこれらの標準に従って構成されていることを確認するのに役立つ microsoft Defender for Cloud
ただし、最終的には、ソリューションに適用されるコンプライアンス要件と、それらの標準に従って Azure リソースを構成する方法を完全に理解する必要があります。 詳細については、Azure コンプライアンス オファリング
この記事では、特定の標準に準拠する方法に関する具体的なガイダンスは提供しません。 代わりに、マルチテナント ソリューションでコンプライアンスとガバナンスを検討する方法に関する一般的なガイダンスを提供します。
異なるテナントが異なるコンプライアンス標準に従う必要がある場合は、環境全体で最も厳格な標準に準拠することを計画してください。 テナントごとに異なる標準に従うよりも、1 つの厳密な標準に一貫して従う方が簡単です。
考慮すべきアプローチとパターン
リソース タグ
リソース タグ を使用して、テナント固有のリソースのテナント識別子を追跡するか、デプロイ スタンプ パターンを使用してスケーリングするときにスタンプ識別子を追跡します。 リソース タグを使用すると、特定のテナントまたはスタンプに関連付けられているリソースをすばやく識別できます。
アクセス制御
Azure RBAC
Azure Resource Graph
Azure Resource Graph は、Azure リソース メタデータ を操作することを可能にします。 Resource Graph を使用すると、複数のサブスクリプションに分散している場合でも、多数の Azure リソースに対してクエリを実行できます。 Resource Graph では、特定の種類のリソースを照会したり、特定の方法で構成されているリソースを特定したりできます。 また、リソースの構成の履歴を追跡するためにも使用できます。
Resource Graph は、大規模な Azure 資産を管理するのに役立ちます。 たとえば、テナント固有の Azure リソースを複数の Azure サブスクリプションにデプロイするとします。 リソースにタグを適用すると、Resource Graph API を使って、特定のテナントまたはデプロイ スタンプに使われているリソースを見つけられるようになります。
Microsoft Purview
Microsoft Purview
標準への準拠を確認する
コンプライアンス ドキュメントを生成する
テナントでは、特定の標準への準拠を示す必要がある場合があります。 Service Trust Portal を使用して、テナントまたはサードパーティの監査者に提供できるコンプライアンス ドキュメントを生成します。
一部のマルチテナント ソリューションには Microsoft 365 が組み込まれており、Microsoft OneDrive、Microsoft SharePoint、Microsoft Exchange Online などのサービスを使用しています。 Microsoft Purview コンプライアンス ポータル は、これらのサービスが規制基準にどのように準拠しているかを理解するのに役立ちます。
デプロイ スタンプ パターン
テナント固有の要件に準拠する必要がある場合は、展開スタンプ パターン に従うことを検討してください。
たとえば、ソリューションのスタンプを複数の Azure リージョンにデプロイできます。 その後、データを配置する必要があるリージョンに基づいて、スタンプに新しいテナントを割り当てることができます。
同様に、新しいテナントでは、既存のソリューション コンポーネント内では満たされない厳密なコンプライアンス要件が導入される場合があります。 そのテナントの専用スタンプをデプロイし、要件に従って構成することを検討できます。
回避するアンチパターン
- テナントのコンプライアンス要件を理解していない。 テナントが課す可能性のあるコンプライアンス要件を想定しないことが重要です。 ソリューションを新しい市場に拡大する予定がある場合は、テナントが運用する可能性が高い規制環境に注意してください。
- 適切なプラクティスを無視する。 コンプライアンス標準にすぐに準拠する必要がない場合は、Azure リソースをデプロイするときに、引き続き適切なプラクティスに従う必要があります。 たとえば、リソースを分離し、ポリシーを適用してリソース構成を確認し、ユーザーではなくグループにロールの割り当てを適用します。 適切なプラクティスに従うことで、最終的に必要になったときにコンプライアンス標準に従うのが簡単になります。
- コンプライアンス要件がないと仮定します。 マルチテナント ソリューションを初めて起動するとき、コンプライアンス要件を認識していない場合や、それに従う必要がない場合があります。 成長するにつれて、さまざまな標準に準拠していることを示す証拠を提供する必要があります。 Microsoft Defender for Cloud を使用して、明示的な要件がなくても、 CIS Microsoft Foundations Benchmark などの一般的なベースラインに対してコンプライアンスの姿勢を監視します。
- 管理を計画していません。 Azure リソースをデプロイするときは、それらを管理する方法を検討してください。 リソースを一括更新する必要がある場合は、Azure CLI、Azure PowerShell、Azure Resource Graph、Azure Resource Manager API などの自動化ツールについて理解しておいてください。
- 管理グループを使用していません。 各スコープでのアクセス制御と Azure Policy リソースなど、サブスクリプションと管理グループの階層を計画します。 運用環境でリソースを使用する場合、これらの要素を導入または変更するのは困難で混乱を招く可能性があります。
- アクセス制御戦略を計画できない。 Azure RBAC は、リソースへのアクセスを管理する方法を高度に制御し、柔軟性を提供します。 個々のユーザーにアクセス許可を割り当てないように、Microsoft Entra グループを使用してください。 セキュリティと柔軟性の適切なバランスを提供するスコープでロールを割り当てます。 可能な限り組み込みのロール定義を使用し、必要な最小限のアクセス許可を提供するロールを割り当てます。
- Azure Policy を使用していません。 Azure Policy を使用して Azure 環境を管理することが重要です。 ポリシーを計画して展開したら、ポリシーコンプライアンスを監視し、違反や例外を慎重に確認してください。
貢献者
この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。
主要著者:
- ジョン ダウンズ |プリンシパル ソフトウェア エンジニア
その他の共同作成者:
- ボーダン・チェルチク |Azure 用 FastTrack のシニア カスタマー エンジニア
- ローラ・ニコラ |Azure 用 FastTrack のシニア カスタマー エンジニア
- アルセン ウラジミルスキー |プリンシパル カスタマー エンジニア、FastTrack for Azure
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次の手順
コストの管理と割り当てに関する手法のページを参照してください。