責任共有モデルと保護領域（IaaS/PaaS/SaaS）

クラウドセキュリティの出発点は「誰が何を守るか」の明確化にある。クラウド提供者と利用者が保護領域を分担する Shared Responsibility Model（責任共有モデル） は、IaaS・PaaS・SaaS の各サービスモデルによって境界線が変わる。設定責任は常に利用者側にあるという原則を理解しなければ、構成ミスによるデータ漏洩は防げない。情報カットオフ ~2025-08、confidence: medium 固定。

クラウドセキュリティの前提：責任共有モデル

クラウド提供者（AWS / Azure / GCP など）と利用者は、セキュリティ責任を分担する契約的・技術的枠組みを持つ。提供者は「クラウド自体のセキュリティ（Security OF the Cloud）」を担い、利用者は「クラウド上のセキュリティ（Security IN the Cloud）」を担う。

この分担を誤解すると、「提供者が守ってくれる」という過信が生まれ、設定ミスやアクセス制御の不備がそのまま放置される。クラウド環境での侵害報告の多くは、提供者側のインフラ障害ではなく、利用者側の構成ミスに起因している。

IaaS（Infrastructure as a Service）の責任分界

IaaS は最も自由度が高い反面、利用者の責任範囲も最大になる。

領域	提供者の責任	利用者の責任
物理インフラ	データセンター・電源・冷却	—
ネットワーク	バックボーン・物理 NW	セキュリティグループ・ACL
ハイパーバイザ	VM ホスト分離	—
OS	—	パッチ適用・ハードニング
ミドルウェア	—	設定・脆弱性管理
アプリ・データ	—	開発・暗号化・バックアップ

ポイント：OS 以上のスタック全体が利用者管理になる。EC2（AWS）/ Azure VM / GCE（GCP）などが代表例。攻撃者から見ると、公開ポートの設定ミスや OS の未パッチが直接の侵入口になる。

PaaS（Platform as a Service）の責任分界

PaaS では提供者が OS とランタイムを管理するため、利用者の責任範囲が絞られる。

領域	提供者の責任	利用者の責任
物理〜ハイパーバイザ	全て	—
OS・ランタイム	パッチ・アップデート	—
アプリケーションコード	—	開発・脆弱性修正
データ	—	暗号化・分類・バックアップ
アクセス制御（アプリ層）	—	認証・認可の実装

ポイント：AWS Elastic Beanstalk / Azure App Service / Google App Engine などが代表例。OS の管理から解放されるが、アプリコードと IAM 設計は利用者責任のまま残る。

SaaS（Software as a Service）の責任分界

SaaS では提供者がアプリケーション層まで管理する。利用者の責任は大幅に縮小するが、ゼロではない。

領域	提供者の責任	利用者の責任
インフラ〜アプリ	全て	—
データ	バックアップ・可用性	分類・輸出・ライフサイクル
アクセス制御	認証基盤の提供	ユーザー管理・MFA 設定
テナント設定	デフォルト提供	組織ポリシーの実装

ポイント：Salesforce / Microsoft 365 / Google Workspace などが代表例。SaaS であっても、テナントの共有設定・外部共有許可・ゲストアクセスの管理は利用者が行う。これを専門的に管理する領域を SSPM（SaaS Security Posture Management）と呼ぶ。

共通の利用者責任

モデルを問わず、利用者が常に担う領域がある。

IAM（Identity and Access Management）：過剰権限の付与は全モデルで最大リスクの一つ。最小権限の原則（Principle of Least Privilege）を徹底し、未使用の権限・アカウントを定期的に棚卸しする。

データ暗号化：転送中（TLS）・保存時（AES-256 等）の暗号化は利用者の選択。提供者がデフォルトで有効にしない設定もある。KMS 鍵の管理責任も利用者側にある。

ネットワーク設定：セキュリティグループ・ファイアウォールルール・ VPC 設計は利用者が定義する。0.0.0.0/0 での全公開は典型的な構成ミスだ。

ログとモニタリング：CloudTrail（AWS）/ Diagnostic Settings（Azure）/ Cloud Audit Logs（GCP）の有効化・保持期間設定は利用者責任。無効化されていると侵害後の調査が困難になる。

構成管理：クラウドリソースの構成ミスが侵害の最多原因になっている。CSPM ツール（tech-150 参照）による継続的な検知が有効だ。

マルチクラウドとハイブリッド環境

AWS・Azure・GCP を並行利用する組織では、責任共有モデルの境界がプラットフォームごとに微妙に異なる。統一した Security Policy・コンプライアンス基準を維持するには、CSPM のマルチクラウド対応や、CIEM による権限の一元可視化が求められる。

オンプレミスとクラウドが混在するハイブリッド環境では、ID フェデレーション（Azure AD / Okta 等）と一元的なポリシー管理が鍵になる。ゼロトラスト原則（tech-117 参照）への移行により、「ネットワーク境界の内側は信頼できる」という前提を排除することが、マルチクラウド時代の保護の基本方針となる。

アンチパターン一覧

#	アンチパターン	リスク	対策
1	提供者任せで設定をデフォルトのまま放置	公開バケット・全公開 SG	設定ポリシーの策定と CSPM による継続検知
2	S3 / Blob Storage を誤って Public に設定	データ漏洩	バケットポリシーレビュー・Block Public Access 有効化
3	SaaS テナント設定を「提供者が安全にしてくれる」と思い込む	外部共有・ゲスト乱立	SSPM 導入・定期棚卸し
4	マルチクラウドで統制が分断し対応が属人化	インシデント対応遅延	統一 CSPM・SIEM 連携
5	KMS 鍵の管理を提供者に完全委任	鍵ローテーション漏れ	BYOK（Bring Your Own Key）または定期ローテーション設定
6	CloudTrail / 監査ログを無効化または短期保持	フォレンジック不能	ログ有効化・S3 + 長期アーカイブ（最低 1 年）

Cloud Security Shared Responsibility Model（責任共有モデルと保護領域）