IAM とアクセス管理
ユーザー、グループ、ロール、ポリシー、AWS による権限の評価方法、STS による一時的な権限、Organizations と IAM Identity Center によるマルチアカウント管理。
- 分野セキュアなアーキテクチャ
- 図 12
- 出題パターン 10
- サービス 9
5 分で押さえる要点
- デフォルトではすべてのリクエストが拒否されます (暗黙の拒否)。一致する Allow が少なくとも 1 つ必要で、どのポリシーであっても明示的な Deny はすべての Allow に優先します。権限に関する問題の読み方：まず Deny を探し、次に SCP、続いてリソースポリシー / ID ポリシー、permissions boundary、セッションポリシーの順に確認します。
- ユーザー = 長期的な ID (パスワード、アクセスキー)、ロール = STS の一時的な認証情報によって「借りる」ID です。AWS は長期のアクセスキーの代わりにロールとフェデレーションの利用を推奨しています。EC2 / Lambda / ECS 上のアプリケーションは常にロールを使います。
- EC2 はインスタンスプロファイル (マシンにアタッチしたロール) を通じて権限を受け取ります。SDK はインスタンスメタデータから一時的な認証情報を自動取得します。「EC2 上の設定ファイルにアクセスキーを保存する」という選択肢は常に不正解です。
- ロールには、trust policy (誰が assume できるか) と permission policy (assume 後に何ができるか) があります。アカウント B からアカウント A へアクセスさせる場合：A に B を信頼するロールを作成し、B 側のユーザーにそのロールへの sts:AssumeRole 権限を付与します。サードパーティの場合は External ID を追加します。
- リソースベースのポリシー (バケットポリシー、キーポリシー、キューポリシーなど) には Principal フィールドがあり、ロールを assume せずにクロスアカウントアクセスを許可できます。クロスアカウントでリソースポリシーを使う場合、呼び出し元は自身の権限のままです。ロールを使う場合、呼び出し元はそのロールの権限に切り替わります。
- Organizations の SCP はメンバーアカウントのユーザー / ロールに対する権限の上限を設定するもので、権限を付与することはありません。管理アカウントとサービスリンクロールには適用されません。「すべてのアカウントで CloudTrail の停止や許可リスト外のリージョンの使用を禁止する」→ OU またはルートにアタッチした SCP の Deny。
- Permissions boundary は特定のユーザー / ロールの権限の上限を設定します。実際の権限は ID ポリシーと boundary の積集合になります。開発者にロールを作成させつつ権限昇格を防ぐには、新しいロールに boundary のアタッチを必須にします。
- IAM Identity Center：Organizations 内の複数アカウントへシングルサインオンでき、permission set で権限を割り当て、外部の IdP (Entra ID、Okta など) とも連携できます。従業員が会社のアカウントで複数の AWS アカウントにアクセスする場合：各アカウントに IAM ユーザーを作成する代わりに、最新の正解は Identity Center です。
- Cognito ユーザープールはユーザーディレクトリ (サインアップ、サインイン、MFA、ソーシャルログイン) です。ID プールはその ID を AWS の一時的な認証情報に交換します。顧客向けのモバイル / Web アプリが S3 や DynamoDB に直接アクセスする場合：IAM ユーザーではなく Cognito を使います。
- ルートユーザーの保護：MFA を有効にし、アクセスキーは作成せず、どうしても必要な作業にのみ使います。日常業務には最小権限のユーザー / ロールを使います。ルートユーザーは、サポートプランの変更やアカウントの閉鎖などの作業にのみ使います。
- ロールの一時的な認証情報の有効期間は設定により 1〜12 時間です。ロールチェーン (あるロールから別のロールを assume すること) は 1 時間に制限されます。12 時間に設定したのにセッションが 1 時間で切れる場合：多くはロールチェーンが原因です。
- IAM Access Analyzer は、信頼ゾーン (アカウント / 組織) の外部に共有されているリソースを検出し、適用前にポリシーを検証します。「外部からのアクセスを許可しているバケット、キー、ロールを見つける」→ Access Analyzer。
- ポリシーの条件 (Condition)：aws:SourceIp、aws:MultiFactorAuthPresent、aws:RequestedRegion、aws:PrincipalOrgID、タグ (ABAC) など。タグによる許可 (ABAC) は、プロジェクトが増えてもポリシーの数を抑えられます。aws:PrincipalOrgID を使うと、アカウントを 1 つずつ列挙せずに組織全体へ共有できます。
構成図
AWS がリクエストを評価する流れ
ステップ
- 適用されるどのポリシーにも Deny があれば、即座に DENY です。
- 組織の SCP / RCP が許可していなければ DENY です。
- ID ポリシーにもリソースポリシーにも Allow がなければ DENY です (暗黙の拒否)。
- Permissions boundary とセッションポリシー (ある場合) も許可していれば ALLOW です。
EC2 がアクセスキーなしでロールを使って S3 を呼び出す
ステップ
- ロールはインスタンスプロファイルで EC2 にアタッチされます。権限はロールの permission policy に定義されています。
- SDK はインスタンスメタデータ (IMDSv2) から一時的な認証情報を自動で読み取ります。
- 一時的な認証情報で S3 を呼び出します。マシン上に長期のキーはありません。
アカウント B のユーザーがアカウント A のロールを使う
Permissions boundary：実際の権限は積集合
SCP が OU 全体の上限を設定する
ステップ
- アカウントを OU に配置し、SCP をルートまたは OU にアタッチします。
- OU Prod 内のすべてのアカウントが SCP を継承します。そのアカウントのルートユーザーを含め、誰も許可リスト外のリージョンを使えません。
IAM Identity Center：1 回のログインで複数アカウントへ
ステップ
- 従業員は会社のアカウントでログインし、グループは Identity Center に同期されます (SCIM)。
- グループごとに、アカウントごとに異なる permission set を割り当てます。退職時は IdP で無効にします。
コンソールへの SAML 2.0 フェデレーション
Cognito：アプリの顧客が S3 にアクセスする
IAM Access Analyzer で外部からのアクセスを検出する
ステップ
- Access Analyzer が、バケット、キー、ロール、キューなどのポリシーを分析します。
- 組織外のアカウントを許可するバケットポリシーは finding として生成され、確認と対処ができます。
ABAC：タグによる権限管理、1 つのポリシーですべてのプロジェクトに対応
ステップ
- 両方のロールが同じ 1 つのポリシーを共有します。条件は、ロールの project タグとリソースの project タグを比較します。
- Heart のロールは project = heart のリソースだけを操作でき、Star のマシンに対しては拒否されます。
- project = heart を付けた新しいマシンを作成すると、Heart チームはすぐに権限を持ち、ポリシーを修正する必要はありません。
IAM で RDS にログインする (パスワード不要)
AWS へのアクセス権限の付与方法を選ぶ
ステップ
- EC2、Lambda、ECS：ロール (インスタンスプロファイル、実行ロール、タスクロール) をアタッチします。アクセスキーをコードに埋め込んではいけません。
- Web / モバイルアプリの顧客：サインインには Cognito ユーザープール、一時的な AWS 認証情報への交換には ID プールを使います。
- 従業員：複数アカウントなら IAM Identity Center (シングルサインオン)、社内 IdP で 1 つのアカウントなら STS 経由の SAML 2.0 フェデレーションを使います。
- 別の AWS アカウントやパートナー：そのアカウントを許可する trust policy を持つロールを使います。サードパーティの場合は External ID を追加します。
比較表
ポリシーの種類
| 種類 | アタッチ先 | 権限を付与するか | 使いどころ |
|---|---|---|---|
| Identity-based | ユーザー、グループ、ロール | はい | アカウント内の ID に権限を付与する |
| Resource-based | バケット、キー、キュー、トピック、ロール (trust) など | はい (クロスアカウントも可) | 別アカウントの principal にリソースへのアクセスを許可する |
| Permissions boundary | ユーザー、ロール | いいえ、上限の設定のみ | 権限昇格させずにロール作成を委任する |
| SCP (Organizations) | ルート、OU、アカウント | いいえ、上限の設定のみ | アカウント全体 / OU のガードレール |
| RCP (Organizations) | ルート、OU、アカウント | いいえ、上限の設定のみ | 組織内のリソースに対するガードレール |
| セッションポリシー | assume role / フェデレーションのセッション | いいえ、上限の設定のみ | 1 つのセッションの権限を絞り込む |
クロスアカウントアクセス
| Assume role | Resource-based policy | |
|---|---|---|
| 方法 | 呼び出し元が、対象アカウントのロールの権限に切り替わる | リソース自身が別アカウントの principal を許可する |
| 元のアカウントの権限 | セッション中は一時的に使えなくなる | そのまま維持される (例：バケット A から B へのコピーを同時に行う場合) |
| 対応サービス | すべてのサービス | resource policy を持つサービスのみ (S3、SQS、SNS、KMS、Lambda など) |
| サードパーティ | External ID を追加して confused deputy を防ぐ | aws:SourceAccount / SourceArn 条件を使う |
ID の対象別の選択
| 対象 | 使うもの | 備考 |
|---|---|---|
| 従業員、複数アカウント | IAM Identity Center (+ 社内 IdP) | permission set → 各アカウントのロール |
| 従業員、単一アカウント、AD あり | SAML 2.0 フェデレーション → AssumeRoleWithSAML | または AD と連携した Identity Center |
| EC2 / ECS / Lambda 上のアプリケーション | ロール (インスタンスプロファイル、タスクロール、実行ロール) | アクセスキーは保存しない |
| Web / モバイルアプリの顧客 | Cognito ユーザープール + ID プール | ソーシャルログイン、MFA |
| AWS 外のサーバー | IAM Roles Anywhere (X.509 証明書) | 長期のアクセスキーの代替 |
| 緊急時 | MFA 付きの break-glass 用 IAM ユーザー | 厳重に保管し、監視する |
Organizations と Control Tower
| Organizations | Control Tower | |
|---|---|---|
| 概要 | アカウントを OU のツリーにまとめ、一括請求、SCP / RCP を提供 | ベストプラクティスに沿ったマルチアカウントの landing zone を構築 |
| ガードレール | SCP を自分で作成する | 用意済みの Controls (preventive = SCP、detective = Config) |
| 使いどころ | 柔軟な制御が必要な場合 | 標準に沿ったマルチアカウント環境を素早く構築したい場合 |
よく出る出題パターン
1EC2 上のアプリケーションが S3 バケットを読み取る必要があります。
答えを見る
正解: バケットへの s3:GetObject 権限を持つロールを、インスタンスプロファイルで EC2 にアタッチする
SDK がメタデータから一時的な認証情報を自動取得し、AWS が自動でローテーションします。
不正解: IAM ユーザーを作成し、マシン上の設定ファイルにアクセスキーを保存する
長期のキーは漏えいしやすく、ローテーションも自分で行う必要があります。
不正解: すべての principal を許可するバケットポリシー
バケットを全世界に公開することになります。
2ユーザーに AdministratorAccess ポリシーがあるのに、メンバーアカウントの CloudTrail を停止できません。
答えを見る
正解: OU / ルートに cloudtrail:StopLogging を Deny する SCP がある
SCP はメンバーアカウントのすべてのユーザー、ロール (ルートユーザーを含む) の上限を設定します。Deny はすべての Allow に優先します。
不正解: cloudtrail:StopLogging 権限が足りない
AdministratorAccess にはすでに含まれています。権限は上位の階層でブロックされています。
3監査法人 (サードパーティ) が、お客様のアカウント内のリソースを読み取る必要があります。
答えを見る
正解: 相手のアカウントが assume できるロールを作成し、trust policy で External ID を必須にする
一時的な認証情報で、取り消しが可能です。External ID が confused deputy を防ぎます。
不正解: IAM ユーザーを作成し、アクセスキーを渡す
長期のキーがお客様の管理外に置かれることになります。
4開発者に Lambda 用のロールを作成させたいが、自分の権限より高いロールは作成させたくありません。
答えを見る
正解: Permissions boundary：新しいロールに指定の boundary がアタッチされている場合に限り iam:CreateRole を許可する
新しいロールの実際の権限は boundary を超えません。
不正解: 開発者に AdministratorAccess を付与しないよう伝えるだけにする
それを防ぐ仕組みがありません。
不正解: SCP
SCP はアカウント全体に適用され、誰が作成したロールかは区別しません。
5500 人の従業員が Microsoft Entra ID のアカウントでログインし、40 個の AWS アカウントにアクセスします。
答えを見る
正解: IAM Identity Center を Entra ID と連携し、アカウントごとにグループへ permission set を割り当てる
シングルサインオンでグループ単位の権限管理ができ、退職時は IdP で無効にすれば権限を失います。
不正解: 各アカウントに、1 人ずつ IAM ユーザーを作成する
20,000 ユーザーとなり管理しきれず、長期のキーも増えます。
6モバイルアプリで、ユーザーが Google でログインし、S3 上の自分専用フォルダーに写真をアップロードします。
答えを見る
正解: Cognito ユーザープール (Google ログイン) + 一時ロールを発行する ID プール。ポリシーでユーザー ID ごとの prefix に制限する
各ユーザーは自分のフォルダーに対する一時的な権限だけを持ちます。
不正解: アプリにアクセスキーを埋め込む
アプリを展開すれば誰でもキーを取り出せます。
7組織外のアカウントにアクセスを許可しているバケット、KMS キー、ロールを把握する必要があります。
答えを見る
正解: 信頼ゾーンを組織にした IAM Access Analyzer
ポリシーを自動で分析し、外部へのアクセス経路ごとに finding を報告します。
不正解: ポリシーを 1 つずつ手作業で読む
リソース数が多いと追いつかず、見落としが発生しやすくなります。
8今後作成されるものも含め、組織内のすべてのアカウントにバケットを共有します。
答えを見る
正解: バケットポリシーで aws:PrincipalOrgID 条件に組織 ID を指定する
組織内の新しいアカウントには自動で権限が付与され、組織外のアカウントには付与されません。
不正解: バケットポリシーにアカウント ID を 1 つずつ列挙する
新しいアカウントができるたびにポリシーを修正する必要があります。
9スクリプトがロール A を assume し、さらに A からロール B を DurationSeconds 4 時間で assume しようとするとエラーになります。
答えを見る
正解: ロールチェーンではセッションが最大 1 時間に制限される
長いセッションが必要な場合：元の ID で直接 B を assume します。
不正解: ロール B の max session duration が 1 時間である
その可能性もありますが、ここでの原因は確実にロールチェーンです。
10重要なバケットのオブジェクトを削除するには MFA を必須にしたいと考えています。
答えを見る
正解: aws:MultiFactorAuthPresent が真でない場合に s3:DeleteObject を Deny するポリシー (バージョニング有効時は MFA Delete も検討)
MFA 条件が、保護したい操作そのものに適用されます。
不正解: コンソールのサインインにだけ MFA を有効にする
個々の API 操作には紐づきません。
早見表
権限の付与・制限には何を使いますか？
| やりたいこと | 使うもの |
|---|---|
| EC2 / Lambda / ECS 上のアプリケーションが AWS を呼び出す必要がある | ロール (インスタンスプロファイル、実行ロール、タスクロール) · 図を見る |
| 別アカウントのユーザーがアクセスする必要がある | ロール + trust policy (サードパーティの場合は External ID) · 図を見る |
| 別アカウントにリソースを使わせる | Resource-based policy (バケット / キー / キューのポリシー) · 図を見る |
| アカウント全体 / OU でアクションを禁止する | SCP · 図を見る |
| 1 つのユーザー / ロールの権限の上限を設定する | Permissions boundary · 図を見る |
| 従業員が複数アカウントにシングルサインオンする | IAM Identity Center · 図を見る |
| 社内 AD で 1 つのアカウントにログインする | SAML 2.0 フェデレーション · 図を見る |
| Web / モバイルアプリの顧客 | Cognito ユーザープール + ID プール · 図を見る |
| 外部に共有されているリソースを見つける | IAM Access Analyzer · 図を見る |
| Deny される理由を理解する | ポリシー評価の順序に沿って確認する · 図を見る |
落とし穴
- ロールを使わず、EC2 上やコード内にアクセスキーを保存する。
- SCP が権限を付与すると思い込む：SCP は上限を設定するだけで、ID ポリシーも必要です。
- SCP が管理アカウントも制限すると思い込む：管理アカウントには適用されません。
- 明示的な Deny は AdministratorAccess を含むすべての Allow に優先することを忘れる。
- External ID なしでサードパーティに assume role を許可する。
- ルートユーザーを日常業務に使う、またはルートユーザーのアクセスキーを作成する。
- アプリケーションの顧客に IAM ユーザーを使う (それは Cognito の役割です)。
- ユーザープール (サインイン) と ID プール (AWS の認証情報への交換) を混同する。
- aws:PrincipalOrgID を使わず、バケットポリシーにアカウントを 1 つずつ列挙する。
- permissions boundary が権限を追加で付与すると勘違いする。
- ロールチェーンではセッションが 1 時間に制限されることを忘れる。
このモジュールのサービス
変わりやすい数値 (AWS ドキュメントで確認済み)
- デフォルトでは、ロールあたり 20 個のマネージドポリシー (最大 25)、ユーザーあたり 10 個 (最大 20)、グループあたり 10 個、アカウントあたり 1,000 ロール (最大 10,000) です。 2026-10-16 確認 ↗
- マネージドポリシーは最大 6,144 文字です。インラインポリシーの合計は、ユーザー 2,048、グループ 5,120、ロール 10,240 文字です (空白は含みません)。 2026-10-16 確認 ↗
- ロールのセッションは max session duration に応じて 15 分から最大 12 時間で、指定しない場合のデフォルトは 1 時間です。 2026-10-16 確認 ↗
- ロールチェーンでは、ロールの max session duration に関係なく、セッションは最大 1 時間に制限されます。 2026-10-16 確認 ↗
- 評価順序：明示的な Deny → RCP → SCP → resource-based → identity-based → permissions boundary → セッションポリシー。明示的な Deny はすべての Allow に優先します。 2026-10-16 確認 ↗
- SCP は権限を付与せず、管理アカウントのユーザー / ロールとサービスリンクロールには適用されません。メンバーアカウントのルートユーザーには適用されます。 2026-10-16 確認 ↗
- SCP は最大 10,240 文字です。ルート、各 OU、各アカウントに直接アタッチできる SCP は最大 10 個で、OU のネストは最大 5 階層です。 2026-10-16 確認 ↗
- Organizations のデフォルトでは最大 10 アカウントです (Service Quotas で引き上げ可能)。 2026-10-16 確認 ↗
- ABAC：principal のタグとリソースのタグが一致する場合に操作を許可する 1 つのポリシーを用います。新しいリソースを追加してもポリシーの修正は不要です。 2026-10-19 確認 ↗
- RDS の IAM データベース認証：Signature V4 で署名したトークンを使い、有効期間は 15 分で、MariaDB、MySQL、PostgreSQL で利用できます。接続は SSL/TLS で暗号化されます。 2026-10-19 確認 ↗