2026年3月23日
諸角 昌宏
本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のない意見をいただければ幸いである。
クラウドが企業のインフラとして本格的に普及し始めた2000年代後半、セキュリティは最大の懸念事項として繰り返し取り上げられた。「データをどこに置くかわからない」「自分でコントロールできない」。そうした不安を背景に、CSAの設立（2009年）、ISO/IEC 27017の策定（2015年）、各CSPによるセキュリティフレームワークの整備など、クラウドセキュリティのベストプラクティスを積み上げるための取り組みが業界全体で重ねられてきた。
そうした積み重ねを経た今、「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という意見を耳にするようになった。ある意味では成熟の証とも言える。ただ、この意見には「概ね妥当だが、そのまま受け入れるには少し注意が必要」と筆者は考えている。クラウド環境ではリスクの発生メカニズムが変わり、責任の所在が分断され、従来の情報セキュリティだけでは見落としが生まれやすい構造がある。「一部である」ことは正しい。しかし「だから特別な考慮は不要」とはならないと考える。本ブログでは、その理由を整理し、具体的にどのようなリスクを念頭に置くべきかを示していきたいと考えている。
命題の構造
「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という主張には、以下の2つの前提が埋め込まれていると考えられる。
- 前提① クラウドセキュリティの原則は情報セキュリティと共通している
- 前提② 共通しているなら、情報セキュリティとして一括して扱えばよい
前提①は「概ね妥当」と言えそうである。CIAの三要素（機密性・完全性・可用性）はクラウドにも適用される。リスク評価・インシデントレスポンスの考え方も情報セキュリティの原則がそのまま使える。その意味では「一部である」という捉え方に一定の合理性がある。
ただし、前提②は必ずしも自明ではないように思われる。「同じ原則が適用できる」ことと「同じ対策で十分である」こととは、少し異なる話ではないだろうか。では、なぜ同じ対策では十分でないのか。その理由を考えるには、クラウド環境におけるリスクの性格を少し丁寧に見ておく必要がある。
クラウド環境でリスクはどう変わるか
ここで、「同じ対策では不十分」という感覚の背景には、クラウド環境がリスクの発生メカニズムを変えているという事実がある。ここで少し立ち止まって、「クラウド固有のリスク」という言葉自体を問い直してみたい。設定ミス・過剰権限・データの不適切な公開・認証の不備など、これらはいずれもクラウド以前から存在していたリスクであり、クラウドが新たに生み出したものではない。より実態に近い言い方は「クラウドで特に考慮が必要なリスク」であると言える。リスクの種類が固有なのではなく、リスクの顕在化しやすさ・影響規模・発生メカニズムが、クラウド環境において特殊な形をとる、ということだと考える。以下に、同じリスクがクラウドで増幅されやすい4つの構造的な理由を上げる。
- スケール：APIひとつの設定ミスが数百万件規模のデータに即時影響しうる
- 速度：IaCの導入などによりミスが複製・展開される速度が人間の確認速度を超えやすい
- 境界の曖昧さ：「内側は安全」という境界が流動的で自明でなくなっている
- 責任の分断：CSPと利用者の責任分断により「誰が対処するか」が見えにくくなる
こうした増幅のメカニズムを理解すると、「情報セキュリティの一部として扱えば十分か」という問いへの答えが少し見えてくる。この点について、国際規格の体系はひとつの示唆を与えてくれる。
ISO/IEC 27001と27017が示す規格上のヒント
ISO/IEC 27001の改訂の歴史と、27017との関係を辿ると、「情報セキュリティの一部ではあるが、専門的な深さは別途必要」という考え方が、規格の構造としても反映されてきたように見える。
| 規格 | クラウドセキュリティの扱い |
| ISO/IEC 27001:2013 | クラウドを独立して扱っていない。供給者関係（A.15）の中にクラウド利用が包含される形にとどまり、クラウド固有の考慮事項は規定されていない。 |
| ISO/IEC 27001:2022 | 新たに「A.5.23 クラウドサービスの利用における情報セキュリティ」を独立した管理策として追加。クラウドサービスの取得・利用・管理・終了のライフサイクル全体にわたるポリシーとプロセスの確立を求めている。ただし「何をすべきか」の入口レベルの規定にとどまっている。 |
| ISO/IEC 27017 | 27001の補完規格（ガイダンス規格）。クラウド固有のセキュリティ管理策を実装レベルで規定。CSPとCSCそれぞれの責任を明示し、仮想環境の分離・管理者権限の制限・クラウド環境の監視・データ削除の確認など、27001では扱われないクラウド固有の管理策を追加している。 |
27001:2022でA.5.23が独立した管理策として追加されたことは、ISO/IECがクラウドを「供給者関係の延長」として扱うだけでは不十分と判断した結果と見ることができる。同時に、A.5.23が「入口レベル」にとどまることで、27017との役割分担がより明確になったとも言えそうだ。27001:2022が「クラウドを使う組織が最低限押さえるべきこと」を示し、27017が「実装レベルの詳細なコントロール」を補うという二層構造となっている。加えて27017の特徴として、CSPとCSC双方に対して異なる管理策を定めている点が挙げられる。これは27001:2022にはない視点であり、「クラウドにおけるセキュリティ責任は一者に帰属しない」という責任共有モデルの考え方を、規格レベルで反映したものと捉えることができる。
27001:2013の時点では「27001だけでは不十分だから27017が生まれた」という話であったが、27001:2022でA.5.23が追加された。しかしながら、27001本体がクラウドを取り込んだにもかかわらず、それでも27017は廃止されず、補完規格として併存し続けている。つまり「27001にクラウドが入れば27017は不要になる」とはならなかった。これは「入口レベルの要求事項」と「実装レベルの詳細なコントロール」は、同一のフレームワークでは代替できないということを示していると考えられる。
ベンダーニュートラルな概念はまだ必要か
AWS、Azure、GCPといったCSPは、自社サービスに特化した詳細なセキュリティ文書を継続的に更新している。また、CSAガイダンスは、V4まではクラウドセキュリティの概念を中心とした内容であったが、V5ではより具体的な実装レベルの内容にシフトしている。こうした状況の中で、ベンダーニュートラルにクラウドセキュリティの概念を説明することに、まだ意味はあるのだろうか。 筆者は、意味はあると考えるが、「誰にとっての意味か」は以前より明確に問われるようになってきているように感じる。
| 立場 | ベンダーニュートラルな概念の必要性 |
| 実装担当者（単一CSP） | CSPの文書で実装が回る場面は多い。ただし、概念の裏付けなく手順だけを習得している場合、「設定は文書通りにやったはずなのになぜ問題が起きたか」という状況につながる可能性がある。 |
| 実装担当者（マルチクラウド） | マルチクラウドの横断的リスク管理にはCSP固有の知識だけでは不十分と考えられる。ベンダーニュートラルな概念が明示的に求められる場面と言える。 |
| 設計・アーキテクト | CSPの選定・評価・責任境界の設計は、特定CSPの操作知識よりも概念的な基盤が判断の軸になる。 |
| セキュリティ評価・監査 | 複数CSPを横断して評価するには、共通の基準軸が必要になる。 |
| 経営・ガバナンス層 | 投資判断・リスク許容・規制対応は、概念レベルの理解が前提になる。 |
CSAガイダンス v5が具体策にシフトした背景には、CSPの文書との競合というより、「概念だけでは実務で参照されにくくなった」という現実への対応があると思われる。ただし逆説的に、具体策の詳細が増すほど、その具体策をどのCSPに、どの優先順位で適用するかを判断するための概念的基盤の価値は相対的に高まるものと考えられる。
まとめ
ここまでの内容を振り返ると、「クラウドセキュリティは情報セキュリティの一部として整理すればよい」という考え方には、一定の合理性があることがわかる。クラウドセキュリティの原則は情報セキュリティと共通しており、CIA三要素やリスク評価の考え方はクラウド環境にもそのまま適用できる。
ただし、「原則が共通している」ことと「同じ対策で十分である」こととは、少し異なる話ではないかと考える。クラウド環境では、同じリスクがスケール・速度・責任の分断・境界の曖昧さという4つの構造的な特性によって増幅されやすい。この点を踏まえると、「情報セキュリティの一部ではあるが、クラウド特有の深さは別途必要」というのが、この問いへのひとつの答えではないかと考える。 ISO/IEC 27001:2022がA.5.23としてクラウドを独立コントロールに加えたこと、27017がCSPとCSC双方への管理策を別途定めていること、そしてベンダーニュートラルな概念が設計・評価・ガバナンスの立場では依然として必要とされていること。これらはいずれも、クラウドセキュリティが「情報セキュリティに吸収されて完結する」のではなく、「情報セキュリティの基盤の上に専門的な理解が積み重なる」という構造を示唆しているのではないかと考えられる。
付録：クラウドで特に考慮が必要なリスク
以下は「クラウドで特に考慮が必要なリスク」をまとめたものである。ISO/IEC 27017が定めるクラウド固有の管理策領域を骨格にしつつ、実務・インシデント事例・規制の観点を加えて整理した。各リスクはクラウド固有というよりも、オンプレミスでも存在するリスクがクラウドの構造的特性（スケール・速度・責任分断・動的変化）によって増幅・複雑化したものとして捉えるとわかりやすい。
データセキュリティ領域
- データの所在地・主権（Data Residency / Sovereignty）
- 意図せぬリージョンへのデータ複製・分散リスク、SaaSでは制御できないリスク
- CSPのレプリケーション設定により意図せず越境移転が発生するリスク
- 国ごとのデータローカライゼーション規制（ロシア、中国P等）との抵触
- マルチリージョン構成時の法的管轄の競合
- データの残存性（Data Remanence）
- クラウドストレージ削除後、実際にデータが消去されたかを確認できない
- スナップショット・バックアップの削除漏れ
- CSPが同一物理メディアを別テナントに再割り当てする際のデータ残存
- ログ・一時ファイルへ機微データ等が意図せず記録されるケース
- 暗号化鍵管理
- CSP管理の鍵を使う場合、CSPによるデータアクセスを完全には排除できない
- BYOK（Bring Your Own Key）とHYOK（Hold Your Own Key）の選択とトレードオフ
- 鍵のローテーション失敗による大規模な復号不能リスク
- HSM（Hardware Security Module）のクラウド実装における信頼性評価
- データ分類とラベリング
- 複数クラウドサービス間でのデータ分類ポリシーの一貫性維持が困難
- 非構造化データ（S3オブジェクト等）への分類適用の難しさ
- 開発環境への本番データのコピーにおける漏洩のリスク
インフラ・プラットフォーム領域
- ハイパーバイザーセキュリティ
- VMエスケープ攻撃
- サイドチャネル攻撃によるテナント間情報漏洩
- ハイパーバイザー自体の脆弱性は利用者側で対処不能
- コンテナセキュリティ
- コンテナイメージの脆弱なベースイメージへの依存
- コンテナランタイムの脆弱性によるホスト侵害
- Kubernetesのデフォルト設定の甘さ（etcdのピア認証がデフォルト無効、保存データの暗号化が非デフォルト）
- コンテナ間のネットワーク分離不備によるラテラルムーブメント
- 特権コンテナの不適切な使用
- サーバーレスセキュリティ
- 関数の実行環境が短命なためフォレンジックが困難
- イベントインジェクション（悪意あるイベントソースによるファンクション・トリガー）
- 依存パッケージの脆弱性管理が見えにくい
- タイムアウト設定の不備によるDoS
- ストレージセキュリティ
- オブジェクトストレージの公開設定ミス（S3バケット等）
- 署名付きURL（Pre-signed URL）の有効期限管理不備
- ブロックストレージのスナップショット共有設定ミス
- バックアップストレージへのランサムウェア感染の波及
- ネットワークセキュリティ
- クラウドリソースのネットワークアクセス制御設定ミスによる意図しない公開
- VPCピアリングの推移的ルーティングの設計誤解によるリスク
- パブリックIPアドレスの意図しない割り当て
- クラウドネイティブなDDoS攻撃（コスト増大を狙った攻撃）
- サービスエンドポイントの設定漏れによるインターネット経由のアクセスのリスク
IAM・アクセス管理領域
- IAMポリシーの複雑性
- ポリシーの組み合わせによる意図しない権限の継承
- インラインポリシーと管理ポリシーの混在による可視化困難
- 条件付きポリシー（IP制限等）の設定ミス
- リソースベースポリシーとIDベースポリシーの競合
- 過剰権限
- 「とりあえず管理者権限」による最小権限原則の形骸化
- 使われていないロール・ユーザーの放置
- 長期アクセス鍵の放置（ローテーションなし）
- クロスアカウントロールの過剰な信頼関係設定
- 認証情報の露出
- ハードコードされたAPIキー
- EC2インスタンスメタデータエンドポイント経由の認証情報窃取
- CI/CDパイプラインへのシークレットのハードコード
- ログへの認証情報の誤出力
- フェデレーション・シングルサインオン
- IdPの侵害によるクラウド環境全体への影響波及
- SAMLレスポンスの署名検証不備
- OAuthのオープンリダイレクト悪用
- JWTの署名アルゴリズム混乱攻撃
アプリケーション・DevSecOps領域
- CI/CDパイプラインのセキュリティ
- パイプラインへの悪意あるコードの注入
- ビルド環境の汚染によるサプライチェーン攻撃
- アーティファクトリポジトリへの不正アクセス
- デプロイ権限の過剰付与
- IaC（Infrastructure as Code）
- TerraformやCloudFormationの設定ミスが大量環境に一括展開される
- IaCテンプレートへのシークレットの埋め込み
- ドリフト（実環境とIaC定義のずれ）による設定管理の崩壊
- モジュール・プロバイダの脆弱性（サプライチェーンリスク）
- APIセキュリティ
- クラウドサービス間通信のAPIキー管理不備
- APIゲートウェイの認証バイパス
- レートリミットの不備によるDoS
- GraphQLの過剰なデータ露出
可視性・運用領域
- ログ・モニタリング
- CloudTrail・Audit Logのデフォルト無効による証跡の欠如
- ログの保存コストを理由にした無効化・期間短縮
- マルチクラウド環境でのログの集約困難
- 攻撃者によるCloudTrailの無効化（検知回避）
- ログの改ざん防止設定の欠如
- 設定管理の継続的監視
- リソースの動的な増減による設定管理対象の常時変化
- 管理されていないクラウドリソースの把握困難
- 設定変更の速度がレビューの速度を超える問題
- CSPのサービス仕様変更による既存設定の無効化
- インシデントレスポンスの困難性
- 揮発性環境（コンテナ・サーバーレス）でのフォレンジック証拠の消失
- CSPへの証拠保全要請の手続き的複雑さ
- マルチリージョン・マルチクラウドでの攻撃経路の追跡困難
- メモリフォレンジックがクラウド環境では原則不可能
法的・コンプライアンス領域
- 責任共有モデルの誤解
- CSPと利用者の責任境界をサービスモデルごとに正確に把握していない
- 「CSPが対応してくれると思っていた」という認識齟齬
- 契約上の責任と技術的な責任の乖離
- クロスボーダー規制
- GDPRのSCC（標準契約条項）要件を満たさないデータ移転
- 各国当局によるCSPへのデータ開示要求への対応義務（CLOUD法）
- 規制ごとに異なる「個人データ」の定義の適用困難
- 監査・証拠保全
- マルチテナント環境での監査証跡の独立性確保
- 米国をはじめとする訴訟制度における電子証拠開示（eDiscovery）でのクラウドデータの収集手続き
- CSPのSOC2レポートの評価能力の欠如（読めても解釈できない問題）
その他のリスク
- マルチクラウド固有のリスク
- クラウド間のID連携の複雑性
- セキュリティポリシーの一貫した適用が困難
- 最も弱いクラウド環境が全体の侵入口になる
- AIワークロードのリスク
- クラウド上のLLM基盤へのプロンプトインジェクション経由のデータ抽出
- 学習データへの不正アクセスによるモデル汚染
- 推論APIの過剰公開
以上