変更要約: in-scope サービス網羅: ID管理(Cognito/Directory Service/IAM Identity Center)・鍵/証明書(CloudHSM/ACM)・脅威検出(GuardDuty/Inspector/Macie/Detective/Security Hub)・ネットワーク防御(Network Firewall/Firewall Manager)・コンプライアンス(Artifact/Audit Manager)を各節に追加
1.1IAM とアクセス管理
IAM のユーザー・グループ・ロール・ポリシー、最小権限の原則、EC2/サービス向けの IAM ロール、フェデレーションといったアクセス設計の基礎を理解します。SAA-C03 の安全なアーキテクチャ設計の出発点です。
安全なアーキテクチャの土台は 「誰が（プリンシパル）何に（リソース）どんな操作（アクション）をできるか」を正しく制御する ことです。AWS では IAM（Identity and Access Management）がこれを担います。SAA-C03 は AWS の設計を問うアソシエイト資格で、Fundamentals より一段深く「シナリオに対して適切なサービスと構成を選べるか」が問われます。IAM はその最初の柱＝安全なアーキテクチャ設計の出発点です。
1.1.1IAM の構成要素
- ユーザー/グループ：ユーザーは個人、グループは複数ユーザーへ権限を一括付与する。
- ロール：一時的な認証情報を引き受ける仕組み。EC2 やサービスに付与し、キーを埋め込まない。
- ポリシー：JSON で許可/拒否を定義し、ユーザー/グループ/ロールにアタッチする。
- 最小権限の原則：必要最小限の権限だけを与える。
| 要素 | 役割 | 使いどころ |
|---|---|---|
| ユーザー | 個人の長期 ID | 人間の操作（最小限に） |
| グループ | ユーザーへ権限を一括付与 | 部署/職務ごとの権限 |
| ロール | 一時認証情報を引き受け | EC2/Lambda/他アカウント/SSO |
| ポリシー | 許可/拒否を JSON で定義 | 上記にアタッチ |
1.1.2ポリシー評価とロールの使い分け
ポリシー評価には重要なルールがあります：既定はすべて拒否（暗黙の拒否）、許可は明示的な Allowで与え、明示的な Deny は常に最優先で勝ちます。複数のポリシー（アイデンティティベース／リソースベース）が重なっても、1つでも Deny があれば拒否されます。また、人間でない処理（EC2 上のアプリ、Lambda、別アカウントからのアクセス）には長期キーを埋め込まず必ずロールを使うのが鉄則です。ロールは一時認証情報を発行するため、漏えい時のリスクが小さく、ローテーションも自動です。
組織の規模が大きくなると、IAM ユーザーを1人ずつ作るよりフェデレーションが有利です。IAM Identity Center（旧 AWS SSO）や SAML/OIDC で、社内の既存 ID（Microsoft Entra ID 等）から AWS ロールを引き受けさせます。複数の AWS アカウントを束ねる AWS Organizations と組み合わせ、SCP（サービスコントロールポリシー） でアカウント全体の上限権限（ガードレール）を設定するのも頻出の設計です。
シナリオ：3層 Web アプリの権限設計。 EC2 上のアプリが S3 と DynamoDB を読む→IAM ロールを EC2 にアタッチ（キー埋め込み禁止）。運用担当者は IAM Identity Center 経由で Entra ID の ID から読み取り専用ロールを引き受け。本番アカウントでは SCP で「特定リージョン以外の作成を禁止」のガードレールを設定。最小権限で必要な操作だけ Allow します。
混同に注意：
①グループは権限の一括付与（ロールではない）／ロールは一時認証情報の引き受け。
②明示的 Deny は常に Allow に勝つ、既定は暗黙の拒否。
③EC2/Lambda/クロスアカウントはキーでなくロール。
④SCP はアカウントの上限（ガードレール）で、それ自体は権限を付与しない（IAM ポリシーで Allow が別途必要）。
Q. グループとロールの違いは？ グループは複数ユーザーへ権限を一括付与する入れ物、ロールは EC2/外部 ID 等が一時的に引き受ける権限の集合。Q. 明示的拒否と暗黙の拒否は？ 何も許可がなければ暗黙で拒否、明示的 Deny は他のどの Allow よりも優先。Q. SCP とは？ Organizations で各アカウントの最大権限を制限するガードレール（権限の付与はしない）。
「EC2 上のアプリが他サービスへアクセス＝IAM ロールを付与（キー埋め込み禁止）」「明示的 Deny が最優先」「大規模な ID 管理＝IAM Identity Center/フェデレーション」「アカウントのガードレール＝SCP」は SAA 頻出です。グループ＝一括付与、ロール＝一時認証情報。
1.1.3その他の主要 in-scope サービス（ID 管理・ディレクトリ）
IAM は AWS リソースへのアクセス制御ですが、アプリ利用者や社員の ID には別のサービスを使います。Amazon Cognito はアプリのユーザー認証（サインアップ/サインイン）と外部 ID プロバイダー連携（ソーシャルログインや SAML/OIDC）を提供し、Web/モバイルアプリのエンドユーザー認証が要るときに選びます。AWS Directory Service はマネージドな Microsoft Active Directoryを提供し、オンプレ AD との信頼関係や、AD 認証を要する EC2/RDS と統合したいときに選びます。組織全体の AWS への一元的なサインインと権限割り当てには AWS IAM Identity Center を使い、複数アカウントへのシングルサインオンを実現します。
| やりたいこと | サービス |
|---|---|
| アプリ利用者の認証・外部 ID 連携 | Amazon Cognito |
| マネージド Active Directory | AWS Directory Service |
| 複数アカウントへの SSO・権限割り当て | AWS IAM Identity Center |
1.1.4この節のまとめ
- IAM＝ユーザー/グループ・ロール・ポリシーでアクセスを制御。明示的 Deny が最優先
- EC2/サービス/クロスアカウントにはロール（キー禁止）、最小権限、ルートは保護
- 大規模はIAM Identity Center/フェデレーション、アカウント上限はSCP（Organizations）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. EC2 上のアプリが S3 にアクセスする際の安全なベストプラクティスはどれですか？
Q2. 多数のユーザーに同じ権限をまとめて付与するのに適した IAM の仕組みはどれですか？
Q3. IAM で「誰が何にアクセスできるか」を許可/拒否で定義する JSON ドキュメントはどれですか？