AWS 責任共有モデル

AWS 責任共有モデルとは何か？

AWS 責任共有モデル（AWS Shared Responsibility Model）は、Amazon Web Services（プロバイダー）とお客様（ユーザー）の間でセキュリティとコンプライアンスの義務を分割する、契約的および運用的なフレームワークです。AWSはクラウドのセキュリティ（security of the cloud）に責任を持ち、お客様はクラウド内のセキュリティ（security in the cloud）に責任を持ちます。この一文は、CLF-C02のセキュリティドメイン全体で最も試験に出る概念であり、各AWSサービスでその境界線がどこに引かれるかを知ることが、タスクステートメント2.1のバックボーンとなります。

高いレベルで見ると、AWS 責任共有モデルは、AWSがすべてのAWSサービスを稼働させるグローバルインフラストラクチャ（データセンター、ハードウェア、ハイパーバイザー、ネットワークケーブル、物理的なアクセスバッジなど）を保護することを示しています。一方、お客様は、そのインフラストラクチャの上に配置するすべてのもの（データ、アイデンティティ、アプリケーションコード、ファイアウォールルール、暗号化キーなど）を保護します。現実世界ではこの共有責任の境界線が曖昧になることはありませんが、試験問題では、サービスモデルがIaaSからPaaS、SaaSへと移行する際のグレーゾーンを狙ってきます。

CLF-C02においてAWS 責任共有モデルが非常に重要である理由は、セキュリティとコンプライアンス（Security and Compliance）ドメインが30%の比重を占め、単一のドメインとして最大だからです。コミュニティのアンケートでも、試験後のレポートで最も言及されるセキュリティ概念として一貫して「責任共有モデル」が挙げられています。もしテストに臨む前に1つしか暗記できないなら、「AWSはクラウドを保護し、お客様はクラウド内を保護する」というフレーズと、EC2、RDS、Lambdaの典型的な例を暗記してください。

AWS 責任共有モデルを理解することは、単に資格試験に合格するためだけのものではありません。クラウドアーキテクチャの設計、監査の指摘への対応、ランブックの作成、そしてクラウド契約の交渉方法を形作ります。本格的なAWSベースの脅威モデルはすべて「これは私の責任か、AWSの責任か、それとも共有か？」という問いから始まります。そして、この章では要求に応じてその問いに答えられるようにトレーニングします。

やさしい解説: AWS Shared Responsibility Model

技術的な詳細に飛び込む前に、3つの異なる日常的な比喩を使ってAWS 責任共有モデルを記憶に定着させましょう。それぞれの比喩は責任共有パターンの1つの側面を捉えており、これらを合わせることで、多くの受験者が陥る「丸暗記」の失敗を防ぎます。

Analogy 1 — アパートの建物（大家と入居者のパターン）

AWSを、巨大で安全なアパートの建物の大家だと考えてください。大家は建物の基礎、施錠されたロビー、駐車場の防犯カメラ、エレベーター、スプリンクラー、送電網、そして正面ゲートの警備員を維持します。これがクラウドのセキュリティです。入居者であるあなたは、自分の部屋の鍵を受け取ります。部屋の中で、誰に鍵の合鍵を渡すか（IAM）、金庫に何を保管するか（顧客データ）、どの窓を施錠するか（Security Groups）、アラームを設定するかどうか（CloudWatch）、壁に何を飾るか（アプリケーションコード）は、あなたが決めます。もしドアの鍵を開けっぱなしにしていて誰かがあなたの部屋に入りラップトップを盗んだとしても、大家の責任ではありません。それはクラウド内のセキュリティであり、責任共有モデルによればあなたの責任です。この大家と入居者の関係により、責任共有の境界線（下層のインフラストラクチャと上層の顧客の選択）が直感的に理解できます。

Analogy 2 — レストランの厨房（キッチンのパターン）

