AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

1. サービス概要

AWS Identity and Access Management (IAM) は、「誰が」「どのリソースに対して」「どの操作を」行えるかを制御する、AWSのアクセス管理サービスです。 認証（誰であるか）と認可（何を許可するか）を担い、最小権限の原則に基づくアクセス制御の基盤となります。

IAMはグローバルサービス（リージョンに依存しない）で、利用は無料です。主なユースケースは、アカウント内の権限管理、EC2／Lambda等のサービスへの権限委譲（ロール）、クロスアカウントアクセス、外部IdPとのフェデレーション、人間のサインオン管理（IAM Identity Center）などです。

2. 主な特徴と機能

2.1 IAMユーザー・グループ

IAMユーザーは個人やアプリ用の長期的なID（パスワード／アクセスキーを持つ）です。IAMグループはユーザーをまとめ、ポリシーを一括付与する単位です（グループにロールは割り当てられず、グループの入れ子もできません）。 近年は人間のアクセスにはユーザーではなくIAM Identity Centerの利用が推奨されます。

2.2 IAMロールとSTS

IAMロールは、永続的な認証情報を持たず一時的な認証情報（AWS STSが発行）を使って引き受ける（AssumeRole）IDです。ロールは信頼ポリシー（誰が引き受けられるか）と許可ポリシー（何ができるか）の2つで構成されます。 EC2への割り当て（インスタンスプロファイル）、Lambda等のサービスロール、クロスアカウント、SAML／OIDCフェデレーションなどに使います。

2.3 ポリシーの種類

• IDベースポリシー: ユーザー／グループ／ロールにアタッチ。AWS管理・カスタマー管理・インラインの3種。
• リソースベースポリシー: リソース側に付与（S3バケットポリシー、SQS/SNS、KMSキーポリシー、Lambdaリソースポリシー等）。クロスアカウント許可に有効。
• 権限境界（Permissions Boundary）: IDが持てる権限の上限を定義（実際の権限は許可ポリシーとの積集合）。
• SCP（Service Control Policy）: AWS Organizationsでアカウント全体の上限を設定（権限を付与はせず制限のみ）。
• セッションポリシー: AssumeRole時に渡し、その場限りでさらに権限を絞る。

2.4 ポリシー評価ロジック

ポリシーはJSON（Effect／Action／Resource／Condition）で記述します。評価は「デフォルト拒否（暗黙的Deny）→ 明示的Allow → 明示的Denyが最優先」。 いずれかのポリシー（SCP・権限境界・リソースベース等）に明示的Denyがあれば必ず拒否され、すべてに許可がなければ暗黙的に拒否されます。

2.5 多要素認証 (MFA) とルートユーザー保護

MFAは仮想MFA、ハードウェアトークン、FIDOセキュリティキー／パスキーに対応します。 ルートユーザーは最上位権限を持つため、日常利用せず、MFAを有効化し、アクセスキーは作成・保持しないのがベストプラクティスです。

2.6 監査・分析ツール

• IAM Access Analyzer: 外部公開アクセスの検出、未使用権限の特定、ポリシー検証、CloudTrailからの最小権限ポリシー生成。
• 認証情報レポート / アクセスアドバイザー: 認証情報の状態一覧や、各サービスへの最終アクセス日時を確認し棚卸し。

2.7 IAM Identity Center とフェデレーション

IAM Identity Center（旧 AWS SSO）は、複数アカウント・アプリへのシングルサインオンと一元的な権限割り当てを提供します。外部IdP（Okta、Entra ID等）や、SAML 2.0／OIDCによるフェデレーションにも対応します。

3. アーキテクチャおよび技術要素

1. 管理者がユーザー／グループ／ロールを作成し、ポリシーを定義・アタッチ。
2. プリンシパルがアクセスキーや一時認証情報、フェデレーションで認証。
3. リクエスト時に、適用される全ポリシー（IDベース・リソースベース・SCP・権限境界・セッション）を評価。
4. 明示的Denyがなく、いずれかで明示的Allowがあれば許可。なければ暗黙的に拒否。
5. ロール引き受けはSTSが一時認証情報（数分〜数時間）を発行し、期限切れで自動失効。

IAMはAWSのグローバル基盤の一部として高可用・高スケーラビリティを提供し、利用者は基盤管理が不要です。

4. セキュリティと認証・認可

• 最小権限の原則: 必要な権限のみ付与し、Access Analyzerやアクセスアドバイザーで継続的に絞り込む。
• ロール優先・キー回避: 長期アクセスキーは避け、EC2/Lambda等にはIAMロール（一時認証情報）を使う。やむを得ない場合はキーを定期ローテーション。
• MFAの強制: ルートと特権ユーザーにMFAを必須化。条件キー aws:MultiFactorAuthPresent で操作を制限可能。
• ガードレール: 組織全体はSCP、個別IDは権限境界で上限を設定。
• 条件（Condition）: 送信元IP、VPC、MFA有無、タグ等で許可を絞る。ABAC（タグベース）でスケーラブルに管理。
• パスワードポリシー: 長さ・複雑さ・有効期限・再利用禁止を強制。

5. 料金形態

AWS IAM および IAM Access Analyzer（外部アクセス分析）は無料で利用できます。ただしIAMと連携する他サービス（EC2、S3、RDSなど）の利用料金は別途発生します。

6. よくあるアーキテクチャ・設計パターン

• サービスへの権限委譲: EC2／Lambda／ECSタスクにIAMロールを割り当て、アクセスキーを埋め込まずにAWSへアクセス。
• クロスアカウントアクセス: 信頼ポリシーで相手アカウントを許可し、AssumeRoleで一時的に権限を取得。
• フェデレーション: 企業IdP（SAML）やWebアイデンティティ（OIDC）からロールを引き受け、IAMユーザーを増やさない。
• 人間のサインオン: IAM Identity Centerで複数アカウントへSSOと権限セットを一元管理。
• ガードレール: Organizations＋SCPでアカウント全体の禁止事項を強制し、権限境界で委譲先の上限を制御。

7. 設定・デプロイ手順（ハンズオン例）

1. ルートユーザーにMFAを設定し、日常作業用のIAMユーザー／Identity Centerユーザーを用意。
2. 職務に応じたグループ（または権限セット）を作成し、管理ポリシーをアタッチ。
3. EC2やLambdaにはサービスロールを作成し、最小権限の許可ポリシーを付与。
4. 必要に応じて権限境界やSCP、条件（MFA必須・送信元IP）でガードレールを設定。
5. Access Analyzerと認証情報レポートで定期的に棚卸しし、不要権限を削除。

8. 試験で問われやすいポイント