CLF 試験：AWS 責任共有モデルを完全理解｜「OF the cloud」と「IN the cloud」で一刀両断
AWS Certified Cloud Practitioner（CLF-C02）の配点 30%・ドメイン 2「セキュリティとコンプライアンス」で必ず問われる責任共有モデルを、出題者の視点で完全整理。攻略の核心は「AWS＝クラウド"の"セキュリティ（Security OF the Cloud）／利用者＝クラウド"内"のセキュリティ（Security IN the Cloud）」という 1 本の境界線。AWS が守る物理・インフラ層と、利用者が守るゲスト OS・パッチ・データ・IAM・セキュリティグループ設定を対比カードで暗記し、EC2（IaaS）と S3（マネージド）で責任範囲が動く理由まで「いつ・なぜ」を軸に押さえる。頻出ひっかけパターンも収録。
CLF-C02 で 2 番目に配点が大きいのは、ドメイン 2「セキュリティとコンプライアンス」（30%）。そして、このドメインで最も繰り返し問われるのが 責任共有モデル（Shared Responsibility Model） だ。クラウドのセキュリティは AWS と利用者の共同作業であり、「どこからどこまでが AWS の責任で、どこからが利用者の責任か」を線引きできるかが合否を分ける。だが、これは丸暗記する論点ではない。「AWS＝クラウド”の”セキュリティ／利用者＝クラウド”内”のセキュリティ」 というたった 1 本の境界線を腹落ちさせれば、初見の選択肢でも「これはどっち側？」と即断できるようになる。本記事は、その境界線を 1 枚に整理し、EC2（IaaS）と S3（マネージド）で責任範囲が動く理由まで対比カードで押さえる。範囲全体の地図は CLF ドメイン 2 攻略 と CLF 試験範囲完全マップ に、試験スペックは CLF 試験完全ガイド にある。
📑 目次
- [結論：責任共有モデルは「OF と IN」で畳む](#1-結論責任共有モデルは of-と-in-で畳む)
- なぜ「共有」なのか：クラウドの大前提
- AWS の責任：Security OF the Cloud
- 利用者の責任：Security IN the Cloud
- 境界線は「サービスの種類」で動く（最重要）
- 対比カード：AWS ⇔ 利用者
- 頻出ひっかけパターン 6 選
- 関連記事
- 関連サイト
1. 結論：責任共有モデルは「OF と IN」で畳む
責任共有モデルの問題は、「ゲスト OS にセキュリティパッチを当てるのは誰の責任か」「物理データセンターのセキュリティは誰が担うか」といった具体的な作業を提示して責任の所在を選ばせる形が定番だ。だからこそ、個別の作業を丸暗記するのではなく、**「それはインフラ側（OF）か、自分が置いたもの（IN）か」**という 1 本の基準で振り分けられる状態にしておくのが最短ルートになる。
2. なぜ「共有」なのか：クラウドの大前提
オンプレミス（自社運用）では、建物の物理セキュリティから OS・アプリ・データまで、すべてを自社が守る必要があった。一方クラウドでは、AWS が物理基盤を肩代わりしてくれる。つまりクラウドのセキュリティは、AWS が守る部分と利用者が守る部分に自動的に分かれる——これが「共有（Shared）」と呼ばれる理由だ。
3. AWS の責任：Security OF the Cloud
AWS が責任を負うのは、クラウドサービスを動かすための基盤すべてだ。AWS 公式の表現では「ハードウェア・ソフトウェア・ネットワーキング・施設（hardware, software, networking, and facilities）」と定義される。利用者が触れない・見えない領域、と言い換えてもよい。
| 評価項目 | 具体例 | ポイント |
|---|---|---|
| 物理セキュリティ | データセンターの入退室管理・監視カメラ・警備 | 利用者は AWS のデータセンターに立ち入れない |
| ハードウェア | サーバー・ストレージ・ネットワーク機器の保守 | 故障対応・物理的な廃棄も AWS |
| 仮想化基盤 | ハイパーバイザー・ホスト OS の管理とパッチ | EC2 を動かす"下の層"は AWS の責任 |
| グローバルインフラ | リージョン・AZ・エッジロケーションの運用 | 地理的冗長性の確保 |
4. 利用者の責任：Security IN the Cloud
利用者が責任を負うのは、AWS が用意した基盤の上に自分が置いたもの・設定したものだ。AWS 公式の表現では「Security IN the Cloud」。具体的には、データ・ゲスト OS・アプリケーション・アクセス管理・暗号化の選択などが該当する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
5. 境界線は「サービスの種類」で動く（最重要）
責任共有モデルで最も差がつくのが、「境界線は固定ではない」という点だ。同じ AWS でも、使うサービスの抽象度（マネージドの度合い）によって、利用者の責任範囲が増減する。AWS 公式も「利用者の責任は、選択するサービスによって決まる」と明記している。
| 評価項目 | 利用者の責任 | 具体例 |
|---|---|---|
| IaaS（例：EC2） | 大きい：ゲスト OS・パッチ・ファイアウォール設定まで利用者 | [EC2](/posts/ec2/) の OS 更新・セキュリティグループ設定は利用者 |
| コンテナ/PaaS 寄り | 中くらい：OS 管理は減るがアプリ・設定は利用者 | プラットフォーム層は AWS、アプリは利用者 |
| マネージド/抽象化（例：S3・DynamoDB） | 小さい：OS・基盤は AWS、データと権限が利用者 | [S3](/posts/s3/) は OS 管理不要。データ・[IAM](/posts/iam/)・暗号化が利用者の主担当 |
6. 対比カード：AWS ⇔ 利用者
ここまでを 1 枚の対比カードに畳む。試験本番では「この作業はどっち？」をこの表を頭に浮かべて即答できれば勝ちだ。
| 評価項目 | AWS の責任（OF the Cloud） | 利用者の責任（IN the Cloud） |
|---|---|---|
| 物理・施設 | データセンターの警備・空調・電源 | （対象外） |
| ハードウェア | サーバー・ストレージ・NW 機器・廃棄 | （対象外） |
| OS | ホスト OS・ハイパーバイザーのパッチ | ゲスト OS のパッチ（EC2 の中身） |
| アプリ | （マネージド部分の基盤） | アプリ・ミドルウェアの設定とパッチ |
| アクセス管理 | 基盤への AWS 従業員アクセス制御 | [IAM](/posts/iam/) でのユーザー・権限管理 |
| ネットワーク制御 | 物理ネットワークの保護 | セキュリティグループ・ネットワーク ACL 設定 |
| データ | （インフラの暗号化基盤の提供） | データの暗号化選択・分類・取り扱い |
| 教育 | AWS 従業員のトレーニング | 自社の従業員のトレーニング |
7. 頻出ひっかけパターン 6 選
これらは「AWS が肩代わりする層」と「利用者が設定する層」の境目を突く CLF の典型だ。対比カード（「ホスト OS ⇔ ゲスト OS」「物理 ⇔ 設定」「IaaS ⇔ マネージド」）にして「どっちがどっち？」を即答できる状態にしておけば、本番で迷わない。責任共有モデルはドメイン 2 の中核であり、ここを固めるだけで配点 30% の領域がぐっと安定する。
8. 関連記事
- CLF ドメイン 2「セキュリティとコンプライアンス」攻略 — 配点 30%・責任共有モデルを含む全体像
- CLF ドメイン 1「クラウドの概念」 — クラウドの大前提を押さえる
- CLF 試験範囲完全マップ：4 ドメイン徹底解説 — ドメイン 1〜4 の地図
- AWS Cloud Practitioner（CLF）試験完全ガイド — スペック・難易度・勉強時間
- AWS IAM 完全ガイド：ユーザー・ロール・ポリシー — 利用者責任の本丸（アクセス管理）
- AWS KMS とは？暗号鍵管理の基本 — 利用者が選ぶ暗号化の道具
- Amazon S3 完全ガイド — マネージドサービスでの責任範囲の代表例
- AWS Organizations と SCP の活用 — 複数アカウントのガバナンス
9. 関連サイト
AWS 公式
- 責任共有モデル（AWS 公式）
- AWS Certified Cloud Practitioner (CLF-C02) 試験ガイド（PDF）
- AWS Certified Cloud Practitioner (CLF-C02) 試験ガイド（Web 版）
- 責任共有 - AWS セキュリティインシデント対応ガイド
- Well-Architected セキュリティの柱：責任共有