AWS IAM でのアクセス権限管理は、「誰（人かアプリか）に、どの操作を、どの範囲で許すか」を決め、その状態を定期的に点検し続ける作業です。この記事では、権限を付ける相手ごとの基本方針、権限が最終的にどう判定されるかの仕組み、そして付けた権限を点検・削減する具体的な手順を説明します。ユーザーやロールの作成手順、ポリシー JSON の書き方そのものは別記事に譲り、ここでは運用全体の設計に焦点を当てます。
権限を付ける相手を3種類に分ける
IAM で扱う「誰」は、大きく次の3種類に分けて考えると整理しやすくなります。
ルートユーザーはアカウント作成時のメールアドレスでログインする特別なユーザーで、すべての操作ができます。ポリシーで制限できない操作もあるため、普段の作業には使いません。MFA を設定し、アクセスキーは作らず、ルートでしかできない作業（一部の請求・アカウント設定など）のときだけ使います。
人（作業者）には、長期間有効なアクセスキーを持たせない構成が AWS の推奨です。組織で複数人が使うなら IAM Identity Center（旧 AWS SSO）で一時的な認証情報を発行する方法が第一候補になります。IAM ユーザーを使う場合も、ポリシーはユーザー個人ではなくグループに付け、人の異動はグループの出し入れで済むようにします。
アプリケーションや AWS サービスには IAM ロールを使います。EC2 上の WordPress が S3 にメディアを置くなら、インスタンスプロファイルでロールを付与し、サーバー内にアクセスキーを置かないようにします。Lambda なら実行ロールです。ロールの認証情報は自動で更新される一時的なものなので、キーの漏えいや入れ替え忘れの心配が減ります。
権限がどう判定されるかを理解する
権限設定でつまずく原因の多くは、判定の仕組みを知らないことです。基本のルールは次のとおりです。
- 何も許可されていない操作は拒否される（暗黙の拒否）
- どこかのポリシーで許可されていれば許可される
- ただし、どこかのポリシーで明示的に拒否（Deny）されていれば、許可より拒否が優先される
さらに、許可の「上限」を決める仕組みが別にあります。AWS Organizations のサービスコントロールポリシー（SCP）はアカウント全体の上限、アクセス許可の境界（Permissions boundary）はユーザーやロール単位の上限です。上限の外にある操作は、アイデンティティベースのポリシーで許可していても実行できません。
S3 バケットポリシーのようなリソースベースのポリシーも判定に加わります。同じアカウント内ではどちらか一方の許可で足りる場合が多い一方、別アカウントからのアクセスでは両側の許可が要る、といった違いがあります。細かな組み合わせは AWS 公式ドキュメントの「ポリシーの評価論理」で確認してください（2026年10月現在）。
「許可したはずなのに AccessDenied になる」ときは、この順で明示的な Deny、SCP、アクセス許可の境界、リソースベースのポリシーを確認していくと原因にたどり着けます。
最小権限のポリシーを付ける
付ける権限は、操作（Action）とリソース（Resource）の両方で範囲を絞ります。WordPress のメディアを S3 の特定のプレフィックスに置くアプリケーション用であれば、次のような形になります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListOnlyUploadsPrefix",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example-media-bucket",
"Condition": { "StringLike": { "s3:prefix": "wp-uploads/*" } }
},
{
"Sid": "ReadWriteUploads",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::example-media-bucket/wp-uploads/*"
}
]
}s3:ListBucket はバケット自体、s3:GetObject などはオブジェクトに対する操作なので、Resource の書き方が異なります。ここを取り違えると、一覧は見えるのに読み込めない、あるいはその逆、という状態になります。
作ったポリシーは、付与する前に IAM Access Analyzer のポリシー検証で文法や過剰な許可の警告がないかを確認できます。
aws accessanalyzer validate-policy \
--policy-type IDENTITY_POLICY \
--policy-document file://media-policy.json人に付ける権限は、AWS 管理ポリシー（読み取り専用、特定サービスの管理者など）から始めて、必要に応じて絞り込むのが現実的です。いきなり細かく作り込むと、業務が止まって結局広い権限を付け直すことになりがちです。
意図どおりに効いているかを確かめる
設定した権限が期待どおりかどうかは、実際に操作する前にポリシーシミュレーターで確認できます。
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:role/wp-media-role \
--action-names s3:PutObject s3:DeleteBucket \
--resource-arns arn:aws:s3:::example-media-bucket/wp-uploads/test.jpg結果の EvalDecision が allowed か implicitDeny・explicitDeny かを見ます。許可したい操作が allowed、許可したくない操作が拒否になっていれば想定どおりです。ただし、シミュレーターは SCP など一部の条件を反映しきれない場合があるため、最終的には検証環境で実際に操作して確かめます。
いま自分がどの認証情報で操作しているかは、次のコマンドで確認できます。複数のプロファイルを使い分けている人は、権限エラーの調査の最初にこれを実行すると取り違えを防げます。
aws sts get-caller-identity付けた権限を定期的に棚卸しする
権限は時間とともに増えていく一方になりがちです。四半期ごとなど、点検の時期を決めておきます。
認証情報レポートは、IAM ユーザーごとのパスワード使用日、MFA の有無、アクセスキーの作成日と最終使用日を一覧にしたものです。
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > credential-report.csv長期間使われていないユーザーやアクセスキーは、いきなり削除せず、まず無効化して影響がないことを確かめてから削除します。
aws iam update-access-key --user-name ops-user --access-key-id AKIAEXAMPLEKEYID --status Inactive最終アクセス情報（Last accessed）では、ユーザーやロールがどのサービスを最後にいつ使ったかを確認できます。付与しているのに長く使われていないサービスの権限は、外す候補です。IAM Access Analyzer には、外部アカウントに公開されているリソースや使われていない権限を検出する機能もあります。機能によっては有料のものがあるため、利用条件を確認してから有効にしてください。
操作の記録は CloudTrail に残ります。誰がいつ IAM のポリシーを変更したかを追えるよう、証跡の設定と保管期間も合わせて確認しておきます。
運用でつまずきやすい点
- 作業用に一時的に付けた広い権限（AdministratorAccess など）を外し忘れる。付与時に期限と担当者を記録しておく
- 退職者や委託先のユーザーが残り続ける。人の出入りの手続きに IAM の作業を組み込む
- アクセスキーをソースコードや設定ファイルに書き、Git に入れてしまう。サーバーではロール、手元では SSO や一時的な認証情報を使う
- ポリシーを直接ユーザーに付け、誰に何が付いているか分からなくなる。グループとロール経由に統一する
変更の前には、現在のポリシーを aws iam get-policy-version などで書き出して控えておくと、問題が起きたときに元に戻せます。本番アカウントの権限を絞るときは、まず検証用アカウントで同じ変更を試してください。
まとめ
- 権限を付ける相手を、ルートユーザー・人・アプリケーションに分けて方針を決める
- 人には IAM Identity Center などの一時的な認証情報、アプリには IAM ロールを使い、長期のアクセスキーを減らす
- 判定は「暗黙の拒否 → 許可 → 明示的な拒否が最優先」。SCP とアクセス許可の境界が上限になる
- ポリシーは Action と Resource の両方で絞り、Access Analyzer の検証とポリシーシミュレーターで確かめる
- 認証情報レポートと最終アクセス情報で定期的に棚卸しし、無効化してから削除する