マルチテナント ソリューションでのガバナンスとコンプライアンスのためのアーキテクチャ アプローチ

Azure の使用が成熟するにつれて、クラウド リソースのガバナンスを検討することが重要になります。 ガバナンスには、テナントのデータの格納と管理方法と、Azure リソースの整理方法が含まれます。 規制、法律、または契約上義務付けられている基準に従う必要がある場合もあります。 この記事では、マルチテナント ソリューションでガバナンスとコンプライアンスを検討する方法について説明します。 また、このような考慮事項をサポートする Azure プラットフォームの主要な機能をいくつか提案します。

主な考慮事項と要件

リソースの分離

テナントの分離要件を満たすように Azure リソースを確実に構成します。 Azure リソースを分離する方法のガイダンスについては、「マルチテナント ソリューションでの Azure リソースの編成」を参照してください。

データ管理

テナントに代わってデータを格納する場合、満たす必要のある要件や義務が存在することがあります。 テナントの観点からは、データの所有権と制御を期待されることがよくあります。 テナントのデータを分離、格納、アクセス、集計する方法を検討します。 ソリューションの動作に影響する可能性のあるテナントの期待と要件を明らかにします。

分離:

テナントのデータを分離する方法については、「マルチテナント ソリューションでのストレージとデータのアーキテクチャ アプローチ」を参照してください。 テナントが独自のデータ暗号化キーを使う要件があるかどうかを検討します。

どのような分離アプローチを実装する場合でも、テナントからデータの監査を要求されることを想定しておく必要があります。 テナントのデータを格納する可能性のあるすべてのデータ ストアを文書化することをお勧めします。 一般的なデータ ソースには、次のようなものがあります。

• ソリューションの一部としてデプロイされたデータベースとストレージ アカウント。
• テナント間で共有されることの多い ID システム。
• ログ:
• データ ウェアハウス。

主権

テナントのデータを格納または処理する物理的な場所に制限があるかどうかを把握します。 テナントから、特定の地理的な場所にデータを格納するように求められる場合があります。 また、特定の場所にデータを格納 "しない" ように求められる場合もあります。 これらの要件は一般に法律に基づいていますが、文化的な価値観や規範に基づいている場合もあります。

データ所在地と主権についての詳細については、ホワイトペーパー「Microsoft Azure リージョンでのデータ所在地とデータ保護の有効化」を参照してください。

テナントから格納データへのアクセス

テナントからは、代理で格納したデータに対する直接アクセスを要求されることがあります。 たとえば、独自のデータ レイクにデータを取り込む場合などです。

このような要求にどのように対応するかを計画します。 テナントのデータを共有データ ストアに格納するかどうかを検討します。 その場合は、テナントが他のテナントのデータにアクセスしないようにする方法を計画します。

バレー キー パターンを使うなどしてこの要件を満たすように設計しない場合は、データベースやストレージ アカウントへの直接アクセスを提供しないでください。 統合のために、API や自動化データ エクスポート プロセスを作成することを検討します。

テナントのシステムと外部システムとの統合について詳しくは、「テナント統合とデータ アクセスのアーキテクチャに関するアプローチ」をご覧ください。

テナントのデータへのアクセス

そのデータまたはリソースを操作できる担当者を制限するテナントの要件があるかどうかを検討します。 たとえば、さまざまな顧客が使う SaaS ソリューションを構築するとします。 ある政府機関から、その国/リージョンの国民のみがそのソリューションのインフラストラクチャとデータにアクセスできるように求められる場合があります。 このような場合、機密性の高い顧客のワークロードに対して、個別の Azure リソース グループ、サブスクリプション、または管理グループを使うことで、この要件を満たすことができます。 これらのリソースを操作する特定のグループのユーザーに対して、厳密にスコープを設定した Azure ロールベースのアクセス制御 (RBAC) ロールの割り当てを適用できます。

複数テナントのデータの集計

複数テナントのデータを組み合わせたり、集計したりする必要があるかどうかを検討します。 たとえば、集計したデータを分析しますか。また、他のテナントに適用可能な機械学習モデルをトレーニングしますか。 お客様がデータを使う方法を、お客様のテナントが理解していることを確認します。 集計データまたは匿名化されたデータの使用を含めます。

コンプライアンスの要件

