責任共有モデルとは？AWS・Azure・GCPでの境界線と企業が守るべきセキュリティ領域をわかりやすく解説

クラウドを使えばセキュリティはプロバイダーにまかせておけば大丈夫――そう思っていませんか？実際、クラウド環境での情報漏洩事故の多くは、利用者側の設定ミスや管理不備が原因です。プロバイダーがどれだけ堅牢な基盤を提供していても、その上に乗せたアプリケーションやデータの保護は利用者の仕事です。

この記事では、クラウドセキュリティの出発点となる「責任共有モデル」の概念と、IaaS・PaaS・SaaS別に企業が担うべき具体的な責任範囲を現場目線で解説します。情シス1人の環境でも今日から実践できる対策もあわせて紹介します。

責任共有モデルとは？

責任共有モデル（Shared Responsibility Model）とは、クラウドサービスのセキュリティ責任を「クラウドプロバイダー」と「利用者（企業）」の間で明確に分担する考え方です。

よく使われる表現は「クラウドのセキュリティはプロバイダーが担い、クラウド上のセキュリティは利用者が担う」というものです。

・プロバイダーの責任: データセンター・物理ハードウェア・ネットワーク・ハイパーバイザーなど、クラウド基盤そのものの安全性
・利用者の責任: クラウド上で動かすOSの設定・アプリケーション・データ・IAM権限・ファイアウォール設定

この区分を正確に理解していないと「プロバイダーが守ってくれているから問題ない」という誤った安心感が生まれ、自社の設定ミスや過剰な権限付与が見逃されてしまいます。

AWSが自社ドキュメントで示しているように、責任の境界線はサービスの種類（IaaS・PaaS・SaaS）によって大きく変わります。

サービスモデルで変わる責任範囲

クラウドのサービスモデルごとに、利用者が管理しなければならないレイヤーは異なります。シンプルなルールは「利用者がコントロールできる範囲が広いほど、責任範囲も広い」です。

1. IaaS（仮想マシン・EC2等）の場合

AWS EC2・Azure Virtual Machines・Google Compute Engineなどが代表例です。プロバイダーが提供するのは「仮想マシンを動かすための基盤」のみで、OSより上のレイヤーはすべて利用者の責任です。

IaaSを使うということは、OSのパッチ管理・セキュリティグループの設定・不要サービスの停止まで、すべて自分たちでやらなければならないということです。

2. PaaS（マネージドDB・アプリ基盤等）の場合

AWS RDS・Azure App Service・Google Cloud SQLなどが代表例です。OSやランタイムの管理はプロバイダーが担いますが、アプリケーションのコード品質・データの暗号化設定・アクセス制御は利用者の責任です。

「DBのOSパッチはAWSがやってくれるから安心」という理解は正しいですが、「DBに接続できるユーザーと権限の設定」は利用者が正しく行わなければ意味がありません。

3. SaaS（Microsoft 365・Google Workspace等）の場合

利用者が管理するレイヤーは最も少ないですが、以下は利用者の責任として残ります。

・ユーザーアカウント管理: 退職者アカウントの削除・休眠アカウントの棚卸し
・多要素認証（MFA）の有効化: プロバイダーが機能を提供していても、有効化は利用者の判断
・共有設定の管理: OneDriveやGoogleドライブの「誰でもアクセス可能」リンクの制御
・アクセス権限の見直し: 必要以上の権限を持つユーザーの定期棚卸し

SaaSを使っていても、設定ミスによる情報漏洩は現実に起きています。

AWS・Azure・GCPの責任共有モデル比較

3大クラウドはそれぞれ公式ドキュメントで責任共有モデルを公開しています。基本的な考え方は共通ですが、表現と詳細に違いがあります。

注目すべきはGCPが採用している「Shared Fate（運命共同）」という表現です。単なる責任の分担ではなく、プロバイダーも利用者と一緒により良いセキュリティを実現しようという姿勢を示しています。ただしどのプロバイダーを使っていても「データの暗号化設定」「IAM権限の絞り込み」「監査ログの有効化」は利用者側の義務である点は変わりません。

中小企業でも今日からできること

責任共有モデルを理解した上で、情シス1人の環境でもすぐ実施できる対策を4つ挙げます。

1. IAM権限を最小権限に絞る

クラウドのIAM（Identity and Access Management）でAdministrator権限を全員に付与している環境をよく見かけます。必要なサービスへのアクセスだけを許可する最小権限の原則を徹底してください。特に、開発・検証用のアカウントが本番環境にフルアクセスできる状態は危険です。

2. 管理者アカウントにMFAを必須設定する

rootアカウントや管理者権限を持つアカウントへの多要素認証（MFA）は外せません。パスワードだけでの認証は、クレデンシャルスタッフィング攻撃（パスワードリスト攻撃）で容易に突破されます。SaaSも含め、管理者権限アカウントにはMFAを必須化しましょう。

3. ストレージのパブリック公開設定を確認する

AWS S3バケット・Azure Blob Storage・Google Cloud Storageの「パブリック公開」設定は定期的に確認してください。意図せずインターネットに公開されたバケットが大規模なデータ漏洩の原因になった事例は多数報告されています。クラウドプロバイダーは警告機能を提供しているので、有効化しておきましょう。

4. 監査ログを有効化する

AWS CloudTrail・Azure Monitor・GCP Cloud Auditのログを有効化し、誰がいつ何にアクセスしたかを記録しておきましょう。インシデント発生時の原因調査に不可欠です。ログを取っていなければ、侵害が起きても何がどこまで影響を受けたかを把握できません。

よくある誤解と注意点

責任共有モデルを巡って現場でよく見られる誤解をまとめます。

・「クラウドはセキュアだからそのまま使えば安全」: プロバイダーが守るのは基盤だけです。その上で動くアプリケーション・データ・設定は利用者の責任です。
・「SaaSを使えばデータ漏洩は起きない」: 共有設定のミスやアクセス権の放置でデータが外部に露出するケースは実際に起きています。
・「コンプライアンス認証（ISO 27001・SOC 2等）を持つプロバイダーだから問題ない」: その認証はプロバイダーの基盤に対するものです。その上に構築するシステムの安全性は利用者が責任を持たなければなりません。
・「オンプレより安全になる」: 安全性はクラウド自体ではなく「どう設定・運用するか」で決まります。誤設定はオンプレより影響範囲が広くなる場合があります。
・「プロバイダーが異常を検知して教えてくれる」: 一部の通知機能はありますが、すべての設定ミスを自動で検出・通知してくれるわけではありません。定期的な自社点検が必要です。

本記事のまとめ

責任共有モデルの本質は「プロバイダーに任せられる部分を正確に把握し、自社が担う部分を確実に守る」という分業の明確化です。クラウドを使うなら、この考え方をチームで共有することがセキュリティ対策の出発点になります。

Linuxサーバーのセキュリティ設定については、姉妹サイトLinuxMaster.JPで詳しく解説しています。クラウド上のLinuxインスタンスを運用している場合はあわせてご参照ください。