AWSを学習し始めると、必ず耳にする言葉が「責任共有モデル（Shared Responsibility Model）」です。
責任共有モデルとは、AWSとユーザーが、それぞれどこまでセキュリティの責任を負うのかを明確にした考え方です。
例えば、Amazon EC2を利用している場合、AWSがデータセンターや物理サーバーの管理を行いますが、OSのアップデートやIAMの設定は利用者が実施しなければなりません。
この責任範囲を正しく理解していないと、「AWSを利用しているからすべてAWSが管理してくれる」と誤解し、セキュリティ事故につながる可能性があります。
また、AWS認定ソリューションアーキテクト アソシエイト（SAA-C03）では、責任共有モデルに関する問題が毎回のように出題されます。
この記事では、責任共有モデルの基本的な考え方から、EC2・RDS・S3・Lambdaなど主要サービスごとの責任範囲、実務での考え方まで、初心者にも分かりやすく解説します。
この記事でわかること
- 責任共有モデルとは何か
- AWSとユーザーの責任範囲の違い
- サービスごとの責任範囲（EC2・RDS・S3・Lambda）
- 初心者が間違えやすいポイント
- SAA試験で頻出のポイント
責任共有モデルとは？
責任共有モデル（Shared Responsibility Model）とは、AWSが提供するクラウドサービスにおいて、「AWS」と「利用者（ユーザー）」がそれぞれ異なる責任を持つという考え方です。
AWSはクラウド基盤を提供していますが、クラウド上で動作するシステムのすべてを管理しているわけではありません。
AWSでは、この考え方を次の2つに分けて説明しています。
- Security of the Cloud（クラウド自体のセキュリティ）
- Security in the Cloud（クラウド上のセキュリティ）
| 責任 | 担当 |
|---|---|
| クラウド自体のセキュリティ（Security of the Cloud） | AWS |
| クラウド上のセキュリティ（Security in the Cloud） | 利用者 |
この2つの違いを理解することが、責任共有モデルを理解する第一歩です。
なぜ責任共有モデルが重要なのか？
オンプレミス環境では、サーバーやネットワーク機器、ストレージなど、すべてを自社で管理する必要があります。
一方、AWSでは物理インフラの管理をAWSが担当するため、利用者はアプリケーションやデータなど、自社に必要な部分だけを管理すればよくなります。
しかし、「AWSを使っているからセキュリティもすべてAWSが対応してくれる」と考えるのは大きな誤りです。
つまり、責任共有モデルを理解することは、AWSを安全に利用するための基本であり、実務でも最初に身につけるべき知識です。
AWSが責任を持つ範囲（Security of the Cloud）
AWSはクラウドサービスを提供する事業者として、クラウド基盤そのもののセキュリティを管理しています。
利用者は物理サーバーやデータセンターの管理を意識する必要はありません。
| AWSが管理する項目 | 内容 |
|---|---|
| データセンター | 建物・入退室管理・監視カメラなど |
| 物理サーバー | サーバー本体・CPU・メモリなど |
| ストレージ装置 | 物理ディスク・RAID構成など |
| ネットワーク設備 | スイッチ・ルーター・光回線など |
| 仮想化基盤 | Hypervisorなどの仮想化技術 |
| リージョン・AZの運用 | 高可用性を維持するための運用 |
利用者はこれらを管理する必要がなく、その分、アプリケーション開発やシステム設計に集中できます。
ユーザーが責任を持つ範囲（Security in the Cloud）
AWSでは、クラウド基盤そのものはAWSが管理しますが、クラウド上で構築したシステムのセキュリティについては利用者が責任を負います。
これを「Security in the Cloud（クラウド上のセキュリティ）」と呼びます。
AWSが安全なクラウド環境を提供していても、IAMの設定ミスやOSの脆弱性を放置すると、不正アクセスや情報漏えいにつながる可能性があります。
| 利用者が管理する項目 | 内容 |
|---|---|
| IAM | ユーザー・ロール・ポリシー・MFAの設定 |
| OS | セキュリティパッチ・アップデート |
| ミドルウェア | Apache、Nginx、Tomcatなどの更新 |
| アプリケーション | プログラムの脆弱性対策・アップデート |
| データ | バックアップ・暗号化・アクセス制御 |
| ネットワーク設定 | Security Group・NACL・VPC設計 |
これらはAWSではなく、利用者自身が適切に設定・管理する必要があります。
💼 実務ではこう考える
企業でAWSを利用する場合、IAMの権限管理やOSのパッチ適用は運用担当者やクラウド管理者の重要な業務です。 AWSが自動で設定してくれるわけではないため、定期的な確認や運用ルールの整備が欠かせません。
サービスによって責任範囲は変わる
責任共有モデルはすべてのAWSサービスで同じではありません。
利用するサービスの種類によって、AWSと利用者の責任範囲は変化します。
一般的には、AWSが多く管理してくれるサービスほど、利用者が管理する範囲は少なくなります。
| サービス | AWSが管理する範囲 | 利用者が管理する範囲 |
|---|---|---|
| Amazon EC2 | 物理設備・仮想化基盤 | OS、ミドルウェア、アプリケーション、データ |
| Amazon RDS | 物理設備、OS、DBエンジン | データ、DB設定、IAM |
| AWS Lambda | インフラ、OS、ランタイム | アプリケーションコード、IAM、データ |
| Amazon S3 | ストレージ基盤 | データ、暗号化、アクセス権限 |
つまり、マネージドサービスを利用するほど、利用者の運用負荷は軽減されます。
EC2とRDSの責任範囲を比較してみよう
SAA試験で最もよく出題されるのが、Amazon EC2とAmazon RDSの責任範囲の違いです。
どちらもサーバーを利用するサービスですが、管理対象が大きく異なります。
| 項目 | Amazon EC2 | Amazon RDS |
|---|---|---|
| 物理サーバー | AWS | AWS |
| 仮想化基盤 | AWS | AWS |
| OS管理 | 利用者 | AWS |
| DBソフトウェア | 利用者 | AWS |
| アプリケーション | 利用者 | 利用者 |
| IAM | 利用者 | 利用者 |
| データ | 利用者 | 利用者 |
EC2ではOSやデータベースソフトウェアの管理も利用者が行います。
一方、RDSではOSやデータベースソフトウェアのパッチ適用や保守はAWSが担当するため、利用者はデータベースの運用やデータ管理に集中できます。
試験でよく問われるポイント
- EC2のOSパッチ適用 → 利用者の責任
- RDSのOSパッチ適用 → AWSの責任
- IAM設定 → どちらも利用者の責任
Amazon S3では誰が責任を持つのか？
Amazon S3はAWSを代表するマネージドサービスですが、「AWSがすべて管理してくれる」というわけではありません。
AWSが管理しているのはストレージ基盤や耐久性、高可用性などです。
一方で、保存するデータやアクセス権限の設定は利用者が責任を持って管理しなければなりません。
| AWS | 利用者 |
|---|---|
| ストレージ設備 | バケットポリシー |
| 物理ディスク | IAMポリシー |
| 複数AZへの冗長化 | 暗号化設定 |
| 耐久性の維持 | 公開設定 |
実際に発生しているS3の情報漏えい事故の多くは、AWSの障害ではなく、利用者による公開設定ミスが原因です。
💼 実務ではこう考える
企業では、S3バケットの公開設定を禁止するルールをAWS ConfigやService Control Policy（SCP）で強制するケースも多くあります。
AWS Lambdaでは誰が責任を持つのか？
AWS Lambdaは、サーバーの構築や運用を意識することなくコードを実行できるサーバーレスサービスです。
EC2と比較すると、利用者が管理する範囲が大幅に少なくなり、インフラ運用の負荷を軽減できます。
しかし、「サーバーレス＝セキュリティ対策が不要」というわけではありません。 Lambdaでも責任共有モデルは適用されます。
| 管理項目 | 担当 |
|---|---|
| 物理サーバー | AWS |
| OS・ランタイム | AWS |
| Lambdaサービス | AWS |
| IAMロール | 利用者 |
| ソースコード | 利用者 |
| 環境変数 | 利用者 |
| 保存データ | 利用者 |
LambdaではOSやミドルウェアの管理は不要ですが、コードの品質やアクセス権限、保存データの保護は利用者の責任です。
サービスごとの責任範囲を比較してみよう
ここまで紹介した主要サービスの責任範囲をまとめると、次のようになります。
| サービス | AWSの責任範囲 | 利用者の責任範囲 |
|---|---|---|
| Amazon EC2 | 物理設備・仮想化基盤 | OS・ミドルウェア・アプリ・データ |
| Amazon RDS | 物理設備・OS・DBエンジン | データ・DB設定・IAM |
| Amazon S3 | ストレージ基盤・耐久性・可用性 | データ・アクセス権限・暗号化 |
| AWS Lambda | インフラ・OS・ランタイム | コード・IAM・データ |
このように、マネージドサービスやサーバーレスサービスを利用するほど、AWSが管理する範囲は広くなります。
💼 実務ではこう使う
責任共有モデルは試験対策だけではなく、実際のシステム運用でも非常に重要な考え方です。
例えば、EC2で稼働しているLinuxサーバーに重大な脆弱性が見つかった場合、AWSが自動でOSを更新してくれることはありません。 利用者自身がパッチ適用や再起動の計画を立て、対応する必要があります。
一方、Amazon RDSではOSやデータベースエンジンの保守はAWSが実施します。そのため、運用担当者はバックアップやデータベース設計、パラメータ設定などに集中できます。
また、S3では公開設定の誤りによる情報漏えいが多く発生しています。企業ではAWS ConfigやIAMポリシー、SCP（Service Control Policy）を利用し、公開設定を制限するケースも少なくありません。
🔥 SAA試験頻出ポイント
- 責任共有モデルは「Security of the Cloud」と「Security in the Cloud」の違いを理解することが重要
- EC2のOSやミドルウェアの管理は利用者の責任
- RDSのOSやDBエンジンの保守はAWSの責任
- S3の公開設定やIAMポリシーは利用者の責任
- LambdaではOS管理は不要だが、コードやIAMロールは利用者が管理する
- マネージドサービスほど利用者の運用負荷は軽減される
⚠ 初心者が間違えやすいポイント
| 誤解 | 正しい理解 |
|---|---|
| AWSならすべてAWSが管理してくれる | クラウド基盤のみAWSが管理する |
| EC2のOS更新はAWSが実施する | EC2のOS更新は利用者が実施する |
| S3は安全なので公開設定は不要 | 公開設定・IAM・暗号化は利用者が管理する |
| Lambdaは完全に管理不要 | コード・IAM・データ管理は利用者の責任 |
AWS公式試験ガイドとの関連
本記事は、AWS認定ソリューションアーキテクト アソシエイト（SAA-C03）の「ドメイン1：セキュアなアーキテクチャの設計」に対応しています。
特に以下の知識は頻繁に出題されます。
- 責任共有モデルの考え方
- IAMによるアクセス制御
- データ保護と暗号化
- AWSが管理する範囲と利用者が管理する範囲
試験では、「誰が責任を持つのか」を問う問題が数多く出題されるため、サービスごとの責任範囲を理解しておくことが重要です。
まとめ
責任共有モデルは、AWSを利用するうえで最も重要な考え方の一つです。
AWSは物理インフラやクラウド基盤のセキュリティを管理し、利用者はIAMやデータ、OS、アプリケーションなどクラウド上のリソースを適切に管理する責任があります。
また、EC2・RDS・S3・Lambdaなど、利用するサービスによって責任範囲は異なります。 その違いを理解することで、安全なシステム設計や適切な運用につながります。
SAA試験では非常に重要なテーマですので、「AWSの責任」と「利用者の責任」を明確に区別できるようにしておきましょう。
