AWS Certified Cloud Practitioner (CLF-C02) #4 Domain 2-1 セキュリティ — 責任共有モデル、IAM の基礎

#3 までで Domain 1 を終えました。ここから試験の 30% を占める最大のドメイン — Security and Compliance に入ります。このドメインは 2 編に分けて扱います。本記事は責任共有モデルと IAM の基礎、次の #5 はコンプライアンスと暗号化です。

責任共有モデル (Shared Responsibility Model) #

CLF-C02 で最も頻繁に出題される単一概念です。「AWS がどこまで責任を持ち、どこから顧客が責任を持つのか」を 1 枚の図にまとめたモデルです。

            ┌────────────────────────────────┐
            │   Customer responsibility      │
   IN       │   ── SECURITY IN THE CLOUD ──  │
   THE      │   顧客データ、プラットフォーム │
   CLOUD    │   IAM ポリシー、OS パッチ、FW  │
            │   ネットワーク / FW 設定       │
            │   クライアント / サーバー側暗号│
            └────────────────────────────────┘
            ┌────────────────────────────────┐
            │   AWS responsibility           │
   OF       │   ── SECURITY OF THE CLOUD ──  │
   THE      │   ハードウェア、ネットワーク   │
   CLOUD    │   ホスト OS / ハイパーバイザー │
            │   グローバルインフラ (Region) │
            │   サービス自体のソフトウェア   │
            └────────────────────────────────┘

中核となる用語は 2 つです。

• Security OF the Cloud — AWS が責任 (クラウド自体のセキュリティ)
• Security IN the Cloud — 顧客が責任 (クラウドの上に乗せたもののセキュリティ)

領域別の責任 #

サービスモデルによって変わる責任 #

同じ AWS でも どのサービスを使うか によって顧客責任の範囲が変わります。

要約: マネージドサービスであるほど AWS の責任が大きくなり、IaaS であるほど顧客の責任が大きくなります。

常に顧客が責任を持つもの #

これはどのサービスを使っても顧客の責任です。

• データ自体 (分類・所有権・アクセス権)
• IAM ユーザー / ロール / ポリシー の設計
• 資格情報の管理 (アクセスキーのローテーション、MFA)
• クライアント側の暗号化 (オプションではあるが必要に応じて適用)

試験の出題パターン #

「OS パッチを自動で適用する責任は誰にあるか?」 → EC2 なら顧客 / RDS なら AWS。選択肢に両方出てくるときはサービス名で分けます。

「S3 バケットのデータを暗号化する責任は?」 → 顧客 (バケットポリシーで暗号化を強制、またはデータ自体を暗号化)。

「EC2 インスタンスで動作するアプリの SQL インジェクション対策の責任は?」 → 顧客。

「AWS データセンターの物理セキュリティは?」 → AWS。

IAM (Identity and Access Management) #

IAM は 誰が (WHO) AWS リソースに 何を (WHAT) できるかを管理するサービスです。グローバルサービスで、無料で提供されます。

実務トラック #2 でコンソールと CLI から直接触ってみました。資格試験の観点では 概念と語彙 に集中します。

IAM の 4 つの中核 #

ユーザー (User) #

サインアップ後に IAM コンソールで作成したユーザーです。人またはサービスアカウントとして使用します。

{
  "Console Login Password": "コンソール接続用パスワード",
  "Access Key ID + Secret Access Key": "CLI / SDK 用のキーペア",
  "MFA Device": "追加認証"
}

グループ (Group) #

同じ権限を複数のユーザーに与えたいときに使います。例: 「開発者グループ」に EC2 の読み取り / 書き込みポリシーを付けると、グループ内のすべての開発者に適用されます。

グループの制約:

• グループにはユーザーしか入れられません。グループの中にグループは入れられません。
• グループ自体は資格情報を持ちません。ログインはできません。

ロール (Role) #

最も混同されやすいオブジェクトです。一時的な資格情報 として動作します。

ロールとユーザーの本質的な違い:

• ユーザーは永続的な資格情報。キーが流出したら破棄・再発行が必要
• ロールは 一時トークン で動作。通常 1 時間有効で自動更新

試験で「EC2 から S3 にアクセスするには資格情報をどう管理すべきか?」が出たら、正解は IAM ロールを付与する (アクセスキーを EC2 に保存するのではなく)。

ポリシー (Policy) #

権限を定義した JSON ドキュメント です。試験でポリシー JSON を直接書く必要はありませんが、構造と語彙 は知っておく必要があります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

ポリシーの種類 #

推奨: AWS Managed Policy → Customer Managed Policy → Inline Policy の順で使うことが推奨されます。

最小権限 (Least Privilege) #

IAM 設計で最も重要な原則です。必要最小限の権限だけ を付与します。

試験の選択肢によく出るアンチパターン:

