クラウドの責任共有モデルとガバナンス。IaaS/PaaS/SaaSで変わる責任範囲と設定ミスの所在

クラウドへの移行が進むほど、現場でくり返し聞かれるのが「結局、セキュリティはどこまでがクラウド事業者の責任で、どこからが自分たちの責任なのか」という問いです。サーバーを自社で抱えていた時代は、物理的な機器からOS、アプリケーション、データまで、良くも悪くもすべて自分たちの管理下にありました。クラウドに移ると、その責任の一部は事業者側に移ります。ところが「クラウドにしたから安心」という空気だけが先に広がり、移ったはずのない責任まで事業者が見てくれていると誤解したまま運用が始まることが少なくありません。

この誤解が表面化するのが、設定ミスによる情報漏えいです。ストレージの公開範囲を絞り忘れた、アクセス権限を広く付けすぎた、ログを残していなかった。こうした事故の多くは、クラウド基盤そのものの欠陥ではなく、利用者側が責任を負う「設定」の領域で起きています。つまり、事業者がどれだけ堅牢な基盤を用意しても、利用者が自分の責任範囲を理解していなければ穴は開きます。

この記事は、クラウドの「責任共有モデル（Shared Responsibility Model）」を原理から噛み砕き、IaaS・PaaS・SaaSという提供形態によって利用者の責任範囲がどう変わるのかを早見表で整理します。そのうえで、設定ミスの責任は誰にあるのか、経営層と現場がそれぞれ何をガバナンスとして握っておくべきかを、実務の判断基準まで掘り下げます。対象は、クラウド利用の意思決定をする経営層・情報システム責任者と、実際に設定を担うクラウド管理者の双方です。

早見表：提供形態ごとの責任範囲#

まず全体像を、Microsoftが公式に示している責任分担マトリクスをもとに整理します。下の表は、スタックの各層について、誰が責任を持つかを提供形態別に並べたものです。「共有」は、事業者が基盤部分を、利用者が設定・利用部分を、それぞれの文脈で分担することを意味します。

この表はMicrosoft Learn「Shared responsibility in the cloud」の責任分担マトリクスに基づいています。表現はクラウド事業者により細部が異なりますが、「データ・設定・ID・アクセス管理は提供形態によらず常に利用者が保持する」という骨格は各社共通です。具体的な分担は契約とサービス仕様で確認してください。

注目すべきは表の上3行です。データ、設定・構成、ID・利用者アカウントは、オンプレミスからSaaSまで一貫して「利用者」と書かれています。クラウド化でOSや物理層の管理は手放せても、自分のデータと、誰がそれにアクセスできるかという統制は、最後まで利用者の手元に残るということです。

責任共有モデルとは何か：of the cloud と in the cloud#

責任共有モデルを最も簡潔に言い表しているのが、AWSの「Security of the Cloud（クラウドそのものの安全）」と「Security in the Cloud（クラウドの中の安全）」という対比です。AWSは前者、すなわちすべてのサービスを動かす基盤（ハードウェア、ソフトウェア、ネットワーク、データセンター施設）を保護する責任を負います。利用者は後者、すなわち自分が選んだサービスの中で、データの暗号化や分類、IAM（Identity and Access Management）による権限設定、ゲストOSの更新やアプリケーションの安全確保を担います。

AWS公式の「Shared Responsibility Model」では、AWSが「Security of the Cloud」、利用者が「Security in the Cloud」を担うと明記されています。利用者の責任範囲は「選択したサービスによって決まる」とされ、EC2のようなIaaS的サービスと、S3やDynamoDBのような抽象化サービスとで、利用者が行う設定作業の量が変わると説明されています。

ここで大切なのは、責任共有モデルが「責任を半分こにする」仕組みではないという点です。床から天井までのスタックを層に切り分け、層ごとにどちらが責任を持つかを割り当てる、というのが正確な理解です。境界線は提供形態によって上下しますが、線が引かれる以上、線より上は必ず利用者が見なければなりません。「共有」という言葉から「お互いがなんとなく見てくれる」という曖昧な状態を連想すると、誰も見ていない層が生まれます。これが設定ミスの温床です。

誤解しやすいのは、「事業者が高いセキュリティ認証を取得しているから、自分たちは何もしなくてよい」という理解です。事業者の認証は、あくまで基盤（of the cloud）について対象範囲内の管理策・統制状況を確認する材料であって、利用者が自分の責任範囲（in the cloud）で行うべき設定の安全性を保証するものではありません。堅牢な金庫を借りても、扉を開けっぱなしにすれば中身は守れない、という関係に近いものです。

なぜIaaS/PaaS/SaaSで責任範囲が変わるのか#

提供形態の違いは、「スタックのどこまでを事業者が面倒を見るか」の違いです。原理から見ると一本の線で理解できます。

IaaSは、仮想マシンやストレージ、仮想ネットワークといった「素材」を提供する形態です。物理層と仮想化基盤は事業者が持ちますが、その上に乗るゲストOS、ミドルウェア、アプリケーション、ネットワークのセキュリティ設定（ファイアウォールやセグメント分割）は利用者が構成します。自由度が高い反面、利用者の責任範囲が最も広いのがIaaSです。OSのパッチ適用を忘れれば、その脆弱性は利用者の責任で放置されたことになります。