次に、AWS 責任共有モデルを、シェフに作業スペースを貸し出すレストランの厨房としてイメージしてください。AWSは厨房（コンロ、冷蔵庫、換気設備、保健所の検査証明書、認可された敷地）を所有しています。これがクラウドのセキュリティです。各シェフ（お客様）は自分の食材（データ）を持ち込み、自分のレシピ（アプリケーションロジック）を選び、自分のステーションに誰が入れるかを決め（IAM）、各皿を味見して承認し（設定）、料理の評判（ビジネス成果）に責任を持ちます。もしコンロが壊れたら、それはAWSの仕事です。もしシェフがスープに塩を入れすぎたら、それはシェフの責任です。EC2（ゼロから自分で調理する）からRDS（AWSの副料理長が下ごしらえを手伝う）、そしてLambda（AWSが調理済みの部品を渡し、あなたは盛り付けるだけ）への移行は、厨房スタッフの助けをどれだけ借りるかによって責任共有モデルが変化する同じ厨房のシナリオです。

Analogy 3 — 保険契約（保険のパターン）

最後に、AWS 責任共有モデルをパッケージ化された保険契約として枠組みづけてみましょう。AWSは物理レイヤー（建物、ハードウェア、ハイパーバイザー、ネットワークファブリック）に保険をかけます。これらの危険（データセンターの火災、ディスク障害、ハイパーバイザーのゼロデイ脆弱性）はAWSがカバーする範囲です。ただし、あなたの保険料（AWSの利用料金）は、その上に保存したコンテンツまではカバーしません。もしあなたがポリシー番号を紛失したり、パスワードを漏洩したり、バケットを誤って公開設定にしたり、ルートアカウントのMFAを有効にし忘れたりした場合、責任共有モデルはその損失の責任を明確にあなたに負わせます。AWSは、彼ら側のカバレッジを証明するための公式なコンプライアンスレポート（AWS Artifactを通じて利用可能）を公開しており、あなたは自分側の監査証拠を提供します。この保険の枠組みは、なぜ「共有（shared）」という言葉が使われるのかを説明しています。どちらか一方の当事者だけでは完全なセキュリティを提供できないからです。

Core Operating Principles — Security OF the Cloud vs Security IN the Cloud

AWS 責任共有モデルの標準的な枠組みは、世界を2つのフレーズに分割します。「Security of the cloud（クラウドのセキュリティ）」と「Security in the cloud（クラウド内のセキュリティ）」です。この前置詞（of / in）がすべてです。

Security OF the Cloud (AWSの責任)

AWSは、すべてのAWSサービスを実行するインフラストラクチャを保護する責任を負います。これには以下が含まれます：

• 物理データセンター — バッジアクセス、カメラ監視、24時間365日の警備員、多層的な境界制御。
• ハードウェア — サーバー、ストレージデバイス、ネットワーク機器、およびそれらの廃棄。
• グローバルネットワークインフラストラクチャ — プライベートAWSバックボーン、Regions、Availability Zones、Edge Locations。
• 仮想化レイヤー（ハイパーバイザー） — Nitro System、ホストファームウェア、ハイパーバイザーのパッチ適用。
• 基盤となるマネージドサービスソフトウェア — RDSエンジンコード、Lambda実行環境、S3ストレージサブシステム。

Security IN the Cloud (お客様の責任)

お客様は、AWSインフラストラクチャの上に配置するすべてのものに責任を負います。これには以下が含まれます：

• 顧客データ — 何をどこに保存するか、暗号化するかしないか、どのくらい保持するかを決定します。
• プラットフォーム、アプリケーション、アイデンティティとアクセス管理 (IAM) — ユーザー、グループ、ロール、ポリシー、MFA、ルートの保護。
• オペレーティングシステム (OS) のパッチ適用（EC2のようなIaaSサービスの場合） — AWSはゲストOSにパッチを当てません。
• ネットワークおよびファイアウォール設定 — Security Groups、Network ACLs、VPCルーティング、サブネット設計。
• クライアント側のデータ暗号化と整合性チェック — 保存時（at rest）および転送時（in transit）の暗号化を選択します。
• サーバー側の暗号化の決定 — 有効か無効か、KMSマネージドキーかカスタマーマネージドキーかを選択します。

AWS 責任共有モデルは、根本的には抽象化に関するものです。AWSが抽象化（ハイパーバイザー、マネージドデータベース、サーバーレスランタイムなど）を追加するたびに、セキュリティの境界線は上に移動します。AWSがより多くを吸収し、お客様が管理するスタックは少なくなります。これは最も重要な試験の原則です。