• 「すべてのユーザーに AdministratorAccess を付与する」— 常に誤答
• 「便宜上すべての IAM ユーザーが同じポリシーを使う」— 誤答
• 「1 人のユーザーにすべての権限を付与し、必要に応じて使う」— 誤答

正解になるパターン:

• ロール (Role) を定義して必要な人に付与する
• グループごとにポリシーを分離する (開発者・読み取り専用・管理者)
• 定期的な権限監査 (IAM Access Analyzer)

MFA (Multi-Factor Authentication) #

パスワードに加えて 2 つ目の認証手段 を要求するセキュリティ強化メカニズムです。

MFA の種類 #

誰に MFA を強制するか #

• root ユーザー — 無条件で MFA (試験出題頻度は最上位)
• IAM 管理者クラスのユーザー — 強く推奨
• コンソールにログインできるすべてのユーザー — ポリシーで強制可能

試験で「AWS アカウントのセキュリティを強化する最初のステップは?」 → root ユーザーに MFA を適用 + IAM ユーザーを作成。

Root ユーザーガイド #

サインアップ直後に受け取るアカウントには root ユーザー がいます。すべての権限を持つので、最も保護されるべき資格情報です。

Root でしかできない作業 (試験によく出る) #

Root 使用の原則 #

• 日常作業は絶対禁止 — IAM ユーザーで
• MFA 必須 — Hardware MFA 推奨
• アクセスキーを作らない — 既にあるなら即座に削除
• パスワードは強力に — 非常に複雑なものを安全な場所に保管

アクセスキー (Access Key) の運用 #

CLI / SDK で使うキーペアです。

Access Key ID:     AKIAIOSFODNN7EXAMPLE
Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

運用原則 #

• コードへのハードコード禁止 — git にプッシュされると数分以内にボットが発見
• EC2 ではアクセスキーの代わりに IAM ロールを使う
• 定期的なキーのローテーション (Access Key Rotation)
• 使っていないキーは無効化
• 2 つを同時に持てる — ローテーション時は新しいキーを作成 → コードを更新 → 古いキーを無効化 → 削除

IAM Identity Center (旧 AWS SSO) #

複数の AWS アカウントと外部 SaaS アプリに 1 つの資格情報 でログインできるサービスです。実務トラック #5 で扱いました。

試験の観点では:

• 複数の AWS アカウントを使う組織 に推奨
• 外部 IdP 連携 可能 (Okta・Azure AD など)
• IAM ユーザーの代わりに 一時的な資格情報 を使用

よく出会う落とし穴 #

1) 「root は常に安全だから日常作業も OK」 #

最も頻繁に出題される罠です。root での日常作業は絶対禁止。IAM ユーザーを作成してそれで作業します。

2) 「最大権限を付与して後で削る」 #

これも選択肢によくあるアンチパターンです。正解は 最小権限から始めて 必要に応じて追加。

3) IAM はグローバルサービスではなくリージョンサービスだという誤解 #

IAM は グローバルサービス です。コンソールで IAM を開くとリージョンセレクターが「Global」に切り替わります。

4) グループの中にグループ #

グループにはユーザーしか入りません。グループの中にグループは 不可。

5) 「EC2 上のコードが S3 にアクセスするためにアクセスキーを EC2 に保存」 #

これはアンチパターンです。正解は IAM ロールを EC2 に付与。

6) MFA をオプション扱いにする #

root の MFA はオプションではありません。必ず適用 します。

7) Inline Policy の乱用 #

再利用性がないため管理が大変になります。Customer Managed Policy として作成し、複数のオブジェクトに付ける方が良いです。

まとめ #

この記事で押さえたこと:

• 責任共有モデル — Security OF the Cloud (AWS) vs Security IN the Cloud (顧客)
• サービスモデルによって責任の境界が変わる — IaaS であるほど顧客の責任が大きい
• データ・IAM・資格情報は常に顧客の責任
• IAM の 4 つの中核 — User / Group / Role / Policy
• ユーザーは永続的な資格情報、ロールは一時的な資格情報 (EC2・Lambda・クロスアカウント)
• ポリシーは JSON ドキュメント — Effect / Action / Resource / Condition
• 最小権限の原則 — 必要最小限のみ付与
• MFA — root には必須、コンソールユーザーには強く推奨
• Root ユーザー は日常作業禁止。MFA 必須。アクセスキーを作らない
• 落とし穴 — root の日常使用 / 最大権限の付与 / IAM はリージョンサービスという誤解 / グループの中にグループ / EC2 にアクセスキー保存 / MFA のオプション扱い

次へ — Domain 2-2 コンプライアンスと暗号化 #

Domain 2 の後半に移ります。

#5 Domain 2-2 コンプライアンス — ガバナンス、AWS Artifact、GDPR / HIPAA では、AWS のコンプライアンス認証の種類とその意味、AWS Artifact による認証ドキュメントへのアクセス、ガバナンスツール (CloudTrail・Config)、そしてデータ暗号化 (保存中・転送中) と KMS の役割をまとめます。