コンプライアンス標準を満たす必要があるかどうかを理解することが重要です。 コンプライアンス要件は、次のような状況で取り入れることがあります。

• お客様、またはお客様のテナントのいずれかが、特定の業界内の業種です。 たとえば、いずれかのテナントが医療業界の業種である場合、場合によっては HIPAA 標準に準拠する必要があります。
• お客様、またはお客様のテナントのいずれかが、現地の法律を遵守する必要がある地理的および地政学的地域に位置しています。 たとえば、いずれかのテナントがヨーロッパに拠点を置いている場合、一般データ保護規則 (GDPR) への準拠が必要な可能性があります。
• サイバー保険ポリシーを購入して、侵害のリスクを軽減します。 サイバー保険プロバイダーは、ポリシーを有効にするために、基準に従い、特定の制御を適用することを求める場合があります。

重要

コンプライアンスの責任は、Microsoft、お客様、お客様のテナントの間で分担されます。

Microsoft は、Microsoft のサービスが特定のコンプライアンス標準を満たすことを保証します。また、お客様のリソースがこれらの標準に従って構成されていることを確認するために役立つ Microsoft Defender for Cloud などのツールを提供しています。

ただし、最終的には、お客様のソリューションに適用されるコンプライアンス要件とそれらの標準に従って Azure リソースを構成する方法を完全に理解することは、お客様の責任です。 詳細については、「Azure のコンプライアンス オファリング」を参照してください。

この記事は、特定の標準に準拠する方法について具体的なガイダンスを提供するものではありません。 そうではなく、マルチテナント ソリューションでコンプライアンスとガバナンスを考慮する方法に関する一般的なガイダンスを提供するものです。

テナントによって異なるコンプライアンス標準に準拠する必要がある場合は、環境全体で最も厳格な標準に準拠するように計画します。 テナントごとに異なる基準に従うよりも、1 つの厳格な基準に一貫して従う方が簡単です。

考慮すべきアプローチとパターン

リソース タグ

リソース タグを使って、テナント固有のリソースのテナント識別子、またはデプロイ スタンプ パターンを使ってスケールするときのスタンプ識別子を追跡します。 リソース タグを使用すると、特定のテナントまたはスタンプに関連付けられているリソースをすばやく識別できます。

アクセス制御

Azure RBAC を使って、マルチテナント ソリューションを構成する Azure リソースへのアクセスを制限します。 ユーザーではなくグループにロールの割り当てを適用するなど、RBAC のベスト プラクティスに従います。 必要最小限のアクセス許可を付与するように、ロールの割り当てのスコープを設定します。 Just-In-Time アクセスや Microsoft Entra ID Privileged Access Management のような機能を使って、リソースへの長期のアクセスを回避します。

Azure Resource Graph

Azure Resource Graph を使うと、Azure リソースのメタデータを操作できます。 Resource Graph を使うと、多数の Azure リソースが複数のサブスクリプションにまたがっている場合でも、横断的にクエリを実行できます。 Resource Graph を使って、特定の種類のリソースに対してクエリを実行することや、特定の方法で構成されたリソースを特定することができます。 また、リソースの構成履歴を追跡するためにも使用できます。

Resource Graph は、大規模な Azure 資産を管理するのに役立ちます。 たとえば、複数の Azure サブスクリプションにまたがるテナント固有の Azure リソースをデプロイする場合があります。 リソースにタグを適用すると、Resource Graph API を使って、特定のテナントまたはデプロイ スタンプに使われているリソースを見つけられるようになります。

Microsoft Purview

保存するデータを追跡および分類するには、 Microsoft Purview の使用を検討してください。 テナントからデータへのアクセスが要求されたときに、含めるべきデータ ソースを簡単に判断できます。

標準への準拠を確認する

Azure Policy、Microsoft Defender for Cloud の規制遵守ポータル、Azure Advisor などのツールを使います。 これらのツールを使うと、コンプライアンス要件を満たし、推奨されるベスト プラクティスに従うように Azure リソースを構成することができます。

コンプライアンス ドキュメントを生成する

テナントから、特定の標準に準拠していることを証明するように求められる場合があります。 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 によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• John Downs | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

• Bohdan Cherchyk | FastTrack for Azure のシニア カスタマー エンジニア
• Laura Nicolas | FastTrack for Azure のシニア カスタマー エンジニア
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

コストの管理と割り当てに関する手法のページを参照してください。