AWS Responsibilities — AWSが常に所有するもの

どのAWSサービスを利用するかにかかわらず、AWSは常にベースラインとなる一連の責任を所有します。責任共有の質問で「データセンターの物理的セキュリティ」や「ネットワークインフラストラクチャのセキュリティ」のようなフレーズを見た場合、それらは常にAWSの責任です。

Physical Data Centers

AWSは、施設入り口での多要素認証、データホールに入る従業員の生体認証、および24時間365日の監視によって物理的なセキュリティを維持します。訪問者は常にエスコートされます。データを保持するドライブは、NIST 800-88プロセスを使用して廃棄前に物理的に破壊されるか、暗号学的に消去されます。この責任がお客様に移行することは決してありません。これは純粋な「クラウドのセキュリティ」としてAWS 責任共有モデルに組み込まれています。

Hardware and Global Infrastructure

サーバー、ルーター、ストレージアレイ、ケーブル、冷却システム、および配電はすべてAWSが所有および保守します。EBSボリュームの基盤となるストレージでディスクが故障した場合、AWSはそれを透過的に交換します。お客様がチケットを提出する必要はなく、ハードウェアを見ることもありません。Region、Availability Zone、およびEdge Locationの可用性、電力、および冷却はAWSの領域のままです。

The Hypervisor and Host OS

ここに重要な罠があります。AWSはハイパーバイザー（ベアメタルとあなたのEC2インスタンスの間のレイヤー）にパッチを適用します。しかし、AWSはあなたのEC2インスタンスの内側にあるゲストOSにはパッチを適用しません。この境界線は、CLF-C02において最もよくテストされる3つのグレーゾーンの1つです。EC2インスタンスを起動した瞬間から、その仮想マシン内で実行されているオペレーティングシステムへのパッチ適用、堅牢化、および監視は、お客様の責任となります。

Customer Responsibilities — お客様が常に所有するもの

サービスに関係なく、AWS 責任共有モデルにおける一部の責任は常にお客様に属します。

Customer Data

お客様は自らのデータをエンドツーエンドで所有します。AWSは、お客様の明示的な許可（IAM経由）なしに、S3オブジェクト、DynamoDBアイテム、またはRDSテーブルのコンテンツにアクセスすることはできません。データの分類、保持、および削除はお客様の責任です。データが保持されている間は、それはお客様のデータです。

Identity and Access Management (IAM)

IAMは常にお客様の責任です。AWSはIAMサービスを提供しますが、ユーザー、グループ、ロール、ポリシー、MFA、パスワードのローテーション、およびルートアカウントの保護を設定するのはお客様です。もし誰かが会社を辞めた後でアクセスキーを無効化し忘れた場合、それは責任共有モデルの下ではお客様側の失敗となります。

Application Code and Configuration

AWS上で実行するすべてのコード（EC2、Lambda、ECS、EKSのいずれであっても）はお客様のものです。入力の検証、シークレットの処理、アプリケーションライブラリの依存関係へのパッチ適用、およびSAST/DASTスキャンはすべて、AWS 責任共有モデルのお客様側に位置します。

Data Encryption Choices

AWSは至る所で暗号化の機能を提供していますが、それをオンにするかどうか、どのキー（AWSマネージド vs カスタマーマネージド）を使用するか、いつローテーションするかを決定するのはお客様です。S3のサーバーサイド暗号化、EBSボリューム暗号化、RDSの保存時の暗号化、KMSキーポリシーはすべて、AWS 責任共有モデルの下での顧客の選択です。

Responsibility Boundary Shifts by Service Type — IaaS vs PaaS vs SaaS

AWS 責任共有モデルは一本の線ではなく、スライディングスケールです。より管理されたサービスになるほど、AWSが引き受ける部分が増え、お客様が管理しなければならない部分は減ります。CLF-C02では、サービスを変更し（EC2 → RDS → Lambda）、責任について何が変わるかを問うシナリオ問題を通じて、この移行をテストするのが大好きです。

IaaS Example — Amazon EC2

EC2は古典的なInfrastructure-as-a-Serviceモデルです。EC2のAWS 責任共有モデルの下では：

