「AWS責任共有モデル」——AWS認定試験の参考書を開くと最初の方に必ず出てくる、あの図を見たことがあるでしょうか。AWSが守る部分と利用者が守る部分を分けた、シンプルな2層構造の図です。
「言ってることは分かるけど、実務でどう使うの?」「マネージドサービスなら全部AWSが守ってくれるんじゃないの?」——後輩からよく聞く質問です。
私自身、大手IT企業のクラウド運用案件で複数のAWSアカウントを構築・運用し、お客様への説明やインシデント対応の場面で、この責任共有モデルを何度も使ってきました。責任共有モデルは試験のための知識ではなく、現場で日常的に使う「クラウドの設計図」です。
この記事では、新人エンジニアが現場で詰まらないように、責任共有モデルを実務目線でかみくだいて解説します。読み終わる頃には、「これは誰の責任か」を即答できるようになっているはずです。
なぜ責任共有モデルが新人エンジニアの最初の関門なのか
後輩を見ていると、責任共有モデルでつまずく理由は3つあると感じます。
(1) 概念が抽象的すぎる
「OF the Cloud」と「IN the Cloud」と言われても、具体的に何を指すのかピンと来ません。教科書的な説明では分割線が一本だけですが、実際の現場では「どこまでが自分の責任か」を判断する場面が無数にあります。
(2) サービスによって責任範囲が変わる
EC2とS3とLambdaでは、利用者が守る範囲が全く違います。「マネージドサービスならAWSが守ってくれる」と単純化して理解してしまうと、ある日突然「これも自分の責任だったのか」と気付いてヒヤッとすることになります。
(3) 試験のための知識として習って終わる
クラウドプラクティショナーの参考書には必ず登場しますが、「責任共有モデル=試験で出る暗記事項」で終わってしまう人が多いのが現実です。本当はセキュリティ設計・インシデント対応・お客様説明のすべての基盤になる概念なのに、その実務的な使い道が伝わっていません。
この3つの壁を、これから順番に崩していきます。
責任共有モデルの基本:「OF the Cloud」と「IN the Cloud」
まずは骨組みを押さえます。AWSが定義する責任共有モデルは、シンプルに2層に分かれます。
AWSが守るもの(Security OF the Cloud)
AWSは「クラウドそのもの」を守ります。具体的には次のような領域です。
- 物理データセンター:入退室管理、災害対策、電源・空調
- ハードウェア:物理サーバー、ストレージ、ネットワーク機器
- 仮想化基盤:Hypervisor、テナント間の分離
- グローバルネットワーク:リージョン間接続、AZ間の通信
これらは利用者が直接触ることのできない領域です。AWSが第三者認証(ISO、SOC、PCI DSSなど)を取得して品質を保証しています。
利用者が守るもの(Security IN the Cloud)
一方、「クラウドの中で動かしているもの」は利用者の責任です。
- データ:保存するデータの内容、暗号化、分類
- IAM・アクセス権限:誰に何を許可するか
- OS・ネットワーク設定:パッチ、セキュリティグループ、ルートテーブル
- アプリケーション:アプリの脆弱性対策、ライブラリの更新
- 監視・ログ:CloudTrailの有効化、ログの保管、アラート設計
覚え方として、私が後輩に教えているのは「触れるものは全部自分の責任」というシンプルな原則です。マネジメントコンソールから操作できる範囲、コードで制御できる範囲——これらはすべて利用者が責任を持つ領域です。
サービス種類で責任範囲は変わる(IaaS/PaaS/SaaS)
ここからが本記事の核心です。「責任共有モデル」と一言で言っても、AWSのサービス種類によって責任範囲は変わります。これを理解していないと、現場で確実に詰まります。
AWSのサービスは大きく3つに分類できます。
IaaSタイプ:EC2(利用者責任が一番大きい)
EC2のようなインフラストラクチャサービスでは、AWSが守るのは物理基盤までです。OS、ミドルウェア、アプリ、データ、ネットワーク制御の全部が利用者責任になります。
つまり、EC2を使う=ほとんどオンプレと同じくらい自分で守る必要があるということです。「クラウドだから安心」ではなく、「クラウドの上で動かしているサーバーの面倒は自分で見る」という認識が必要です。
コンテナ系:RDS、ECSなど(中間)
RDSのようなマネージドサービスでは、OSとミドルウェアのレイヤーはAWSが管理します。新人が誤解しがちですが、それでも次の領域は利用者責任のまま残ります。
- データベース内のデータの分類、暗号化設定の有効化
- ユーザー権限の管理(DBユーザー、IAM)
- セキュリティグループでのネットワーク制御
- バックアップ設計(自動バックアップを有効にするかどうかは利用者判断)
「マネージドだから設定しなくていい」のではなく、「マネージドの中で利用者が設定すべき項目がある」と捉えてください。
抽象化サービス:S3、Lambda(利用者責任が一番小さい)
S3やLambdaのような抽象化サービスでは、AWSがアプリ実行環境まで全部管理してくれます。利用者の責任は、データ・権限・コードのみに絞られます。
ただし、ここで油断するのが新人の罠です。S3のバケットの公開設定、Lambdaのロール設定、これらを誤ると一気に事故になります。「自分で触れる範囲が狭い分、その狭い範囲のミスが致命傷になりやすい」のがこのカテゴリの特徴です。
主要サービスごとの責任分界:EC2/RDS/S3/Lambda
抽象論ばかりでは分かりづらいので、新人が触る4サービスについて、具体的に「誰が何をする」を整理します。
| 項目 | EC2 | RDS | S3 | Lambda |
|---|---|---|---|---|
| OSパッチ | 利用者 | AWS | 該当なし | AWS |
| ミドルウェア更新 | 利用者 | AWS(DBエンジン) | 該当なし | AWS(ランタイム) |
| アプリ脆弱性対策 | 利用者 | 利用者(クエリ・接続文字列) | 該当なし | 利用者(コード) |
| データ暗号化設定 | 利用者 | 利用者 | 利用者 | 利用者 |
| ネットワーク制御 | 利用者(SG/NACL) | 利用者(SG) | 利用者(バケットポリシー) | AWS(基本) + 利用者(VPC設定) |
| バックアップ | 利用者(AMI/Snapshot) | 利用者(自動バックアップ設定) | 利用者(バージョニング設定) | 該当なし |
| ログ取得 | 利用者 | 利用者(有効化判断) | 利用者(アクセスログ) | 利用者(CloudWatch) |
表で見ると分かりますが、「データ暗号化」「ネットワーク制御」「バックアップ」「ログ」の4項目はどのサービスでも利用者責任です。これらは「マネージド度合いに関係なく自分の領域」だと覚えてしまうのが早いです。
新人がやりがちな「責任範囲の勘違い」5つ
後輩を見ていて何度も目撃した、典型的な勘違いを5つにまとめました。
勘違い①:「マネージドサービスなら全部AWSが守ってくれる」
マネージドサービスはOS・ミドルウェアまでをAWSが管理してくれますが、その上で動かすデータと権限は利用者責任です。RDSをマネージドだからと言ってIAMやセキュリティグループを甘く設定すれば、即セキュリティ事故につながります。
勘違い②:「S3はAWSが守ってくれるから安心」
S3バケットの公開設定ミスによる情報漏洩事故は、ニュースで何度も報道されています。S3のインフラはAWSが守りますが、バケットの公開設定は完全に利用者責任です。「Block Public Access」を有効にする、バケットポリシーを最小権限で書く、これらは利用者が必ず行う作業です。
勘違い③:「データはAWSが暗号化してくれる」
S3、EBS、RDSなどには暗号化機能がありますが、多くの場合「暗号化を有効にするかどうかの判断と設定」は利用者が行います。特に古いリソースは暗号化が無効のまま運用されているケースがあります。新規リソース作成時に必ず暗号化オプションをチェックする習慣をつけてください。
勘違い④:「ログはAWSが取ってくれている」
CloudWatchの一部メトリクスは自動取得されますが、CloudTrail(API操作ログ)、S3アクセスログ、VPCフローログ、CloudWatch Logs Insightsなどは「有効化する判断」が利用者責任です。インシデント発生時に「ログがなくて調査できない」となるのは、最初の有効化を怠っているケースがほとんどです。
勘違い⑤:「AWSのコンプライアンス認証があれば自分たちも認証相当」
AWSはISO 27001、SOC 1/2/3、PCI DSSなどの認証を取得していますが、これは「AWSのインフラがその認証を満たしている」という意味であって、利用者のシステムが自動的に認証相当になるわけではありません。利用者側で適切な設定・運用ができていることが、認証の前提です。
現場でどう使う?お客様・社内への説明シーン
責任共有モデルは「知っているだけ」では意味がなく、実務で「使えるか」が問われます。私が現場で実際に責任共有モデルを使う典型的なシーンを3つ紹介します。
シーン①:セキュリティ要件の整理
新規システム設計時、お客様から「セキュリティ対策を一覧で出して欲しい」と言われることがあります。この時、責任共有モデルを基に「AWS側で担保される項目」と「自社で実装する項目」を整理して提示します。
これがあると、「物理セキュリティはAWSの認証で担保、IAM・暗号化・ログは弊社側で実装」のように、議論が整理されます。お客様の理解も格段に早くなります。
シーン②:インシデント発生時の責任分界
システム障害が起きた時、最初に判断すべきは「これはAWS側の問題か、自社の問題か」です。
- AWS Health Dashboardで該当リージョンの障害情報を確認 → AWS側の問題なら復旧待ち
- CloudTrailで自分たちが何をしたかを確認 → 設定変更が原因なら自社対応
- セキュリティグループ、IAMポリシーの変更履歴をチェック
責任共有モデルが頭に入っていると、この切り分けが直感的にできます。「OF the Cloud」の問題ならAWSサポートへ、「IN the Cloud」の問題なら自分たちで調査、という判断軸が明確になります。
シーン③:監査対応・外部認証取得
ISMS、Pマーク、SOC2などの監査では、「クラウドの中でどこまで自分たちが管理しているか」を説明する必要があります。責任共有モデルは、この説明の前提として必ず使われます。
「AWSの認証を引用しつつ、利用者責任の領域でやっている対策を具体的に列挙する」——これが監査対応の基本パターンです。
インシデント対応で責任分界を切り分ける思考法
新人が一番焦るのが、本番でトラブルが起きた時の切り分けです。私が後輩に教えている「3つの質問」を紹介します。
質問1:「どのレイヤーで起きているか?」
物理障害(電源、ネットワーク機器の故障など)ならAWS側です。OSやアプリのエラー、設定ミスなら利用者側です。エラーメッセージとログから、まずレイヤーを特定します。
質問2:「自分たちが直近で何かを変更したか?」
CloudTrailで直近24時間のAPI履歴を見れば、自分たちの変更内容が一覧で分かります。設定変更・リソース削除・権限変更などが直近にあれば、それが原因の可能性が高いです。
質問3:「他のお客様でも同じ事象が出ているか?」
AWS Health DashboardやAWSのステータスページを見て、リージョン単位の障害があるかをチェックします。広範囲の事象ならAWS側、自社だけの事象なら自社内の問題です。
この3つの質問を順番に問えば、責任分界はほぼ間違いなく切り分けられます。パニックになった時こそ、この型に当てはめて冷静に判断するのが現場の鉄則です。
AWS責任共有モデルに関するよくある質問(FAQ)
Q1. AWS責任共有モデルとは何ですか?
AWSと利用者がセキュリティ責任を分担するという考え方です。AWSは「クラウドのセキュリティ(物理データセンター・ハードウェア・仮想化基盤)」を担当し、利用者は「クラウド内のセキュリティ(OS・ネットワーク設定・データ・IAM・アプリケーション)」を担当します。トラブル対応や監査の責任分界に直結する重要な概念です。
Q2. マネージドサービスを使えばセキュリティは全部AWSが守ってくれる?
違います。マネージドサービス(RDSやLambdaなど)でもAWSが担当するのはあくまでインフラ・OS・ミドルウェア部分です。データの暗号化設定、アクセス権限の管理(IAM)、ネットワークアクセス制御(セキュリティグループ)、データの中身そのものなどは常に利用者の責任です。
Q3. S3バケットの公開設定ミスは誰の責任?
完全に利用者の責任です。S3のインフラはAWSが守りますが、バケットのアクセス権限設定は利用者が行うため、設定ミスによる情報漏洩はAWSの責任範囲外です。これは責任共有モデルにおける典型的な「IN the Cloud」の領域で、多くの新人がここで詰まります。
Q4. EC2のOSパッチは誰が当てる?
利用者が当てます。EC2はIaaS(インフラストラクチャサービス)に分類され、OS以上のレイヤーはすべて利用者責任です。一方、RDSはマネージドサービスなのでデータベースエンジンのパッチはAWSが当てます。サービスの種類によってパッチ責任が変わる点に注意が必要です。
Q5. 責任共有モデルはどんな時に使う知識?
主に3つの場面で使います。1つ目はセキュリティ設計のチェックリストとして。2つ目はインシデント発生時に「AWS側の問題か自社の問題か」を切り分ける判断軸として。3つ目はお客様や監査人に「どこまで自分たちが管理しているか」を説明する根拠資料として。実務での会話に頻繁に登場する概念です。
まとめ:責任共有モデルは「クラウドの設計図」
長くなったのでポイントを整理します。
- AWSは「OF the Cloud(物理基盤)」を守り、利用者は「IN the Cloud(中で動かすもの)」を守る
- サービス種類(IaaS / コンテナ系 / 抽象化サービス)によって責任範囲は階段状にスライドする
- どのサービスでも「データ暗号化・ネットワーク制御・バックアップ・ログ」の4項目は利用者責任のまま
- 「マネージド=全部安心」「AWSの認証=自分たちも認証相当」は典型的な勘違い
- セキュリティ設計、インシデント切り分け、監査対応の3シーンで実務的に使う知識
責任共有モデルは試験のためだけの暗記事項ではなく、クラウド時代のエンジニアが日常的に使う「設計図」です。「これは誰の責任か」を即答できるようになると、お客様との会話も、インシデント対応も、格段にスムーズになります。
AWS学習を本格的に進めるなら、(別記事「最初の3ヶ月で押さえるAWS基礎学習ロードマップ」)と(別記事「AWSの請求が怖くなくなる — 料金構造の考え方」)もぜひ合わせて読んでみてください。「学習の順序」「料金」「責任分界」の3点が揃えば、新人エンジニアとして自走できる基礎が固まります。
コメント