変更要約: AZ-120 第1章を新規作成(ドメイン1: ターゲット要件・サイジング(SAPS/HANA メモリ・SAP 認定 VM・サポートシナリオ・クォータ・ライセンス・コスト)・移行戦略(lift-and-shift/lift-shift-migrate/lift-shift-migrate to HANA・Azure Migrate)、Azure 環境(Azure RBAC・Entra ID 認証・Azure Policy ガバナンス・管理階層・SAP ランディングゾーン)、SAP RISE 統合(マネージド SaaS 型・VNet ピアリング/プライベートエンドポイント/ExpressRoute・データアーカイブ・Entra ID 統合))。
1.2Azure 環境とガバナンス
SAP ワークロード向けの認可とアクセス制御、Azure Policy によるガバナンス、認証、管理階層、SAP 向け Azure ランディングゾーンを理解します。
SAP の本番ランドスケープは規制・統制が厳しいため、Azure 側で アクセス制御・ガバナンス・標準化された基盤(ランディングゾーン) を設計します。
1.2.1アクセス制御とガバナンス
認可は Azure RBAC で最小権限を割り当て、認証は Microsoft Entra ID(SAP/SaaS アプリのシングルサインオン含む)で行います。ガバナンス/コンプライアンス は Azure Policy で、許可リージョン・必須タグ・暗号化必須・SKU 制限などを宣言的に強制します(RBAC が「誰が何をできるか」、Policy が「リソースがどうあるべきか」を担う点を区別)。
1.2.2管理階層とランディングゾーン
管理階層 は 管理グループ→サブスクリプション→リソースグループ で構成し、ポリシー/RBAC の継承境界を環境(本番/QA/開発)や課金に沿って設計します。SAP 向け Azure ランディングゾーン は、ネットワーク・ID・ガバナンス・監視を標準化したベースライン環境で、SAP ワークロードを一貫した統制下に迅速に展開できます。「組織全体に標準を継承させたい」=管理グループ+Policy、「SAP の本番基盤を標準化」=ランディングゾーン、が定石です。
決め手:「誰が何をできるか」=Azure RBAC。「リソースがどうあるべきか(リージョン/タグ/暗号化を強制)」=Azure Policy。「組織全体に継承」=管理グループ。「SAP 基盤を標準化して迅速展開」=Azure ランディングゾーン。認証は Entra ID(SSO)。
混同に注意:
①RBAC(権限委任)と Azure Policy(リソース制約)を取り違えない。
②管理グループ(継承境界)とリソースグループ(配置単位)は別。
③ランディングゾーンは標準化されたベースラインで、単なる 1 リソースグループではない。
④Policy は監査だけでなく拒否/修復も可能。
1.2.3この節のまとめ
- 認可=Azure RBAC(最小権限)、認証=Entra ID(SSO)、ガバナンス=Azure Policy(リソース制約強制)
- 管理階層=管理グループ→サブスクリプション→リソースグループで継承境界を設計
- SAP 向け Azure ランディングゾーンで基盤(NW/ID/ガバナンス/監視)を標準化
進捗の記録にはログインが必要です。
理解度チェック
(軽い確認用)Q1. SAP ワークロードのリソースに、許可リージョン・必須タグ・暗号化必須などの組織標準を宣言的に強制したい。最適なのはどれですか?
Q2. 管理者に SAP リソースグループの管理権限だけを最小権限で委任したい。最適なのはどれですか?
Q3. 組織全体のサブスクリプションにポリシーと権限を継承させる境界を設計したい。最適なのはどれですか?
Q4. SAP ワークロードの基盤(ネットワーク・ID・ガバナンス・監視)を標準化し、一貫した統制下で迅速に展開したい。最適なのはどれですか?
Q5. Azure RBAC と Azure Policy の違いとして正しいのはどれですか?