PaaSは、OSやランタイム、ミドルウェアまでを事業者が管理し、利用者はアプリケーションのコードと、その設定・データ・アクセス制御に集中する形態です。OSパッチのような運用負担は事業者に移りますが、アプリケーションの設定不備やアクセス権限の付与ミスは引き続き利用者の責任です。

SaaSは、できあがったアプリケーションをそのまま使う形態です。OSもネットワークも事業者が管理し、利用者の責任は主に「誰にどの権限を与え、どのデータを置き、どう共有するか」に絞られます。責任範囲は最も狭くなりますが、ゼロにはなりません。ファイル共有設定を「リンクを知っている全員」にしてしまえば、それは利用者側の設定ミスです。

この一本の線を頭に入れておくと、新しいサービスを評価するときに「このサービスはどこに線が引かれているか」「線より上で自分たちが設定すべきことは何か」を最初に問えるようになります。

設定ミスの責任は誰にあるのか#

ここが本記事の核心です。クラウドで起きる情報漏えいの多くは、クラウド基盤そのものが破られた結果ではなく、利用者が責任を持つ「設定」の領域で起きています。ストレージの公開設定、アクセス権限、ネットワークの開放範囲、ログの取得。いずれも前掲の表で「利用者」または「共有」の側にある項目です。

責任共有モデルに照らせば、これらの設定ミスによる被害は、原則として利用者の責任です。事業者は安全に設定できる「手段」（権限管理機能やデフォルトで非公開にする初期設定など）を提供しますが、その手段を正しく使う責任は利用者にあります。契約上も、多くの利用規約は「利用者の設定・運用に起因する損害」を事業者の免責としています。つまり、設定ミスで漏えいが起きても、事業者に賠償を求められるとは限らず、対外的な説明責任や被害者への対応は利用者が負うのが通常です。

総務省の「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」でも、利用者の責任範囲はSaaS・PaaS・IaaSの利用形態によって変化すること、そして事業者と利用者が責任範囲を合意し、その内容を明確にすることの重要性が示されています。責任は一律ではなく、サービスの内容や利用条件ごとに両者で合意して決まる、という考え方が公式に整理されています。

総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」（2021年9月公表）は、クラウドにおける責任分界のあり方を整理した国内の公的ガイドラインです。利用者の責任範囲が提供形態で変わること、責任範囲を契約で明確化することの重要性が示されています。

実務での判断基準を一つ挙げるなら、「この設定が間違っていたとき、被害者に説明し対応するのは誰か」を考えることです。答えが自社であれば、それは自社の責任範囲です。クラウド事業者がデータセンターの火災に対応してくれても、自社が公開設定を誤って顧客情報を漏らした事故の謝罪と再発防止を、事業者が代わりに行ってくれることはありません。

ガバナンスとして握るべきこと#

責任共有モデルを「知っている」だけでは事故は防げません。経営と現場の双方で、継続的に回る統制（ガバナンス）に落とし込む必要があります。原理を踏まえた要点を挙げます。

第一に、責任範囲の文書化です。利用するサービスごとに、どの層が事業者で、どの層が自社かを書き出し、自社側の項目に担当を割り当てます。「共有」の項目は特に空白になりやすいので、自社が何を設定するのかを具体化します。前掲の早見表は出発点であり、実際の境界は契約とサービス仕様で確認するのが原則です。

第二に、設定の継続的な点検です。クラウドの設定は一度決めて終わりではなく、サービスの仕様変更や担当者の異動で少しずつずれていきます。公開設定・アクセス権限・アカウントの棚卸しを定期的に行い、できれば設定逸脱を自動で検知する仕組み（クラウドの設定監査機能やCSPM的なツール）を併用します。

第三に、IDとアクセス権限の統制です。表が示すとおり、ID・アカウント・アクセス管理はどの形態でも利用者の責任です。最小権限の原則、退職者・異動者のアカウントの確実な無効化、特権アカウントへの多要素認証は、提供形態を問わず効きます。

第四に、責任の所在を経営課題として扱うことです。設定ミスによる漏えいの説明責任は経営が負います。だからこそ、現場任せにせず、どのサービスにどんな責任が残っているか、点検が回っているかを経営層が把握できる報告の仕組みを持つことが、ガバナンスの肝になります。

中小企業であれば、IPAの「中小企業の情報セキュリティ対策ガイドライン」と付属するクラウドサービスの安全利用に関する資料が、規模に応じた現実的な始め方の参考になります。

IPA「中小企業の情報セキュリティ対策ガイドライン」は、中小企業向けに情報セキュリティの基本方針づくりから具体策までを示した公的資料で、クラウドサービスの安全利用に関する付録も提供しています。自己診断ツールなど、小規模でも始めやすい手段がまとまっています。

よくある質問#

まとめ#

クラウドの責任共有モデルは、「基盤の安全は事業者、その上の設定・データ・利用者管理は利用者」という役割分担を、スタックの層ごとに割り当てる考え方です。IaaSからSaaSへ進むほど利用者の責任は狭まりますが、データ・設定・ID・アクセス権限はどの形態でも常に利用者の手元に残ります。情報漏えいの多くはこの利用者側の設定領域で起き、その説明責任は利用者が負います。だからこそ、責任範囲を文書化し、設定を継続的に点検し、経営が把握できる統制に落とし込むことが欠かせません。

責任共有モデルで自分の側に残る「ID・アクセス」をどう強くするかは、