• AWS — 物理データセンター、ハードウェア、ハイパーバイザー、AWSマネージドネットワークファブリック。
• Customer — ゲストOS（パッチ適用、堅牢化）、インストールされたソフトウェア、ランタイム、データ、IAM、Security Groups、ネットワークACL、ホストファイアウォール、暗号化の選択、監視エージェント。

EC2はお客様に最大の責任を押し付けます。OSから上のすべてを所有します。これが「EC2のOSパッチ適用」の質問でほとんどの場合お客様が正解となる理由でもあります。

PaaS Example — Amazon RDS

Amazon RDSはPlatform-as-a-Serviceです。RDSのAWS 責任共有モデルでは、OS、データベースエンジンのインストール、およびDBのパッチ適用がAWSに移行します。

• AWS — IaaSのすべてに加えて、データベースホストのゲストOS、データベースエンジンソフトウェア、自動バックアップ、DBエンジンのパッチ適用ウィンドウ、Multi-AZのフェイルオーバー。
• Customer — エンジン内のデータベースユーザーアカウントと権限、スキーマ設計、クエリパフォーマンス、データ、RDS APIのIAM、保存時の暗号化設定、RDSエンドポイント周りのSecurity Groups、バックアップ保持設定。

SaaS Example — Amazon DynamoDB and AWS Lambda

DynamoDB、Lambda、S3のような高度に管理された（SaaSライクまたはサーバーレスと呼ばれることもある）サービスの場合、AWS 責任共有モデルはさらにAWS側に傾きます。

• AWS — すべてのインフラストラクチャ、OS、ランタイム、オートスケーリング、サービス自体のパッチ適用、可用性、および実行環境。
• Customer — アプリケーションコード（Lambda用）、テーブル設計とアクセスパターン（DynamoDB用）、データ、IAM、および暗号化設定。

特にLambdaについて、AWSはお客様が選択したランタイムバージョン（例：Python 3.12）を所有しパッチを適用します。しかし、AWSがランタイムを非推奨（deprecated）にした場合、コードを移行する責任はお客様にあります。責任共有モデルでは、非推奨通知を無視することは許されません。

Side-by-Side Comparison — EC2 vs RDS vs Lambda Responsibility

以下は、3つのサービスアーキタイプにわたるAWS 責任共有モデルの試験対応の標準的な表です。各セルではなく、パターンを暗記してください。

パターンに注目してください：EC2からRDS、そしてLambdaへと移行するにつれて、行がCustomerからAWSに反転します。これがAWS 責任共有モデルの実際の動きです。試験で各行の暗記をテストすることは稀であり、パターンを把握しているかどうかをテストします。

Shared Responsibilities — The Middle Ground

AWS 責任共有モデルにおける一部の項目は、純粋に共有されます。両当事者に役割があり、これを正しく理解することがCLF-C02の差別化要因となります。

Patch Management (Shared Concept)

AWSは自身が所有するインフラストラクチャ（ハイパーバイザー、マネージドサービスエンジン）にパッチを適用します。お客様は、その上にインストールしたもの（EC2のゲストOS、アプリケーションの依存関係）にパッチを適用します。AWS 責任共有モデルでは、これを「パッチ管理 — 共有」として枠組みづけています。概念は両側に適用されますが、それぞれが特定のレイヤーを所有しているためです。

Configuration Management (Shared Concept)

AWSは、基盤となるインフラストラクチャをセキュリティのベストプラクティス（デフォルト拒否のハイパーバイザー分離など）に合わせて設定します。お客様は自身のソソース（バケットポリシー、SGルール、IAMポリシー）を設定します。どちらの側にも設定があり、エンドツーエンドのセキュリティのためには両方が正しくなければなりません。

Awareness and Training (Shared Concept)

AWSは自社のスタッフにセキュリティのトレーニングを実施し、ベストプラクティスのドキュメントを公開します。お客様は自社のエンジニアとユーザーをトレーニングします。もしあなたの会社の開発者がGitHubでアクセスキーを漏洩させた場合、それはお客様のトレーニングの失敗です。もしAWSのエンジニアが内部データを漏洩させた場合、それはAWSのトレーニングの失敗です。

Encryption in Transit

