AWS 共有責任モデル 完全解説 — CLF-C02 Domain 2（Security & Compliance 30%）攻略

AWS 共有責任モデルは CLF-C02 最高配点ドメインの中核概念で、ここを誤解すると本番で複数問落とす。「AWS がセキュリティをやってくれる」という単純なメンタルモデルでは、Domain 2: Security and Compliance（30% 配点、約 15 問）の半分を取りこぼす可能性が高い。本記事はこの責任モデルを「サービスタイプごとに境界が動く動的モデル」として正確に理解し、IAM・主要セキュリティサービス・コンプライアンス枠を CLF-C02 合格水準まで体系化する。

AWS Cloud Practitioner CLF-C02 完全攻略 — 試験概要と Domain 1: Cloud Concepts（2026-05-26 公開） で Domain 1 の Cloud Concepts を、クラウドコンピューティング 完全入門 2026（2026-05-25 公開） で全体像を押さえた前提で、最高配点の Domain 2 に踏み込む。

なぜ Domain 2 が最高配点（30%）なのか

CLF-C02 の 4 ドメイン中、Security and Compliance が 30% で最大配点を持つ理由は明快だ。「クラウドが安全か」という問いは、企業がクラウド採用を決める瞬間に必ず出てくる。経営層、法務部、セキュリティ部門が AWS を承認するためには、責任の所在、データ保護、コンプライアンス対応が体系的に説明できなければならない。CLF-C02 は「クラウドの最低限を理解している」を保証する認定なので、ここを最重視する。

50 問中の採点対象でいうと、Domain 2 は 15 問。試験全体で Domain 2 を半分以上正解できれば、合格圏に大きく近づく。逆にここで 5 問しか取れないと、他ドメインで満点近くを取らない限り 700 / 1000 に届かない。

AWS 共有責任モデルは Domain 2 の中で約 3〜4 問が出題されると見られ、ここを完璧に押さえることが投資対効果として最大だ。

AWS 共有責任モデル — 2 つの「セキュリティ」

公式 Shared Responsibility Model は、責任を 2 つの領域に分ける。

Security OF the Cloud（AWS 責任） は、データセンターの物理セキュリティ、サーバハードウェア、ネットワーク機器、仮想化ハイパーバイザー、ホスト OS、AWS サービスのソフトウェア層、これらすべてを AWS が運用・保守・パッチ適用する責任を負う。顧客が直接アクセスする手段はない。

Security IN the Cloud（顧客責任） は、ゲスト OS のパッチ適用、アプリケーションコード、データ（保管時 / 転送時の暗号化）、IAM ロール / ポリシー設定、ネットワーク ACL とセキュリティグループ、こうした顧客自身の構成と運用の責任を顧客が負う。

このモデルの肝は「顧客責任の範囲はゼロにはならない」点だ。クラウドに乗せた瞬間に全てが安全になるのではなく、AWS が物理層を担保する分、顧客は論理層に集中してセキュリティを担保する、というトレードオフだ。

サービスタイプ別の責任境界

責任境界はサービスタイプで動く。これが共有責任モデルの最も誤解されるポイントだ。

EC2 ではホスト OS は AWS、ゲスト OS は顧客責任。これは「インスタンス内で Linux のセキュリティアップデートを当てるのは顧客」という意味だ。RDS は逆にゲスト OS まで AWS が管理し、顧客は DB ユーザーとデータの責任を持つ。S3 では物理ストレージとサービスは AWS、バケットの公開設定とオブジェクト ACL は顧客責任。Lambda では実行環境すべてが AWS で、顧客はコードと IAM だけ管理する。

「マネージドサービスを使うほど顧客責任は減る」が原則で、これは「マネージドサービスの方が安全」という意味ではなく「責任が事業者に寄る」という意味だ。設定ミスのリスクは依然として顧客側に残る。例えば Lambda 関数のコードに SQL インジェクション脆弱性があれば、AWS は何も助けてくれない。コードレビュー、脆弱性スキャン、ペネトレーションテスト、これらは引き続き顧客の責任範囲だ。

