Microsoft AZ-900: ガバナンスとコンプライアンス — 学習ガイド

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure AZ-900 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

Azureにおけるガバナンスは、階層化された一連の統制を通じて、クラウドの利用をビジネス、セキュリティ、規制の要件に整合させます。これには、組織構造、ポリシー、標準化されたデプロイ、偶発的な変更からの保護、継続的な監査などが含まれます。これらの機能は、Azure Resource Managerのコントロールプレーンでネイティブに動作し、単一のサブスクリプションから大規模なマルチテナント環境までスケールします。優れたガバナンスは、ドリフトを削減し、一貫性を強制し、開発者のベロシティを妨げることなくコンプライアンスの証拠を提供します。コンプライアンスは、強力なインベントリと変更履歴に依存します。Azureは、サブスクリプションを横断したリソースのほぼリアルタイムの可視性、規範的な規制マッピング、機密情報を特定・分類するためのデータ検出機能を提供します。その結果、標準が一度定義されれば、自動的に適用され、継続的に証明され、大規模に修正される、防御可能なクラウドポスチャが実現します。

Azure Policy: 定義、イニシアチブ、場所の制御、修復

Azure Policyは、リソースの作成/更新時（およびその後も定期的に）にリソース構成を評価し、望ましい状態を強制するガードレールを定義します。ポリシー定義は、条件と効果を使用して、リソースプロバイダーによって公開されるリソースプロパティを評価します。主要な効果には、Deny、Audit、Append、Modify、DeployIfNotExists、AuditIfNotExists、Disabledがあります。ポリシーは、管理グループ、サブスクリプション、リソースグループ、またはリソースのスコープで割り当てることができ、継承により、notScopesで除外されない限り、より広範な割り当てが下位に適用されます。イニシアチブは、関連するポリシー定義を単一のパッケージにグループ化し、一貫性のある再現可能な割り当てのためのパラメーターを持たせます。例えば、セキュリティベースラインのイニシアチブには、診断設定の要求、パブリックエンドポイントの制限、タグ付けの強制、バックアップ欠落の監査といったポリシーを含めることができます。イニシアチブを割り当てると、含まれるすべてのポリシーが1つのアクションで適用され、単一のコンプライアンスビューが生成されます。組み込みポリシーである「許可された場所 (Allowed locations)」は、リソースグループとリソースを作成できる場所を制限し、承認されていないリージョンへのデプロイを防ぎ、データ所在地と主権の確保に役立ちます。作成リクエストが禁止されたリージョンを対象とした場合、Deny効果がリソースプロバイダーに到達する前に操作をブロックし、厳格なコンプライアンスを保証します。ドリフトが検出されると、修復タスクによってリソースが大規模にコンプライアンス準拠の状態に戻されます。DeployIfNotExistsおよびModifyポリシーの場合、ポリシー割り当てのマネージドIDを使用して、非準拠のリソースを再構成します（例えば、ストレージアカウントで診断設定を有効にしたり、必須タグを追加したりします）。修復ジョブは、スコープを絞って実行することも、サブスクリプション全体で実行することもでき、コンプライアンスの結果は監査追跡のためにポリシーごと、リソースごとに表示されます。

• 目的
  • ポリシー定義: リソースプロパティを評価する単一のルール
  • イニシアチブ (ポリシーセット): 共通のパラメーターを持つポリシー定義のバンドル
  • 割り当てスコープ: 管理グループ、サブスクリプション、リソースグループ、またはリソース
  • 一般的な効果: Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists
  • 修復の要件: 割り当てにマネージドIDが必要。Modify/DeployIfNotExistsに適用可能
• ユースケース
  • ポリシー定義: SKU、TLS、タグ、プライベートエンドポイントの強制
  • イニシアチブ (ポリシーセット): セキュリティまたはガバナンスのベースラインを適用
  • 割り当てスコープ: 継承と除外を利用した広範な強制
  • 一般的な効果: 強制的な適用または証拠のみの監査
  • 修復の要件: ターゲットリソースを変更するのに十分な権限

