はじめに
本記事は、AWS 認定 クラウドプラクティショナー（CLF-C02）の試験範囲を「間違えやすい・混同しやすい箇所」に絞って解説する連載の 第2回 です。
今回扱うのは、試験ドメイン2「セキュリティとコンプライアンス」の中でも最初に立ちはだかる 責任共有モデル（Shared Responsibility Model） です。ドメイン2は CLF-C02 全体の 30% を占める最大級の出題比率を持つ領域で、CLF-C01 の 25% から比率が引き上げられました。その入り口がこの責任共有モデルであり、ここを曖昧にしたまま先へ進むと、IAM やセキュリティサービスの問題でも足元をすくわれます。
責任共有モデルは一見シンプルです。「AWS が守る範囲」と「利用者が守る範囲」を分ける、それだけの話に見えます。しかし試験では、その境界線が「サービスの種類によって動く」という性質を突いたひっかけが頻出します。本記事では、筆者がつまずきやすいと感じたポイントを対比形式で整理していきます。
大原則：「of the cloud」と「in the cloud」
まず、すべての土台になる対比です。AWS はこのモデルを Security "of" the Cloud と Security "in" the Cloud という2つのフレーズで表現しています。
Security OF the Cloud → AWS の責任（クラウド「を」守る）
Security IN the Cloud → 利用者の責任（クラウド「の中」を守る）
混同しやすいポイント：「セキュリティはクラウドだから AWS が全部やってくれる」と考えてしまうこと。
正しい理解：AWS が責任を負うのは、サービスを動かす インフラストラクチャ です。具体的には、ハードウェア、ソフトウェア、ネットワーキング、そしてそれらを収容する物理施設（データセンター）です。ホスト OS と仮想化レイヤーから下、施設の物理セキュリティまでが AWS の管理範囲です。一方で、その上に乗せる データ・設定・アクセス管理 は常に利用者の責任です。
ひっかけ例：「Amazon S3 に保存したデータの暗号化を有効にする責任は誰にあるか？」という問題で「AWS」を選ぶと誤りです。データの保護（暗号化の有効化やアクセス権設定）は利用者側の責任です。AWS は S3 のインフラとサービス自体の堅牢性を保証しますが、その中に入れるデータをどう守るかは利用者が決めます。
混同①：境界線は「サービスの種類」で動く
責任共有モデルで最もよく問われるのが、境界線が固定ではない という点です。
混同しやすいポイント：「OS のパッチ適用は利用者の責任」と丸暗記してしまうこと。
正しい理解：これは EC2 のような IaaS では正しい のですが、マネージドサービスでは AWS 側に移る ため、サービスによって答えが変わります。
| サービス例 | 区分 | ゲスト OS のパッチ | 代表的な利用者責任 |
|---|---|---|---|
| Amazon EC2 | IaaS | 利用者 | OS 更新、ミドルウェア、SG 設定、アプリ |
| Amazon RDS | マネージド | AWS | DB 設定、認証情報、ネットワーク制御、データ |
| Amazon S3 / DynamoDB | フルマネージド | （該当なし） | アクセス権、暗号化設定、データ管理 |
ひっかけ例：「Amazon RDS for MySQL の OS とデータベースエンジンのパッチ適用は誰の責任か？」という問題。EC2 の感覚で「利用者」を選ぶと誤りです。RDS はマネージドサービスなので、基盤 OS と DB エンジンのパッチは AWS が担当します。利用者が担うのは、DB のパラメータ設定、ユーザー認証、ネットワークアクセス制御（セキュリティグループ）、そして格納するデータの管理です。
つまり「マネージドの度合いが高いほど、利用者の責任範囲は狭くなる」という比例関係を押さえておくのが攻略のコツです。EC2（自分で全部）→ RDS（OS は任せる）→ S3 / Lambda（基盤はほぼ任せる）と、右に行くほど AWS の担当が増えます。
混同②：3種類のコントロール（継承・共有・利用者固有）
CLF-C02 では、責任を3つのコントロール種別で整理する考え方も問われます。言葉が似ていて混同しやすい部分です。
混同しやすいポイント：「共有コントロール（Shared Controls）」を「AWS と利用者が一緒に1つの作業をする」と捉えてしまうこと。
正しい理解：共有とは「同じ統制テーマを、AWS と利用者がそれぞれの層で別々に担う」という意味です。共同作業ではなく、責任の 層が分かれている イメージです。
| コントロール種別 | 意味 | 具体例 |
|---|---|---|
| 継承コントロール（Inherited） | AWS が完全に担い、利用者がそのまま恩恵を受ける | 物理・環境セキュリティ、施設の管理 |
| 共有コントロール（Shared） | 同じテーマを AWS と利用者が別々の層で担当 | パッチ管理、構成管理、意識向上・トレーニング |
| 利用者固有（Customer Specific） | 利用者のワークロード次第で完全に利用者が担う | アプリ層のゾーンセキュリティ、通信経路の保護 |
ひっかけ例：「パッチ管理は誰の責任か？」という問題。「AWS」または「利用者」のどちらか一方だけを選ぶと、問題の意図次第では不正解になります。パッチ管理は 共有コントロール です。AWS はインフラの欠陥を修正し、利用者はゲスト OS とアプリケーションにパッチを当てます。「構成管理（Configuration Management）」や「従業員のトレーニング（Awareness & Training）」も同様に共有コントロールで、AWS は自社の機器・従業員に対して、利用者は自社の OS・DB・アプリ・従業員に対して、それぞれ責任を負います。
混同③：「コンプライアンスは AWS 任せ」ではない
混同しやすいポイント：「AWS は数多くのコンプライアンス認証を取得しているから、利用者側は何もしなくてもコンプライアンスを満たせる」と考えること。
正しい理解：AWS の認証（例：ISO 27001、SOC、PCI DSS など）は インフラ部分の準拠 を保証するもので、その証跡は AWS Artifact からダウンロードできます。しかし、その上で動くアプリケーションやデータの取り扱いが規制（HIPAA、GDPR など）に準拠しているかは、利用者が設計・運用する責任です。AWS は「準拠しやすい基盤」を提供しますが、「利用者のシステム全体の準拠」を肩代わりはしません。
ひっかけ例：「アプリケーションが GDPR に準拠していることを保証するのは誰か？」→ 答えは利用者です。AWS が提供するのは準拠を支える基盤とエビデンス（AWS Artifact 経由）であり、最終的なコンプライアンス責任は利用者にあります。
まとめ早見表
責任の所在を、典型的な対象別に一覧化します。試験直前の見直しに使ってください。
| 対象 | 責任 | ひとことメモ |
|---|---|---|
| データセンターの物理セキュリティ | AWS | 継承コントロールの代表 |
| ハードウェア・グローバルインフラ | AWS | リージョン/AZ/エッジを含む |
| ホスト OS・仮想化レイヤー | AWS | 「ここから下」が AWS |
| EC2 のゲスト OS パッチ | 利用者 | IaaS だから自分で |
| RDS の OS / エンジンパッチ | AWS | マネージドなので任せる |
| セキュリティグループの設定 | 利用者 | ファイアウォール設定は利用者 |
| IAM ユーザー・権限の設計 | 利用者 | 「クラウドの中」の設定 |
| 顧客データそのもの | 利用者 | 常に利用者。例外なし |
| データの暗号化（有効化・鍵管理） | 利用者 | S3 でも RDS でも利用者が設定 |
| ネットワークトラフィックの保護 | 利用者 | 暗号化・整合性・ID 管理 |
| インフラの認証取得（ISO/SOC 等） | AWS | 証跡は AWS Artifact で入手 |
| アプリ/データの規制準拠（GDPR 等） | 利用者 | 基盤は AWS、準拠は利用者 |
迷ったときの判断軸はシンプルです。「データ・設定・アクセス」に関わるものは利用者、「物理・基盤・仮想化レイヤーから下」は AWS。そして マネージドの度合いが上がるほど利用者の担当は減る。この2つを軸にすれば、大半の問題は解けます。
次回予告
第3回は、ドメイン2の中核である IAM（Identity and Access Management） を扱います。ルートユーザー / IAM ユーザー / グループ / ロール / ポリシー / MFA / 最小権限の原則という、名前が似ていて役割を取り違えやすい要素を、対比形式で整理する予定です。「ロールとユーザーはどう違うのか」「いつポリシーをアタッチし、いつロールを引き受けるのか」をすっきりさせます。