ログインしたからといって権限が生まれるわけではない

一言でいうと

認証(authentication)は「誰か」、認可(authorization)は「何ができるか」です。クラウドはこの2つを完全に分離しているので、ログインに成功しても何もできない状態が正常です。

なぜ必要なのか

401と403を区別できないと、デバッグが2倍長くかかります。

レスポンス	意味	直す場所
401 Unauthorized	誰なのかわからない	資格情報・トークン・署名
403 Forbidden	誰なのかは知っているが、許可されない	ポリシー・権限

名前が紛らわしく付けられています。401が実は認証の失敗で、403が認可の失敗です。クラウドAPIでAccessDeniedを受け取ったら、それは403系で、資格情報は正常だという意味です。キーを再発行しても無駄です。

どう動くのか

プリンシパル(principal)の種類

権限は「人」にだけ付くわけではありません。

プリンシパル	例	特徴
ユーザー(user)	担当者のアカウント	長期の資格情報。人がログインします
グループ(group)	`developers`	ユーザーのまとまり。権限をまとめます
ロール(role)	`ec2-app-role`	誰でも引き受けられます。一時的な資格情報
サービス	Lambda関数、EC2インスタンス	ロールを引き受けて動作します
外部のアイデンティティ	Google・GitHubのOIDC	フェデレーションでロールを引き受けます

ここでロールが核心的な概念です。人ではなく「権限のまとまり」で、条件を満たすプリンシパルが一時的に借りて使います。あとのモジュールで詳しく扱います。

評価順序: 明示的な拒否が勝つ

複数のポリシーが1つのプリンシパルに付いているとき、結果は次のように決まります。

1. 명시적 Deny 가 하나라도 있으면      → 거부  (무엇도 이를 뒤집지 못한다)
2. 명시적 Allow 가 하나라도 있으면     → 허용
3. 아무것도 없으면                     → 거부  (기본 거부)

2つが重要です。

デフォルトは拒否です。権限は足したときにだけ生まれます。安全な既定値です。
Denyが絶対に優先されます。管理者権限があっても、組織レベルのDenyが1つあれば塞がれます。ガードレールを作る方法が、これです。

ポリシーが付く2つの場所

同じ結果を、2つの方向から作れます。

アイデンティティベース(identity-based): プリンシパルに付けます。「この人はあのバケットを読める」
リソースベース(resource-based): リソースに付けます。「このバケットはあの人が読める」

アカウントの中では、普通はアイデンティティベースだけを使います。アカウントをまたぐと、両方が必要です。他のアカウントのプリンシパルが自分のバケットを読むには、向こうのアイデンティティポリシーに許可があり、こちらのバケットポリシーにも許可がある必要があります。クロスアカウントのアクセスがよく失敗する理由です。

現場での姿

AccessDeniedを受けて、キーを再発行した → 認可の問題なので、何の効果もありませんでした。
管理者なのに特定の操作だけが塞がれる → 上位の組織ポリシーのDenyです。
クロスアカウントのアクセスができない → 片側にだけ許可を入れていました。

拒否されたときに何を見るか

AccessDeniedを受けたときに、どこでも手当たり次第に調べずに済むよう、確認の順序を決めておく必要があります。クラウドで1つのリクエストが許可されるまでに、通過しなければならない関門が複数あるからです。

自分は今、誰なのか。思っているプリンシパルで合っているか、まず確認します。インスタンスで動くコードは、たいてい付いているロールで動作しますが、人は自分の個人の資格情報で試して、「通りますけど」と言います。現在のプリンシパルを出力するコマンドは、どのクラウドにもあるので、まずそれを出力します。
どの関門で塞がれたか。組織レベルのポリシー、アイデンティティポリシー、リソースポリシー、そして一時的な資格情報を発行するときに絞っておいた範囲。このうち1つでも許可しなければ、拒否です。
アクション名とリソース名が正確か。ポリシーに書いたアクション名のタイプミスは、エラーを出さず、ただ合わないルールになります。リソースの表記も同じで、バケット自体とその中のオブジェクトは別のリソースなので、両方が必要な場合がよくあります。
条件が付いていないか。送信元IP、時刻、タグ、多要素認証かどうかのような条件が付いていると、普段は通るのに、特定の状況でだけ塞がれます。「昨日は通ったのに」という報告の相当な数が、ここから出ます。

そして、判定を推測せず、ツールに尋ねる習慣が重要です。主要なクラウドは、「このプリンシパルが、このアクションを、このリソースに対してできるか」を実際に評価してくれる機能を提供していて、どのポリシーが決定を下したかまで教えてくれます。ポリシー文書を目で読んで推論するより、何倍も速く、人が見落としやすい上位の組織ポリシーまで含めて答えてくれます。

最後に、ログを見ます。拒否されたリクエストは監査ログに残り、そこにはプリンシパル・アクション・リソース・時刻がすべて入っています。開発者が口頭で伝えた症状よりも、この1行のほうがはるかに正確なので、調査の出発点は常にこの記録であるべきです。

次に見ること

そのポリシー文書が実際にどう書かれているかを、1行ずつ分解してみます。