2026.07.21 インフラ

AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説

AWS IAM（Identity and Access Management）は、AWSアカウント内で「誰が」「どのリソースに」「どの操作を許すか」を制御する権限管理の基盤サービスです。この記事では、ユーザー・グループ・ロール・ポリシーという4つの構成要素と、リクエストの許可・拒否を決める権限評価ロジック、そして長期のアクセスキーとSTSによる一時認証情報の違いまでを一次情報で整理します。ロールやポリシーのクォータ、最小権限・MFA・IAM Identity Center・Access Analyzerといった権限設計のベストプラクティス、さらに採用すべき方針と避けるべきアンチパターンまで、実装者が設計時に迷う論点を具体的な数値と条件で示します。

目次

まとめ：AWS IAMの仕組み・認証情報・権限設計の要点

AWS IAMは、AWSリソースへのアクセスを認証（誰か）と認可（何を許すか）で制御するサービスで、追加料金なくアカウントに標準で付いてきます。中核は、ログイン主体である「ユーザー」、権限をまとめて配る「グループ」、一時的に権限を引き受ける「ロール」、そして許可内容をJSONで記述する「ポリシー」の4要素です。ポリシーをユーザーやロールにアタッチして初めて操作が通り、何もアタッチしなければ既定は拒否になります。

設計で効いてくるのは、権限評価が「明示的なDenyを最優先し、明示的なAllowが無ければ拒否する」ルールで動くこと、そして人やアプリに長期のアクセスキーを配らず、ロール経由のSTS一時認証情報へ寄せることです。ロールのセッションは既定1時間・最大12時間で自動失効するため、鍵の漏えいリスクを構造的に下げられます。判断に迷う実装者は、まず本記事の採用条件と避けるべき設計の節で、自社アカウントの権限構成を当てはめてください。

AWS IAMの仕組みと4つの構成要素（ユーザー・グループ・ロール・ポリシー）

IAMを設計に落とし込むには、まず「認証と認可の分担」と「4つの構成要素の役割」を押さえます。ここを曖昧にしたまま権限を配ると、必要以上の操作を許してしまう過剰権限や、逆に業務が止まる権限不足を招きます。

ルートユーザーとIAMアイデンティティの違い・IAMが担う認証と認可

AWSアカウントには、作成時のメールアドレスでログインする「ルートユーザー」と、IAMで発行する「IAMアイデンティティ」の2系統があります。ルートユーザーは請求設定や解約を含む全操作が可能な最上位権限のため、日常運用では使わず、MFAで固く保護して封印するのが原則です。実際の作業は、IAMで作ったユーザーやロールに必要な権限だけを与えて行います。IAMは、リクエスト元が本人かを確かめる「認証」と、その主体に操作を許すかを判定する「認可」の両方を担う点が、単なるログイン機能との違いです。

ユーザー・グループ・ロールの違いと権限を配る単位ごとの使い分け

ユーザーは特定の人やアプリに紐づく永続的な主体で、パスワードやアクセスキーといった認証情報を持ちます。グループはユーザーの集合で、同じ職務のメンバーにポリシーをまとめて配る器です。ロールは特定の人に固定されず、必要なときだけ一時的に引き受ける権限のセットで、引き受けた瞬間にSTSが短命の認証情報を発行します。EC2やLambdaなどのAWSサービス、別アカウント、外部IdP経由の人間には、ユーザーではなくロールを割り当てるのが定石です。長期の鍵を配らずに済むため、権限の受け渡しが安全に閉じます。

ポリシーの種類（アイデンティティベース／リソースベース／許可境界）とJSON構造

ポリシーは許可内容を定義したJSONドキュメントで、Effect（AllowかDeny）、Action（操作）、Resource（対象）、任意のCondition（条件）で1文を組み立てます。ユーザーやロールに付けるアイデンティティベースのポリシーが基本で、S3バケットやSQSキュー側に付けて「誰からのアクセスを許すか」を定めるリソースベースのポリシーと組み合わせるのが実務の形です。さらに、権限委任の上限を定める許可境界（Permission Boundary）や、AWS Organizationsでアカウント横断の枠をはめるSCP／RCPを重ねることで、多層の制御を設計できます。AWS管理ポリシーをそのまま使うと権限が広めになりがちなので、まず管理ポリシーで動作を確認し、そこからカスタマー管理ポリシーへ絞り込む順序が扱いやすいです。

権限評価の仕組みと認証情報（長期アクセスキー vs STS一時認証情報）

