IAM — ポリシー評価の「なぜ」を語る

なぜIAMが試験の20%を占めるのか

IAM。試験の配点は20%。全6ドメインで最大。ここを落としたら受からない。

IAMポリシーは書ける。Allow書いて、Resource指定して、動いた。それはできる。でもC03が聞いてくるのはそこじゃない。ポリシーが3つも4つも重なったとき、最終的にアクセスできるのか、できないのか。ここが問われる。

金融機関のセキュリティチームにいるとしよう。営業のAさんが「S3の顧客データにアクセスしたい」と言ってきた。マネージャーが権限をあげた。でも経営層がOrganizations全体に「このバケットは誰も触るな」と指示を出している。Aさんはアクセスできるか。できない。明示的Denyが最強で、何があっても覆らない。

評価エンジン — デフォルトDenyと明示的Denyの絶対性

AWSのポリシー評価の出発点は、全部Deny。何も書かなければ何もできない状態。これがデフォルトDeny。AWSのセキュリティ哲学の根幹。

何かやりたいなら明示的にAllowを書く。書かなければ動かない。

実装してしばらくして「このユーザーに削除権限まであるのはマズい」と気づいたら、明示的Denyを書く。「Allowを消せばいい」は間違い。来月、別のマネージャーが同じAllowを書くかもしれないから。

優先順位は3つ。明示的Denyが最強で1つでもあれば終わり。複数のAllowはORで合成される。どこにもAllowがなければデフォルトDeny。

複数ポリシーの足し算は、気づかないうちに意図しない権限を生む。3つのポリシーが合成されて営業担当がEC2を削除できるようになっていた、という事故は現場でよくある。

Permission Boundary — 天井の仕組み

大企業で部門マネージャーに権限管理を委譲するとき、経営層は「超えてはいけない上限」を設定したい。それがPermission Boundary。天井を引く仕組み。

Boundaryは「許可」ではなく「制限」。天井を設定しているだけで、その中が自動的に許可されるわけではない。

営業部マネージャーが部下にS3とDynamoDBのフルアクセスをあげた。でも経営層がBoundaryで「営業部はS3だけ」と設定してある。部下はDynamoDBに触れない。天井が効いている。

逆に、BoundaryでS3もDynamoDBもOKにしても、実ポリシーでAllowを書かなければ何もできない。数学で言うとANDの関係。Boundaryと実ポリシーの共通部分だけが実際の権限。ベン図の重なるところだけ。

SCP — 組織の最高法規

Permission Boundaryは個人の天井。SCPはアカウント全体の天井。Organizations全体に効く超強力な制御。

設計には2つの戦略がある。Allow list方式は「許可したものだけ使える」。厳格だが管理が大変。Deny list方式は「禁止したもの以外は使える」。柔軟で管理しやすく、こちらが主流。

超重要な例外として、管理アカウントにはSCPは効かない。自分で自分を制限したら何もできなくなるから。試験で「SCPが効かないアカウントは」と聞かれたら、管理アカウント。日常的には使わず、重大な操作のときだけ使うのがベストプラクティス。

クロスアカウント — 握手の両手

AアカウントのユーザーがBアカウントのリソースにアクセスするには、2つの条件が両方そろう必要がある。Bが「Aを信頼する」と宣言する信頼ポリシー。Aのユーザーに「Bにアクセスしていい」という権限ポリシー。握手と同じで、両手がそろって初めて成立する。

Confused Deputy問題にも注意。信頼された第三者を経由して、本来アクセスできない人がアクセスする攻撃パターン。対策はExternalId。AssumeRoleするときに合言葉を要求する仕組み。

RBAC vs ABAC — スケールの壁

RBACはロールで権限を分ける。小さい組織なら十分。だが成長すると、営業新人ロール、営業部長ロール、営業部長Aプロジェクトロールとロールが爆発する。347個のロールを管理するのは地獄。

ABACはタグで制御する。department=sales、level=seniorというタグを付けて、ポリシーで属性を条件にする。新しい人が入ったらタグを付けるだけ。成長企業ではABACが適切なケースが多い。

フェデレーション — IAMユーザーを作らない世界

大企業がActive Directoryで何千人を管理しているとき、全員分のIAMユーザーを作るのは二重管理。フェデレーションを使えば、AWSにIAMユーザーを作らずに外部の認証基盤からログインできる。

IAM Identity Center（旧SSO）が主流。Organizations全体でシングルサインオン。Permission Setsで権限を管理する。エンタープライズでの最適解は個別IAMユーザーではなく、フェデレーションと一時認証情報。

落とし穴と試験直前チェック

S3のリソースARNでarn:aws:s3:::my-bucketだけだとメタデータ操作しかできない。オブジェクトの読み書きにはarn:aws:s3:::my-bucket/*も必要。

Permission Boundaryを設定しても実ポリシーのAllowがなければ何もできない。ANDの関係を忘れない。

クロスアカウントは信頼ポリシーと権限ポリシーの両方が必要。片方だけでは動かない。

全体の評価フロー。リクエストが来たらデフォルトDeny。SCPチェック。リソースベースポリシー。Permission Boundary。Identity-basedポリシー。セッションポリシー。どこかにDenyがあれば即拒否。全部通過して初めてAllow。