【AWS中級へのステップ】IAM ユーザーの権限を最小化するための３ステップ
はじめに
猫とアポロチョコとSystems Managerが好きな m.hayakawa です。
本記事は、AWS サービスの基本設計には慣れてきたものの、「この構成で問題ないのか」「より良い設計方法はないのか」といった実務的な課題に直面している方向けの内容となります。
AWS 初学者が中級者へとステップアップするために押さえておきたい実践的な知識や TIPS のひとつを紹介し、初学者の方が知識をより深めるため、またベテランの方が知識を再確認するための一助となることを目指しています。
IAM ユーザーの最小権限の原則
突然ですが、IAM ユーザーの最小権限は意識できていますか。
IAM ユーザーやロールの権限が広いと、アクセスキーが漏れた場合に大きな被害につながります。だからこそ、権限はできるだけ絞っておきたいところです。
とはいえ、開発中はとりあえず広めの権限で進めて、あとで絞ろう、と考えることもあるでしょう。しかし、その「あとで絞る」はつい後回しになりがちです。気づけば広い権限のまま本番環境で使われていた、なんてこともあるかもしれません。
いざ権限を絞ろうとすると、そのアプリケーションが本当に必要としているアクションを正確に洗い出すのは、意外と大変です。手作業だとどうしても抜け漏れが出てきます。絞りすぎればアプリケーションが動かなくなりますし、緩いままではリスクが残ってしまいます。
前知識: 3 つの機能とその制約
こうした権限の絞り込みに使える AWS の機能として、本記事では次の 3 つを扱います。
- IAM の「最終アクセス日時」
- 付与済みの権限のうち、使っていないサービスやアクションの利用状況を確認する
- IAM Access Analyzer のポリシー生成
- CloudTrail の操作ログから、実際に使われたアクションだけを含むポリシーの叩き台を自動生成する
- Amazon Athena による CloudTrail ログの直接クエリ
- ポリシー生成では扱えないデータイベントやリソースを特定する
これらは参照するデータソースや分析対象が異なり、単体では最小権限を詰めきれません。まずはその違いを整理します。
目的とデータソースの違い
まず、各機能が「何のための機能か」と「どこを参照するか」を整理します。
| 機能 | 主な目的 | データソース | 分析期間 |
|---|---|---|---|
| 最終アクセス日時 | 使っていないサービス・アクションを削る棚卸し | IAM 独自の追跡 | サービスレベルは最大 400 日 |
| IAM Access Analyzer ポリシー生成 | 使ったアクションからポリシーを組み立てる | CloudTrail 証跡 + サービス最終アクセス情報 | 最大 90 日 |
| Athena による CloudTrail ログの直接クエリ | データイベントとリソースを特定する | CloudTrail 証跡（S3 バケット内のログ） | 証跡の保持期間に依存 |
「最終アクセス日時」は付与済みの権限から使っていないものを絞り込む機能、「ポリシー生成」は使ったアクションからポリシーを生成する機能です。分析期間も異なり、ポリシー生成は最大 90 日、最終アクセス日時のサービスレベルは最大 400 日です。そのため、90 日を超えて使われていないサービスも、最終アクセス日時では確認できる場合があります。
特定できる粒度の違い
次に、各機能が「どこまで細かく特定できるか」を整理します。
| 機能 | データイベント（データプレーン） | リソースレベルの特定 |
|---|---|---|
| 最終アクセス日時（サービスレベル） | 管理イベント・データイベントを含む | 不可（サービス単位） |
| 最終アクセス日時（アクションレベル） | 管理イベントのみ | 不可（リソース ARN は対象外） |
| IAM Access Analyzer ポリシー生成 | 対象外（管理イベントを対象） | 制約あり |
| Athena による CloudTrail ログの直接クエリ | 証跡でデータイベントを記録していれば対象 | 可（resources を参照） |
最終アクセス日時には、サービスレベルとアクションレベルの2種類があります。サービスレベルは、管理イベントとデータイベントを含む API アクセスをサービス単位で追跡します。そのため、S3 のデータイベントも「S3 を使った」という実績としては確認できます。
ただし、アクションレベルはサービス管理アクションが対象で、データイベントには対応していません。そのため、S3 を使ったことは分かっても、GetObject や PutObject といったアクション単位や、対象オブジェクトの ARN までは特定できません。
IAM Access Analyzer のポリシー生成は、管理イベントを基にアクション単位のポリシーを作ります。ただし、生成された Resource がそのまま最終形になるとは限りません。リソースを絞れるかはアクションの仕様次第です。AWS サービス認可リファレンス で確認して、リソースを絞れるかを確認しましょう。
この差により、ポリシー生成では「イベントなし」なのに、サービスレベルの最終アクセス日時では S3 が表示されるという食い違いが起きることがあります。データイベントのアクションと ARN まで確認したい場合は、CloudTrail ログを Athena で直接クエリします。
このように、削れる粒度は「サービス単位 → アクション単位 → データイベント・リソース単位」と段階的に細かくなります。本記事では、粒度の大きい順に3つを組み合わせて絞り込みます。
前提
登場するリソースは下記とします。
- 権限を絞りたい対象の IAM ユーザー X
- IAM ユーザー X の操作を記録した CloudTrail 証跡（管理イベントおよびデータイベントを記録）
- 証跡ログの保存先 S3 バケット
- Athena によるクエリを行うための環境
ステップ1. 最終アクセス日時で使っていないサービスを棚卸しする
すでに運用中の IAM ユーザーに広めの権限が付与されている場合、まず粒度の大きいところから削っていきます。ここで有効なのが IAM の「最終アクセス日時」です。
IAM マネジメントコンソールで対象ユーザーの「最終アクセス日時」タブを開くと、「許可されるサービス」の一覧が表示され、サービスごとの「最終アクセス日時」を確認できます。長期間アクセスされていないサービスは、そのユーザーの業務では使われていない可能性が高く、権限から削る候補になります。
なお、このステップはあくまで「サービス単位」の棚卸しです。より細かいアクション単位で確認したい場合は、サービス名を押下することで、そのサービス内のアクション単位での最終アクセス日時を確認できます。
ただし、アクションレベルの最終アクセス情報はデータプレーンイベントには対応していません。公式ドキュメントには次のように記載されています。
アクションの最終アクセス情報は、いかなるデータプレーンイベントについても利用できません。
そのため、S3 の GetObject などのデータイベントは、アクションレベルでは表示されません。一方、サービスレベルはアクセス試行を対象とするため、拒否されたリクエストも記録されます。
サービスの最終アクセスデータには、成功したアクセス試行だけでなく、AWS API へのアクセス試行がすべて含まれます。
このステップで「そもそも使っていないサービス」を落としたうえで、残ったサービスについてアクション単位の権限を詰めていきます。
ステップ2. IAM Access Analyzer のポリシー生成でアクション単位の叩き台を作る
ステップ1 で残したサービスに対して、次は実際に使われたアクションだけを含むポリシーの叩き台を作ります。ここで IAM Access Analyzer のポリシー生成を使います。この機能は、CloudTrail の操作ログを分析し、管理イベント（コントロールプレーン）ベースのポリシーを自動生成します。手順やサービスの詳細は下記の記事が詳しいため、ここでは要点のみ整理します。
大まかな流れは次のとおりです。
- CloudTrail 証跡を有効化する（ポリシー生成には証跡が必要）
- 対象の IAM ユーザーまたはロールの「アクセス許可」タブから「ポリシーを生成」を開始する
- 分析期間（最大 90 日）・CloudTrail アクセス用のサービスロール・分析対象の証跡を指定して生成を待つ
- 生成されたポリシーのリソース ARN プレースホルダーを実際の ARN に置き換える（リソースレベル権限に対応しないアクションは
*のままにする） - マネージドポリシーを作成して対象のユーザーまたはロールにアタッチし、動作を確認する
これにより、最終アクセス日時よりも細かい「アクション単位」の叩き台が作れます。ただし、この叩き台は管理イベントに基づくものです。公式ドキュメントには、データイベントは分析対象に含まれないと記載されています。
データイベントは利用不可 - IAM Access Analyzer は、生成するポリシーにおいて、Amazon S3 のデータイベントなどのデータイベントについてはアクションレベルのアクティビティを識別しません。
そのため、S3 の GetObject / PutObject のようなデータイベントは含まれません。対象の IAM ユーザーがデータイベント操作のみを行っていた場合、生成結果に「サービスとアクションは見つかりませんでした」と表示されることがあります。また、iam:PassRole も CloudTrail で追跡されないため含まれません。データイベントを使う IAM ユーザーの場合、次のステップが必要になります。
ステップ3. Athena で CloudTrail ログを直接クエリしてデータイベントとリソースを詰める
ステップ2 のポリシー生成でカバーできないデータイベント、およびリソースレベルの特定は、CloudTrail 証跡のログを Athena で直接クエリすることで補います。前提として、対象の証跡でデータイベントの記録が有効になっている必要があります。
詳細な方法については下記のブログにて紹介をしておりますため、本記事では割愛します。
細部を詰めるための注意点
3 つのステップで実務上必要な水準までは権限を絞り込めますが、いくつか注意点があります。
- ポリシー生成の分析対象は過去 90 日で、
iam:PassRoleは含まれない - データイベントは、証跡で記録を有効にしていなければ後から追えない。
- 対象アクションがデータイベントに該当する場合は、記録を有効化してから対象の操作を実行し、ログを残しておく
- 記録には追加のコストが想定されるため、期間を限定する運用も検討する必要がある
- 「最小権限」の解釈には幅があるため、どのレベルまでリソースを絞るか、ワイルドカードをどこまで許容するかといった方針をプロジェクト内で統一しておく
修正後は、対象の操作を再実行して権限の過不足を必ず検証してください。
補足: 開発段階でポリシーの叩き台を作るアプローチ
ここまで紹介した 3 つのステップは、いずれも「すでに付与された権限を、運用後のログや利用実績から絞り込む」アプローチでした。一方で、そもそも権限が強すぎる状態を作らないために、開発の段階でポリシーの叩き台を用意しておくアプローチもあります。
IAM Policy Autopilot は、アプリケーションのソースコードを静的解析し、SDK 呼び出しからアイデンティティベースの IAM ポリシーを生成するオープンソースツールです。運用ログではなくコードを解析するため、運用を開始する前に叩き台を用意できます。
運用後のログから絞り込む本記事のアプローチと、開発段階でコードから叩き台を作るアプローチは、対立するものではありません。開発段階で叩き台を作っておき、運用後にログで精緻化するという組み合わせも考えられます。要件や開発フローに応じて選択ください。
まとめ
IAM ユーザーの権限を最小化するための現実的なステップとして、最終アクセス日時・IAM Access Analyzer のポリシー生成・Athena によるログクエリの 3 つを、粒度の大きいところから細かいところへと段階的に組み合わせる方法を紹介しました。
それぞれの機能は参照するデータソースと分析対象が異なり、単独では最小権限を詰めきれません。最終アクセス日時はサービス単位の棚卸し、ポリシー生成はアクション単位の叩き台、Athena はデータイベントとリソースの特定と、担う粒度が異なります。特にデータイベント（データプレーン）の扱いに差があるため、この違いを理解したうえで組み合わせることが重要です。細部まで正確に詰めるには CloudTrail のログを追う必要がある、という点を踏まえて、要件に沿った落としどころを選択ください。
参考資料
- IAM Access Analyzer で最小権限のポリシーを洗い出す
- Generate a policy based on AWS activity - IAM ユーザーガイド
- IAM last accessed information - IAM ユーザーガイド
- Query AWS CloudTrail logs - Amazon Athena ユーザーガイド
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AI をフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026 年 1 月 アノテーション㈱から社名変更しました
