クラウド共有責任モデルとは

クラウド共有責任モデル (Shared Responsibility Model) とは、クラウド環境のセキュリティをクラウドプロバイダーと利用者で分担する考え方です。プロバイダーは「クラウドのセキュリティ」(物理インフラ、ハイパーバイザー、ネットワーク基盤) に責任を持ち、利用者は「クラウド内のセキュリティ」(データ、アクセス制御、アプリケーション設定) に責任を持ちます。

この境界を正しく理解していないと、「クラウドに移行したからセキュリティはプロバイダーが担保してくれる」という誤解が生まれ、利用者側の設定不備によるインシデントが発生します。実際に、クラウド環境のセキュリティインシデントの大半は、利用者側の設定ミス (IAM の過剰権限、ストレージのパブリック公開、暗号化の未設定) が原因です。

サービスモデルごとの責任範囲

責任の境界はクラウドのサービスモデルによって異なります。

IaaS (EC2、Azure VM 等): プロバイダーは物理インフラとハイパーバイザーまでを管理。利用者は OS のパッチ適用、ミドルウェアの設定、アプリケーションのセキュリティ、データの暗号化、ネットワーク設定のすべてに責任を持つ。最も利用者の責任範囲が広い
PaaS (Lambda、App Service 等): プロバイダーが OS とランタイムまでを管理。利用者はアプリケーションコード、データ、IAM 設定に責任を持つ。サーバーレス環境では OS パッチの責任がなくなるが、関数の権限設定やイベントソースの検証は利用者の責任
SaaS (Microsoft 365、Salesforce 等): プロバイダーがアプリケーションまでを管理。利用者はデータの管理、ユーザーアクセスの制御、設定の最適化に責任を持つ。責任範囲は最も狭いが、設定ミスによるデータ漏洩リスクは依然として存在する

利用者が見落としやすい責任領域

共有責任モデルにおいて、利用者が特に見落としやすい領域があります。

クラウドストレージのアクセス設定: S3 バケットや Azure Blob Storage のパブリックアクセス設定は利用者の責任。デフォルト設定を確認せず、意図せずデータを公開してしまうケースが多発している
ログの有効化と保管: CloudTrail、VPC Flow Logs、アクセスログなどの有効化は利用者が行う。プロバイダーはログ基盤を提供するが、有効化と保管期間の設定は利用者の判断
バックアップとリカバリ: プロバイダーはインフラの冗長性を確保するが、利用者のデータのバックアップは利用者の責任。マネージドデータベースでも、ポイントインタイムリカバリの設定やクロスリージョンバックアップは利用者が構成する
コンテナイメージのセキュリティ: ECS や EKS のコントロールプレーンはプロバイダーが管理するが、コンテナイメージ内の脆弱性やアプリケーションの設定は利用者の責任

共有責任モデルを組織に定着させるには

共有責任モデルを正しく運用するには、技術的な対策だけでなく組織的な取り組みが必要です。

責任分界点の文書化: 利用しているサービスごとに、プロバイダーと利用者の責任範囲を明文化する。特に PaaS と SaaS では境界が曖昧になりやすいため、具体的な設定項目レベルで整理する
セキュリティベースラインの策定: CIS Benchmarks や AWS Well-Architected Framework のセキュリティの柱を参考に、組織のセキュリティベースラインを定義する
自動監査の導入: AWS Config、Azure Policy、Google Cloud Security Command Center などのサービスで、セキュリティ設定の逸脱を自動検知する
定期的な見直し: クラウドサービスは頻繁にアップデートされるため、新機能の追加やデフォルト設定の変更に応じて責任範囲を見直す

よくある誤解

クラウドに移行すればセキュリティはプロバイダーが全て担保してくれる: プロバイダーが責任を持つのは物理インフラやプラットフォームの基盤部分のみです。データの保護、アクセス制御、アプリケーションの設定、暗号化の有効化などは利用者の責任であり、オンプレミスと同等以上のセキュリティ意識が求められます。
マネージドサービスを使えば利用者のセキュリティ責任はほぼなくなる: マネージドサービスは OS やミドルウェアの管理負担を軽減しますが、IAM 設定、ネットワークアクセス制御、データの暗号化、ログの有効化などは依然として利用者の責任です。責任の範囲が狭くなるだけで、なくなるわけではありません。

クラウド共有責任モデル