こんにちは、アイレットの日下です。

AWSを運用していて、「管理者権限（AdministratorAccess）を付けているのに、なぜか操作が弾かれる」という謎現象に頭を抱えました。

実は、IAMを「ただのログイン管理」だと思っていると、このAccess Deniedの謎から抜け出せません。

今回は、私が実務を通じて学んだ「IAMの本当の正体」と、どのように権限管理を行うのか、そのポイントを整理しました。

1. IAMの正体は「APIリクエストのたびに動く門番」

IAMは、ログインした時だけチェックをしているわけではありません。 コンソールでボタンを押した瞬間、CLIでコマンドを打った瞬間、あるいはLambdaがS3にアクセスした瞬間。すべてのAPIリクエストが発生するたびに、毎回「この操作を許可していいか？」を裁いています。

ここで重要なのが、IAMには「鉄の掟」があることです。

  • 「ダメ」と言われたら絶対ダメ（Deny優先）： どこか1箇所でも明示的な「Deny（拒否）」があれば、どれだけ「Allow（許可）」を積んでも即座にリクエストは叩き潰されます。
  • 「枠」からはみ出たらアウト： SCPやPermissions Boundaryといった「権限の上限」が決まっている場合、その枠の外にある操作はすべて拒否されます。

[開始]
↓
1. 明示的な Deny（拒否）はあるか？
├─ YES ────→ 【 拒否 (Access Denied) 】
└─ NO ──【2へ】
↓
2. 明示的な Allow（許可）はあるか？
├─ YES ─→ 【 許可 (Allow) 】
└─ NO ─→ 【 デフォルト拒否 (Default Deny) 】

2. 「誰か」ではなく「どんな条件か」で認可を制御する

最近の設計では、IAMユーザー（アクセスキー）を直接使うのは避けるべきであり、一時的な認証情報である「IAMロール」を使いこなすことが推奨されています。

さらに一歩進むなら、Condition（条件）の活用です。 「このIPアドレスからか？」「MFAを通しているか？」「正しいタグが付いているか？」といった属性で権限を切り替える（ABAC）ことで、ガチガチに固定されない柔軟な運用が可能になります。

3. 「権限の重なり」の読み解き方

「権限はあるはずなのに失敗する」とき、以下の4点を疑います。

  • SCP（ガードレール）： Organizationsを使っている場合、アカウント全体にブレーキがかかっていることがあります。一方、管理アカウントの場合はSCPが効かないです。
  • Permissions Boundary（境界）： 「他人にユーザーを作らせるが、自分より強くはさせない」という檻のような設定です。境界と権限ポリシーの共通部分しか有効になりません。
  • リソースポリシー： S3やKMSなど、リソース側にも「誰に許可するか」の定義があります。同一アカウントなら「どちらかに許可があればOK」ですが、クロスアカウントなら「両方の許可」が必須です。
  • Trust Policy（信頼関係）： そもそも「そのロールになっていいか」の握手が成立していないと、AssumeRoleすらできません。

4. 最小権限は「人間が考える」のをやめる

「最小権限（Least Privilege）」が大事なのは分かっていますが、何百もあるAPIアクションから必要なものだけを手書きで選ぶのは、正直しんどい作業です。 そこで登場するのが、IAM Access Analyzer です。

IAM Access Analyzer とは？

一言で言えば、「設定が安全かどうかを、チェック・補助してくれる機能」です。 大きく分けて2つの強力な機能を持っています。

  • 外部露出のスキャン： リソースが意図せずパブリック公開やクロスアカウントアクセスを許していないかを常時監視します。
  • ポリシー生成： 過去の「事実（ログ）」に基づいて、理想的なポリシーを自動で書き起こしてくれます。

なぜ「ロール」から作成するのか

かつてはIAM Policy Simulatorを使って、「手作業でシミュレーターで試す」のが主流でしたが、IAM Access Analyzerは「実際に使ったログ（CloudTrail）からポリシーを生成させる」ことができます。

特定の「ロール」を選択して分析にかけることで、そのロールが過去90日以内に実行したAPIアクションを Analyzer が精査します。 そのため「想像で作るポリシー」ではなく、「実際に必要とした権限」だけを抽出できるため、最も安全かつ確実に最小権限を実現できるのです。

実践：CloudTrail からポリシーを生成する

作成は非常にシンプルです。対象のIAMロールの詳細画面から「ポリシーを生成」を選択します。

CloudTrailの証跡と分析期間（添付画像では直近6日間）を指定するだけで、Analyzerが裏側でログの棚卸しを開始します。

しばらく待つと、以下のようなポリシーが作成されます。

生成されたポリシーを見ると、S3の権限だけでなく cloudtrail:GetTrail などが含まれています。これは IAM Access Analyzer がログを分析する過程で必要とした権限もセットで構成されているためです。

肝心の S3 権限に注目すると、アクションだけでなくリソース（バケット名）までピンポイントで絞り込まれています。これこそが、過去のログという事実に基づいた最小権限の作り方です。

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “cloudtrail:GetTrail”,
“Resource”: “*”
},
{
“Effect”: “Allow”,
“Action”: [
“iam:GenerateServiceLastAccessedDetails”,
“iam:GetServiceLastAccessedDetails”
],
“Resource”: “*”
},
{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”: [
“arn:aws:s3:::example-app-bucket”,
“arn:aws:s3:::example-app-bucket/*”
]
}
]
}

まとめ：IAMは「育てていく」もの

今回お伝えしたかったのは、IAMは一度設定して終わりではなく、実際の運用に合わせて研ぎ澄ませていくものだということです。

「Access Denied」はエラーではなく、設計を見直すためのヒントです。最新の評価ロジックとIAM Access Analyzerを使いこなして、安全でスムーズなAWS環境を構築していきましょう