TLSは共同の取り組みです。AWSのサービスエンドポイントはTLSを提供します。お客様は、HTTPSのみのバケットポリシーを適用するかどうか、RDSへのTLS接続を要求するかどうか、VPN暗号化を設定するかどうか、またはCertificate Managerを有効にするかどうかを選択します。両当事者が協力します。

Key Numbers and Must-Memorize Facts

CLF-C02ではパーセンテージを暗唱することは求められませんが、標準的な言い回しを知っていることは求められます。以下は暗記のアンカーです。

• "Security of the cloud" = AWSの責任（インフラストラクチャ）。
• "Security in the cloud" = お客様の責任（データ、設定、アイデンティティ）。
• お客様が常に所有する3つのもの: データ、IAM、ネットワーク/暗号化の設定。
• AWSが常に所有する3つのもの: 物理施設、ハードウェア、ハイパーバイザー。
• EC2 = お客様がゲストOSにパッチを当てる。これに尽きます。
• RDS = AWSがゲストOSとDBエンジンにパッチを当てる。お客様はスキーマとアプリにパッチを当てる。
• Lambda = AWSがランタイムにパッチを当てる。お客様は関数コードと依存関係にパッチを当てる。
• S3 = AWSがAPIの背後にあるすべてにパッチを当てる。お客様はバケットポリシー、オブジェクトACL、データの分類を所有する。
• IAMは常にお客様の責任。AWSがあなたに代わってIAMを設定してくれるサービスはありません。
• 暗号化キーの所有権は選択に依存する: AWS所有のキー（AWSが管理）、KMSのAWSマネージドキー（AWSがローテーションし、お客様が監査可能）、KMSのカスタマーマネージドキー（お客様がローテーションと削除を制御）。

Common Exam Traps — Gray Zones and Service-Type Shifts

AWS 責任共有モデルは、CLF-C02で最も厄介なひっかけ問題をいくつか生み出します。過去12ヶ月のコミュニティデータによると、「責任共有のグレーゾーン」は、セキュリティとコンプライアンスドメインで最も頻繁に見られるペインポイントです。

Trap 4 — S3 Object Permissions

S3はバケットを提供しますが、オブジェクトレベルのACL、バケットポリシー、およびブロックパブリックアクセス（Block Public Access）設定はお客様が所有します。バケットが誤って公開された場合、AWS 責任共有モデルでは100%お客様の責任とされます。AWSはデフォルトでブロックパブリックアクセスを追加して支援していますが、それを有効にするかどうかはお客様の選択です。

Trap 5 — EC2 OS Patching

試験の作成者はこの問題が大好きです。問題で「EC2インスタンスのオペレーティングシステムにパッチを適用するのは誰か？」と聞かれます。答えは常にお客様であり、AWSではありません。AWSはハイパーバイザーにのみパッチを当てます。お客様側で自動化したい場合はAWS Systems Manager Patch Managerを使用できますが、AWS 責任共有モデルの下では依然としてお客様の責任です。

Trap 6 — Shared vs Customer vs AWS Wording

一部の質問では、タスクが「AWSのみ」、「お客様のみ」、または「共有（shared）」であるかを尋ねます。パッチ管理という概念については、答えは「共有」です。ハイパーバイザーのパッチ適用については、AWSです。EC2のゲストOSのパッチ適用については、お客様です。概念について尋ねているのか、特定のレイヤーについて尋ねているのか、問題を注意深く読んでください。

Shared Responsibility Model vs AWS Well-Architected Security Pillar

両方ともAWSセキュリティの世界に存在し、両方ともCLF-C02に出現しますが、これらは異なる質問に答えるものです。AWS 責任共有モデルは、各セキュリティレイヤーに誰が責任を持つかを定義します。Well-Architected Security Pillarは、お客様の側をどのようにうまく実行するかを定義します。

AWS Shared Responsibility Model

• 目的 — 境界の契約。
• 出力 — 分業（「AWSがXを行い、私がYを行う」）。
• 用途 — 監査のスコーピング、コンプライアンスの証拠収集、インシデントの責任分析。

Well-Architected Security Pillar

