AWS責任共有モデルとは（CLF-C02頻出）
AWSの「責任共有モデル（Shared Responsibility Model）」は、クラウドのセキュリティ責任をAWSと利用者（お客様）で分担する考え方です。試験では「どこまでがAWSで、どこからが利用者か」を問われやすく、暗号化・バックアップ・アクセス権限・ネットワーク公開設定などが典型論点になります。
公式の言い回しとしては、AWSはSecurity of the Cloud（クラウドそのもののセキュリティ）、利用者はSecurity in the Cloud（クラウド上のセキュリティ）を担います。詳細は公式ページを参照してください：https://aws.amazon.com/jp/compliance/shared-responsibility-model/
まず押さえる結論：責任の境界は「サービスのマネージド度」で動く
同じAWSでも、サービスの種類によって利用者が担う範囲が変わります。一般に、マネージド度が高い（フルマネージドに近い）ほどAWSの担当が広がり、自由度が高い（IaaS寄り）ほど利用者の責任が増えます。
- IaaS（例：EC2）：利用者がOS以上を運用（責任が大きい）
- PaaS/マネージド（例：RDS）：OSや基盤運用はAWS側、設定やデータ保護は利用者側
- フルマネージド寄り（例：DynamoDB）：運用負荷は小さいが、アクセス制御・データ保護設計は残る
AWS側の責任（Security of the Cloud）
AWSが責任を持つのは「クラウドを成り立たせる土台」です。利用者が直接触れない（または管理できない）層をAWSが運用します。
1) 物理インフラのセキュリティ
- データセンター（施設）と入退室管理
- 物理サーバー、ストレージ、ネットワーク機器
- 電源・空調・耐障害などの設備
2) グローバルインフラの提供・運用
- リージョン／アベイラビリティゾーン（AZ）の提供と運用
- エッジロケーション（例：CDNなど）
3) 仮想化基盤・サービス基盤の保護
- ホストOS、仮想化レイヤー（ハイパーバイザー）
- 各サービスの基盤（コントロールプレーンや運用基盤）
公式の補足として、Well-ArchitectedのSecurity Pillarでも「AWS側＝Security of the Cloud」を明確に説明しています：https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html
利用者側の責任（Security in the Cloud）
利用者が責任を持つのは「クラウド上で使うものの安全」です。設定ミス・権限ミス・公開範囲ミスが事故に直結しやすい領域です。
1) データの保護
- 保存するデータの内容・分類（機密性の判断）
- バックアップ／復元（復旧手順含む）の設計
- データ保持期間・削除ポリシー
2) IDとアクセス管理（IAM等）
- 誰が何にアクセスできるか（認証・認可）
- 最小権限、MFA、キー管理（漏えい対策）
3) 設定・構成（ネットワーク／公開範囲／セキュリティ設定）
- VPC、サブネット、ルート、セキュリティグループ等の設計
- インターネット公開の可否、許可ポート、接続元制限
4) 暗号化（有効化・鍵運用）と通信保護
- 保存時暗号化を有効にするか（S3/EBS/RDS等）
- KMSキーの選択、キーポリシー、権限管理
- 通信のTLS化（HTTPS等）、証明書運用
公式ホワイトペーパー（Risk and Compliance）の責任共有モデル解説も参照できます：https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/shared-responsibility-model.html
サービス別：担当範囲の違い（CLF-C02向けに3サービスで整理）
ここからは、試験でイメージしやすい代表例として DynamoDB / RDS / EC2 を比較します。ポイントは「AWSが運用を肩代わりしても、アクセス制御と復元戦略と鍵・暗号化の運用は利用者に残りやすい」ことです。
Amazon DynamoDB（フルマネージドに近い）
特徴：運用負荷が小さく、DB基盤の管理をAWSに任せられる。
- AWSの担当（例）：DB基盤の運用、可用性確保、サービス基盤の維持
- 利用者の担当（例）：IAM等によるアクセス権限、バックアップ/復元戦略（保持期間や運用方針）、暗号化方式や鍵運用の設計
Amazon RDS（マネージドDB）
特徴：OSやDBエンジンの運用をAWSが担う一方、DBの「使い方の安全」は利用者が担う。
- AWSの担当（例）：OS/DBエンジンの運用（サービスの範囲内）、基盤の維持管理
- 利用者の担当（例）：DBユーザー/権限、ネットワーク公開設定、バックアップ方針（スナップショット運用等）、暗号化の有効化判断と鍵・権限の管理
Amazon EC2（仮想サーバー/IaaS）
特徴：自由度が最も高い分、セキュリティ運用責任も最大になりやすい。
- AWSの担当（例）：データセンター、物理サーバー、物理ネットワーク、仮想化基盤
- 利用者の担当（例）：OSのパッチ適用、ミドルウェア/アプリ管理、セキュリティ設定（FW/SG等）、バックアップ計画、暗号化/鍵運用、ユーザー管理
試験で差がつく「ひっかけポイント」3つ
1) 「自動バックアップがある」≠「復元戦略が不要」
AWSがバックアップ機構を提供しても、保持期間・復元手順・RTO/RPOなどの復旧設計は利用者側に残ることが多いです。
2) 「暗号化される」≠「鍵の管理責任が消える」
暗号化機能が用意されていても、どの鍵を使うか、誰に復号権限を与えるかは利用者が設計します。
3) 「AWSだから安全」ではなく「設定が正しいこと」が前提
公開設定（例：誤った外部公開）や過剰権限（例：不要な管理者権限付与）が事故要因になりやすいため、責任共有モデルは「境界を理解して設定ミスを防ぐ」ための考え方として押さえます。
CLF-C02での位置づけ（公式試験ガイド）
AWS Certified Cloud Practitioner（CLF-C02）では、責任共有モデルの理解が明確に要求されています。出題範囲の公式情報は試験ガイドを参照してください：
- 日本語PDF：https://d1.awsstatic.com/ja_JP/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf
- HTML（Exam Guideのオンライン版）：https://docs.aws.amazon.com/aws-certification/latest/examguides/cloud-practitioner-02.html
まとめ：覚え方（最短）
- AWS：クラウドの土台（施設・物理・基盤・仮想化・サービス基盤）を守る
- 利用者：クラウド上の中身（データ・権限・設定・暗号化運用・復元）を守る
- マネージド度が高いほどAWSの担当が広がるが、アクセス制御とデータ保護設計は残りやすい