はじめに

「 共有責任モデル（Shared Responsibility Model）」という言葉を聞いたことがあっても、それが何を意味し、クラウドコンピューティングにどんな影響を与えるのか、正しく理解している人は意外と少ないかもしれません。

本記事では、オンプレミスとの比較を交えながら、クラウドにおける責任分担の違いをわかりやすく解説します。

オンプレミスでは「すべて自社の責任」

まずは、従来のオンプレミス環境から見ていきましょう。

オンプレミス（自社データセンター） の場合、企業は以下の全てを自ら管理・保守する必要があります。

物理スペースの維持（建物やラックなど）

電源、空調、物理的セキュリティ

ネットワーク機器や物理サーバー

オペレーティングシステムやアプリケーションのパッチ適用

ユーザーアカウントやアクセス制御

データそのもの

つまり、「すべては自社の責任」です。

クラウドに移行すると、これらの責任がクラウドプロバイダーと利用者（コンシューマー）との間で分担されます。これが「共有責任モデル」です。

たとえば、クラウドSQLを利用する場合、データベースそのものの管理はプロバイダーの責任ですが、そこに保存するデータやアクセス制御は利用者側の責任です。

一方、自分でVM（仮想マシン）を立ち上げて、その中にSQLをインストールする場合は、OSやSQLのアップデートも含めて利用者側の責任になります。

クラウドサービスは、大きく次の3つに分類されます。それぞれで「どこまでプロバイダーが責任を持つか」が異なります。

物理インフラまではプロバイダー、それ以降は利用者の責任

OSの更新やアプリケーションの保守も自分で行う必要あり

ベンダー	製品例	内容	責任分担（例）
Azure	Azure Virtual Machines	仮想マシンを自由に構成	OSのパッチ適用、アプリの管理は利用者
AWS	Amazon EC2	自由に構成可能な仮想マシン	セキュリティグループやIAMの設定は利用者責任
GCP	Compute Engine	スケーラブルなVMを提供	OSやアプリの管理、アップデートは利用者

OSやランタイムはプロバイダーが管理

アプリケーションとデータだけ利用者が管理すればOK

ベンダー	製品例	内容	責任分担（例）
Azure	Azure App Service / Azure SQL Database	WebアプリやDBのPaaS	サービスの稼働維持やパッチはAzureが実施
AWS	AWS Elastic Beanstalk / RDS	アプリやDBを簡単にデプロイ	アプリケーションコードとデータは利用者管理
GCP	App Engine / Cloud SQL	自動スケーリング付きのPaaS	ミドルウェアの管理はGoogle側、データは利用者責任

ほとんどの責任がプロバイダー

利用者は「ID管理」と「データ保護」に集中すれば良い

ベンダー	製品例	内容	責任分担（例）
Azure	Microsoft 365 / Dynamics 365	オフィス系SaaS／CRM等	データのアクセス権・内容は利用者が管理
AWS	Amazon WorkMail / Amazon Chime	メール・コラボレーションSaaS	データやユーザー管理の責任は利用者
GCP	Google Workspace（旧G Suite）	Gmail, Docs, Drive など	コンテンツや共有権限はユーザー責任

責任モデルのまとめ

クラウドは便利な反面、責任の所在が曖昧だと「誰も管理していなかった」状態になりかねません。特に多くのセキュリティインシデントは「設定ミス」「アクセス権限の甘さ」によるものです。

「クラウドにしたから安全」ではなく、「クラウドだからこそ責任を明確にする」 という意識を持ちましょう。