CLF-C02 では「EC2 のホスト OS パッチは誰の責任か」「RDS のデータ暗号化は誰の責任か」のような問いが頻出する。前者は AWS、後者は顧客が暗号化を有効化する責任を持つ（実際の暗号化操作は AWS が代行）。

共有コントロール — 重なる責任

共有責任モデルには「共有コントロール (Shared Controls)」という第 3 領域がある。AWS と顧客の両方が責任を分担して達成する項目だ。代表例は次のとおり。

• パッチ管理: AWS はインフラとマネージドサービスのパッチ、顧客はゲスト OS とアプリのパッチ
• 構成管理: AWS はインフラデバイスの構成、顧客はゲスト OS / DB / アプリの構成
• 意識とトレーニング: AWS は AWS 従業員の教育、顧客は自社従業員の教育

「両方やる」のではなく「役割を明確に分担する」のが共有コントロールの本質だ。CLF-C02 では「パッチ管理は AWS と顧客で分担される」程度の理解で十分だが、SAA-C03 や Security Specialty では具体的な分担境界を問われる。

IAM — Users / Groups / Roles / Policies の関係

AWS IAM (Identity and Access Management) は、AWS の誰が何にアクセスできるかを制御する中央集権サービスだ。CLF-C02 では IAM の 4 つのコンポーネントを正確に理解する必要がある。

Users は AWS アカウント内の個別アイデンティティで、人間のユーザーまたはアプリケーションを表す。コンソールパスワードとアクセスキーを持つ。

Groups は Users の集合で、共通のポリシーをまとめて適用する単位だ。「Developers グループ」「Admins グループ」のように組織のロールに対応させる。Users は複数の Groups に所属できる。

Roles は AWS リソース（EC2 / Lambda 等）や外部 ID プロバイダー、別の AWS アカウントが一時的に引き受ける権限の塊だ。長期クレデンシャル（アクセスキー）を持たず、Assume Role で短期トークンを発行する。これがセキュリティ上の最大のメリットで、「サーバに鍵を埋め込まない」運用を可能にする。

Policies は権限の実体で、JSON 形式で「誰が（Principal）」「何に（Resource）」「どんな操作（Action）」をしていいか / してはいけないか（Effect: Allow / Deny）を記述する。Managed Policy（AWS 提供）と Customer Managed Policy（顧客作成）の 2 種類がある。

IAM のベストプラクティスは「最小権限の原則 (Least Privilege)」だ。必要最低限の権限だけ付与し、過剰権限を避ける。AdministratorAccess の安易な配布は、事故の温床になる。

MFA と Identity Center

ルートユーザーや特権 IAM ユーザーには、MFA (Multi-Factor Authentication) の有効化が必須だ。Virtual MFA（Authy / Google Authenticator アプリ）、Hardware MFA（YubiKey 等）、SMS（非推奨）の 3 種類がある。MFA は「知識情報（パスワード）」と「所持情報（デバイス）」を組み合わせる多要素認証で、パスワード漏洩単独での乗っ取りを防ぐ。

AWS IAM Identity Center（旧 AWS Single Sign-On、2022 年改名）は、複数 AWS アカウントへの SSO とユーザーディレクトリ統合を提供する。Permission Sets を Identity Center で定義し、それを各アカウントに展開する仕組みで、企業の大規模なマルチアカウント運用の標準ツールだ。SAML 2.0 経由で Microsoft Entra ID（旧 Azure AD）、Okta、Google Workspace と連携できる。

CLF-C02 では「Identity Center は何を提供するか」「MFA はどう設定するか」程度の概念理解で十分だ。

AWS セキュリティサービス群

AWS は階層別に多数のセキュリティサービスを提供する。CLF-C02 で名前と役割を覚えるべき主要サービスはこうだ。

