CLF / ドメイン2 セキュリティとコンプライアンス

重要な内容

AWS IAM (Identity and Access Management)

は、「誰が」「どのAWSリソースに」「何をできるか」を管理するサービスです。 AWSアカウント内のユーザーやアプリケーションの認証（本人確認）と認可（操作の許可）を担当します。

CLF では、の扱い、ユーザー・グループ・ロール・ポリシーの役割の違い、 やといったセキュリティのベストプラクティスを判断できることが重要です。

Point
  • IAM = Identity and Access Management（IDとアクセスの管理） の略です。
  • Identity（アイデンティティ） は「誰であるか」、Access Management は「何を許可するか」を指します。
  • IAM は追加料金なしで利用できます。
  • 和訳

概要

AWSアカウントを作成した直後は、すべての操作ができるだけが存在します。 ルートユーザーを日常的に使うのは危険なため、 で管理者や開発者ごとのアイデンティティを作成し、必要な権限だけを与えて利用します。

IAM では、主に次の要素を組み合わせてアクセスを管理します。

概要の図 IAMユーザー人やアプリの identity IAMグループユーザーのまとまり IAMポリシー許可・拒否のルール IAMロール一時的に引き受ける権限 AWSリソースS3・EC2 など

代表的な使い道は、社員ごとの IAM ユーザー作成、部署単位のグループへの権限付与、 上のアプリケーションへのロールによる権限付与です。

試験では、「この要件にはユーザー・グループ・ロール・ポリシーのどれを使うか」と「セキュリティのベストプラクティスはどれか」を判断します。

主要技術

①ルートユーザーとIAMユーザー ⚠️ 頻出

は、アカウント作成時のメールアドレスでサインインする、すべての権限を持つ特別なアイデンティティです。 ユーザーは、IAM で作成する個々の利用者やアプリケーション向けのアイデンティティです。

アイデンティティ特徴判断ポイント
ルートユーザーアカウント内のすべての操作が可能です。日常業務では使わず、 を設定して厳重に保護します。
IAMユーザー付与されたポリシーの範囲だけ操作できます。日常の作業はこちらで行います。

ルートユーザーにしかできない作業は、アカウントの解約や一部の契約・支払い関連の設定など、ごく一部に限られます。

ルートユーザーが必要な作業の例補足
ルートユーザーのメールアドレス・パスワードの変更 に属さない単独のアカウントで必要です。アカウント名・連絡先・代替連絡先の変更はルートユーザーでなくても行えます。
アカウントの解約単独のアカウントではルートユーザーが必要です。Organizations のメンバーアカウントは管理アカウントから解約できます。
IAM ユーザーの権限の復旧唯一の IAM 管理者が自分の権限を誤って外したときに、ルートユーザーでサインインしてポリシーを直します。
すべてのプリンシパルを拒否する ポリシーの修正・削除誤った設定で誰もアクセスできなくなったバケットを元に戻します。
マーケットプレイスへの出品者登録 のリザーブドインスタンスを販売するための登録です。

ルートユーザーのメールアドレスは、退職や休暇で連絡が滞らないよう、会社が管理するグループ宛てのアドレスにすることが推奨されます。 ルートユーザーには MFA の設定が求められます。IAM のパスワードポリシーは、ルートユーザーのパスワードには適用されません。

Organizations を使う場合は、IAM の「ルートアクセス管理」（ルートアクセスの一元管理）を有効にすると、管理アカウントからメンバーアカウントのルートユーザーの認証情報（パスワード、、MFA など）を削除できます。 誤った S3 バケットポリシーの削除など、ルートユーザーが必要な一部の作業も、管理アカウントから特権タスクとして実行できます。 この機能を有効にした組織で新しく作成したアカウントは、初めからルートユーザーの認証情報を持ちません。

⚠️ 頻出: 「ルートユーザーを保護する方法」は、MFA の有効化、日常利用の禁止、アクセスキーを作成しない（作成済みなら削除する）が基本です。

②IAMグループ