設計の可否を分けるのは、リクエストが最終的に許可されるか拒否されるかを決める評価ロジックと、そこに渡す認証情報の種類です。ここを理解しないまま権限を足していくと、「なぜか通らない」「意図せず通ってしまう」の両方が起こります。

ポリシー評価ロジック：デフォルト拒否・明示的Allow・明示的Denyが最優先

IAMの権限評価は、いずれのポリシーにも許可がなければ拒否する「デフォルト拒否」から始まります。どこかのポリシーに明示的なAllowがあれば操作は通り、そのうえでどれか1つでも明示的なDenyがあれば、他の許可を打ち消して必ず拒否になります。この「明示的Denyが最優先」という順序が、権限設計の安全弁です。広めのAllowを配ったうえで、触れてほしくない操作だけをDenyで確実に塞ぐ、といった多層の設計が成り立ちます。SCPや許可境界による上限も、この評価の中で「越えられない天井」として働きます。

アクセスキー（長期）とIAMロール／STS（一時認証情報）の違い

認証情報には、失効しない長期のアクセスキーと、STSが発行して数十分から数時間で切れる一時認証情報の2種類です。アクセスキーはコードや設定ファイルに直書きされて漏えいする事故が起きやすく、AWSはワークロードにも人間にもロール経由の一時認証情報を使うよう求めています。EC2にはインスタンスプロファイル、Lambdaには実行ロール、外部の人間にはIdPフェデレーションでロールを引き受けさせれば、長期キーをどこにも置かずに運用できるのが要点です。CI/CDやオンプレミスのサーバーからも、OIDCフェデレーションやIAM Roles Anywhereでキーレス化する設計が採れます。

設計時に押さえておく主要クォータ（既定値・2026年7月時点）

IAMには変更できない、あるいは申請で引き上げるクォータがあり、大規模アカウントの設計では最初に確認しておきます。ロールは既定1,000（申請で最大10,000）、グループは既定300（最大500）、カスタマー管理ポリシーは既定1,500（最大10,000）です。1つのエンティティにアタッチできる管理ポリシーは、ユーザー10・ロール10・グループ10が既定の上限です。ロールを引き受けたセッションの有効期間は既定1時間で、900秒から最大12時間まで設定できます。STSのリクエストは既定でアカウント・リージョンあたり毎秒600件までさばけます。

クォータ項目 既定値（最大）
ロール／アカウント 1,000（10,000）
グループ／アカウント 300（500）
カスタマー管理ポリシー 1,500（10,000）
管理ポリシーのアタッチ（ユーザー／ロール） 各10（20／25）
ロール信頼ポリシー長 2,048文字（8,192）
ロールセッション有効期間 既定1時間・900秒〜12時間
STSリクエスト 600件/秒（申請で増枠）

AWS IAMの権限設計ベストプラクティス（2026年時点）

IAMの設計品質は、派手な仕組みよりも運用の地味な積み重ねで決まります。AWSが公式に示す指針を、実装の手順に落として整理しましょう。概念全体の位置づけはクラウドとは何か、AWSの仕組みと判断軸を解説した記事、AWS環境の初期構築でIAMをどう組み込むかはAWS環境構築の手順を解説した記事が参考になります。

最小権限の徹底とルートユーザーの保護・フィッシング耐性MFA

権限は、業務を完了できる最小限だけを、特定のリソースと条件に絞って与えます。ルートユーザーは初期設定を終えたら封印し、MFAで固く守るのが前提です。すべての人間のユーザーにMFAを必須とし、AWSはパスキーやセキュリティキーといったフィッシング耐性の方式を推奨しています。ポリシーにはConditionで「TLS必須」「特定IPからのみ」といった条件を足し、許可の範囲を状況で締めましょう。長期のアクセスキーがどうしても要る場面では、最終アクセス情報を見ながら定期的にローテーションする運用を組みます。

IAM Identity Centerによる集中管理とフェデレーション

ユーザーをアカウントごとに個別作成すると、退職者の権限削除漏れや棚卸しの手間が膨らみます。複数アカウント運用では、IAM Identity Center（旧AWS SSO）で人の認証を1か所に集約し、既存のIdPや社内ディレクトリと連携させる設計が扱いやすいです。人はIdPでログインしてロールを引き受け、AWS側にはユーザー実体を持たせない構成にすれば、認証情報の管理点が1つに閉じます。MFAやSSOなど認証基盤全体の選定は認証・ID管理の違いと選定を解説した記事で判断軸を確認できます。

IAM Access Analyzerによる検証と不要権限の棚卸し

