はじめに
クラウドのセキュリティ設計をしていると、当たり前のように「責任共有モデル」という言葉を使います。IaaS ならここまでがベンダー、ここからが自分たち。SaaS なら大半はベンダー側。この線引きは誰がいつ言い出したのでしょうか。
その答えのかなり近くにあるのが、今回取り上げる O'Reilly の『Cloud Security and Privacy』です。原著は2009年刊。EC2 が登場して数年、Salesforce.com が「クラウド」という言葉をマーケティングに使い始めた直後という、極めて初期のタイミングで書かれた一冊です。
正直に言うと、製品情報としての価値はほぼ残っていません。登場するサービスは古く、数字は当時のアナリスト予測、参照される規格も現在は改訂済みです。それでも読む価値があると感じたのは、この本が 「クラウドで何が構造的に難しくなるのか」を、製品名に依存しない形で言語化している からです。
本記事では、章ごとの要点を整理したうえで、「17年経って当たった予測・外れた予測」という観点で振り返ってみます。
書誌情報
| 項目 | 内容 |
|---|---|
| 原題 | Cloud Security and Privacy |
| 邦題 | クラウドセキュリティとプライバシー |
| 著者 | Tim Mather / Subra Kumaraswamy / Shahed Latif |
| 出版社 | O'Reilly Media |
| 原著刊行 | 2009年 |
| 分量 | 本編12章 + 用語集 + 付録3本 |
著者の顔ぶれがそのまま本書の性格を表しています。
- Tim Mather — Symantec の CISO を約7年務め、その後 RSA でセキュリティ戦略を担当した実務家
- Subra Kumaraswamy — Sun Microsystems で IAM プログラムを率いた技術者。Cloud Security Alliance の創設メンバー
- Shahed Latif — KPMG のパートナー。IT 監査側の視点を担当
CISO・エンジニア・監査人という3つの立場が揃っていることが、本書の記述バランスを決めています。技術一辺倒でも、コンプライアンス一辺倒でもありません。
本書の構造
章立ては、下から上に積み上がる構成になっています。
第1章 はじめに ── 進化史としてのクラウド
第2章 クラウドとは何か ── 定義とSPIモデル
─────────────────────────── ここから各論
第3章 インフラセキュリティ ── ネットワーク / ホスト / アプリ
第4章 データセキュリティ ── 転送中 / 保存 / 処理中
第5章 IAM ── 信頼境界の再定義
第6章 セキュリティ管理 ── ITIL / ISO 27001・27002
第7章 プライバシー ── PII とデータライフサイクル
第8章 監査とコンプライアンス ── GRC と統制のライフサイクル
─────────────────────────── ここから外側の話
第9章 CSPの実例
第10章 Security as a Service
第11章 企業ITの役割の変化
第12章 結論とクラウドの将来
第3章〜第5章が技術者向け、第6章〜第8章がマネジメント・監査向け、第9章以降が業界動向という配分です。設計・アーキテクチャに関心がある読者であれば、第3章から第7章までが本命になります。
核心となる3つの主張
章ごとの詳細に入る前に、本書全体を貫く主張を3つに絞って挙げておきます。
1. 責任は移転できるが、説明責任は移転できない
本書で最も繰り返し出てくる原則です。契約によって運用責任（responsibility）をプロバイダーに渡すことはできる。しかし、法的にも社会的にも、最終的な説明責任（accountability）は そもそもそのデータを集めた組織 に残り続ける。
インシデントが起きたとき、利用者が非難するのはサービス提供元ではなく「そのサービスを選んだ会社」だ、という指摘は身も蓋もありませんが的確です。
2. 信頼境界は静的なものではなくなる
従来、信頼境界は自社データセンターの物理的・論理的な輪郭と一致していました。クラウドではこれが動的に伸縮し、IT 部門の管理外にはみ出します。
その結果、ネットワーク制御の喪失を、より上位のソフトウェア制御で補うしかないという構図になります。強力な認証、ロールやクレームに基づく認可、属性の信頼できるソース、ID フェデレーション、SSO、ユーザー活動の監視 —— 本書が IAM に1章まるごと割いている理由がここにあります。
3. 処理中のデータは、ほぼ確実に平文である
転送中は暗号化できる。単純なオブジェクトストレージとして置くだけなら保存時も暗号化できる。しかし クラウド上でデータを「処理」する以上、その瞬間は復号されている必要がある。
刊行時点で完全準同型暗号は理論的なブレークスルーが報じられた直後という段階で、実用性は遠い将来の話とされていました。したがって本書の結論は極めて保守的です —— 機微データ・規制対象データはパブリッククラウドに置かない。
章ごとの要点
第1章 — 進化としてのクラウド
冒頭がロンドン地下鉄の "Mind the gap" から始まります。クラウドコンピューティングとそのセキュリティは本来一致しているべきなのに、実際には隙間がある、という掴みです。
技術的に面白いのは、クラウドを ISP の連続的な進化 として位置づけている点です。
| 世代 | 提供内容 |
|---|---|
| ISP 1.0 | ダイヤルアップ等のインターネット接続 |
| ISP 2.0 | メール等の付加価値サービス |
| ISP 3.0 | コロケーション施設 |
| ISP 4.0 | ASP（専用インフラ上のアプリ提供） |
| ISP 5.0 | クラウド（SPIモデル） |
ここで重要なのが ASP と SaaS の違いです。ASP は顧客ごとに専用インスタンス・専用ホストを割り当てていました。SaaS は共有インフラ上でアプリケーションへのアクセスを提供します。マルチテナンシーこそが分岐点である、という整理は今読んでも綺麗です。
第2章 — 定義とSPIモデル
本書はクラウドを5つの属性で定義します。
- マルチテナンシー（共有リソース）
- 大規模なスケーラビリティ
- 弾力性（エラスティシティ）
- 従量課金
- リソースのセルフプロビジョニング
NIST の定義とほぼ重なりますが、本書は マルチテナンシーを筆頭に置いている点が特徴的です。セキュリティ本らしい優先順位と言えます。
もう一つ、当時から指摘されている課題が API の非標準性です。CSP ごとに独自 API を持つためアプリケーションの移植性がなく、相互運用も困難。しかも「顧客を囲い込む」市場インセンティブが働くため、CSP 側に標準化を進める動機がない —— この構造分析は、17年経った今もほとんどそのまま通用します。
第3章 — インフラセキュリティ
ネットワーク／ホスト／アプリケーションの3レベルに分けて論じる、情報セキュリティの標準的なフレームで整理されています。ここでの注意喚起が良いです。
インフラセキュリティ = IaaS のセキュリティ、と単純に同一視してはいけない
PaaS や SaaS でも、プロバイダー側のインフラは顧客の脅威・リスク・コンプライアンス管理に影響を与えるからです。
ネットワークレベルでは4つのリスク要因を挙げています。
- 転送中データの機密性・完全性
- 適切なアクセス制御（認証・認可・監査）
- インターネット公開リソースの可用性
- ネットワークゾーン／階層モデルがドメインに置き換わること
4番目が特に示唆的です。従来は「開発系と本番系はネットワークレベルで論理分離され、かつホストレベルでも物理分離されていた」のに対し、クラウドでは分離がアドレッシング目的の論理分離だけになり、同一物理サーバー上でハイパーバイザーによってのみ隔てられている状態になる、と。
具体例として挙がっている IP アドレスの再利用問題 も面白い論点です。解放された IP アドレスが十分に「エイジング」されずに他の顧客へ再割り当てされる。DNS キャッシュや ARP テーブルのクリアにはタイムラグがある。結果として、存在しないはずのリソースにアクセスできる時間帯が生まれる —— インフラを共有するとはこういうことだ、という具体性のある説明です。
第4章 — データセキュリティと保管
個人的に 本書で最も価値がある章だと感じました。データを状態別に切り分けて論じます。
| 状態 | 暗号化の可否 | 論点 |
|---|---|---|
| 転送中 | 可能 | 機密性と完全性を両方満たすプロトコル選択 |
| 保存時（単純ストレージ） | 可能・推奨 | IaaS のオブジェクトストレージ等 |
| 保存時（アプリ利用） | 困難 | 暗号化するとインデックス・検索ができない |
| 処理中 | 事実上不可 | 復号が必要 |
「暗号化すると検索できなくなるから、PaaS/SaaS のデータは通常暗号化されない」という指摘は、検索可能暗号や機密コンピューティングが実用段階に入りつつある現在から見ても、問題設定として正しかったと言えます。
さらに本章は、以下の3概念を明確に区別しています。
データリネージ（Data Lineage）
データがいつ・どこを通ってきたかの経路。どのバケットに置かれ、いつどのインスタンスで処理され、どこへ戻ったか。監査上必要になるが、自社管理環境ですら手間がかかり、パブリッククラウドでは事実上提供不可能だと本書は断じます。
データプロベナンス（Data Provenance）
完全性（改竄されていない）に加えて、計算の正確性まで含む概念。金融計算や科学計算で必要になります。本書は通貨換算の例を挙げてこの違いを説明していて、「2ドル」という結果が完全性を満たしていても、どの国のドルで、どの為替レートで、正しく換算されたかが証明できなければプロベナンスは満たさない、と。
データリマネンス（Data Remanence）
削除したはずのデータの残存表現。CSP の多くがこの点にほとんど言及していないこと、そして「DoD 5220.22-M 準拠」と軽々しく言うベンダーが実際にはその文書を読んでいないらしいこと（当該マニュアル141ページ中、データ残留に関する記述は3段落しかない）への批判が印象的です。より具体的な指針としては NIST SP 800-88 を参照すべき、と誘導しています。
第5章 — アイデンティティとアクセス管理
信頼境界が動的になる以上、IAM が防御の中心になる —— という主張を、認証・認可・監査（AAA）の定義から丁寧に積み上げる章です。
IAM は双方向であるという指摘が重要です。顧客側の実践が成熟していることだけでなく、CSP 側が SAML のような標準やフェデレーションをサポートしていることも必要になります。
逆に言えば、社内の IAM が壊れている組織はその壊れ方をクラウドに輸出するということでもあります。ディレクトリが乱立し、プロビジョニングが手作業で、権限が棚卸しされていない状態のままクラウドに出れば、過剰権限がそのまま外側に広がるだけです。この警告は現在の方が切実かもしれません。
IAM プロセスとして挙げられているのは以下です。
- プロビジョニング／デプロビジョニング
- 資格情報と属性の管理
- 認可管理
- アクセス管理の実施
- 監視と監査
第6章 — クラウドにおけるセキュリティ管理
管理フレームワークとして ITIL と ISO/IEC 27001・27002 を軸に据え、そこからクラウドで重点を置くべきプロセスを抽出しています。
- 可用性管理
- アクセス制御
- 脆弱性管理
- パッチ管理
- 構成管理
- インシデント対応
- システム利用とアクセスの監視
そのうえで、SPI モデル × デプロイメントモデル（パブリック／プライベート）のマトリクスで、どこまでが顧客の責任かを整理しています。これが責任共有モデルの表としてかなり早い時期の形だと思います。
たとえばパブリック SaaS では、顧客側に残るのはアクセス制御（部分的）、利用監視（部分的）、インシデント対応のみ。IaaS では OS とアプリケーションの脆弱性管理・パッチ管理・構成管理まで顧客側に戻ってくる。現在の各クラウドベンダーが公開している責任分界表と、骨格はほとんど同じです。
第7章 — プライバシー
章の冒頭に置かれた著者の言葉が的確です。
セキュリティがあってもプライバシーがないことはあり得るが、セキュリティがなければプライバシーはあり得ない
「プライバシーは情報セキュリティのサブセットである」という誤解を最初に潰しにいきます。
本章の実用的な部分は データライフサイクルの各フェーズごとにクラウドの影響を問うフレームです。
| フェーズ | 主な問い |
|---|---|
| 生成 | PII の所有者は誰か。分類はいつ行うか |
| 利用 | 収集目的と整合しているか。第三者と共有されるか |
| 移送 | 公衆網を通るか。暗号化義務はあるか |
| 変換 | 派生・集約後も元の保護と利用制限が維持されるか |
| 保管 | アクセス制御・完全性・可用性・機密性はどう保たれるか |
| アーカイブ | 保持期間は自社の方針と整合するか |
| 破棄 | 本当に消えるのか、アクセスできなくなっただけか |
最後の「破棄」が厄介です。クラウドストレージは可用性向上のために複数システム・複数サイトへ複製します。可用性のためのメリットが、そのまま破棄の困難さになる。CSP が本当に消したのか、それとも顧客からアクセスできなくしただけなのか、どう検証するのか —— GDPR の消去権をめぐる議論を先取りしているようにも読めます。
管轄権の問題も提起されています。データが海外のデータセンターに転送されうること、各国法が特定種類の PII の越境移転を制限していること、そして 組織が知らないうちに転送が行われて現地法に抵触しうること。データレジデンシー要件が当たり前になった現在から見ると、問題設定は完全に正しかったと言えます。
第8章 — 監査とコンプライアンス
KPMG のパートナーが担当した章らしく、CSP 側の統制構築プロセスを ライフサイクルとして描いています。
戦略の定義 → 要件の定義 → アーキテクチャの定義 → ポリシーの定義
→ プロセス・手順の定義 → 継続的運用 → 継続的モニタリング → 継続的改善
面白いのは、統制水準の設定が 経営判断として扱われている点です。基準を低く設定しすぎれば新規顧客の要件を満たせない。高く設定しすぎれば顧客にとって導入が困難になり、CSP 自身も費用対効果を保てない。セキュリティを純粋なコストではなく、ターゲット市場に応じた設計変数として位置づけています。
また、規制ごとに個別対応するのは持続不可能であり、共通のキーコントロール群に統合して一度のテストで複数の要件セットを満たすという GRC のアプローチを推しています。これは現在のコンプライアンス自動化ツールの発想そのものです。
付録には SAS 70 Type II と SysTrust のレポート構成例が収録されています。SAS 70 は既に SSAE/SOC に置き換わっているため、ここは資料的価値に留まります。
第9章〜第11章 — 業界動向
第9章の CSP 紹介は、率直に言って今読む価値が最も薄い章です。当時のサービス構成のスナップショットとして眺める程度で十分でしょう。
第10章の Security as a Service は逆に予測が当たった章です。メールフィルタリング、Web コンテンツフィルタリング、脆弱性管理、IDaaS —— 列挙されているカテゴリは、そのまま現在の SECaaS 市場です。マルウェア対策をエンドポイントからクラウドへ移す発想（当時の USENIX 論文を引きつつ、複数エンジンによる検出率向上を根拠にしている）も、現在の EDR/XDR の考え方に繋がっています。
第11章の「IT 部門は実装提供者ではなく、リスクアドバイザー・ガイダンス提供者になる」という予測も、プラットフォームエンジニアリングやガードレール整備という形で、かなりの程度実現したと言えるでしょう。
第12章 — 結論
当時のアナリスト予測と、IT 幹部への調査結果を並べて締めています。数字自体はもう意味を持ちませんが、アナリストは強気、現場の IT リーダーは慎重という乖離の構図と、その慎重さの最大の理由がセキュリティだったという事実は、記録として面白く読めます。
17年後から見た答え合わせ
当たったもの
- 責任共有モデルの骨格 — SPI × デプロイメントモデルの責任分界の形は、現在の各ベンダーの分界表とほぼ一致
- IAM が防御の中心になる — アイデンティティが新しい境界線である、という現在の共通認識そのもの
- API 非標準による囲い込み — マルチクラウドが依然として難しい理由の本質
- データレジデンシー／管轄権 — GDPR 以降、法制度の側が本書の懸念に追いついた
- Security as a Service の伸長 — 列挙されたカテゴリがそのまま市場化
- IT 部門の役割変化 — 実装者からガードレール提供者へ
外れた、あるいは前提が変わったもの
- 「機微データはパブリッククラウドに置かない」という結論 — 現在は金融・医療を含めて置くのが前提。ただしこれは本書の分析が誤っていたというより、KMS、HSM、BYOK、機密コンピューティング、監査認証の整備といった「不足していた統制」がその後に埋まったと見るべきでしょう
- データリネージは実現不可能 — クラウドネイティブな監査ログ・トレーシング基盤の充実により、当時想定されたよりは追跡可能になった
- 暗号化されたままの処理は遠い未来 — 完全準同型暗号は依然として用途限定ですが、TEE ベースの機密コンピューティングという別ルートで一定の実用化が進んだ
外れ方が示唆的です。本書が「無理だ」と判断した項目の多くは、技術ではなく統制と契約の不在が理由でした。そして実際に埋まったのは、その統制と契約の側でした。
設計・アーキテクチャの観点で持ち帰れるもの
書評としてまとめる際に、自分が実務で使えそうだと感じた考え方を3つ挙げておきます。
1. データを状態で分けて設計する
転送中／保存時／処理中で守り方が変わり、守れる限界も変わります。「暗号化しています」で思考停止せず、処理中は必ず平文になるという前提から逆算する。どのコンポーネントが平文に触れるのかをアーキテクチャ図に明示できているか、という問いは今でも有効です。
2. 完全性とプロベナンスを混同しない
「改竄されていないこと」と「正しく計算されたこと」は別の保証です。監査対象システムや金額計算を扱う設計では、この区別を意識するだけで必要なログ設計が変わります。
3. 責任分界を「表」で持つ
本書の第6章のマトリクスは、そのまま自分のシステムに置き換えて書けます。可用性管理・アクセス制御・脆弱性管理・パッチ管理・構成管理・インシデント対応・監視の7項目について、どこまでがベンダーで、どこからが自分たちかを書き出す。曖昧なセルが残れば、それがそのままリスクです。
こんな人におすすめ
向いている人
- クラウドセキュリティの「なぜそうなっているか」を知りたい方
- 責任共有モデルを、暗記ではなく導出として理解したい方
- セキュリティ設計を、技術・管理・監査の3視点で整理したい方
- 技術史・思想史として読むのが好きな方
向いていない人
- 特定クラウドの実装手順を知りたい方（公式ドキュメントの方が確実です）
- 最新の脅威動向を追いたい方（コンテナ・サーバーレス・CI/CD は当然扱われていません）
- 資格試験対策として読みたい方（規格の版が古いため、そのまま使うと誤りのもとです）
読み方の提案
通読する必要はないと思います。おすすめは 第2章 → 第4章 → 第5章 → 第7章 の順です。定義を押さえたうえで、データ・アイデンティティ・プライバシーという「今も本質が変わっていない3つ」を読む。第6章の責任分界マトリクスを確認したら、第9章以降は流し読みで十分でしょう。
まとめ
『Cloud Security and Privacy』は、古いことが弱点にならない珍しい技術書です。
製品情報としては完全に古びています。しかし、クラウドという実行モデルが本質的に何を難しくするのか —— 境界が動くこと、リソースを共有すること、処理には平文が必要なこと、そして責任は渡せても説明責任は渡せないこと —— を製品名に依存せず言語化しているため、その部分は今も読めます。
そして「当時できないとされたことが、なぜ今できているのか」を辿ると、それを可能にしたのが技術単体ではなく、統制・契約・監査という周辺の整備だったことが見えてきます。設計の議論をしていると技術的解決に寄りがちですが、この本はそこに一度ブレーキをかけてくれます。
クラウドセキュリティを「覚えるもの」から「導けるもの」に変えたい方には、一読の価値がある一冊だと思います。
参考
- Tim Mather, Subra Kumaraswamy, Shahed Latif 『Cloud Security and Privacy』O'Reilly Media, 2009
- NIST SP 800-88 "Guidelines for Media Sanitization"
- ISO/IEC 27001 / 27002
- Markdown記法 チートシート - Qiita