• 目的 — お客様側のベストプラクティスフレームワーク。
• 出力 — 設計原則（強力なアイデンティティ基盤の実装、トレーサビリティの有効化、全レイヤーでのセキュリティ適用、自動化、転送中および保存中のデータ保護、データから人を遠ざける、イベントへの備え）。
• 用途 — アーキテクチャレビュー、セキュリティ態勢の改善、設計のガイダンス。

試験問題では、この2つを並置することがあります。シナリオで「ハイパーバイザーへのパッチ適用責任が誰にあるかを定義するフレームワークはどれか？」と問われた場合、答えはAWS 責任共有モデルです。「セキュリティのベストプラクティスを自動化することを推奨する原則はどれか？」と問われた場合、答えはSecurity Pillarです。これら2つは補完的ですが、互換性はありません。

Practical Application — Real-World Decision Flow

AWS 責任共有モデルを実際の行動に移すとこのようになります。

Step 1 — Identify Service Type

ワークロードはEC2（IaaS）で実行されていますか？RDS/ECS-on-EC2（PaaSに近い）ですか？それともLambda/DynamoDB/S3（マネージド/サーバーレス）ですか？これにより、ベースラインの責任分割が固定されます。

Step 2 — Overlay the Always-Customer Items

データ、IAM、ネットワーク制御はあなたのものです。ポリシーが存在することを確認します。

Step 3 — Identify Shared Items

転送中の暗号化とパッチ管理という概念。どのレイヤーで誰が何をするかを定義します。

Step 4 — Verify AWS's Side Via AWS Artifact

AWS Artifactは、SOC 2レポート、ISO 27001証明書、PCI-DSSコンプライアンス証明書、およびHIPAA BAAをホストしています。これらの文書は、AWSがAWS 責任共有モデルの自らの側を満たしていることを示すためのものです。監査人はこれらを要求します。

Step 5 — Build Customer Evidence

あなたはログ（API監査用のCloudTrail、アプリケーション用のCloudWatch Logs）、設定スナップショット（AWS Config）、およびIAMアクセスのレビューを提供します。これが責任共有モデルにおけるお客様側の証拠です。

Shared Responsibility in Compliance Frameworks

HIPAA、PCI-DSS、GDPR、SOC 2、ISO 27001、FedRAMPなど、AWSがサポートするすべてのコンプライアンス制度は、AWS 責任共有モデルを通じてスコープが設定されます。AWSはインフラストラクチャスコープ（クラウドのセキュリティ）のコンプライアンスを提供し、お客様はそれを継承してその上に自身のコントロールを重ねます（クラウド内のセキュリティ）。

HIPAAの場合、AWSはHIPAA対象サービスをカバーするビジネスアソシエイト契約（BAA）に署名します。PHIを処理するお客様のアカウント内のすべてはお客様が管理します。PCI-DSSの場合、AWSはレベル1のサービスプロバイダーとして認定されていますが、お客様はそのスコープ内で引き続きカード会員データ環境を設定する必要があります。AWS 責任共有モデルは、AWSが何を証明し、お客様が自分自身で何を証明しなければならないかの境界線を引きます。

FAQ — AWS 責任共有モデル

Q1: AWS 責任共有モデルの最も優れた1文の要約は何ですか？

A: AWSはクラウドのセキュリティ（インフラストラクチャ）に責任があり、お客様はクラウド内のセキュリティ（データ、アイデンティティ、設定、およびアプリケーション）に責任があります。この正確な表現は、AWSがすべての公式文書で責任共有モデルを説明する方法であり、CLF-C02が認識することを期待している表現です。

Q2: AWSは私のEC2オペレーティングシステムにパッチを当ててくれますか？

A: いいえ。AWSはハイパーバイザーとホストインフラストラクチャにパッチを適用しますが、EC2インスタンスのゲストオペレーティングシステムはAWS 責任共有モデルの下で常にお客様の責任です。OSのパッチ適用を自動化するにはAWS Systems Manager Patch Managerを使用します — 自動化の仕組みはAWS内にありますが、責任は引き続きお客様にあります。

Q3: RDSやLambdaのようなマネージドサービスの場合、AWS 責任共有モデルはどう変わりますか？