AWS Shield Standard は全 AWS 顧客に無料で適用される DDoS 保護で、Layer 3/4 の SYN フラッドや UDP リフレクションを自動緩和する。Advanced は $3,000/月（12 ヶ月契約必須）で、Layer 7 の保護、24/7 の Shield Response Team (SRT) アクセス、DDoS 攻撃時のコスト保護（攻撃で増えた CloudFront / Route 53 / ELB 料金の払い戻し）が付く。

AWS WAF は CloudFront / API Gateway / ALB の前段に設置し、SQL インジェクション、XSS、悪意のあるボットなどを HTTP リクエストレベルでブロックする。Web ACL が $5/月、ルールが $1/月、リクエストが $0.60/100 万、という従量課金モデルだ。

Amazon GuardDuty は AWS 環境内の異常活動を ML で検出する。「コインマイニングプロセス起動」「異常な API 呼び出しパターン」「既知のマルウェア IP との通信」、こうした脅威を 24/7 で監視し、findings として通知する。30 日間無料トライアル後は使用量ベースの従量課金になる。

監査・コンプライアンス系サービス

セキュリティの検知系に加えて、監査とコンプライアンス対応のサービスも CLF-C02 に出る。

CloudTrail は AWS で起きた全 API 呼び出しを記録する「監査台帳」だ。「誰が、いつ、何のリソースに、どんな操作をしたか」が全て残る。インシデント発生時の追跡、コンプライアンス対応、内部統制、すべての基盤になる。デフォルトで 90 日間保持され、S3 への長期保存も設定できる。

AWS Config はリソースの構成変更を継続記録する。「セキュリティグループにこの IP が追加されたのはいつ、誰か」「S3 バケットがパブリックになった瞬間はいつか」、こうした構成履歴を提供し、構成ルール違反を自動検知できる。

AWS Trusted Advisor は AWS が提供する自動診断ツールで、5 カテゴリ（コスト最適化 / セキュリティ / 耐障害性 / パフォーマンス / サービス制限）をチェックする。Basic Support では Core チェック 7 項目のみ、Business 以上のサポートプランで全 100+ チェックが利用可能になる。

コンプライアンス枠と AWS Artifact

AWS は世界中の主要なコンプライアンス枠に対応した認証を取得している。CLF-C02 で名前を覚えておくべき代表的な枠はこうだ。

• PCI DSS: クレジットカード業界のセキュリティ基準
• HIPAA: 米国の医療情報保護法
• ISO 27001 / 27017 / 27018: 情報セキュリティ管理の国際標準
• SOC 1 / 2 / 3: 監査法人による内部統制報告書
• FedRAMP: 米国連邦政府向けクラウドセキュリティ基準
• GDPR: EU 一般データ保護規則

AWS Artifact は、これらの監査レポートを顧客がオンデマンドでダウンロードできるポータルだ。SOC 2 Type II レポートを顧客が監査人に提出する、ISO 27001 認証書をエンタープライズ取引先に共有する、こうした実務で日常的に使われる。

「AWS がコンプライアンス認証を持っている」ことと「顧客のサービスがコンプライアンスに準拠している」ことは別問題だ。AWS のインフラレベルは認証取得済みだが、顧客のアプリケーションレベルでのコンプライアンス対応は顧客責任のままだ。これも共有責任モデルの応用例の 1 つだ。

暗号化と AWS KMS

データ保護の中核ツールが AWS KMS (Key Management Service) だ。暗号鍵の生成、保管、ローテーション、利用権限管理を一元化するマネージドサービスで、S3 / EBS / RDS / Secrets Manager 他、ほぼ全 AWS サービスと統合される。

暗号化は 2 タイプある。Encryption at Rest（保管時暗号化） は S3 オブジェクト、EBS ボリューム、RDS スナップショット等を AES-256 で暗号化する。Encryption in Transit（転送時暗号化） は TLS / SSL でクライアントとサーバ間の通信を暗号化する。

