1.3ガバナンスによるセキュリティとコンプライアンスの強制

個々のリソースを手作業で守るだけでは、規模が大きくなると抜け漏れが生じます。ガバナンス は「組織全体に共通のルールを定義し、自動で強制し、準拠状況を継続的に評価する」仕組みです。SC-500 では、ルールの強制に Azure Policy、態勢の評価に Microsoft Defender for Cloud、権限の最小化に Azure RBAC、誤操作の防止に リソースロック、復旧の保護に Azure Backup、そして再現性のある実装に IaC を用います。

1.3.1Azure Policy—制御の強制（組み込み／カスタム）

Azure Policy は、リソースが満たすべき条件をポリシー定義として表し、作成・更新時に評価して効果（effect）を適用します。代表的な効果は Deny（条件違反の作成を拒否）、Audit（違反を記録するが許可）、DeployIfNotExists（不足する設定を自動デプロイ＝修復）、Modify（タグ等を自動付与）です。複数の定義を束ねたものが イニシアチブ（ポリシーセット） で、規制要件のまとまりを一括適用できます。例：「パブリック IP を持つストレージを拒否」「診断設定がなければ自動で追加」。これは予防的（preventive）統制の中心です。

1.3.2Defender for Cloud—態勢評価とコンプライアンス

Microsoft Defender for Cloud は、環境のセキュリティ態勢を継続評価する CSPM の中心です。セキュリティ標準（security standards） として Microsoft Cloud Security Benchmark などを適用し、違反は 推奨事項（recommendations） として提示、全体の健全度は セキュアスコア（Secure Score） で数値化されます。規制コンプライアンス（regulatory compliance） ダッシュボードでは、PCI DSS・ISO 27001 などの規制フレームワークへの準拠状況を可視化します。Azure Policy が「強制」なら、Defender for Cloud は「評価・可視化・改善提案」の役割です（内部的に多くの推奨事項は Policy で実装されます）。

1.3.3RBAC—ロール管理と過剰特権の是正

Azure RBAC は「どの ID（誰）に・どのスコープ（管理グループ/サブスク/RG/リソース）で・どのロール（何ができる）を割り当てるか」で認可を表します。まず 組み込みロール（Reader・Contributor・Owner や各サービス固有ロール）で要件を満たせないか確認し、足りなければ カスタムロール を最小権限で定義します。運用で陥りがちな 過剰特権（over-privileged） は、Entra のアクセスレビュー、Defender for Cloud の推奨事項、PIM の適格化で棚卸し・是正します。Owner や User Access Administrator のような権限を委譲できるロールの乱用に特に注意します。

1.3.4リソースロック・Azure Backup・IaC

• リソースロック：CanNotDelete（削除禁止・変更可）と ReadOnly（変更・削除禁止）。重要リソースの誤削除/誤変更を防ぐ。RBAC とは独立に効く。
• Azure Backup のセキュリティ：論理削除（soft delete）・不変コンテナー/不変ストレージ・Multi-User Authorization（MUA） により、ランサムウェアや内部不正によるバックアップの破壊を防ぐ。
• IaC によるセキュリティ制御：Bicep/ARM/Terraform でセキュリティ設定をコード化し、レビュー・再現・横展開を可能にする。What-If/プレビューで適用前に差分を確認。

1.3.5この節のまとめ

• Azure Policy＝予防/強制（Deny/Audit/DeployIfNotExists/Modify・イニシアチブで束ねる）
• Defender for Cloud＝態勢評価（標準/推奨/セキュアスコア）＋規制コンプライアンスの可視化
• RBAC＝最小特権（組み込み→カスタム）。過剰特権はアクセスレビュー/PIM/推奨で是正
• リソースロック（CanNotDelete/ReadOnly）・Azure Backup（不変/MUA）・IaC で誤操作防止と再現性を確保