IAM のユーザー・ロール・ポリシーという言葉は分かった。許可と拒否の評価順も読んだ。それでも「実際に誰にどのポリシーをどこまで付けるのか」で手が止まる、という段階の記事です。AdministratorAccess を付ければ確かに動きますが、それでは最小権限になりません。かといって JSON を1行目から書く自信もない。ここでは、その迷いを3つの判断に分けて、順番に決められるようにします。
この記事の結論
- 権限の設計は「誰に付けるか」「ポリシーの種類をどれにするか」「どこまで絞るか」の3つの判断に分けて決めます。
- 人のサインインは一時的な認証情報（フェデレーション）、アプリはロールが基本です。長期のアクセスキーは例外です。
- 出発点は AWS 管理ポリシーです。用途に絞りたいときは、コピーしてカスタマー管理ポリシーにします。
- インラインポリシーは「その1つの主体だけ」の例外用です。複数の主体に付くなら管理ポリシーにします。
- 最小権限は一度で決めません。広く始め、使われた実績を見ながら絞ります。
権限の設計では何を決めるのか｜主体・ポリシーの種類・絞り方の3つ
権限の設計で決めることは、実は3つしかありません。順番に、ひとつずつ決めていきます。
- 誰に付けるか（主体）。 人なのか、アプリケーションなのか。人ならどう束ねるか。
- どのポリシーの種類にするか。 AWS 管理ポリシー、カスタマー管理ポリシー、インラインポリシーのどれか。
- どこまで絞るか。 アクション・リソース・条件のどこで狭めるか。
迷う原因の多くは、この3つを一度に決めようとすることです。「S3 の読み取りだけ許可するポリシーを、開発者に付ける」という1文の中に、3つの判断が混ざっています。分けて考えると、それぞれの選択肢は意外に少なく、決めやすくなります。
THREE DECISIONS決めることは3つ
権限の設計は誰に・どの種類で・どこまで絞るかの3つに分ける
-
主体
誰に付けるか — 人はフェデレーション、アプリはロール
同じ権限の人はグループで束ねる
-
種類
どのポリシーにするか — 管理ポリシーが基本
インラインは1つの主体だけの例外
-
絞り
どこまで絞るか — アクション・リソース・条件
広く始めて、実績を見て狭める
なお、権限の設定そのものは利用者の側の責任です。AWS が土台を守ってくれても、誰に何を許すかは自分たちが決めることになります。この前提のうえで、3つの判断を順に見ていきます。
誰に付けるか｜人はフェデレーション、アプリはロール、グループで束ねる
人には一時的な認証情報を
AWS のベストプラクティスは、人が AWS にアクセスするときは、ID プロバイダーとのフェデレーションで一時的な認証情報を使うことを勧めています。会社のアカウント管理の仕組みでサインインし、そのつど短い期間だけ有効な認証情報を受け取る形です。この仕組みを組み込んだ入口が IAM Identity Center で、詳しくは 
READ ALSO — 学習中向け・段2 構成
IAM Identity Center とは何か｜複数アカウントへのサインインを1か所にまとめ、許可セットで権限を配る
で扱っています。
IAM ユーザーに長期のパスワードやアクセスキーを持たせる形は、漏れたときに長く悪用されるため、例外の扱いです。
アプリにはロールを
EC2 や Lambda のような、AWS の上で動くアプリケーションは、IAM ロールで権限を受け取ります。たとえば Lambda 関数なら、関数に実行ロールを割り当て、そのロールに必要な権限だけを付けます。EC2 なら、インスタンスにロールを付けると、一時的な認証情報が自動で配られ、自動で入れ替わります。
反対に、アクセスキーをソースコードや設定ファイルに書き込む形は、公開リポジトリやログから漏れる典型的な事故の元です。後の「設計の失敗例」でもう一度触れます。
同じ権限をまとめて渡すにはグループ
同じ権限を複数の人にまとめて渡したいときは、IAM グループを使います。権限をグループに付け、人をグループに入れます。担当が変わったら、グループから外して別のグループに入れるだけです。ユーザー1人ずつにポリシーを付けていると、付け忘れと外し忘れが必ず出ます。
整理すると、主体の選び方は次のとおりです。
| 渡す相手 | 基本の方法 | 補足 |
|---|---|---|
| 人（サインインして使う） | フェデレーション（Identity Center など）で一時的な認証情報 | 長期のアクセスキーは例外 |
| 同じ権限を持つ複数の人 | グループにまとめる | 付け外しが1か所で済む |
| AWS 上で動くアプリ | ロール（実行ロール・インスタンスのロールなど） | コードにキーを書かない |
CHECK 1ここまでの確認
開発者が10人いて、全員に同じ権限をまとめて付けたい。付け外しを1か所で済ませるには何を使う?
答えと解説
答え: 2. IAM グループに権限を付け、メンバーを入れる
グループは「同じ権限の束」を人にまとめて渡す入れ物です。入れる・外すだけで権限が変わります。なお人のサインインの入口は、長期の認証情報より ID プロバイダーのフェデレーションが推奨です。「誰に付けるか」の節を読み直してください。
AWS 管理ポリシー・カスタマー管理ポリシー・インラインポリシーはどう選ぶか
主体が決まったら、付けるポリシーの種類を選びます。IAM には、アイデンティティに付けるポリシーの種類が3つあります。違いは「誰が管理するか」「変更できるか」「いくつの主体に付けられるか」の3点です。
| 種類 | 誰が管理するか | 変更できるか | 付け先 |
|---|---|---|---|
| AWS 管理ポリシー | AWS | 利用者は変更できない（AWS が更新する） | 複数の主体に付けられる |
| カスタマー管理ポリシー | 利用者 | 利用者が変更できる | 複数の主体に付けられる |
| インラインポリシー | 利用者 | 利用者が変更できる | 1つの主体にだけ埋め込まれる |
POLICY TYPES管理ポリシーかインラインか
複数に付くなら管理ポリシー、1つだけに結び付くならインライン
管理ポリシー
AWS 管理 / カスタマー管理
- 管理者AWS か、利用者
- 変更AWS 管理は不可、カスタマー管理は可
- 付け先複数の主体に付けられる
インラインポリシー
主体に埋め込む
- 管理者利用者
- 変更可
- 付け先1つの主体とだけ1対1
出発点は AWS 管理ポリシー
AWS 管理ポリシーは、AWS があらかじめ用意した、よくある用途向けのポリシーです。ゼロから書かずに済み、権限の全体像をつかむ足場になります。ただし用途に対して広すぎることがあるので、「そのまま恒久的に使う」ものではなく、「出発点」として扱います。
自分の用途に合わせたいときは、AWS 管理ポリシーの中身をコピーして、カスタマー管理ポリシーとして作り直します。AWS 管理ポリシーそのものは書き換えられません。AWS が管理して更新していくものだからです。
絞ったものはカスタマー管理ポリシーに
自分で絞ったポリシーは、カスタマー管理ポリシーにします。1つのポリシーを複数のグループやロールに付けられるので、直すときも1か所で済みます。変更の履歴を追う、どこに付いているかを調べるといった管理も、管理ポリシーの形ならしやすくなります。
インラインポリシーは例外用
インラインポリシーは、ユーザー・グループ・ロールの1つに直接埋め込む形です。その主体と1対1で、切り離せません。「このロールを消したら、このポリシーも一緒に消えてほしい」というように、主体と運命をともにさせたいときの例外用です。
迷ったときの基準は単純です。複数の主体に付く可能性が少しでもあるなら、管理ポリシー。 インラインにして後から「実は他にも要る」となると、同じ内容を書き写すことになり、片方だけ直し忘れる事故につながります。
CHECK 2ここまでの確認
AWS 管理ポリシーの中身を、自分の用途に合わせて直接書き換えられる?
答えと解説
答え: 2. 書き換えられない。変えたいならコピーしてカスタマー管理ポリシーにする
AWS 管理ポリシーは AWS が管理し、AWS が更新します。利用者が編集できるのはカスタマー管理ポリシーです。「ポリシーの種類はどう選ぶか」の表を読み直してください。
最小権限へ絞る手順｜広く始めて、アクション・リソース・条件で狭める
最小権限とは、業務に必要な権限だけを付けるという原則です。ただ、「必要な権限」は設計の段階で完全には分かりません。実際にアプリを動かして、初めて「この API も呼んでいた」と分かることが多いからです。そこで AWS のベストプラクティスも、まず広めの権限で始めて、実績を見ながら絞っていく進め方を示しています。
WIDE THEN NARROW広く始めて絞る
最小権限は一度で決めず、実績を見て絞り直す
-
広く始める
AWS 管理ポリシーを出発点に
-
実績を見る
使われた権限を確かめる
-
絞る
アクション・リソース・条件で
-
見直す
担当や構成が変わったら戻る
手順の流れ
- 広く始める。 AWS 管理ポリシーなどを出発点に、動かすのに必要な範囲を付ける。
- 使われた権限を見る。 実際にどのアクションが使われたかを確かめる。AWS には、アクセスの実績から権限を見直すための仕組み（IAM Access Analyzer など）があります。中身は
READ ALSO — プロフェッショナル向け・段4 設計
IAM Access Analyzer とは何か｜外部への共有・未使用の権限・ポリシー検証を「信頼ゾーン」で見張る仕組み
で扱うので、ここでは「実績を見る手段がある」とだけ押さえます。 - 絞る。 使われていない権限を外し、アクション・リソース・条件で狭める。
- 見直す。 担当や構成が変われば必要な権限も変わるので、定期的に、使われていない権限が残っていないかを見る。
「広く始める」は、広いまま放っておいてよいという意味ではありません。手順の3と4までやり切って、初めて最小権限に近づきます。
絞る3つの軸
ポリシーは、Allow か Deny か、そして次の3つの軸で範囲を決めます。
| 軸 | 決めること | 絞り方の例 |
|---|---|---|
| Action | 何をするか | 「S3 のすべて」ではなく、読み取りの s3:GetObject だけ |
| Resource | 何に対してか | 「すべてのバケット」ではなく、特定のバケットの特定のプレフィックスだけ |
| Condition | どんな状況なら | 接続元の IP アドレスの範囲、MFA の有無など |
たとえば、機械学習の学習ジョブの実行ロールに、特定のバケットの特定のプレフィックスだけを読ませる場合は、こう書きます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/training-data/*"
}
]
}
Action を s3:GetObject に、Resource を training-data/ 以下に絞っています。ほかのデータや、書き込みには触れません。ここに特定の IP からだけ許可する、といった状況の制限を足したいときは、Condition を加えます。
"Condition": {
"IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
}
203.0.113.0/24 は文書用の例示のアドレスです。実際には自社の出口のアドレス範囲を入れます。アクションとリソースだけでなく、条件でも絞れる、という点を覚えておいてください。
CHECK 3ここまでの確認
必要な権限が最初から完全には分からないとき、最小権限をどう進めるのがよい?
答えと解説
答え: 2. 広めに始めて、使われた実績を見ながら絞っていく
必要な権限は、実際に使ってみて初めて分かることが多いからです。広く始めて絞るのは公式も示す進め方で、広いまま放置するのは別の話です。「絞る手順」の節を読み直してください。
CHECK 4ここまでの確認
ポリシーの中で、接続元の IP アドレスのような「状況」で許可を絞りたいとき、使う要素は?
答えと解説
答え: 3. Condition
Action は「何をするか」、Resource は「何に対して」、Condition は「どんな状況なら」を決めます。絞る軸は3つあります。「絞る手順」の節を読み直してください。
設計の失敗例｜AdministratorAccess の常用・ワイルドカード・アクセスキーの埋め込み
最後に、権限の設計で繰り返し出てくる失敗の型を3つ挙げます。
権限の設計でやってはいけない3つ
- 日常の作業に AdministratorAccess を付け続ける
- Action や Resource に、理由なくワイルドカード（
*）を並べる - アクセスキーをコードや設定ファイルに書き込む
AdministratorAccess の常用
「動かないから、とりあえず AdministratorAccess」は、最初の動作確認では楽ですが、そのまま残るのが問題です。AWS は、この強い権限を管理者の作業に限って使うよう案内しています。日常の開発者には、職務に合わせた AWS 管理ポリシーや、用途に絞ったポリシーを付けます。
理由のないワイルドカード
"Action": "s3:*" や "Resource": "*" は、書くのは簡単ですが、意図しない範囲まで許してしまいます。ワイルドカードそのものが悪いのではありません。「プレフィックス以下をまとめて」のように、範囲が説明できる使い方は正当です。避けるのは、絞る作業を後回しにした結果の * です。
アクセスキーの埋め込み
EC2 上のアプリが S3 を読みたいとき、コードにアクセスキーを書き込む形は避け、インスタンスにロールを付けます。ロールなら一時的な認証情報が自動で配られ、自動で入れ替わるので、漏れても被害の期間が限られます。Lambda でも同じで、実行ロールに権限を付けます。コードやログに認証情報を残さない、という原則は、アプリ側の設計にも直結します。
設計メモの残し方と、次に読むもの（マルチアカウントの権限設計へ）
権限は、付けた時点より、後から見直すときに効いてきます。「なぜこのポリシーをこのロールに付けたのか」が残っていないと、怖くて外せなくなり、広いまま固定されます。次の3点だけでも、メモとして残しておくと、見直しが楽になります。
- 誰に（主体）： グループ名・ロール名と、使う人やアプリ
- 何を許したか： 付けたポリシーの名前と、絞った Action・Resource・Condition
- なぜ： 業務上の理由と、見直す時期
この記事で扱ったのは、1つのアカウントの中で、誰にどのポリシーをどこまで付けるかでした。複数のアカウントを持つ構成になると、その外側に、アカウント全体の上限を引く仕組み（SCP や権限境界）が加わります。そこは 
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウントの権限設計｜SCP・許可セット・権限境界・ABAC を「どこで絞るか」で組む
で扱います。
この記事の論点を、練習問題で確かめることもできます。最小権限の原則、グループ、ポリシーの構造、Condition、ロールでの権限付与は、AWS 認定の試験でも繰り返し問われる分野です。
参照ソース
- AWS Identity and Access Management ユーザーガイド｜IAM のセキュリティのベストプラクティス — 人はフェデレーションで一時的な認証情報を使うこと、ワークロードにはロールを使うこと、広めに始めて最小権限へ絞ること、AWS 管理ポリシーから始めてカスタマー管理ポリシーで絞ること、条件や未使用権限の見直しの根拠として使用
- AWS Identity and Access Management ユーザーガイド｜管理ポリシーとインラインポリシー — 3種類のポリシーの管理者・変更可否・付け先の違い、AWS 管理ポリシーをコピーしてカスタマー管理ポリシーを作ること、インラインポリシーが主体と1対1であることの根拠として使用
