Azure での SaaS ワークロードのガバナンス
ガバナンスは、クラウド サービスの使用を整理、制御し、規制に合わせるために使用できる一連のコントロール、プラクティス、ツールです。 ガバナンスは、受け入れ可能な使用基準を設定し、承認されていないアクセスと変更を防ぎ、クラウド アクティビティをクラウド戦略全体と整合させる一連のガードレールと考えることができます。 効果的なガバナンスを設けることで、リスクが軽減され、コンプライアンスが確保され、組織のビジネス目標がサポートされます。 サービスとしてのソフトウェア (SaaS) ソリューションを構築するときは、開始時からガバナンスを優先することが極めて重要です。 この方法によって、セキュリティで保護され、コスト効率が高く、効率的なソリューションの基礎が築かれます。
コスト ガバナンス
ビジネスの成功を確実にするには、ソリューションを実行するためのコストを把握するのが肝要です。 これらのコストを効率的に分析、管理、最適化しながら、それらのコストを制御する必要があります。 Azure でソリューションの構築を開始すると、料金計算ツールやコスト アナライザーなどのツールを使用してコストを見積もることができます。
SaaS のコストを追跡および制御する方法と顧客への課金方法の詳細については、「Azure での SaaS ワークロードの課金とコスト管理」を参照してください。
設計上の考慮事項
名前付け規則とタグ付け戦略を策定します。 名前とタグは、リソースを管理し、所有権をすばやく決定するために使用できるメタデータを提供します。 リソースの名前付けに一貫性を持たせると、Azure リソースの管理と管理に役立ちます。 Azure リソース タグは、リソースに適用し、それらを識別するために使用するメタデータ キーと値のペアです。
メタデータを使用して、次のような情報を追跡することを検討します。
- リソースの種類。
- 関連付けられているワークロード。
- 運用環境、ステージング環境、開発環境など、使用される環境。
- リソースの場所。
- 顧客固有のデプロイのためにリソースを使用する顧客または顧客のグループ。
リソースの名前付け戦略については、クラウド導入フレームワーク: リソースの名前付けに関する記事を参照してください。
ポリシーを使用して自動化されたガバナンスを実装します。 ポリシーは、組織の標準を定義し、ワークロードとリソースのコンプライアンスを評価するうえで重要です。 これは、リソースの一貫性、規制コンプライアンス、セキュリティ、管理、コスト効率を実現するために使用できるガバナンス ツールです。
Azure Policy を使用して、ワークロードの要件に合わせてカスタマイズされた、許可されたサービスとサービスの種類のサービス カタログを作成します。 このカタログは、承認されたサービスのみが使用されるようにすることで、誤って過剰な支出が発生するのを防げます。 たとえば、必要な仮想マシン (VM) の種類、シリーズ、サイズを決定したら、それらの VM のデプロイのみを許可するポリシーを実装できます。 ポリシーは、ユーザーやプリンシパルのアクセス許可レベルに関係なく、すべてのユーザーとプリンシパルに一様に適用します。
トレードオフ: セキュリティと運用効率。ポリシーを多く実装しすぎると、チームの生産性が低下する可能性があります。 最も重要な要素に対する自動制御の実装に努めます。コスト管理ツールを使用します。 Microsoft Cost Management には、コスト ガバナンスをサポートするための次のような複数のツールが用意されています。
コスト分析は、クラウド支出に関する分析と分析情報にアクセスするために使用できるツールです。 これらのコストは、さまざまな高機能でカスタマイズ可能なビューを通じて確認できます。 これらのビューでは、リソース グループ、サービス、サブスクリプション別のコストなどの詳細な分析情報が示されます。 コスト分析を使用すると、累積コストと日単位のコストを分析し、請求書の詳細を確認できます。
Cost Management の予算は、Azure 内のさまざまな範囲で支出ガードレールとアラートを確立するために使用できるツールです。 予算アラートは、支出実績または予測支出に基づいて構成できます。 管理グループ、サブスクリプション、リソース グループなど、さまざまなレベルで予算を割り当てることもできます。
コストのアラートは、3 種類のアラートを使用してクラウド支出を監視するのに役立ちます。
予算アラートは、予算のしきい値に達したとき、または間もなく予測のしきい値に達するときに、受信者に通知します。
異常アラートは、クラウド支出に予期しない変更が発生したときに、受信者に通知します。
スケジュールされたアラートは、クラウド全体の支出に関する毎日、毎週、または毎月のレポートを受信者に送信します。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| Cost Management を有効にします。 このツールは、Azure portal 内で、課金アカウント、サブスクリプション、リソース グループ、または管理グループにアクセスできるすべてのユーザーが利用できます。 |
Microsoft Cloud での支出を分析、監視、最適化するツールにアクセスできます。 |
| Azure Policy を作成して、許可されたリソースの種類や場所などのコスト管理を適用します。 | この戦略は、一貫した標準を適用し、デプロイできるリソースを制御し、リソースとクラウド支出のコンプライアンスを追跡するのに役立ちます。 |
| 適切なコスト アラートを有効にします。 | コスト アラートでは、予期しないクラウド支出や定義済みの制限に近づいたときに通知を受けられます。 |
| 一貫性のある名前付け規則とリソース タグを使用します。 Azure リソース タグを適用して、特定の顧客専用のリソースを示します。 | メタデータに一貫性を持たせると、どのリソースがどの顧客に属するかを追跡するのに役立ちます。 この方法は、顧客専用のリソースをデプロイする場合に特に重要です。 |
セキュリティとコンプライアンス
セキュリティとコンプライアンスは、クラウド ワークロードの基礎となる設計原則であり、適切なクラウド ガバナンスの重要な構成要素です。 セキュリティ制御 (ロールベースのアクセス制御など) は、ユーザーが環境内で実行できるアクションを決定するのに役立ちます。 ポリシーによる制御は、デプロイされたワークロードの特定の規制コンプライアンス標準を達成するのに役立ちます。
詳細については、「Azure のロールベースのアクセス制御 (RBAC)」と「Azure Policy」を参照してください。
SaaS ソリューションを開発する場合、顧客のデータを保護し、ビジネス運用をサポートするうえで、顧客はソリューションの提供者に依存します。 SaaS ソリューションを顧客に代わって運用するには、顧客のセキュリティの期待を満たすか超える必要があります。 また、顧客によって課される特定のコンプライアンス要件を満たす必要がある場合もあります。 この要件は、医療や金融サービスなどの規制対象の業界の顧客や、多くの大企業の顧客に共通します。
設計上の考慮事項
Microsoft Entra テナントを定義します。 Microsoft Entra テナントは、Azure リソースを管理できる ID の境界を定義します。 ほとんどの組織の場合、すべてのリソースで 1 つの Microsoft Entra テナントを使用するのが適しています。 SaaS を構築する場合、ニーズに応じて Microsoft Entra テナントを結合または分離するために使用できるさまざまな方法があります。
SaaS を使用するかどうかを決定するときは、次の異なる 3 種類のユース ケースを考慮することが重要です。
"内部 SaaS" ("エンタープライズ" または "企業" と呼ばれることもあります) は、Microsoft 365 や自分で使用するその他のツールなど、自分の組織のリソースをホストする場合を指します。
"運用 SaaS" は、顧客が接続して使用する SaaS ソリューションのための Azure リソースをホストする場合です。
"非運用環境 SaaS" は、開発、テスト、ステージング環境など、SaaS ソリューションの非運用環境用に Azure リソースをホストする場合です。
ほとんどの独立系ソフトウェア ベンダー (ISV) は、前の一覧のすべての目的で 1 つの Microsoft Entra テナントを使用します。
場合によっては、複数の Microsoft Entra テナント間で目的の一部を分離するための、特定の業務上の正当な理由がある場合があります。 たとえば、セキュリティ レベルの高い政府機関の顧客を扱う場合、顧客の要件として、内部アプリケーション用、運用環境用、非運用環境用の SaaS ワークロードに個別のディレクトリを使用する場合があります。 このような要件は一般的ではありません。
重要
複数の Microsoft Entra テナントを管理するのは、困難な場合があります。 複数のテナントを管理すると、管理オーバーヘッドとコストが増加します。 慎重に対応しないと、複数のテナントのために、セキュリティ リスクが高まる可能性があります。 どうしても必要な場合にのみ、複数の Microsoft Entra テナントを使用します。
SaaS のデプロイ時に Microsoft Entra テナントを構成する方法の詳細については、「Azure ランディング ゾーンの ISV に関する考慮事項」を参照してください。
ID を管理します。 ID は、アクセス管理の基盤を形成する、クラウド セキュリティの土台です。 SaaS を開発するときは、さまざまな種類の ID を考慮する必要があります。 SaaS ソリューションでの ID の詳細については、「Azure での SaaS ワークロードの ID およびアクセス管理」を参照してください。
Azure リソースへのアクセスを制御します。 Azure リソースは、ソリューションの重要な構成要素です。 Azure には、リソースを保護するための複数の方法が用意されています。
Azure RBAC は、Azure コントロール プレーンと環境内のリソースへのアクセスを制御する承認システムです。 Azure RBAC は、Azure リソースに対して実行できるアクションを決定する定義済みロールとカスタム ロールのコレクションです。 ロールは、特権管理者ロールおよび職務権限ロールとして分類されます。 これらのロールは、定義したスコープ内のリソース セットに対して実行できる操作を制限します。 Azure RBAC は、ワークロードを管理するすべてのユーザーに最低特権アクセスを付与できます。
Azure のロックは、Azure リソースが誤って削除または変更されることの防止に役立ちます。 リソースにロックを適用すると、特権管理者ロールを持つユーザーであっても、最初に明示的にロックを削除しない限り、リソースを削除することはできません。
トレードオフ: セキュリティと運用効率。RBAC とロックは、クラウドのセキュリティとガバナンス戦略の重要な要素です。 ただし、一般的な操作を実行できるユーザーを厳しく制限すると、運用上の複雑さが生じる可能性があることを考慮してください。 セキュリティと機能のニーズのバランスが取れるように調整します。 緊急時や主要なメンバーが対応できない場合は、責任をエスカレーションする明確な計画を立てます。規制標準に準拠します。 顧客の多くが、特定のコンプライアンス規制を満たすために、リソースを厳密に制御する手段を必要とします。 Azure には、組織がコンプライアンスのニーズを満たすソリューションを Azure で構築するのに役立つ複数のツールが用意されています。
Azure Policy は、組織の標準を定義し、ワークロードとリソースのコンプライアンスを評価して適用するのに役立ちます。 定義済みの標準または独自のカスタム コンプライアンス標準を実装できます。 Azure Policy には、一般的な規制標準のために組み込みのポリシー イニシアチブまたはポリシーのグループが多数用意されています。 これらのポリシーには、FedRAMP High、HIPAA、HITRUST、PCI DSS、ISO 27001 が含まれます。 ポリシーを環境に適用すると、コンプライアンス ダッシュボードにコンプライアンス全体の詳細スコアが表示されます。 このダッシュボードは、環境を標準にするための修復計画を作成するときに使用できます。 Azure Policy を使用して以下ができます。
ポリシーで定義されている条件に基づいて、リソースのデプロイを拒否します。 たとえば、データ所在地の要件に違反する Azure リージョンに、データ リソースがデプロイされることを防止できます。
リソースのデプロイまたは構成を監査して、コンプライアンス標準を満たす構成でデプロイされているかどうかを判断します。 たとえば、VM を監査して、バックアップが構成されていることを確認し、構成されていない VM を一覧表示できます。
リソースのデプロイを修復します。 拡張機能をデプロイするか、新規または既存のリソースの構成を変更することで、標準に準拠していないリソースを修復するポリシーを構成できます。 たとえば、修復タスクを使用して、Microsoft Defender for Endpoint を VM に自動的にデプロイできます。
Microsoft Defender for Cloud では、サブスクリプションに適用する標準とベンチマークでのコンプライアンス制御とベスト プラクティスに照らし合わせて、リソースの構成を継続的に評価します。 Defender for Cloud では、全体的なコンプライアンス スコアが計算されます。これは、変更を加える必要がある点を判断するのに役立ちます。
Defender for Cloud の既定では、セキュリティとコンプライアンスベースのプラクティスのベースライン標準として、Microsoft クラウド セキュリティ ベンチマーク (MCSB) が使用されます。 MCSB は、Microsoft が提供する一連のコンプライアンス制御であり、Azure 上のほとんどのワークロードに推奨されます。 別の標準を満たす必要がある場合は、他の利用可能なコンプライアンス オファリングを使用できます。
ヒント
規制標準にすぐに準拠する必要がない場合であっても、いずれにせよ標準に従う必要があります。 ソリューションのデプロイを開始したときから MCSB のような標準に準拠しておくのが、後で過去にさかのぼって適用するよりも、はるかに簡単です。
コンプライアンス標準は、さまざまなスコープに適用できます。 たとえば、特定の標準のスコープとして、特定の Azure サブスクリプションを定義できます。 Defender for Cloud を使用して、他のクラウド プロバイダーでホストされているリソースの構成を評価することもできます。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| ユーザーとグループが職務権限を完了するために必要な最小限のアクセス権を付与します。 特権ロールの割り当ての数を制限します。 特権管理者ロールではなく、職務権限固有のロールを使用できるかどうかを判断します。 |
資格情報が侵害された場合は、露出を減らすことができます。 |
| Azure サブスクリプション所有者の数を制限します。 | サブスクリプション所有者が多すぎると、資格情報が侵害されるリスクが高まります。 |
| ロールは、ユーザーでなく、グループに割り当てます。 | この方法では、必要なロールの割り当ての数が減り、管理オーバーヘッドが削減されます。 |
| 設計プロセスの早い段階で、セキュリティ ベースラインを採用します。 MCSB を出発点と考えてください。 MCSB は、Azure および他のクラウドやオンプレミスの環境全体にわたり、アプリケーションのセキュリティを向上させるための明確で実用的なアドバイスを提供します。 | MCSB は、クラウド固有の制御に重点を置くことで、全体的なセキュリティ態勢を強化するのに役立ちます。 |
| Azure のロックを使用して、環境が誤って変更されるのを防ぎます。 | ロックは、リソース、リソース グループ、サブスクリプションの誤った変更や削除を防ぐのに役立ちます。 |
| Azure Policy または Defender for Cloud を使用してコンプライアンスを評価します。 | ポリシーは、組織の標準を適用し、規制コンプライアンスを満たすのに役立ちます。 |
その他のリソース
マルチテナントは、SaaS ワークロードを設計するための主要なビジネス手法です。 これらの記事では、ガバナンスに関する考慮事項について、より詳しく説明します。
次のステップ
リソースに適した Azure リージョンを選択し、SaaS ソリューションの成長と進化をサポートするリソース組織戦略を開発する方法について説明します。