【AWS解説 基本編 #4】責任共有モデル入門　AWS側と利用者側の管理範囲

基本編 #4（全 6 回予定）

【AWS解説 基本編 #1】AWSとは？クラウドとオンプレミスの違いを整理では、クラウドを使っても運用がゼロになるわけではない、と触れました。

今回はその考え方をもう少し掘り下げて、AWSと利用者のどちらが何を管理するのかを整理します。

前回までの記事はこちらです。

• 【AWS解説 基本編 #1】AWSとは？クラウドとオンプレミスの違いを整理
• 【AWS解説 基本編 #2】AWSは「サービス」を組み合わせて使う
• 【AWS解説 基本編 #3】リージョンとAZ、マルチAZの違い

AWSを使い始めると、

物理設備はAWSが管理するなら、セキュリティもすべてAWSに任せてよいのでは？

と感じることがあります。

しかし、AWSを利用したからといって、セキュリティや運用に関する責任がすべてAWSへ移るわけではありません。

AWS側は何を守るのか
利用者は何を管理しなければならないのか

この境界を整理するのが、責任共有モデル（Shared Responsibility Model）です。

---

責任共有モデルとは

責任共有モデルとは、AWSと利用者が、セキュリティやコンプライアンスについて、それぞれどこまで責任を持つかを整理した考え方です。

日々のAWS運用において、誰が何を管理するのかを判断する基準にもなります。

一言で覚えるなら、次の対比が分かりやすいです。

• AWSは「クラウドのセキュリティ」を担う
• 利用者は「クラウド内のセキュリティ」を担う

オンプレミスでは、建物、電源、サーバー、OS、アプリケーション、データなど、広い範囲を自分たちで管理する必要があります。

クラウドでは、その一部をAWSが管理してくれます。

ただし、すべてがAWS任せになるわけではありません。

---

AWS側の責任

AWS側は、クラウドを支える土台の安全性と運用に責任を持ちます。

たとえば、次のような領域です。

• データセンターの建物や設備の管理
• データセンターへの入退室管理
• 電源や冷却設備の管理
• 物理サーバーの管理
• 物理ネットワークの管理
• 仮想化基盤の管理
• ホストOSの管理

これらは、AWS利用者が直接操作しないクラウドの裏側にあたります。

イメージとしては、サーバーを設置する建物や機材を用意し、セキュリティや耐障害性を考慮しながら運用する部分です。

前回説明したリージョンやAZも、AWSが提供・運用するクラウド基盤の一部です。

ただし、どのリージョンを使用するか、複数AZを利用した構成にするかといった設計は、利用者側が判断します。

利用者がAWSマネジメントコンソールから、データセンターの鍵やラックの電源ケーブルを操作することはありません。

そこはAWS側の責任範囲です。

---

利用者側の責任

一方で、AWS上に保存するデータや、作成したリソースの設定、アカウントや権限の管理などは、基本的に利用者側の責任です。

主な利用者側の責任には、次のようなものがあります。

• データの保存方法や公開範囲の管理
• IAMやアカウントの設定
• パスワードやMFAによるアカウント保護
• アプリケーションの実装と管理
• セキュリティグループなどの通信制御
• データを暗号化するかどうかの判断と設定
• EC2のゲストOSやミドルウェアの管理
• OSのパッチ適用
• アプリケーションの脆弱性対応

たとえば、VPC、セキュリティグループ、ネットワークACLなど、AWS上で利用者が設定するネットワーク構成も利用者側が管理します。

AWSが物理ネットワークを管理していても、利用者がセキュリティグループで全ポートを外部へ公開してしまえば、それは利用者側の設定によるものです。

学習目的でAWSを使う場合でも、次の点は早めに意識しておくと安心です。

• ルートユーザーを日常的な作業に使用しない
• MFAを有効にする
• 必要以上に強いIAM権限を付与しない
• アクセスキーをソースコードなどに書かない
• 意図しない公開設定になっていないか確認する
• 作成したリソースを放置しない

クラウドの土台はAWSが管理していても、設定ミスや権限の付けすぎは利用者側の問題になります。

コスト管理も利用者側で行う

不要なリソースの削除や料金の確認も、AWSを利用するうえでは利用者側が行う必要があります。

これはセキュリティ上の責任とは少し異なりますが、クラウド運用で忘れてはいけない管理項目です。