Azure Blueprints: ポリシー、RBAC、リソースグループ、テンプレートによる標準のパッケージ化

Azure Blueprintsは、組織がコンプライアンスに準拠した環境を一貫して展開（スタンプ）できるように、ガバナンスのアーティファクトをパッケージ化します。ブループリント定義には、ポリシー割り当て、Azureロールベースのアクセス制御（RBAC）割り当て、リソースグループ定義、および標準インフラをプロビジョニングするためのARMテンプレート（Bicepを含む）などのデプロイアーティファクトを含めることができます。パラメーターにより、単一のバージョン管理された信頼できる情報源（source of truth）を維持しながら、割り当てごとにカスタマイズが可能です。Blueprintsは、「何が存在すべきか、誰が何を行えるか」をワークロードのコードから分離するのに役立ちます。例えば、ベースラインのブループリントは、スポークリソースグループを作成し、監査チームにReaderロールを、プラットフォームチームにContributorロールを割り当て、ハブ＆スポークネットワークテンプレートをデプロイし、診断とセキュリティのためのイニシアチブを割り当てることができます。ブループリントを1つ以上のサブスクリプションに割り当てると、すべてのアーティファクトが正しい順序で適用され、コンプライアンス状態が記録されます。バージョン管理により制御された更新が可能になり、アーティファクトのロックによってデプロイ後の重要なコンポーネントを保護できます。

• 主な焦点
  • Azure Policy: 構成とコンプライアンスのガードレール
  • ARM/Bicep テンプレート: 宣言的なリソースデプロイ
  • Azure Blueprints: サブスクリプションを横断する標準のパッケージ化と統制
• RBACを含むか
  • Azure Policy: いいえ（別途割り当て）
  • ARM/Bicep テンプレート: いいえ（別途割り当て）
  • Azure Blueprints: はい（アーティファクトとしてロール割り当てを含む）
• ポリシーを含むか
  • Azure Policy: N/A
  • ARM/Bicep テンプレート: いいえ（ポリシーリソースのデプロイは可能だが、割り当ては不可）
  • Azure Blueprints: はい（アーティファクトとしてポリシー割り当てを含む）
• リソースグループを作成するか
  • Azure Policy: 命名/タグを要求/強制できる
  • ARM/Bicep テンプレート: ネストされたデプロイを介してデプロイ先として、または作成可能
  • Azure Blueprints: はい（ブループリントの一部としてRGアーティファクトを定義）
• 一般的な用途
  • Azure Policy: SKUの制限、診断、タグの強制
  • ARM/Bicep テンプレート: VNet、Key Vault、App Serviceのプロビジョニング
  • Azure Blueprints: ポリシー + RBAC + インフラを備えたコンプライアンス準拠のランディングゾーンを展開

組織と標準: 管理グループ、サブスクリプション、リソースグループ、名前付けとタグ

Azureの管理階層により、ガバナンスのスケーリングが可能になります。管理グループはサブスクリプションの上に位置し、すべての子サブスクリプションに継承されるポリシーとRBACを適用する場所を提供します。サブスクリプションは、課金、サービス クォータ、およびほとんどのコントロールのセキュリティ境界を定義します。リソースグループは、ライフサイクル、アクセス許可、デプロイロジックが連携したリソースを保持します。各リソースは、厳密に1つのリソースグループと1つのサブスクリプションに属します。名前付けとタグ付けの標準は、ガバナンスの意図を運用上の明確さに変換します。名前には、サービス制限内でリソースタイプの略語、ワークロード、環境、リージョンをエンコードする必要があります（例: kv-payroll-prod-eus2）。タグは、コスト配分、所有権、データ分類、自動化キーのために、リソース全体にビジネスコンテキストを追加します（例: costCenter=FIN、owner=ops-team@contoso.com、dataSensitivity=Confidential）。Modify および Append 効果を持つ Azure Policy は、タグの存在と値のパターンを強制し、リソースグループからリソースへタグを継承させることができます。ここでの一貫性が、信頼性の高いコストレポート、アクセスレビュー、ライフサイクル自動化を推進します。

