AWS で AccessDenied や is not authorized to perform と言われる。「権限は足したはずなのに、まだ拒否される」が定番のハマり方で、これは拒否にも種類があり、評価の仕組みを知らないと足し続けるだけになる。エラー文の読み方から整理する。
先に結論
- エラー文から「誰が・どのアクションを・どのリソースに」を先に抜き出す
- 明示的 Deny（Explicit Deny）があると、許可を足しても勝てない
- SCP / Permissions Boundary / セッションポリシーが天井になっていることがある
- S3・KMS はリソース側ポリシーも効く。クロスアカウントや KMS では、両側の許可が揃わないと通らない
- 裏取りは CloudTrail と IAM ポリシーシミュレータで行う
エラーメッセージの読み方
拒否メッセージには、必要な情報がだいたい全部入っている。代表例はこういう形。
An error occurred (AccessDenied) when calling the PutObject operation:
User: arn:aws:iam::123456789012:user/example
is not authorized to perform: s3:PutObject
on resource: "arn:aws:s3:::example-bucket/path/file.txt"
- User の ARN: 想定したユーザー / ロールで実行できているか。まず
aws sts get-caller-identity で「今の自分」を確認するのが先 - perform の後: 不足しているアクション名
- on resource の後: 対象リソース。バケット単位で足したつもりがオブジェクト ARN が必要、が定番のズレ
拒否の種類：暗黙的拒否と明示的拒否
- 暗黙的拒否: 許可ポリシーがどこにも無いので拒否。許可を足せば直る
- 明示的拒否: どこかのポリシーに Deny 文がある。許可をいくら足しても Deny が勝つので、Deny の出所を探すのが先
- ざっくりの評価順: 組織 SCP → リソースベースポリシー → Permissions Boundary → セッションポリシー → ID ベースポリシー
よくある落とし穴
- クロスアカウント: 別アカウントのリソースは、呼び出し側とリソース側の両方で許可が要る
- KMS: 暗号化された S3 / EBS などは、対象サービスへの許可に加えてキーポリシー（またはグラント）も必要
- 条件（Condition）: 送信元 IP、MFA 有無、組織 ID などの条件で Deny / 不許可になっている
- セッションの鮮度: 引き受けたロールや一時認証情報が期限切れ・別プロファイルを見ている
- 境界（Boundary）: ロールに境界が設定されていると、境界の範囲外は ID ポリシーで足しても通らない
裏取りの道具
- CloudTrail: 拒否された API 呼び出しもイベントとして残る。誰が・いつ・何を叩いて拒否されたかを確定できる
- IAM ポリシーシミュレータ: 対象プリンシパルとアクションを指定して、許可・拒否と効いたポリシーを事前に確認できる
- decode-authorization-message: エラーに暗号化メッセージが含まれる場合は、STS でデコードすると拒否理由の詳細が読める
- IAM Access Analyzer: 外部公開や想定外の許可の検出に。拒否の直接原因探しと合わせて棚卸しに使う
対処の進め方
- 不足アクションを1つずつ、対象リソースを絞って足す。ワイルドカード（*）で一気に開けない
- セッションポリシーは発行時点で固定される。条件を変えた場合は、新しいセッションを取り直して確認する
- 直った後は、足した許可が本当に必要だったか見直す。切り分け用に広げた許可を戻し忘れない
ざっくりまとめ
- まずエラー文の「誰が・何を・どこに」を読む。それが切り分けの半分
- Deny が勝っている型と、許可が無いだけの型を分ける
- 裏取りは CloudTrail とシミュレータ。推測でポリシーを足し続けない
関連記事