学習のために一時的に作成したリソースでも、削除せずに残していると料金が発生し続けることがあります。

---

サービスによって境界が変わる

責任共有モデルは、いつも同じ位置で明確に分かれるわけではありません。

利用するAWSサービスによって、利用者側が管理する範囲は変わります。

EC2の場合

EC2では、AWSが物理サーバーや仮想化基盤、ホストOSを管理します。

一方で、EC2インスタンス上の次のような項目は利用者が管理します。

• ゲストOS
• OSのパッチ
• ミドルウェア
• アプリケーション
• セキュリティグループ
• EC2内に保存するデータ

EC2は仮想サーバーを比較的自由に利用できる反面、利用者が管理する範囲も広くなります。

マネージドサービスの場合

S3、DynamoDB、Lambdaなど、インフラ管理が抽象化されたマネージドサービスでは、OSや物理基盤の管理をAWSが担います。

そのため、利用者は次のような項目に集中できます。

• データ
• IAM権限
• サービスの設定
• アプリケーションコード
• 外部への公開範囲
• 暗号化の設定

ただし、マネージドサービスを使っても、利用者側の責任がなくなるわけではありません。

責任を持つ対象が、OSや基盤から、データ、権限、サービス設定などへ移ると考えると分かりやすいです。

たとえばS3では、物理ディスクの管理を利用者が行う必要はありません。

一方で、

• 誰がバケットへアクセスできるのか
• オブジェクトを外部へ公開するのか
• 暗号化を有効にするのか
• バケットポリシーをどう設定するのか

といった項目は、利用者側が管理します。

物理ディスクはAWSが管理していても、利用者が設定した公開範囲によってデータが外部へ公開された場合、その設定は利用者側の責任になります。

最初から、すべてのサービスの責任範囲を暗記する必要はありません。

AWSサービスを使うときに、

このサービスでは、自分は何を設定し、何を守る必要があるのか

を確認する習慣を持つことが大切です。

---

つまずきやすいポイント

「クラウドならセキュリティ対策済み」と思う

AWSはクラウドの土台をセキュアに設計・運用しています。

しかし、利用者が行う設定や権限管理、データの扱いまで、自動的にすべて安全になるわけではありません。

公開設定のミスや、アクセスキーの不適切な管理によって、クラウドでもセキュリティ事故は発生します。

「マネージドサービスなら何もしなくてよい」と思う

S3やLambdaなどでは、利用者がサーバーやOSを直接管理する必要はありません。

しかし、データの公開範囲、IAM権限、暗号化、サービス設定、アプリケーションコードなどは、引き続き利用者が管理します。

AWSが管理する範囲が増えても、利用者側の責任がゼロになるわけではありません。

「全部AWSのせい」「全部自分のせい」と考える

責任共有モデルでは、AWSと利用者の双方に責任があります。

障害やセキュリティインシデントが発生したときに、

• AWSが管理するクラウド基盤の問題なのか
• 利用者が設定したネットワークや権限の問題なのか
• アプリケーションやデータの問題なのか

を切り分けられると、原因調査や対応を進めやすくなります。

学習用アカウントでも責任はなくならない

無料枠や学習目的でAWSを使う場合でも、アカウントの保護やリソースの管理は利用者側の責任です。

特に、次のような点には注意が必要です。

• アクセスキーの漏洩
• 意図しない外部公開
• 強すぎるIAM権限
• 不要なリソースの削除忘れ
• 想定していない料金の発生

---

まとめ

責任共有モデルは、AWSと利用者のどちらが何を守り、管理するのかを整理した考え方です。

AWSは、次のようなクラウドの土台を管理します。

• データセンター
• 物理サーバー
• 物理ネットワーク
• 仮想化基盤
• ホストOS

一方で、利用者は次のようなクラウド内の項目を管理します。

• データ
• アカウント
• IAM権限
• アプリケーション
• ネットワーク設定
• 各AWSサービスの設定
• EC2のゲストOSやミドルウェア

利用するサービスによって責任の境界は変わりますが、最初は、

クラウドの土台はAWS、設定とデータは利用者

と覚えると分かりやすいです。

そのうえで、AWSサービスを使うたびに、利用者側に残る管理項目を公式ドキュメントで確認していくとよいでしょう。

次回は、AWSを安全かつ適切に設計・運用するための観点をまとめた、Well-Architectedフレームワークを入門レベルで紹介します。