KMS Customer Master Key (CMK) には AWS Managed Key（AWS が管理、無料）と Customer Managed Key（顧客が完全コントロール、$1/月/キー + API 呼び出し従量課金）の 2 種類がある。Secrets Manager（$0.40/月/秘密 + API 呼び出し従量）は API キーやデータベース接続情報を安全に保管・自動ローテーションする上位サービスだ。

ネットワーク分離と VPC セキュリティ

VPC レベルのセキュリティ機構は 2 層構造になっている。

Security Groups はインスタンスレベルのステートフルファイアウォール。許可ルールのみを定義し、戻りのトラフィックは自動許可される。

Network ACL (NACL) はサブネットレベルのステートレスファイアウォール。許可と拒否の両方を定義でき、戻りトラフィックも明示的に許可する必要がある。

「SG はインスタンスを守る、NACL はサブネット境界を守る」という二重防御で、片方を突破されてももう片方で防ぐ Defense in Depth が実現する。CLF-C02 では「SG はステートフル、NACL はステートレス」の対比を覚えておくと正答率が上がる。

練習問題（Domain 2 想定）8 問

Q1. EC2 インスタンスのゲスト OS パッチ適用は誰の責任か。
A. AWS
B. 顧客
C. AWS と顧客の共有責任
D. インスタンス起動時に自動的に適用される
正解: B

Q2. AWS Shield Standard の利用料金はいくらか。
A. $0（無料、全顧客に自動適用）
B. $3,000/月
C. $5/月
D. リクエスト数に応じた従量課金
正解: A

Q3. S3 バケットを暗号化する場合、暗号化の有効化は誰の責任か。
A. AWS が自動的に有効化する
B. 顧客が選択して有効化する
C. リージョンによって異なる
D. 暗号化は不要
正解: B

Q4. IAM のベストプラクティスとして、最も推奨される原則はどれか。
A. 全ユーザーに AdministratorAccess を付与する
B. 最小権限の原則（Least Privilege）に従う
C. ルートユーザーを日常業務で使う
D. MFA は管理者だけ有効化する
正解: B

Q5. Amazon GuardDuty が解析する主なデータソースに含まれないものはどれか。
A. CloudTrail Logs
B. VPC Flow Logs
C. DNS Logs
D. S3 オブジェクトの中身（自動スキャン）
正解: D（Macie が S3 内データを解析する役割を持つ）

Q6. コンプライアンスレポート（SOC 2 等）を AWS 顧客がオンデマンドで入手できるサービスはどれか。
A. AWS Config
B. AWS Artifact
C. AWS Trusted Advisor
D. CloudTrail
正解: B

Q7. Security Group と Network ACL の違いとして正しいものはどれか。
A. SG はサブネットレベル、NACL はインスタンスレベル
B. SG はステートフル、NACL はステートレス
C. SG は拒否ルールを書ける、NACL は許可ルールのみ
D. SG と NACL は同じもの
正解: B

Q8. Lambda 関数のセキュリティで顧客が責任を持つ範囲は何か。
A. 関数コード、IAM ロール、環境変数管理
B. 実行環境の OS パッチ
C. ホストサーバの物理セキュリティ
D. 仮想化ハイパーバイザー
正解: A

攻撃シナリオで責任分担を理解する

共有責任モデルを抽象論で覚えるより、典型的な攻撃シナリオで責任分担を考える方が腹落ちする。

シナリオ 1: EC2 インスタンスがマルウェア感染。攻撃者は古い Apache の脆弱性を突いて侵入した。これは顧客責任の領域だ。AWS のホスト OS や仮想化レイヤーが侵害されたわけではなく、顧客がゲスト OS のパッチを怠った結果だ。修復責任、データ復旧、報告書作成、すべて顧客側で対応する。