• 管理グループ
  • 目的: 複数のサブスクリプションにまたがる大規模なガバナンス
  • 一般的な用途: ビジネスユニットや環境へのポリシー、RBAC、イニシアチブの適用
  • 格納できるもの: 子の管理グループとサブスクリプション
  • 重要な注意点: 最大6階層の深さ（ルートを除く）。継承は下位に流れる
• サブスクリプション
  • 目的: 課金とサービスの境界
  • 一般的な用途: ワークロードの分離、コストの分離、クォータ管理
  • 格納できるもの: リソースグループとリソース
  • 重要な注意点: ここでのポリシー/RBACの割り当ては、含まれるすべてのリソースグループに影響する
• リソースグループ
  • 目的: リソースのライフサイクルとアクセス許可の境界
  • 一般的な用途: 関連リソースの同時デプロイ、更新、削除
  • 格納できるもの: リソース
  • 重要な注意点: リソースは1つのRGにしか存在できない。RG/サブスクリプション間の移動にはサービス固有の制約がある

リソースロックと偶発的な削除の防止

リソースロックは、意図しない変更に対する最後の防衛線を提供します。ロックは、サブスクリプション、リソースグループ、またはリソースのスコープで適用され、下位に継承されます。ロックには2つの種類があります:CanNotDeleteは削除を防ぎますが読み取りと書き込み操作を許可し、ReadOnlyはすべての書き込みと削除操作を制限します（事実上、読み取り操作のみを許可します）。ロックは、ポータル、CLI、PowerShell、ARM/Bicep、およびサードパーティのIaCツールからのアクションに対して保護します。共有または重要なインフラストラクチャ（仮想ネットワーク、ルートテーブル、DNSゾーン、本番環境のKey Vaultsなど）にはCanNotDeleteを使用し、削除をブロックしながらメンテナンスを継続できるようにします。ReadOnlyは、アーカイブされたストレージアカウントや規制上の証拠コンテナなど、完全に静的でなければならないアーティファクトに限定して使用してください。多くのサービスは通常の運用に書き込みを必要とし、ReadOnlyの下では失敗します。十分なアクセス許可を持つプリンシパル（例: Microsoft.Authorization/locks/* を持つ所有者）のみがロックを解除でき、ロックの解除自体がアクティビティログで監査可能な操作です。

• CanNotDelete
  • 読み取り: 許可
  • 書き込み/更新: 許可
  • 削除: ブロック
  • 典型的なユースケース: VNet、ルートテーブル、本番Key Vaults、重要なRGの保護
  • 考慮事項: 構成変更は許可される。ロックが解除されるまで削除操作は失敗する
• ReadOnly
  • 読み取り: 許可
  • 書き込み/更新: ブロック
  • 削除: ブロック
  • 典型的なユースケース: 証拠ストア、アーカイブストレージ、不変の構成の保持
  • 考慮事項: 多くのサービスはReadOnly下では機能しない。更新とスケーリングはブロックされる

監査、インベントリ、規制コンプライアンス: Resource Graph、Activity Log、Defender for Cloud、Microsoft Purview

Azure Resource Graphは、Kustoクエリ言語（KQL）を使用して、サブスクリプションや管理グループ全体で高速かつ大規模なインベントリとポスチャのクエリを提供します。これにより、どのストレージアカウントに暗号化が欠けているか、どのVNetがパブリックIPを公開しているか、どのリソースがポリシーに準拠していないかといった問いに答えることができます。結果はダッシュボード、CMDB同期、修復パイプラインに供給されます。Resource Graphは、Cost Managementデータと組み合わせることで、ポリシーコンプライアンスの状態、タグの分布、コスト配賦のディメンションを明らかにすることもできます。Azure Activity Logは、リソースに対するコントロールプレーン操作を記録します。これには、誰が、何を、いつ行ったかが含まれ、デフォルトで90日間保持されます。長期保存、相関分析、SIEMへの取り込みのために、Activity LogをLog Analytics、Azure Storage、またはEvent Hubsに転送します。変更履歴分析は、構成のドリフトを特定し、インシデント対応をサポートし、監査の証拠を提供します。Microsoft Defender for Cloudは、評価をAzure Security Benchmark、ISO/IEC 27001、NIST SP 800-53、PCI DSS、CISなどの標準にマッピングすることで、技術的なポスチャを規制のビューに変換します。規制コンプライアンスダッシュボードには、合格/不合格のコントロール、影響を受けるリソース、修復ガイダンスが表示されます。自動プロビジョニングを有効にすると、必要な場所にエージェントとポリシーが統合され、セキュアスコアが優先順位付けの指標を提供します。Microsoft Purviewは、Azure、マルチクラウド、オンプレミスのソースにまたがるデータを検出し、分類し、カタログ化します。スキャンにより、Azure Storage、SQL、Synapse、Power BIなどの多くの場所にある機密データ（例：財務、PII、健康）を特定し、組み込みまたはカスタムの分類子を適用します。Purviewデータマップとカタログは、系列（リネージ）、所有権、秘密度ラベル付けを提供し、これらはMicrosoft Information Protectionと統合されます。これにより、規制上の義務に沿ったデータ損失防止とアクセスポリシーの決定が可能になります。

• 主な機能
  • Azure Resource Graph: 大規模なインベントリとポスチャのクエリ
  • Activity Log: コントロールプレーン操作の監査証跡
  • Defender for Cloud (規制): ポスチャを標準にマッピングし、修正の優先順位を決定
  • Microsoft Purview: データの検出、分類、カタログ化、系列 (リネージ)
• スコープ
  • Azure Resource Graph: MG/サブスクリプション横断
  • Activity Log: テナントごと、LA/Storage/Event Hubへのルーティングあり
  • Defender for Cloud (規制): サブスクリプション/テナントごと、イニシアチブの割り当てあり
  • Microsoft Purview: データソース横断 (Azure, M365, オンプレミス, マルチクラウド)
• 典型的な出力
  • Azure Resource Graph: KQLクエリ結果、ダッシュボード、エクスポート
  • Activity Log: 誰が/何を/いつ、ステータス、エラーコード
  • Defender for Cloud (規制): コントロールのコンプライアンス状況、セキュアスコア、推奨事項
  • Microsoft Purview: データ資産、秘密度ラベル、スキーマ、系列 (リネージ) グラフ

実践的な問題: Fabrikam Retail Groupにおけるコンプライアンスに準拠したランディングゾーンの標準化

シナリオ: Fabrikam Retail Groupは、北米とEUで事業を展開しており、厳格なデータレジデンシーとPCI DSSの義務を負っています。複数のアプリケーションチームが毎月ワークロードをデプロイしていますが、これまでのアドホックなデプロイにより、タグ付けの不整合、承認されていないリージョンでのリソース作成、共有ネットワークの偶発的な削除などが発生していました。経営陣は、標準化されコンプライアンスに準拠したランディングゾーン、統制の有効性に関する継続的な証拠、そしてストレージおよび分析プラットフォーム全体にわたる機密データの検出を要求しています。

課題: リージョン制限を強制し、ポリシーとRBACでデプロイを標準化し、コアインフラストラクチャの偶発的な削除を防ぎ、インベントリと変更履歴を維持し、ISO 27001とPCI DSSに対するレポートを作成し、機密データを検出・分類するAzureガバナンスアプローチを設計・実装すること。

推奨アプローチ:

1. 管理グループ階層を作成します: ルートに/Fabrikam、その子として/Corp (共有サービス)、/NA、/EUを配置し、それぞれの配下に/Prodと/NonProdを追加します。サブスクリプションを適切な管理グループに移動します。
2. 管理グループレベルでポリシーイニシアチブを作成します: (a) 地域ごとの許可された場所、(b) 必須タグ (costCenter, owner, dataSensitivity) をModify/Appendで設定、(c) コアサービスに対するLog Analyticsへの診断設定の強制、(d) PaaSサービスに対するSKUおよびパブリックネットワークの制限。これらのイニシアチブを、リージョンに応じたパラメータを設定して/NAと/EUに割り当て、notScopesを使用してブレークグラス用のサブスクリプションを除外します。
3. 標準ランディングゾーンのブループリントをパッケージ化します: アーティファクトには、ハブおよびアプリケーションのリソースグループの作成、RBACの割り当て (プラットフォームチームにNetwork Contributor、監査にReader)、診断とタグに関するポリシー割り当て、そしてvNET、ピアリング、Key Vault、Log AnalyticsをデプロイするためのARMテンプレートが含まれます。ブループリントをバージョン管理し、すべてのProdおよびNonProdサブスクリプションに割り当てます。
4. リソースロックを適用します: ハブのVNet、ルートテーブル、共有DNSゾーン、Log AnalyticsワークスペースにCanNotDeleteを適用し、規制準拠のエクスポート用のアーカイブストレージアカウントにReadOnlyを適用します。共有サービスサブスクリプションのOwnerが、計画的な変更時に自身の承認を得てロックを解除できることを検証します。
5. すべてのサブスクリプションからのActivity Logのエクスポートを有効にし、中央のLog Analyticsワークスペースに送信し、不変（時間ベース）の7年間のリテンションポリシーが設定されたストレージアカウントにアーカイブします。非準拠リソース、不足しているタグ、リージョンおよびdataSensitivityタグ別のアセットを一覧表示するResource Graphダッシュボードを構築します。
6. テナント全体でMicrosoft Defender for Cloudを有効にします。規制標準としてISO/IEC 27001とPCI DSSを選択し、自動プロビジョニングをオンにして、推奨事項を確認します。重要度の高い検出結果から作業項目を作成し、サブスクリプションごとのセキュアスコアの向上を追跡します。
7. /Corp共有サービスサブスクリプションにMicrosoft Purviewをデプロイします。データソースとしてAzure SQL、Storage、Synapse、Power BIを登録します。組み込みの機密情報の種類を使用して、スケジュールされたスキャンを構成し、データセットを分類します。データカタログを公開し、データ所有者を割り当てます。検出された秘密度ラベルをエクスポートして、条件付きアクセスとDLPに情報を提供します。

Azureの論理的根拠: このアプローチは、まず管理グループのスコープ設定から始め、ポリシーとRBACが予測どおりに継承されるようにします。次に、Azure Policyとイニシアチブでコアな統制を強制し、デプロイ時のコンプライアンス違反を防止します。ブループリントは、ポリシー、RBAC、リソースグループ、インフラストラクチャテンプレートをパッケージ化し、リージョンや環境ごとのパラメータ化を可能にしながら、一貫したランディングゾーンを展開します。リソースロックは、適切な場合には日々の構成を妨げることなく、重要な共有サービスを偶発的な削除から保護します。一元化されたActivity Logの保持とResource Graphは、信頼性の高いインベントリと変更の証拠を提供します。Defender for Cloudは、ライブの規制統制マップと優先順位付けされた修復策を提供し、一方、Microsoft Purviewは機密データを検出・分類して、Fabrikamの分析環境全体でPCI DSSとデータレジデンシーの統制をサポートします。

← コスト管理とサービスの経済性 · すべてのドメイン · 監視、自動化、管理 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →