AWS責任共有モデルを初心者向けに整理する

AWS Cloud Practitionerで最初に押さえるべき考え方が、責任共有モデル（Shared Responsibility Model）です。これは「AWSが全部守ってくれる」という話ではありません。AWSが守る範囲と、利用者が守る範囲を分けて理解するための考え方です。

結論

AWSはクラウド基盤そのものを守ります。利用者は、クラウド上でどう設定し、どう使うかを守ります。

AWSの公式ドキュメントでは、AWSが「クラウドのセキュリティ（Security of the Cloud）」に責任を持ち、利用者が「クラウド内のセキュリティ（Security in the Cloud）」に責任を持つ、という言い方で説明されています。前置詞の of と in が分界点を表しているので、この対比で覚えると混乱しにくくなります。

AWS側の責任

AWS側の責任は、物理的なデータセンター、ハードウェア、ネットワーク基盤、仮想化基盤などです。利用者がデータセンターに入ってサーバーを守ることはありません。その部分はAWSが管理します。

たとえば、物理サーバーの故障対応、データセンターの入退室管理、電源や空調の管理、ホストOSと仮想化レイヤーへのパッチ適用はAWS側の責任です。

利用者側の責任

利用者側の責任は、IAMユーザーやIAMロールの権限設定、S3バケットの公開設定、EC2のゲストOS設定、アプリケーションの脆弱性対策、保存するデータの管理などです。

たとえば、S3バケットを誤ってパブリック公開した場合、それは基本的に利用者側の設定ミスです。AWSがS3というサービス基盤を安全に運用していても、利用者が公開設定を間違えれば情報漏えいにつながります。

統制の3分類

AWSは責任範囲を3つの型に整理しています。試験でも実務でも、この分類で考えると判断しやすくなります。

パッチ管理が「共有される統制」に入るのがポイントです。AWSは基盤側にパッチを当てますが、EC2のゲストOSやアプリケーションの依存ライブラリは利用者が当てます。

サービスごとに責任範囲は変わる

責任共有モデルは、利用するサービスによって利用者側の責任範囲が変わります。同じ「AWSを使う」でも、EC2とLambdaでは利用者が背負う量がまったく違います。

マネージドサービスになるほど、利用者はインフラ管理から離れ、データ、権限、設定、アプリケーションに集中します。ただし「責任がゼロになる」わけではありません。Lambdaでも、実行ロールに管理者相当の権限を付ければ、それは利用者側の設計上の問題です。

よくある誤解

誤解1: マネージドサービスなら設定ミスは起きない

RDSはOSパッチをAWSが当ててくれますが、セキュリティグループの送信元を 0.0.0.0/0 で開ければ、誰でも接続を試せる状態になります。マネージドかどうかと、設定が安全かどうかは別の話です。

誤解2: バックアップはAWSが勝手に取ってくれる

S3はオブジェクトの耐久性が非常に高いサービスですが、利用者が誤って削除した場合に戻せるかどうかは、バージョニングやレプリケーションを有効にしているかどうかで決まります。これらはデフォルトで有効ではないため、必要なら利用者が有効化します。RDSの自動バックアップも、保持期間を 0 日にすれば取得されません。

誤解3: 責任共有モデルはセキュリティだけの話

可用性も分界の対象です。AWSはアベイラビリティゾーンという単位で障害を分離できる基盤を提供しますが、複数AZに配置するかどうかを決めるのは利用者です。単一AZに置いた構成がAZ障害で停止した場合、それは設計上の選択の結果として扱われます。

設定を確認する

責任共有モデルは概念だけで終わらせず、自分のアカウントで確認できる形に落とすと理解が定着します。たとえばS3のブロックパブリックアクセス設定は、AWS CLIで次のように確認できます。

aws s3api get-public-access-block --bucket YOUR_BUCKET_NAME

4項目（BlockPublicAcls / IgnorePublicAcls / BlockPublicPolicy / RestrictPublicBuckets）がすべて true であれば、ACLやバケットポリシーで意図せず公開される経路は塞がれています。現在のAWSでは、新規作成したバケットはこの4項目が有効な状態から始まります。「S3はデフォルトで公開される」という古い前提のまま覚えていると、誤答や誤設計につながります。

試験で問われるポイント

Cloud Practitionerでは、次のような観点が問われます。

• AWSはデータセンターや物理基盤、ホストOS、仮想化レイヤーを管理する
• 利用者はIAM、データ、アプリケーション設定、ゲストOSを管理する
• EC2ではOSパッチなど利用者側の責任が大きい
• マネージドサービスではAWS側の管理範囲が広がるが、権限設定とデータ管理は常に利用者側に残る
• パッチ管理・構成管理・教育は「共有される統制」に分類される

「AWSが管理するのはどれか」「利用者が管理するのはどれか」を選ぶ形式で問われることが多いため、サービス名と分界点をセットで覚えるのが有効です。責任共有モデルはAWS公式の試験ガイドでもセキュリティ領域の中心概念として位置づけられており、サービスを問わず判断の土台になります。

実務での注意点

実務では「AWSだから安全」ではなく、「AWSを安全に設定できているか」が重要です。特にIAM、S3、セキュリティグループ、CloudWatch Logsは初学者が事故を起こしやすい部分です。

CloudWatch Logsは見落とされがちですが、アプリケーションが出力したログに個人情報や認証情報が混ざれば、それはログの保管場所の問題ではなく、何を出力するかを決めた利用者側の問題になります。

このサイトでも、S3は直接公開せずCloudFront OAC経由にし、GitHub ActionsのIAM権限もS3デプロイとCloudFront Invalidationに絞る設計にしています。責任共有モデルを設計に反映するというのは、こうした個々の判断の積み重ねです。

関連用語

• IAM
• Amazon S3
• Amazon CloudFront

次に読む記事

• IAMユーザー・IAMロール・IAMポリシーの違い
• AWS Cloud Practitionerの模擬問題を解く