コンテンツにスキップ
CloudPick

共同責任モデル

文書基準: 2026年8月

なぜ共同責任なのか

Section titled “なぜ共同責任なのか”

自社の電算センターを賃貸ビルで運用していると仮定してみましょう。建物の入退室管理、消防設備、電力供給はビル管理会社が責任を負います。しかし、サーバー室内部の機器管理、データバックアップ、アクセス権限設定は入居企業である私たちが責任を負わなければなりません。ビル管理会社がどれほどセキュリティをしっかり行っていても、サーバー室のパスワードを「1234」に設定すれば、セキュリティ事故は私たちの責任です。

クラウドも同じ構造です。クラウドを利用したからといって、すべてのセキュリティと運用の責任がベンダーに移るわけではありません。ベンダーとユーザーがそれぞれ責任を負うべき領域が明確に分かれており、これを共同責任モデル(Shared Responsibility Model)と呼びます。

核心概念

Section titled “核心概念”

ベンダーの責任領域 —「クラウドのセキュリティ(Security of the Cloud)」

Section titled “ベンダーの責任領域 —「クラウドのセキュリティ(Security of the Cloud)」”

クラウドベンダーは、クラウドインフラ自体のセキュリティに責任を負います。

  • 物理的セキュリティ — データセンター建物、入退室管理、CCTV、生体認証
  • ハードウェア — サーバー、ストレージ、ネットワーク機器の管理および交換
  • ハイパーバイザー — 仮想化レイヤーのセキュリティおよび分離
  • ネットワークインフラ — グローバルバックボーンネットワーク、リージョン間接続

ユーザーの責任領域 —「クラウド内のセキュリティ(Security in the Cloud)」

Section titled “ユーザーの責任領域 —「クラウド内のセキュリティ(Security in the Cloud)」”

ユーザーは、クラウド上で運用するワークロードのセキュリティに責任を負います。

  • データ — 保存データの暗号化、分類、アクセス制御
  • アプリケーション — コードのセキュリティ脆弱性、パッチ管理
  • アクセス制御 — IAMポリシー、ユーザー権限、MFA設定
  • オペレーティングシステム — OSパッチ、セキュリティ設定(IaaSの場合)
  • ネットワーク設定 — セキュリティグループ、ファイアウォールルール、VPC構成

サービスモデルによる責任境界の変化

Section titled “サービスモデルによる責任境界の変化”

利用するサービスモデル(IaaS、PaaS、SaaS)によって、ユーザーの責任範囲が変わります。SaaSに近づくほどベンダーがより多くの領域を管理し、IaaSに近づくほどユーザーの管理領域が広がります。

領域 IaaS PaaS SaaS
データ ユーザー ユーザー ユーザー
アプリケーション ユーザー ユーザー ベンダー
ランタイム ユーザー ベンダー ベンダー
ミドルウェア ユーザー ベンダー ベンダー
オペレーティングシステム ユーザー ベンダー ベンダー
仮想化 ベンダー ベンダー ベンダー
サーバー/ストレージ/ネットワーク ベンダー ベンダー ベンダー
物理的セキュリティ ベンダー ベンダー ベンダー

例えば、EC2(IaaS)を利用する場合はOSパッチからユーザーの責任ですが、RDS(PaaS)を利用する場合はOSパッチをAWSが担当します。Google Workspace(SaaS)を利用する場合はアプリケーション管理までGoogleが担当し、ユーザーはデータとアクセス権限のみを管理すればよいことになります。

ベンダー別比較

Section titled “ベンダー別比較”
項目 AWS Azure Google Cloud OCI
モデル名 Shared Responsibility Model Shared Responsibility Shared Fate Shared Security Model
基本構造 伝統的な共同責任 AWSと類似 共同運命モデル 伝統的+自動化重視
ベンダーの追加サポート Well-Architected Tool, Trusted Advisor Defender for Cloud, Secure Score Security Command Center, Assured Workloads Cloud Guard, Security Zones
セキュリティのデフォルト値 ユーザーが明示的に設定 ユーザーが明示的に設定 セキュリティのデフォルト値がより厳格 Security Zonesで自動的に強制
公式ドキュメント AWS Azure Google Cloud OCI

AWSは最も伝統的な共同責任モデルを提示しています。「クラウドのセキュリティ」と「クラウド内のセキュリティ」を明確に区分しており、ユーザーは自身の責任領域を自ら管理する必要があります。

AWSはこれを支援するためにさまざまなセキュリティサービス(GuardDuty、Security Hub、IAM Access Analyzerなど)を提供していますが、有効化と設定はユーザーの役割です。詳細はセキュリティ体制管理を参照してください。

モデル名: Shared Responsibility Model

実務でよく見落とされる部分

Section titled “実務でよく見落とされる部分”

共同責任モデルを理解していても、実務でよく発生するセキュリティの過ちがあります。

  • ストレージの公開アクセス — バケットを誤ってパブリックに設定し、データが流出。データ保護を参照
  • IAMの過剰権限 — 管理者権限を付与したまま縮小しない。IAMとアクセス制御を参照
  • 暗号化キー管理 — ベンダー管理キー vs 顧客管理キー(CMK) vs BYOKの選択。シークレット管理を参照

コンプライアンス

Section titled “コンプライアンス”

各国/業界別の規制によって、セキュリティ認証が必要になる場合があります。各ベンダーは、認証レポートを直接ダウンロードできるサービスを提供しています。

ベンダー 認証レポートサービス 説明
AWS AWS Artifact SOC、ISO、PCIなどの監査レポートを直接ダウンロード
Azure Service Trust Portal 監査レポート、コンプライアンスガイド
Google Cloud Compliance Reports Manager ISO、SOCレポートのダウンロード
OCI Oracle Cloud Compliance 認証状況およびレポート

よくある間違い

Section titled “よくある間違い”
  • 「クラウドを使えばセキュリティはベンダーの責任だ」 — ベンダーはインフラのセキュリティのみに責任を負います。データ暗号化、アクセス制御、ネットワーク設定は常にユーザーの責任です。
  • 「マネージドサービスならセキュリティ設定は不要だ」 — PaaS/SaaSであっても、アクセス権限、ネットワーク露出、暗号化設定はユーザー自身が構成する必要があります。
  • 「認証さえ取得すればセキュリティは保証される」 — ベンダーのSOC/ISO認証は、インフラレベルのセキュリティを証明するだけであり、ユーザーのワークロードのセキュリティまで保証するものではありません。

チェックリスト

Section titled “チェックリスト”
  • 利用中のサービスモデル(IaaS/PaaS/SaaS)別に、ユーザーの責任領域を識別したか?
  • ストレージ(バケット/Blob)の公開アクセス設定を点検し、不要なパブリックアクセスを遮断したか?
  • ベンダーが提供するセキュリティ点検ツール(Trusted Advisor、Defender、Security Command Centerなど)を有効化したか?

参考資料

Section titled “参考資料”

標準とフレームワーク

Section titled “標準とフレームワーク”

AWS

Section titled “AWS”

Azure

Section titled “Azure”

Google Cloud

Section titled “Google Cloud”

OCI

Section titled “OCI”