はじめに
クラウドコンピューティングは「良いもの」、クラウドセキュリティは「悪いもの」という文句がハイテク業界でよく聞かれます。では、具体的にどこが問題なのでしょうか。本書『Cloud Security and Privacy』（Tim Mather・Subra Kumaraswamy・Shahed Latif 著）は、その問いに体系的に答えようとする一冊です。
本書はやや古い書籍ではあるものの、クラウドセキュリティの構造的な課題——責任分界点の不明確さ、マルチテナント環境のリスク、IAM標準の未成熟さ——は今日でも本質的に変わっていません。クラウド移行を検討するエンジニアや、セキュリティ要件を整理したいアーキテクトにとって、概念的な土台を築く上で有益な内容です。
第1〜2章：クラウドコンピューティングとは何か
本書は冒頭で、ロンドン地下鉄の「隙間にご注意ください（Mind the gap）」というアナロジーを使います。クラウドコンピューティングとそのセキュリティの間には「隙間」がある——これが本書全体のテーマです。
クラウドコンピューティングの定義として本書が採用するのは、以下の5属性です。
- マルチテナンシー（共有リソース）
- 大規模なスケーラビリティ
- 弾力性（オンデマンドでリソースを増減できる）
- 従量課金制
- リソースのセルフプロビジョニング
サービス提供モデルは「SPIフレームワーク」として整理されています。
| モデル | 概要 |
|---|---|
| SaaS | ソフトウェアをサービスとして提供。顧客はインフラ・OSを管理しない |
| PaaS | 開発プラットフォームを提供。顧客はアプリ開発・デプロイに集中できる |
| IaaS | インフラ（CPU・ストレージ・ネットワーク）を仮想化して提供 |
また、デプロイモデルとしてパブリッククラウド・プライベートクラウド・ハイブリッドクラウドが解説されます。パブリッククラウドはセキュリティ管理がCSP（クラウドサービスプロバイダー）に委ねられる一方、プライベートクラウドは顧客が物理・論理両面のセキュリティを高度に制御できます。
クラウド導入の技術基盤としては、仮想化技術（ハイパーバイザー）・ブロードバンド接続・APIが挙げられています。APIが標準化されていない現状では、CSP間のポータビリティが困難であり、顧客のベンダーロックインを招きやすいと指摘されています。
第3章：インフラストラクチャセキュリティ
インフラセキュリティはネットワーク・ホスト・アプリケーションの3層で論じられます。
ネットワークレベル
パブリッククラウドでは、以下の4つのリスク要因が特に重要です。
- 転送中データの機密性・整合性確保（HTTPSではなくHTTPを使うと改ざんリスクがある）
- 適切なアクセス制御（IPアドレスの再利用問題など）
- インターネット接続リソースの可用性確保（BGPプレフィックスハイジャック、DNSキャッシュポイズニング、DDoS攻撃など）
- ネットワークゾーン・階層モデルのドメインへの置き換え
従来の「イントラネット/エクストラネット」「開発/本番」といったゾーン分離モデルはパブリッククラウドでは実質的に消滅します。代わりにセキュリティグループやドメインによる論理分離となりますが、従来モデルより精度・保護強度は低くなります。
緩和策としては、転送中データの暗号化（TLS/IPSec）、プライベートクラウドへの移行、CSPが提供するネットワークアクセス制御の活用が挙げられます。
ホストレベル
クラウド特有の脅威としては、VMエスケープ・ハイパーバイザーへの脆弱なアクセス制御・内部脅威などが挙げられます。また、クラウドの弾力性（VMの迅速なプロビジョニングと破棄）は、脆弱性・パッチ管理を従来のデータセンターより格段に難しくします。
IaaSにおけるホストセキュリティの責任は顧客側にあります。推奨される対策は以下の通りです。
- デフォルトセキュアなカスタムVMイメージを使用する
- SSHパスワード認証を禁止し、秘密鍵で管理する
- ホストファイアウォールで必要最小限のポートのみ開放する
- ホストベースのIDS（OSSECなど）を導入する
- システム監査・イベントログを別ログサーバーに集約する
- 侵害の疑い時はインスタンスをシャットダウンし、スナップショットでフォレンジックを行う
アプリケーションレベル
Webアプリの脆弱性（OWASP Top 10：XSS・SQLインジェクションなど）はクラウド固有ではありませんが、パブリッククラウドに公開されるアプリはインターネットの脅威モデルに基づいて設計する必要があります。セキュリティをSDLC（ソフトウェア開発ライフサイクル）に組み込むことが不可欠です。
また、クラウドの従量課金モデルに対するDoS攻撃は、サービス停止だけでなくコストを急増させるEDoS（Economic Denial of Sustainability）攻撃という形もとり得ます。
第4章：データのセキュリティと保管
データセキュリティには、転送中・保存中・処理中のデータ、データ系統（データリネージ）、データの来歴（プロベナンス）、データ残留という6つの側面があります。
暗号化の限界
- 転送中データはTLS/HTTPSで保護可能
- 保存データはIaaS上の単純ストレージ（S3など）なら暗号化できるが、PaaS・SaaSのマルチテナントDBでは暗号化するとインデックス・検索が困難になるため通常は非暗号化
- 処理中データは復号しなければ処理できない（完全準同型暗号は当時の研究段階）
つまり、クラウド上のデータは少なくとも処理中は平文になる可能性が高いです。
鍵管理
暗号化を行う場合、鍵管理が最重要課題になります。本書は以下の問題を指摘しています。
- 多くのCSPが顧客データを単一の鍵で暗号化している
- 最悪のケースでは全顧客のデータを1つの鍵で管理しているプロバイダーも存在する
- データを処理しているCSPに鍵管理を委託するのは推奨されない
- NIST SP 800-57の鍵管理推奨事項を参照すべき
データの可用性とデータ残留
クラウドストレージは「バックアップ」を意味しません。プロバイダーによっては冗長化しているだけでバックアップは別料金というケースもあります。また、データを削除しても記憶媒体に残留データが残るデータ残留リスクもあります。現状の緩和策の結論は明確です——機密データや規制対象データはパブリッククラウドに置かない、あるいは暗号化した上で単純ストレージとしてのみ使用するということです。
第5章：アイデンティティとアクセス管理（IAM）
クラウドサービスの導入によって、組織の「信頼境界」は静的なものから動的なものへと変化します。ネットワーク制御の喪失を補うために、IAM（Identity and Access Management）の重要性が増します。
認証・認可・監査（AAA）
IAMの基本構成要素は以下の通りです。
| 機能 | 内容 |
|---|---|
| 認証（AuthN） | ユーザーの身元を確認する（LDAP・AD連携など） |
| 認可（AuthZ） | 認証後にアクセス権限を決定する |
| 監査 | アクセス記録をレビューし、ポリシー準拠を確認する |
IAM標準と企業向けプロトコル
本書は以下の4つの主要IAM標準を解説しています。
SAML（Security Assertion Markup Language）
フェデレーションとSSOのデファクトスタンダードです。大手SaaSプロバイダー（Google Apps・Salesforce.com等）がサポートしており、組織のIdPを使って委任認証を実現できます。フィッシング攻撃への耐性も向上します。
SPML（Service Provisioning Markup Language）
クラウドサービスへのユーザーアカウント自動プロビジョニングのための標準です。ジャストインタイムプロビジョニングを実現できます。
XACML（eXtensible Access Control Markup Language）
ポリシー管理とアクセス決定のための汎用XMLベース言語です。複数アプリにまたがる統一認可ポリシーを実現できますが、本書執筆時点ではXACMLをサポートするクラウドサービスはほぼ存在しませんでした。
OAuth
認証情報を開示せずに別CSPが保護リソースにアクセスできるようにする標準です。API経由でのサービス間連携に使われます。
IDフェデレーションの2つのアーキテクチャ
- エンタープライズIdP：自組織内にIdPを構築し、クラウドサービスへの認証を委任する。既存IAMインフラを活用できるが、フェデレーション対応のアーキテクチャ変更が必要。
- IDaaS（Identity-as-a-Service）：Symplified・Ping Identity等のサードパーティが提供するクラウドベースのID管理サービスを利用する。統合の複雑さを軽減できるが、可用性・SLAに依存する。
本書の結論として、CSPのIAM標準サポート（SAML・SPML・XACML）は当時いまだ不十分であり、顧客はCSP評価時にIAM機能を重要な評価基準に含めるべきだと述べられています。
第6章：クラウドにおけるセキュリティ管理
クラウド環境においても、従来のISO 27002等のセキュリティ管理フレームワークは適用可能ですが、SPIデリバリーモデルに応じて責任分界点が変わります。SaaSではCSPが多くの管理責任を持ち、IaaSでは顧客がほぼ全責任を負います。
CSPへのセキュリティ要求
組織はCSPが適切なセキュリティ管理（予防的管理・検出的管理・是正管理）を実施していることを確認するため、以下の手段を活用すべきとされています。
- NDA（秘密保持契約）に基づく情報開示要求：設計・アーキテクチャ・テスト結果の共有を求める
- SysTrust / ISO 27002準拠の評価フレームワーク：第三者評価を通じた保証の取得
- SLAへのセキュリティ条項の明示：可用性・インシデント対応・脆弱性開示ポリシーを契約に盛り込む
特に、SaaSおよびPaaSの顧客はホストレベルのセキュリティをCSPに依存せざるを得ないため、CSPがどのようなセキュリティ衛生管理を行っているかについて適切な水準の保証を得ることが顧客の責任と強調されています。
セキュリティ管理の責任分界（SPIモデル別）
| レイヤー | SaaS | PaaS | IaaS |
|---|---|---|---|
| アプリケーション | CSP | 顧客 | 顧客 |
| ランタイム・ミドルウェア | CSP | CSP | 顧客 |
| OS・仮想サーバー | CSP | CSP | 顧客 |
| ハイパーバイザー | CSP | CSP | CSP |
| 物理インフラ | CSP | CSP | CSP |
第7章：プライバシー
クラウドコンピューティングとプライバシーの問題は複雑です。データが複数の地理的拠点に分散して処理・保存されるため、適用される法的管轄が複数にまたがる可能性があります。
特に注意が必要なのは以下の点です。
- データの所在地：どの国・地域のデータセンターにデータが存在するかを把握することが困難
- 規制の適用範囲：HIPAA・SOX・GDPRなど規制が地域によって異なる
- SLAでのプライバシー保護規定：CSPとの契約にプライバシー保護条項を明示すべき
- プライバシーポリシーの確認：CSPが収集するメタデータ（利用ログ等）の取り扱い方針を理解する
また、クラウドサービスを利用することで、CSPが組織の利用状況に関するメタデータを蓄積することになります。このメタデータ自体の保護も顧客が意識すべき課題です。例えば、どのユーザーがいつどのデータにアクセスしたかというアクセスログは、CSPがセキュリティ目的で収集・保持する一方、顧客がそれを監査目的で取得できるかどうかはCSPのポリシーによって異なります。
第8章：監査とコンプライアンス
クラウドにおける監査の難しさは、CSPのインフラへの可視性が制限されることにあります。顧客がアクセスできる監査ログや監査証跡が不十分なケースが多く、PCI DSSやSOXなどの規制コンプライアンスを維持するための従来の監査手法がそのまま適用できないことがあります。
SAS 70レポートの活用
本書ではSAS 70レポート（現在のSOC 2に相当）の活用が推奨されています。SAS 70はCSPのコントロールを第三者機関が評価するものであり、顧客がCSPのセキュリティ体制を検証する上で重要な手段です。
SAS 70レポートには2種類あります。
- Type I：特定時点での統制の設計適切性を評価
- Type II：一定期間（通常6ヶ月以上）にわたる統制の運用有効性を評価
Type IIのほうが実際の運用の信頼性を示すため、より価値が高いとされています。
コンプライアンス管理の課題
クラウドを使用しても、コンプライアンス管理の責任は顧客に残ります。CSPが規制準拠を「肩代わり」することはなく、「コンプライアンスのためのインフラを提供する」にすぎません。CSP選定時には以下を評価基準に含めるべきです。
- CSPが保有するコンプライアンス認定（ISO 27001・SOC 2・PCI DSS等）
- 顧客が監査ログにアクセスできるか
- インシデント発生時の通知・対応プロセス
- 脆弱性開示ポリシー（CVE参加状況等）
第9〜10章：CSPの具体例とSecurity as a Service
第9章ではAWS・Google App Engine・Salesforce.comといった当時の主要CSPのセキュリティ体制を比較しています。共通して言えるのは、セキュリティに関する透明性が不十分であるという点です。
第10章では**Security as a Service（SECaaS）**を扱っています。WAF・DDoS対策・脆弱性スキャン・ログ管理などをクラウド経由でサービスとして提供するモデルであり、インフラセキュリティを補完する手段として注目されています。
第11章：クラウドがIT組織の役割に与える影響
クラウドの普及により、IT組織の役割は「インフラを構築・管理するプロバイダー」から「サービスを調達・統合・ガバナンスするブローカー」へと変化します。
この変化は以下の新たなスキルセットを求めます。
- クラウドサービスの評価・契約・SLA管理
- セキュリティリスク評価とコンプライアンス管理
- ベンダーマネジメントとサプライチェーンセキュリティ
第12章：結論とクラウドの将来
本書は、クラウドセキュリティの問題をまとめて次のように結論付けています。
クラウドコンピューティングに伴うセキュリティリスクは、クラウド特有の原因ではなく、クラウドによって既存のリスクが悪化したものである
すなわち、ネットワーク・ホスト・アプリケーションレベルのセキュリティ課題はクラウドで生まれたものではなく、クラウドの特性（マルチテナント・弾力性・透明性の欠如）によって従来より困難になったものです。
将来の展望として、以下の点が期待されていました（執筆時点）。
- 完全準同型暗号の実用化による処理中暗号化の実現
- IAM標準（SAML・XACML等）の普及と成熟
- クラウド監査フレームワーク（SAS 70 / SOC 2）の標準化
- セキュリティAPIの標準化による相互運用性向上
クラウド移行前のセキュリティチェックリスト
本書の内容を踏まえ、クラウド移行・CSP選定時に確認すべき主要ポイントをまとめます。
ネットワーク・インフラ
- 転送中データのTLS暗号化が徹底されているか
- ネットワークゾーニング（セキュリティグループ等）の設計が行われているか
- DDoS対策（WAF・CDN等）が考慮されているか
データセキュリティ
- 保存データの暗号化方針と鍵管理プロセスが定義されているか
- 機密データ・規制対象データをパブリッククラウドに置く必要があるかどうかを評価したか
- データのバックアップポリシーとRTO/RPOが定義されているか
IAMとアクセス管理
- SAML等によるID連携（SSO）の実装計画があるか
- 最小権限原則に基づくIAM設計がされているか
- 特権アカウントの管理（MFA強制・アクセスログ監査）が整備されているか
監査・コンプライアンス
- CSPのSAS 70 / SOC 2 Type IIレポートを取得・確認したか
- 監査ログへのアクセス権限と保持期間をSLAに明記したか
- 対象規制（PCI DSS / HIPAA / SOX等）に対するCSPの対応状況を確認したか
インシデント対応
- インシデント発生時のCSPからの通知プロセスを確認したか
- フォレンジック調査に必要なログ取得が可能かを確認したか
本書はやや古いものの、クラウドセキュリティの構造的課題をネットワーク・ホスト・アプリ・データ・IAM・プライバシー・監査という多層的な視点で体系的に整理しており、現在でも十分に参照価値があります。
読んで特に印象的だったのは以下の3点です。
① 責任共有モデルの明確化
「クラウドだから安全」という誤解を丁寧に解きほぐしながら、SPIデリバリーモデルに応じて誰がどの層のセキュリティ責任を負うのかを整理しています。現在のAWSの責任共有モデル（Shared Responsibility Model）の考え方と完全に一致しており、概念の源流を辿る意味でも有益でした。
② IAMの複雑さと標準化の重要性
SAML・OAuth・XACML等の標準が未成熟だった時期の記述であるにもかかわらず、「アプリケーションから認証を外部化すべき」「認可ポリシーを標準化すべき」という方向性は現在のゼロトラストアーキテクチャとも整合しています。
③ データ残留と暗号化の現実的な限界
処理中のデータは復号が必要であり、完全な暗号化はトレードオフを伴うという指摘は、現在のクラウド設計でも変わらない制約です。機密データをパブリッククラウドに置く際のリスク評価をどう行うか、改めて考えさせられました。
まとめ
本書が示すクラウドセキュリティへのアプローチは、一言で言えば「既存のセキュリティ原則をクラウドの特性に合わせて再適用する」ことです。クラウドはまったく新しいセキュリティ問題を生み出したわけではなく、既存のリスクを増幅・複雑化させたものです。
クラウド移行を検討しているチームや、セキュリティ設計を担当するエンジニアにとって、責任分界点の整理・IAMアーキテクチャの設計・データ保護の方針策定において、本書の体系的な視点は今でも参考になりました。