AWS IAM
AWS Identity and Access Management
概要
AWS IAM は、誰が（認証）どの AWS リソースに対して何を（認可）できるかを制御する、アカウントの基盤となるセキュリティサービスです。ユーザー、グループ、ロールといったID と、それらに付与するポリシーによって権限を定義します。IAM 自体は追加料金なしで利用でき、すべての AWS 操作はこの認可レイヤーを通過します。最小権限の原則に従い、必要な操作だけを許可する設計が、アカウント全体の安全性を左右します。
主要な概念
ユーザー・グループ・ロール
IAM ユーザーは長期的な認証情報を持つ個人や用途を表し、グループはユーザーをまとめて権限を一括付与する仕組みです。ロールは特定の権限セットを持つ「被り物」で、誰でも一時的に引き受け（AssumeRole）られます。EC2 や Lambda にロールを割り当てれば、アクセスキーをコードに埋め込まずに一時的な認証情報を安全に取得できます。
ポリシーの種類
アイデンティティベースポリシーは ユーザー/グループ/ロールにアタッチして権限を定義し、リソースベースポリシー（S3バケットポリシーなど）はリソース側に「誰を許可するか」を書きます。さらにアカウント全体の上限を定める Service Control Policy（Organizations）、ロール引き受け時に権限を絞るパーミッションバウンダリーやセッションポリシーがあります。
ポリシー評価ロジック
リクエストの許可可否は明確なルールで決まります。明示的な Deny が一つでもあれば常に拒否されます。Deny がなく、いずれかのポリシーに明示的な Allow があれば許可、どこにも Allow がなければ暗黙の拒否（デフォルト拒否）となります。SCP やパーミッションバウンダリーなど複数の境界がある場合は、そのすべてで許可されて初めてアクセスできます。
最小権限とロールの活用
最小権限の原則とは、業務に必要な権限だけを与え、不要な権限は持たせない考え方です。長期のアクセスキーを配るより、ロールによる一時認証情報を使う方が安全で、IAM Access Analyzer で過剰な権限や外部公開を検出できます。クロスアカウントアクセスもロールの引き受けで実現するのが定石です。
多要素認証とルートユーザー保護
パスワードに加えて MFA を有効にすると、認証情報が漏えいしても不正利用を防ぎやすくなります。特にすべての権限を持つルートユーザーは MFA を必須にし、日常運用では使わず、請求設定など限られた操作のためだけに使うのがベストプラクティスです。
典型的なユースケース
- EC2やLambdaにIAMロールを割り当て、アクセスキーを埋め込まずにAWS APIを呼ぶ
- 部門やジョブ機能ごとにグループを作り、ポリシーで権限をまとめて管理する
- 別アカウントのロールを引き受けるクロスアカウントアクセスを安全に構成する
- SCPで組織全体に対しガードレール（利用可能リージョンやサービスの制限）を敷く
- MFAと最小権限ポリシーで、特権操作や本番リソースへのアクセスを厳格化する
試験での出題観点
IAM は全試験で問われ、特にセキュリティ系設問の中心です。CLF では責任共有モデルとルートユーザー保護・MFA が、SAA/DVA では「アプリからAWS APIを呼ぶならアクセスキーではなくロール」が定番の正解パターンです。ポリシー評価ロジック（明示的Denyが最優先、Allowがなければ暗黙の拒否）は文章問題で頻出で、SCP・パーミッションバウンダリー・リソースベースポリシーが重なるケースの可否判定はSAPで問われます。クロスアカウントアクセスはほぼ常にロールのAssumeRoleが答えになります。「キーを配らない」「最小権限」「明示的Deny優先」を反射的に判断できるかが鍵です。
関連サービス
最終更新日: 2026-06-24
本ページの内容は、AWS公式ドキュメントを基に作成し、運営者が編集・監修しています。詳しくは編集・品質管理方針をご覧ください。