責任共有モデル、結局「誰が何を守る」問題〜クラウドは勝手に安全じゃない〜

2026年1月9日

「クラウドに上げたんだから、セキュリティもAmazonやGoogleがやってくれるんでしょ？」
もし現場でこんな声が聞こえたら、黄色信号です。

クラウド事故の多くは、事業者の不具合ではなく、私たちの「設定ミス」で起きます。
なぜこんな勘違いが起きるのか。
それは、契約書の一番大事なページ、「責任共有モデル（Shared Responsibility Model）」を読み飛ばしているからです。

今回は、この小難しい図を「誰が・何を・守るのか」という現場の言葉に翻訳します。

目次 [ close ]

「家の鍵」をかけるのは誰か

クラウドの責任分担は、賃貸マンションに似ています。

大家さん（クラウド事業者）の責任
建物の耐震性、オートロックの故障、エレベーターの点検。
これらは入居者が頑張っても直せません。だから大家さんが保証します。

入居者（私たち）の責任
自分の部屋の鍵をかけること、合鍵を怪しい人に渡さないこと、窓を開けっ放しにしないこと。

クラウド事業者が保証するのは「クラウド自体のセキュリティ（Security of the Cloud）」だけです。
私たちが責任を持つのは「クラウドの中のセキュリティ（Security in the Cloud）」です。

どれだけ頑丈なマンション（AWS）でも、部屋の鍵（パスワード）を「0000」にしていたら、泥棒に入られるのは当たり前ですよね。

マンションの例で言うなら、サービス形態によって「家具付き」かどうかが変わります。

サービス形態	事業者の守備範囲	利用者が守るべきもの	現場のタスク例
IaaS（例：AWS EC2など）	土地、建物、電気、ネットワーク配線など	OS以上全部（OS、アプリ、データ、ID）	OSのパッチ当て、アンチウイルス、ポート制限、IAM設計
PaaS（例：Google App Engineなど）	OSまで面倒見てくれる	アプリとデータ（アプリ、データ、ID）	アプリの脆弱性診断、秘密情報管理、DB暗号化、権限制御
SaaS（例：Salesforceなど）	アプリまで面倒見てくれる	データとID（権限設定、入力データ）	誰に権限を与えるか、MFA設定、退職者アカウント棚卸し

注意点：どのパターンでも「データ」と「ID（誰が入れるか）」は絶対に私たちの責任です。
ここだけは、GoogleもAmazonも守ってくれません。

理屈はわかりました。じゃあ明日何をすればいいのか。
まずは一番事故りやすい「鍵」の点検から始めましょう。

「SaaSの招待設定」を見てみる：SalesforceやSlack、Boxなどで、管理者権限が退職者を含めて放置されていないか確認する。
「公開設定」を疑う：S3バケットやストレージが「全世界に公開（Public）」になっていないか確認する。「便利だから」で開けた一時的な穴が、情報漏洩の入り口になる。

クラウドは、正しく設定すればオンプレミスより安全です。
でも、鍵をかけ忘れたら、世界中から泥棒が入れる「一番危険な場所」になります。

来週は、この鍵のかけ忘れを機械に監視させる「CSPM」という飛び道具について話します。