A: 境界線が上方に移動します。RDSの場合、AWSはゲストOSとデータベースエンジンのパッチ適用を引き受けます。お客様はデータ、スキーマ、ユーザー、IAMのみを管理します。Lambdaの場合、AWSはランタイムと実行環境を管理します。お客様は関数コードと設定のみを管理します。管理される部分が多いサービスほどお客様の所有範囲は減りますが、お客様がデータ、IAM、暗号化の選択に対する責任を放棄することは決してありません。

Q4: AWS 責任共有モデルにおいて、IAM設定の責任者は誰ですか？

A: すべてのサービスで常に、お客様です。AWSはIAMサービス自体を提供します（それはAWSのインフラストラクチャの責任です）が、設定（ユーザー、ロール、グループ、ポリシー、MFA、ルート保護）は常にお客様の責任です。アクセスキーの漏洩や過剰な権限を持つポリシーは、お客様側の失敗です。

Q5: AWSがAWS 責任共有モデルの自らの側を満たしているという証拠はどこで見つけられますか？

A: AWS Artifactは、AWSのコンプライアンスレポートや契約のための公式セルフサービスポータルです。SOCレポート、ISO証明書、PCI-DSSコンプライアンス証明書、HIPAA BAAなどをホストしています。お客様はこれらを使用して、AWSがAWS 責任共有モデルの「クラウドのセキュリティ」部分を果たしていることを監査人に証明します。

Q6: 私のS3バケットが誤って公開されてしまった場合、それはAWSの責任ですか、それとも私の責任ですか？

A: あなたの責任です。AWS 責任共有モデルの下では、バケットポリシーとブロックパブリックアクセス設定はお客様が所有する設定です。AWSは安全なデフォルトを提供しています（2023年4月以降の新しいバケットではブロックパブリックアクセスがデフォルトでオンになっています）が、最終的な設定の選択 — そして監査証跡 — はお客様にあります。AWSがあなたのデータを漏洩させたのではなく、あなたの設定が漏洩させたのです。

Q7: 転送中の暗号化はAWSの責任ですか、それともお客様の責任ですか？

A: 共有されています。AWSはサービスエンドポイントでTLSを提供し、内部サービス間のトラフィックを暗号化します。HTTPSのみのアクセスを強制するかどうか、RDS接続にTLSを要求するかどうか、VPNトンネルを暗号化するかどうか、AWS Certificate Manager経由でカスタム証明書を管理するかどうかを決定するのはお客様です。AWS 責任共有モデルの下で真のエンドツーエンドの転送中暗号化を実現するには、両当事者がそれぞれの役割を果たす必要があります。

Further Reading and Official Sources

• AWS Shared Responsibility Model — https://aws.amazon.com/compliance/shared-responsibility-model/ — 信頼できるランディングページ。
• AWS Overview Whitepaper — Security and Compliance — https://docs.aws.amazon.com/whitepapers/latest/aws-overview/security-and-compliance.html — 例付きの詳細な解説。
• AWS Certified Cloud Practitioner Exam Guide (CLF-C02) — https://d1.awsstatic.com/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf — タスクステートメント 2.1 の詳細。
• AWS Artifact — https://aws.amazon.com/artifact/ — コンプライアンスドキュメントのハブ。
• AWS Well-Architected Security Pillar — https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html — お客様側をうまく実行するためのコンパニオンフレームワーク。

Summary — AWS Shared Responsibility Model in One Page

AWS 責任共有モデルは、すべてのAWSの会話における「誰が何を保護するのか」という問いに対する答えです。AWSはクラウドを保護します：データセンター、ハードウェア、ハイパーバイザー、マネージドサービスエンジン。お客様はクラウド内を保護します：データ、IAM、アプリケーション設定、ネットワークルール、暗号化の選択。この境界線はサービスタイプによって移動します。IaaSであるEC2はお客様に最も多くの責任を押し付け、RDSのようなマネージドサービスはOSとエンジンをAWSに戻し、LambdaのようなサーバーレスサービスやDynamoDBのようなマネージドサービスはさらに多くをAWSに引き継ぎます。常にお客様のものとなる3つのもの：データ、IAM、そして暗号化の設定。常にAWSのものとなる3つのもの：物理施設、ハードウェア、ハイパーバイザー。これらのアンカーを暗記し、その移行を理解すれば、CLF-C02のAWS 責任共有モデルの章は確実にポイントを稼げる分野になります。