T1-Q17: S3 ABACはAllowだけでは足りない。条件なしAllowを明示的Denyで潰す

対象誤答: T1 Q17 S3 ABAC EXPLICIT DENY

あなたの選択と正答

観点	内容
あなたの選択	バケットポリシーは同じトラストゾーン内のプリンシパルには適用されない、という方向に解釈した。
正答	プリンシパルのIAMアイデンティティベースポリシーが条件なしでS3 PutObjectを許可している場合、条件付きAllowだけでは制限できない。明示的Denyが必要。
誤答の引力	リソースポリシーの条件付きAllowで十分だと思っている。別のアイデンティティポリシーが条件なしAllowを持つと、Denyなしでは抜け道が残る。
判断軸	S3制御で『必ずこの条件を満たせ』を作るなら、満たさない場合のExplicit Denyを設計する。

この問題の芯

T1-Q17 は S3 の ABAC/タグ条件/PutObject 制御の問題。あなたは「同じトラストゾーンならバケットポリシーが効かない」方向に寄った。正しくは、条件付きAllowだけでは、別のIAMアイデンティティポリシーによる条件なしAllowを潰せない。必要なのは明示的Deny。

IAM評価の基本に戻す

AWSの認可では、どこかに明示的Denyがあれば必ず拒否される。一方、Allowは複数のポリシーから合成される。S3バケットポリシーで「タグが一致したらAllow」を書いても、同じプリンシパルに条件なしの s3:PutObject Allow が付いていれば、条件を満たさないPutObjectが別経路で許可される可能性がある。

強制したい条件はDenyで書く

タグが一致しないPutObjectを確実に止めたいなら、こういう考え方になる。

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:RequestObjectTag/Team": "${aws:PrincipalTag/Team}"
    }
  }
}

これは「Teamタグが一致しないPutObjectは、他にAllowがあっても拒否」という設計。

次回の秒殺ルール

「条件を満たしたら許可」ではなく「条件を満たさないなら必ず拒否」が必要な問題では、Explicit Denyを探す。
S3、KMS、VPC endpoint policy、SCPの問題ではこの差がそのまま正誤になる。

仕上げの一問一答