付与した権限が広すぎないかは、勘ではなくツールで検証するのが確実です。IAM Access Analyzerは、CloudTrailのアクセス実績から最小権限のポリシーを生成し、記述したポリシーを100を超えるチェックで検証できます。公開・クロスアカウントのアクセスがデプロイ前に想定どおりかも先読みで分析できるため、意図しない外部公開を先回りで防げるのが利点です。あわせて、最終アクセス情報を使って使われていないユーザー・ロール・権限を定期的に洗い出し、不要なものを削っていく棚卸しを運用サイクルに組み込みます。

AWS IAMの設計で採用すべき方針と避けるべきアンチパターン

ここでは玉虫色にせず判断を言い切ります。IAMは自由度が高いぶん、方針を決めずに権限を足していくと、誰も全体像を説明できない状態に陥ります。自社アカウントのどこから手を付けるかを、条件付きで見極めてください。

採用が効く権限設計の条件（ロール前提・アカウント分離・境界設計）

効果が出るのは、次の条件を満たす設計です。まず、人にもワークロードにも長期キーを配らず、ロールとSTS一時認証情報を前提に組むことです。次に、本番・検証・監査といった役割でAWSアカウントを分け、Organizationsのガードレール（SCP／RCP）で越えてはいけない操作を全体に敷きます。そのうえで、権限管理を委任するチームには許可境界で上限を設け、現場が自律的にポリシーを作れる余地を残すのが扱いやすい構成です。AWS上でこうした権限設計やアカウント分離を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で構成の妥当性を検討できます。

避けるべき権限設計のアンチパターンと現場ではまりやすい失敗例

避けるべきなのは、まず全開のAction: "*"を配って「動いたからよし」とする設計です。過剰権限は侵害時の被害を一気に広げます。次に、アクセスキーをソースコードや共有ドキュメントに直書きする運用で、これは漏えい事故の典型です。ルートユーザーのアクセスキーを作って自動処理に使うのも避けます。さらに、明示的Denyの評価順を理解せずにAllowだけを積み重ね、どのポリシーで何が通るか誰も追えなくなる状態も失敗パターンです。判断に迷う境界では、まず狭い権限から始めてAccess Analyzerの検証で不足分だけを足す、という「絞ってから広げる」順序が安全です。

よくある質問

AWS IAMの権限設計で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

AWS IAMの利用に料金はかかりますか？

IAM自体は追加料金なしで、AWSアカウントに標準で付いてくる機能です。ユーザー・グループ・ロール・ポリシーをいくつ作っても、IAMの利用そのものに課金は発生しません。ただし、IAMで許可した操作の結果として使ったEC2やS3などのリソースには通常どおり料金がかかるため、権限設計とコスト設計は別軸で考えます。

IAMユーザーとIAMロールはどう使い分けますか？

特定の人やアプリに固定的に紐づけるならユーザー、必要なときだけ一時的に権限を引き受けさせるならロールです。AWSのサービス、別アカウント、外部IdP経由の人間には、長期キーを持たせずに済むロールを使うのが定石です。ロールはSTSが短命の認証情報を発行するため、漏えいしても時間で失効し、被害を抑えられます。

アクセスキーは使わないほうがよいですか？

失効しない長期のアクセスキーは、直書きによる漏えい事故が起きやすいため、AWSはロール経由の一時認証情報を優先するよう求めています。EC2はインスタンスプロファイル、CI/CDはOIDCフェデレーション、オンプレミスはIAM Roles Anywhereでキーレス化できます。どうしても長期キーが要る場合は、最終アクセス情報を見て定期的にローテーションしてください。

ポリシーで許可したのにアクセスが拒否されるのはなぜですか？

権限評価は、どこかに明示的なDenyがあれば他の許可を打ち消して必ず拒否する仕組みだからです。SCPや許可境界、リソースベースのポリシーが上限として効いている場合も、アイデンティティ側でAllowしても通りません。拒否の原因は、IAM Policy Simulatorやアクセス分析で、どのポリシーが効いているかを1つずつ切り分けて特定します。

複数のAWSアカウントの権限はどう一元管理しますか？

IAM Identity Center（旧AWS SSO）で人の認証を1か所に集約し、AWS Organizationsのアカウント群にロールを割り当てて集中管理します。既存のIdPや社内ディレクトリと連携させれば、AWS側にユーザー実体を持たずに済むのが利点です。アカウント横断の禁止事項はSCP／RCPでガードレールとして敷き、越えられない天井を全体に設定します。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る