1.2認可制御とリソース階層

認証の次は認可＝誰が何をできるかです。最小権限を、リソース階層・条件・拒否ポリシー・特権の時間制限で実現します。

1.2.1IAM と最小権限の認可

アクセスは IAM で付与します。基本ロールを避け 事前定義/カスタムロール を使い、職務分掌（separation of duties）で強すぎる単一者を作らないようにします。権限は グループ にまとめて付与し、属性で絞る IAM 条件（時間/IP/リソース）と、明示的に禁止する IAM 拒否ポリシー を併用します。アクセスの境界（誰がどこから）を Access Context Manager（アクセスレベル）で定義し、過剰権限の発見・推奨は Policy Intelligence（IAM Recommender 等）で行います。常時の高権限を避けるには Privileged Access Manager（PAM）で必要時のみ昇格・自動失効させます。「明示的に禁止＝IAM 拒否ポリシー」「条件付き許可＝IAM 条件」「一時的な特権昇格＝Privileged Access Manager」を結びます。

1.2.2リソース階層と組織ポリシー

アクセス制御は リソース階層（組織→フォルダ→プロジェクト→リソース）に沿って設計し、IAM と制約を 継承 させます。大規模では フォルダ/プロジェクト を環境/チーム/事業単位で整理します。全社一貫のガードレールは 組織ポリシー（事前ビルド の制約や カスタム組織ポリシー）で階層継承して強制します（例：外部 IP 禁止、特定リージョン限定）。「許可＝IAM」「制約の強制＝組織ポリシー」は別レイヤーで、両方を組み合わせて最小権限とガードレールを実現します。

1.2.3この節のまとめ

• IAM は事前定義/カスタム＋グループ付与、条件で絞り拒否ポリシーで禁止、職務分掌を守る
• 常時高権限を避け Privileged Access Manager で時間制限昇格、過剰権限は Policy Intelligence で縮小
• リソース階層で継承、全社ガードレールは組織ポリシー（事前ビルド/カスタム）