導入
「うちのS3バケットから情報が漏れた。AWSのせいだ」——本当にそうでしょうか。実はAWSと利用者のあいだには、明確な役割分担のルールがあります。
説明
責任共有モデル（Shared Responsibility Model）とは、クラウドのセキュリティを「AWSが担う部分」と「利用者が担う部分」に切り分ける考え方です。大きく2つに分かれます。
- クラウド”の”セキュリティ（Security of the Cloud）＝AWSの責任 … データセンターの物理的な警備、ハードウェア、電源・空調などの設備、ネットワークインフラ、そして仮想化を行う基盤（ハイパーバイザー）そのものを守ること。利用者はここに手を出せないし、出す必要もありません。
- クラウド”内”のセキュリティ（Security in the Cloud）＝利用者の責任 … 自分が置いたデータの暗号化、OSやミドルウェアの設定・パッチ適用、ネットワーク（ファイアウォール）の設定、そして「誰が何にアクセスできるか」を管理するIAMの設定。ここはAWSではなく利用者が守るべき領域です。
重要なのは、この境界線がサービスの種類によって動くことです。Amazon EC2（仮想サーバー）のように利用者がOSレベルまで触れるサービスは利用者の責任範囲が広く、Amazon S3やAWS Lambdaのようなマネージドサービスは、AWSがOSやミドルウェアの管理まで肩代わりするため利用者の責任範囲が狭くなります。「マネージドの度合いが上がるほど、利用者の作業は減るが責任がゼロになるわけではない」という点も忘れてはいけません。データの中身や設定ミスは、どんなサービスでも常に利用者の責任です。
具体例
実際に起きがちな事故を、責任の所在で振り分けてみましょう。
| 起きたこと | 誰の責任か | 理由 |
|---|---|---|
| S3バケットを「公開」設定にしたまま顧客情報を置き、流出した | 利用者 | 設定（アクセス権）は利用者の領域 |
| EC2のOSのパッチを当てず、既知の脆弱性を突かれた | 利用者 | OSから上の管理は利用者の領域 |
| データセンターが火災に遭い、ハードが損傷した | AWS | 物理設備・施設はAWSの領域 |
| AWSの仮想化基盤（ハイパーバイザー）に脆弱性が見つかった | AWS | 基盤そのものはAWSの領域 |
ニュースになる「クラウドからの情報漏洩」の大半は、実はAWSの基盤の欠陥ではなく、利用者側の設定ミス（公開設定・弱い権限）です。「クラウドにしたから安全」ではなく、「AWSが守る部分の“上”は自分で守る」——この線引きが責任共有モデルの核心です。
読んでみよう
CLF試験では「セキュリティグループの設定ミスは誰の責任か」のような設問が出ます。物理・基盤側はAWS、設定・データ側は利用者、という線引きを最初に覚えておきましょう。