CLF ドメイン 2「セキュリティとコンプライアンス」攻略：責任共有モデル・IAM・Artifact
AWS Certified Cloud Practitioner（CLF-C02）の出題ドメイン 2「セキュリティとコンプライアンス」（配点 30%・最重要）を、公式試験ガイドの 4 つの task statement に沿って徹底解説。AWS と利用者の境界を定める責任共有モデル（Security OF the Cloud / IN the Cloud）、IAM のユーザー・ロール・ポリシーと最小権限・MFA・ルートユーザー保護、AWS Artifact とコンプライアンスプログラム、GuardDuty・Shield・WAF・Inspector・Macie などセキュリティサービス群まで、暗記すべき公式フレーズと頻出ひっかけパターンを整理する。CLF 最大の得点源を確実に取りに行くための一枚。
CLF-C02 の 4 ドメインで最も配点が大きいのがドメイン 2「セキュリティとコンプライアンス」で、なんと 30%。技術の深さよりも「AWS と利用者、どちらが何を守るのか」という役割分担を公式の言い回しで言えるかが問われる。中心はただ一つ、責任共有モデル。ここを軸に IAM・コンプライアンス・セキュリティサービスが枝分かれしていく。本記事は試験ガイドの 4 つの task statement（2.1〜2.4）に沿って、覚えるべきフレーズと頻出ひっかけを一気に整理する。範囲全体の地図は CLF 試験範囲完全マップ に、試験スペックや勉強時間は CLF 試験完全ガイド に、配点 24% のドメイン 1 は クラウドの概念 攻略 にまとめている。
📑 目次
- 結論：ドメイン 2 は「責任共有モデルを軸に」攻める
- ドメイン 2 の全体像（4 つの task statement）
- 2.1 責任共有モデル（最頻出）
- 2.2 セキュリティ・ガバナンス・コンプライアンス
- 2.3 アクセス管理（IAM）
- 2.4 セキュリティのコンポーネントとリソース
- 頻出ひっかけパターン 6 選
- 関連記事
- 関連サイト
1. 結論：ドメイン 2 は「責任共有モデルを軸に」攻める
ドメイン 2 は配点が最大なだけでなく、暗記で確実に取れる領域だ。問われるのは暗号アルゴリズムの中身ではなく、「この作業は AWS と利用者のどちらの責任か」「このサービスは何のためにあるか」という位置づけ。技術の深掘りは SAA 以上に任せ、CLF では「責任の境界」と「サービスの役割」の 2 点に集中すれば、30% を効率よく拾える。
2. ドメイン 2 の全体像（4 つの task statement）
公式試験ガイドは、ドメイン 2 を 4 つの task statement に分解している。まずこの 4 つの「棚」を頭に作ろう。
| 評価項目 | 問われること | キーワード |
|---|---|---|
| 2.1 責任共有モデルを理解 | AWS と利用者の責任分界 | Security OF / IN the Cloud・サービス種別で変わる境界 |
| 2.2 セキュリティ・ガバナンス・コンプライアンスを理解 | 法規制・監査への対応 | AWS Artifact・コンプライアンスプログラム・データ所在 |
| 2.3 アクセス管理を識別 | 誰が何にアクセスできるか | IAM・最小権限・MFA・ルートユーザー保護 |
| 2.4 セキュリティのコンポーネントを識別 | 守るための部品とサポート | GuardDuty・Shield・WAF・Inspector・Trusted Advisor |
この 4 つの根っこは 1 つ——**「クラウドのセキュリティは AWS と利用者の協働で成り立つ」**という考え方だ。責任分界（2.1）を起点に、利用者側の責務としてアクセス管理（2.3）とコンプライアンス対応（2.2）があり、それらを支える道具がセキュリティサービス群（2.4）。この一本の線を意識すると、4 つが地続きでつながる。
3. 2.1 責任共有モデル（最頻出）
ドメイン 2、いや CLF-C02 全体でも最頻出の超定番が AWS 責任共有モデル（Shared Responsibility Model）。AWS と利用者がセキュリティ責任を分担するという考え方で、公式の言い回しがほぼそのまま出題される。
| 評価項目 | AWS の責任 | 利用者の責任 |
|---|---|---|
| 標語 | Security OF the Cloud（クラウド「の」セキュリティ） | Security IN the Cloud（クラウド「内」のセキュリティ） |
| 守る対象 | 物理データセンター・ハードウェア・ネットワーク基盤・ホスト OS・仮想化レイヤー | ゲスト OS・アプリ・データ・IAM 設定・ファイアウォール（SG）設定 |
| データの暗号化 | 暗号化「機能」の提供（KMS 等） | 暗号化を「有効にする／鍵を管理する」判断と設定 |
| 一言で | 「クラウドそのもの」を守る | 「クラウドに載せたもの」を守る |
サービス種別で境界が動く
責任共有モデルの肝は、**「使うサービスの種類によって、利用者の責任範囲が変わる」**こと。マネージドの度合いが高いほど、AWS が肩代わりする範囲が広がる。
| 評価項目 | 例 | 利用者が負う責任 |
|---|---|---|
| IaaS（例：EC2） | 仮想サーバー | ゲスト OS のパッチ・ミドルウェア・アプリ・データまで利用者が管理（責任が広い） |
| コンテナ系（例：RDS・Lambda） | マネージド DB / 関数 | OS パッチは AWS。利用者はデータ・アクセス権・ネットワーク設定を管理 |
| 抽象化（例：S3・DynamoDB） | フルマネージド | AWS が基盤・OS を管理。利用者はデータと権限設定に集中（責任が狭い） |
4. 2.2 セキュリティ・ガバナンス・コンプライアンス
法規制や業界基準（コンプライアンス）にクラウドでどう対応するかを問うのが 2.2。中心となるのがコンプライアンス文書を入手するサービスとガバナンスの仕組みだ。
| 評価項目 | 役割 | 一言でいうと |
|---|---|---|
| AWS Artifact | 監査レポートの入手 | ISO・SOC・PCI DSS などの第三者監査報告書をオンデマンドでダウンロード |
| AWS Compliance Programs | 対応規格の一覧 | AWS が準拠する各種コンプライアンスプログラム（GDPR・HIPAA 等）の枠組み |
| AWS Config | 構成の記録・評価 | リソース構成の変更を記録し、ルール違反を検出（[Config](/posts/config/)） |
| AWS Organizations / SCP | 組織統制 | 複数アカウントを束ね、[SCP](/posts/scp/) で利用可能サービスを制限 |
ここで押さえる勘所
- AWS Artifact は「AWS のセキュリティ・コンプライアンス報告書を入手する場所」。利用者自身の監査対応で「AWS は ISO27001 を取得しているか」を示す証跡として使う。Artifact Agreements では BAA（HIPAA）などの契約も確認・受諾できる
- コンプライアンスは責任共有。AWS は基盤の認証を取得するが、「利用者の環境を準拠状態に保つ」のは利用者の責任。Artifact で報告書を入手しても、自社アプリの設定責任までは肩代わりされない
- **データの所在（データレジデンシー）**は利用者がリージョン選択で制御する。AWS は「利用者が指定したリージョンの外へ勝手にデータを移さない」——この原則も問われやすい
- 監査ログの基盤は CloudTrail（誰が何の API を呼んだか）、構成監査は AWS Config が担う
5. 2.3 アクセス管理（IAM）
「誰が・何に・どこまでアクセスできるか」を制御するのが AWS IAM（Identity and Access Management）。ドメイン 2 で IAM は最頻出テーマであり、用語の区別がそのまま得点に直結する。詳しくは IAM 完全ガイド にゆずり、ここでは CLF で問われる骨子を整理する。
| 評価項目 | 正体 | 使いどころ |
|---|---|---|
| IAM ユーザー | 人や個別アプリの恒久的な ID | 長期のアクセスキー／パスワードを持つ。人間に 1 人 1 アカウント |
| IAM グループ | ユーザーの束 | 部署・職務単位で権限をまとめて付与（グループに人を入れる） |
| IAM ロール | 一時認証を引き受ける器 | EC2 やサービス・他アカウントに一時的な権限を委譲（[IAM ロール](/posts/iam-role/)） |
| IAM ポリシー | 権限の定義（JSON） | 「誰が・何に・許可/拒否」を記述（[IAM ポリシー](/posts/iam-policy/)） |
IAM ベストプラクティス（頻出）
ほかに、複数アカウントや既存 ID（Active Directory・Google 等）と連携するなら IAM Identity Center（旧 AWS SSO、Identity Center）、組織全体でアカウントを束ね統制するなら AWS Organizations と SCP ——という対応も「名前と用途」レベルで押さえておく。
6. 2.4 セキュリティのコンポーネントとリソース
最後の 2.4 は、セキュリティを実現するサービス群と、困ったときのサポート／情報源の識別。一つひとつの深い設定は不要で、「何を守るサービスか」を即答できることがゴールだ。
| 評価項目 | 役割 | 守る対象 |
|---|---|---|
| Amazon GuardDuty | 脅威検知 | ログを機械学習で分析し不正アクセス・異常を検知（[GuardDuty](/posts/guard-duty/)） |
| AWS Shield | DDoS 防御 | DDoS 攻撃からの保護（Standard は自動・無料／[Shield](/posts/shield/)） |
| AWS WAF | Web アプリ防御 | SQL インジェクション等の悪意あるリクエストを遮断（[WAF](/posts/waf/)） |
| Amazon Inspector | 脆弱性スキャン | EC2・コンテナの既知の脆弱性を自動診断（[Inspector](/posts/inspector/)） |
| Amazon Macie | 機密データ検出 | S3 内の個人情報など機密データを ML で発見（[Macie](/posts/macie/)） |
| AWS KMS | 暗号鍵管理 | 暗号化に使う鍵を一元管理（[KMS](/posts/kms/)） |
| AWS Security Hub | 統合管理 | 各種セキュリティ検出結果を一元集約（[Security Hub](/posts/security-hub/)） |
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
サポートと情報源も出題範囲
セキュリティ運用を助ける「情報源」も 2.4 に含まれる。
- AWS Trusted Advisor —— アカウントを自動チェックし、セキュリティ（MFA 未設定・ポートの開放など）・コスト・パフォーマンスの観点で改善を助言（Trusted Advisor）
- AWS Knowledge Center / ドキュメント / re:Post —— 公式の Q&A・技術文書。セキュリティの疑問を調べる一次情報源
- AWS Security Bulletins / AWS Security Blog —— 脆弱性情報やベストプラクティスの発信元
7. 頻出ひっかけパターン 6 選
ドメイン 2 で点を落とす典型パターンを、対策とセットで挙げておく。
これらは「役割が似たもの・境界が紛らわしいもの」を突いてくる CLF の典型。1 つずつ覚えるより、対比カード（「Shield ⇔ WAF」「GuardDuty ⇔ Inspector」「OF ⇔ IN」）にして「どっちがどっち？」を即答できる状態にしておくと本番で迷わない。
8. 関連記事
- CLF 試験範囲完全マップ：4 ドメイン徹底解説 — ドメイン 1〜4 の全体地図（まずはこちら）
- CLF ドメイン 1「クラウドの概念」攻略 — 配点 24%・暗記で稼ぐ前ドメイン
- AWS Cloud Practitioner（CLF）試験完全ガイド — スペック・難易度・勉強時間・申し込み
- AWS IAM 完全ガイド：ユーザー・ロール・ポリシー — ドメイン 2 最頻出テーマの本丸
- GuardDuty の脅威検知機能 — セキュリティサービスの代表格
- AWS WAF の使い方と OWASP 対策 — Web アプリ防御の定番
9. 関連サイト
AWS 公式
- AWS Certified Cloud Practitioner (CLF-C02) 試験ガイド（Web 版）
- AWS Certified Cloud Practitioner (CLF-C02) 試験ガイド（PDF）
- AWS 責任共有モデル（公式）
- AWS Artifact（公式）
- AWS コンプライアンスプログラム（公式）
- AWS IAM とは（公式ドキュメント）