シナリオ 2: S3 バケットからデータ漏洩。バケットポリシーが「全公開」になっており、誰でもアクセスできた。これも顧客責任。AWS は「公開設定の選択肢」を提供するが、実際に公開するかは顧客の判断だ。Block Public Access 設定を有効化していれば防げた事故、というのが典型パターンだ。

シナリオ 3: AWS リージョン全体の停電。これは事業者責任の領域だが、本来「リージョン全体の停電」は AWS が複数 AZ 構成で回避できる設計になっている。1 AZ だけに依存する設計をしていた顧客は「自分が複数 AZ にレプリカを置かなかった」点で間接的に責任を負う。AWS は SLA に従って返金等の対応をするが、ビジネス影響は顧客が負担する。

シナリオ 4: ハイパーバイザーの脆弱性で隣接テナントからメモリ読み取り。これは事業者責任。仮想化ソフトウェアと物理ハードウェアは AWS の管理範囲で、Spectre / Meltdown のような CPU 脆弱性に対するパッチ適用も AWS が一斉に行う。顧客は対応を待つ立場だ。

これらのシナリオに即答できるレベルになれば、Domain 2 の責任分担系問題はほぼ全問正解できる。

AWS 共有責任モデルの誤解パターン

実務でよく見る共有責任モデルの誤解を 3 つ整理しておく。

誤解 1: 「クラウドだから自動でバックアップされる」。これは半分正しく半分間違い。RDS は自動バックアップ機能があるが、保持期間 (1〜35 日) と自動有効化は顧客設定。EBS は明示的にスナップショットを取らない限りバックアップされない。S3 も標準ではバックアップ概念がなく、バージョニング有効化やクロスリージョンレプリケーションを顧客が設定する。

誤解 2: 「IAM ユーザーに権限を与えなければ安全」。実は「ルートユーザーで操作」「アクセスキーを GitHub にコミット」「MFA 未設定」、こうした基本的な運用ミスが事故の大半を占める。IAM 設計よりも、ルートユーザー保護と MFA 強制、アクセスキーのローテーション、これらの徹底が先だ。

誤解 3: 「AWS が SOC 2 を取っているから自社サービスも準拠している」。これは完全な誤りだ。AWS のインフラレイヤーは SOC 2 認証済みだが、顧客のアプリケーションコード、データ処理ロジック、運用プロセス、これらは顧客自身が SOC 2 監査を受ける必要がある。AWS Artifact で SOC 2 レポートをダウンロードできるのは「インフラ層が認証済みである証明」を顧客が監査人に提示するためだ。

まとめ — 次は Domain 3 コアサービスへ

AWS 共有責任モデルを軸に、IAM の 4 コンポーネント、MFA と Identity Center、主要セキュリティサービス（Shield / WAF / GuardDuty / Inspector / Macie / Detective）、監査系（CloudTrail / Config / Artifact / Trusted Advisor）、コンプライアンス枠、KMS、VPC セキュリティ、ここまでが Domain 2 の核となる。本番では Domain 2 の 15 問のうち 11 問以上を取れば、合格圏に大きく近づく。

最高配点のもう 1 つのドメイン、Domain 3: Cloud Technology and Services（34%）は、EC2 / S3 / RDS / Lambda / VPC を中心としたコアサービス約 30 個を網羅する内容だ。次の記事で深掘りする。AWS 共有責任モデルの理解は、Domain 3 のサービス選択判断や Domain 4 の料金最適化にも繋がる、CLF-C02 全体を貫く中核概念だ。

参照

• AWS Shared Responsibility Model
• AWS Identity and Access Management (IAM)
• AWS IAM Identity Center
• AWS Shield
• AWS WAF
• Amazon GuardDuty
• Amazon Inspector
• Amazon Macie
• AWS Artifact
• AWS Compliance Programs
• AWS Key Management Service
• AWS Cloud Practitioner CLF-C02 完全攻略 — 試験概要と Domain 1: Cloud Concepts（2026-05-26 公開）
• クラウドコンピューティング 完全入門 2026（2026-05-25 公開）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.