グループは、複数の IAM ユーザーをまとめてポリシーを付与するための仕組みです。 ユーザー1人ずつにポリシーを付けるより、グループに付与するほうが管理が簡単になり、付け忘れや消し忘れを防げます。

  • グループにはユーザーだけが所属できます。グループの中にグループは入れられません。
  • ユーザーは複数のグループに所属できます。

⚠️ 頻出: 「多数のユーザーへ同じ権限を効率よく付与したい」という要件は、IAM グループが答えになります。

③IAMポリシーと最小権限 ⚠️ 頻出

ポリシーは、どの操作を許可または拒否するかを 形式で記述した文書です。 ユーザー、グループ、ロールにアタッチ（関連付け）して使います。

ポリシーの種類特徴判断ポイント
AWS管理ポリシーAWSがあらかじめ用意したポリシーです。一般的な職務に合わせて手軽に使えます。
カスタマー管理ポリシー利用者が自分で作成するポリシーです。組織の要件に合わせて細かく制御できます。

権限設計の基本はの原則です。 業務に必要な操作だけを許可し、不要な権限は与えません。

Point
  • Principle of Least Privilege（最小権限の原則） は、必要最小限の権限だけを与える考え方です。
  • ポリシーで明示的に許可されていない操作は、初期状態ではすべて拒否されます（暗黙の拒否）。
  • 和訳

⚠️ 頻出: 「必要な権限だけを付与すべき」という選択肢は、最小権限の原則としてほぼ常に正しい方針です。

ポリシーの評価では、明示的な拒否（Deny）が最も優先されます。 あるポリシーで許可していても、別のポリシーで明示的に拒否していれば、その操作はできません。 どのポリシーでも許可されていない操作は、暗黙の拒否で実行できません。

AWS の推奨は、まず職務に合う AWS 管理ポリシーで始め、利用状況が分かってきたら、必要な操作と対象リソースだけを書いたカスタマー管理ポリシーへ絞り込む進め方です。 AWS 管理ポリシーは AWS が保守し、新しいサービスや操作が増えると AWS が更新します。一方で全利用者向けに作られているため、自社の職務に対しては最小権限にならないことがあります。 IAM Access Analyzer は、 に記録された実際のアクセス履歴をもとに、使った操作だけを許可するポリシーを生成できます。

④IAMロールと一時的な認証情報 ⚠️ 頻出

ロールは、特定のユーザー専用ではなく、必要なときに引き受けて使う権限のセットです。 ロールにはパスワードやのような長期的な認証情報がなく、引き受けたときに有効期限付きのが発行されます。

利用シーン説明
上のアプリケーションが へアクセスEC2 インスタンスにロールを割り当てます。アクセスキーをサーバー内に保存する必要がなくなります。
関数が他サービスへアクセスLambda 実行ロールで権限を付与します。
別のAWSアカウントからのアクセスアクセスにロールを使います。
社内の既存IDでAWSを利用（）外部のIDでサインインし、ロールの権限で操作します。

⚠️ 頻出: 「EC2 のアプリケーションに S3 への権限を安全に与える方法」は、アクセスキーをコードや設定ファイルに埋め込むのではなく、IAM ロールを使うのが正解です。

Point
  • Role（ロール） は「役割」という意味です。人に固定された ID ではなく、必要なときにかぶる「帽子」のイメージで覚えます。
  • 一時的な認証情報は AWS STS（Security Token Service） が発行します。
  • 和訳

⑤MFAと認証情報の管理 ⚠️ 頻出

のアイデンティティは、用途に応じて異なる認証情報を使います。

認証情報用途判断ポイント
パスワードへのサインインパスワードポリシーで強度や有効期限を管理できます。
CLI や からのプログラムによるアクセス長期的な認証情報のため、埋め込みや共有を避け、可能ならロールで代替します。
パスワードに追加する多要素認証認証アプリや物理デバイスで「知識+所持」の2要素にします。

MFA（Multi-Factor Authentication）は、パスワードが漏えいしても不正サインインを防ぎやすくする仕組みです。 特にと強い権限を持つユーザーには MFA の有効化が推奨されます。

⚠️ 頻出: 「アカウントのセキュリティを強化する最初の一歩」として、ルートユーザーへの MFA 設定と、日常作業用の IAM アイデンティティの利用が問われます。

論点押さえること
パスワードポリシーIAM ユーザーのパスワードに、最小文字数、文字の種類、有効期限、過去のパスワードの再利用禁止などをアカウント全体で強制します。ルートユーザーのパスワードとアクセスキーには適用されず、失敗回数によるロックアウトも設定できないため、MFA と組み合わせます。
MFA の種類パスキーや FIDO セキュリティキー、認証アプリ（仮想 MFA）、ハードウェアの TOTP トークンがあります。フィッシングに強いパスキーやセキュリティキーが推奨されます。
人の CLI 利用 でサインインすると、CLI でも有効期限付きのを使え、長期のアクセスキーを PC に保存せずに済みます。
アクセスキーが必要な場面IAM ロールにも IAM Identity Center にも対応しないサードパーティーのツールなどに限り、IAM ユーザーのアクセスキーを使います。権限を絞り、不要になったら更新・削除します。
アクセスキーの漏えいパスワードの変更や MFA の追加ではアクセスキーによる操作は止まりません。漏れたキーを無効化して削除し、新しい認証情報へ切り替えます。

⑥IAM Identity Centerと関連機能

複数のAWSアカウントや複数の業務アプリケーションを使う組織では、 ユーザーを個別に作るよりも、 でサインインを一元管理する方法が推奨されています。

機能・サービス役割判断ポイント
AWS IAM Identity Center複数アカウントへの（SSO）を提供します。「複数アカウントのユーザー管理を一元化」で選びます。
IAM Access Analyzer外部と共有されているリソースや未使用の権限を検出します。「意図しない外部アクセスの発見」で選びます。
IAM 認証情報レポートアカウント内ユーザーの認証情報の状態を一覧化します。パスワードやの棚卸しと監査に使います。
最終アクセス情報（アクセスアドバイザー）ユーザー、ロール、ポリシーで許可されたサービスを最後に使った日時を示します。 の管理アカウントでは やアカウント単位のアクセスレポートも作れます。「使われていない権限を見つけて削る」で選びます。

では、IAM の設定は利用者の責任です。 ユーザーの作成、権限の付与、 の設定は AWS が代行するものではなく、利用者が適切に管理します。

IAM Identity Center では、ユーザーを Identity Center 自身のディレクトリで作るほか、 や Microsoft Entra ID・Okta などの外部 ID プロバイダーを ID ソースにできます。 職務ごとの権限は「許可セット」として一度定義し、ユーザーやグループとアカウントの組み合わせに割り当てると、各アカウントに IAM ロールとして展開されます。 利用者は AWS アクセスポータルに1回サインインし、割り当てられたアカウントやアプリケーションを選んで使います。

試験対策

CLF の問題では、まず「誰に・何に権限を与えたいのか」を確認します。 人が使うならユーザーとグループ、AWSサービスやアプリケーションに与えるならロール、と整理すると選びやすくなります。

問題文のキーワード優先して考える機能理由
の保護有効化・日常利用の禁止最も強い権限を持つため厳重に保護します。
多数のユーザーに同じ権限を付与グループユーザーをまとめて権限管理できます。
のアプリに への権限を付与の保存が不要で安全です。
必要最小限の権限だけを付与の原則IAM の基本的なベストプラクティスです。
パスワード漏えいへの追加対策MFA多要素認証で不正サインインを防ぎます。
CLI・ からのアクセスアクセスキー（またはロール）プログラムによるアクセス用の認証情報です。
複数アカウントのサインインを一元化 で複数アカウントを一元管理できます。
誰がどんな操作をしたかの記録IAM ではなく操作履歴の記録サービスです。

よくある誤答は、権限の管理（IAM）と操作履歴の記録（CloudTrail）の混同です。 IAM は「操作を許可・拒否する」サービスであり、「実行された操作を記録する」のは CloudTrail です。 また、EC2 からのアクセスにアクセスキーを埋め込む選択肢は、ロールがある場合は誤りと考えます。

参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください