クラウドセキュリティアライアンス（CSA）は、2024年7月15日、「クラウドコンピューティングのためのセキュリティガイダンス V5」（https://cloudsecurityalliance.org/artifacts/security-guidance-v5）を公開した。CSAガイダンスV5では、コンテナ／マイクロサービス／サーバーレスセキュリティの扱いが大幅に増えたのが特徴である。後編では、アプリケーションセキュリティに関連する新ガイダンスの追加・変更点について概説する。

クラウドネイティブ技術をベースとする米国のFedRAMP改革が本格化

2024年7月26日、米国ホワイトハウス傘下の行政管理予算局（OMB）は、クラウドサービスのセキュアな採用を加速するためのFedRAMPガイダンスを公表した（関連情報（https://www.whitehouse.gov/omb/briefing-room/2024/07/26/fact-sheet-omb-releases-fedramp-guidance-to-accelerate-the-secure-adoption-of-cloud-services/））。その中で、FedRAMPのモダナイゼーションのために、以下の3点に注力することを表明している。

• 不可欠で効率的なセキュリティにフォーカスする
• 政府機関にとってクラウド利用をより簡単で安全なものにする
• FedRAMPガバナンスを強化する

これに先立ちFedRAMPは、2024年6月27日、大統領令第14110号（人工知能の安心、安全で信頼できる開発と利用）に呼応した「新興技術優先順位付けフレームワーク」を公表していた（関連情報（https://www.fedramp.gov/2024-06-27-release-of-et-framework/））。このフレームワークでは、人工知能（AI）をトップバッターとして、重要なクラウド関連新興技術（ET）に優先順位付けを行い、それに基づいて、FedRAMPの内部業務やレビューのプロセスを行うとしている。FedRAMPは、優先順位付けの対象となるAI関連新興技術基準として、以下の3つを挙げている。

1. チャットインタフェース
2. コード生成デバッグツール
3. プロンプトベースの画像生成

FedRAMPは、今後、新興技術優先順位付けフレームワークの対象となる技術領域を定期的に見直していくとしている。

参考までに、2024年2月時点で、ホワイトハウスが重要・新興技術として指定する領域には、以下のようなものがある（関連情報（https://www.whitehouse.gov/wp-content/uploads/2024/02/Critical-and-Emerging-Technologies-List-2024-Update.pdf））。これらの領域はいずれも米国の国家安全保障の対象であり、重要インフラを支えるクラウドプラットフォームにも、強固なセキュリティ管理策が要求される。

• 先進コンピューティング
• 先進工学材料
• 先進ガスタービンエンジン技術
• 先進ネットワークセンシング・シグニチャー管理
• 先進製造
• 人工知能（AI）
• バイオテクノロジー
• クリーンエネルギー生成・保存
• データプライバシー、データセキュリティ、サイバーセキュリティ技術
• 指向性エネルギー
• 高度な自動化、自律化、無人システム（UxS）、ロボティクス
• ヒューマンマシンインターフェース
• 極超音速
• 統合型通信ネットワーク技術
• 位置、航法、時刻（PNT）技術
• 量子情報実現技術
• 半導体・マイクロエレクトロニクス
• 宇宙技術システム

また、上記のうちAIでは、以下のような技術が挙げられている。

• 機械学習
• 深層学習
• 強化学習
• 感覚的知覚認識
• AI保証評価技術
• 基盤モデル
• 生成AIシステム、マルチモーダル、大規模言語モデル
• 教育、微調整、検証向けの合成データアプローチ
• 計画、推論、意思決定
• AIの安全性、信頼性、セキュリティ責任ある利用を向上させるための技術

上記AI技術領域に関して、FedRAMPの優先順位付けフレームワークがどこまでカバーしていくのか、今後の動向が注目される。

また、ホワイトハウスの対象領域になっているデータプライバシー、データセキュリティ、サイバーセキュリティ技術に関しては、以下のような技術が挙げられている。

• 分散台帳技術（DLT）
• デジタル資産
• デジタル決済技術
• デジタルアイデンティティ技術、生体認識および関連インフラストラクチャ
• 通信ネットワークセキュリティ
• プライバシー強化技術
• データフュージョンおよびデータの相互運用性、プライバシー、セキュリティ向上のための技術
• 分散秘密計算
• サプライチェーンセキュリティ計算処理
• 人工現実（AR）／仮想現実（VR）におけるセキュリティとプライバシーの技術

上記の技術領域の中には、すでにCSAの個別WGの活動対象となっているテーマが多く含まれており、今後、FedRAMP改革への対応だけでなく、国境を越えたハーモナイゼーションが期待される。

伝統的なIaaS／PaaSを前提としてきたアプリケーションセキュリティ

ところで、CSAガイダンスV4.0では、「アプリケーションセキュリティ」の章で、PaaSおよびIaaSのクラウドコンピューティング環境のソフトウェアを構築する開発者や運用するITチームに焦点を当てていた。具体的には、以下のような構成になっていた。

10. アプリケーションセキュリティ
10.0 はじめに
10.1 概要
10.1.1 セキュアソフトウェア開発ライフサイクルとクラウドコンピューティング
10.1.2 セキュアな設計と開発
10.1.3 セキュアな配備
10.1.3.1 脆弱性診断への影響
10.1.3.2 侵入検査への影響
10.1.3.3 配備パイプラインのセキュリティ
10.1.3.4 Infrastructure as Code ”と不可変性による影響
10.1.4 セキュアな運用
10.1.5 クラウドのアプリケーション設計とアーキテクチャへの影響
10.1.6 クラウド事業者が考慮すべきその他の事項
10.1.7 DevOps の隆盛とその役割
10.1.7.1 セキュティへの波及効果とその長所
10.2 推奨事項

　そして、以下のような推奨事項を提示していた。

• 利用しているクラウド事業者の持つセキュリティに関する能力を把握すること。ベースラインのセキュリティだけでなく、複数のプラットフォームとサービスの全般にわたって把握すること。
• 初期設計のプロセスにセキュリティを組み込むこと。クラウド上のデプロイは多くの場合未経験の領域であり、早い段階でセキュリティチームを関わらせる場は広がっている。
• 形式の整ったSDLCを導入できていないときは、CDに移行してデプロイパイプラインにセキュリティの自動化を組み入れることを検討すること。
• 脅威モデリング、SAST、DAST(ファジングを含む)は全て取り入れるべきである。テストはクラウド環境で機能するように設定しなければならない。しかし同時に、クラウドプラットフォームに固有の懸念事項、例えばAPI資格情報の保存状態などをテストできる設定もしなければならない。
• 新しくクラウド内で遭遇するアーキテクチャの選択肢や要求条件を理解すること。それらをサポートするべく、自組織のセキュリティポリシーとセキュリティ基準を改定すること。決して単純に従来の基準を全く新しいコンピューティングモデルに強制的にはめ込むようなことはしないこと。
• 配備プロセスにセキュリティテストを組み込むこと。
• セキュリティコントロールを自動化するために、Software Defined Securityを活用すること。
• 可能なら、イベント駆動型セキュリティを活用し、セキュリティ事案に対する検知と修復の自動化を実現すること。
• 複数の異なるクラウド環境を利用し、管理用ダッシュボードへのアクセスの分離を改善すること。同時に、本番環境は固定しつつ、開発チームには必要な開発環境の設定を自由にさせること。

DevSecOpsの柱はセキュアソフトウェア開発ライフサイクル（SSDLC）

これに対してCSAガイダンスV5では、以下のような構成になっている。

10. アプリケーションセキュリティ
10.1 セキュアな開発ライフサイクル
10.1.1 CSAセキュア開発ライフサイクル
10.1.2 脅威モデリング
10.1.3 セキュアな設計と開発
10.1.4 テスト：デプロイ前
10.1.5 テスト：デプロイ後
10.2 セキュアなクラウドアプリケーションアーキテクチャ
10.2.1 クラウドのアーキテクチャレベルのセキュリティへの影響度
10.2.2 クラウドのアプリケーション設計とアーキテクチャへの影響度
10.2.3 Infrastructure as Codeとアプリケーションセキュリティ
10.2.4 APIセキュリティのベストプラクティス
10.3 アイデンティティ／アクセス管理のアプリケーションセキュリティ
10.3.1 アプリケーションコンポーネント上での許可の設定
10.3.2 秘密管理
10.4 DevSecOps：CI／CDとアプリケーションテスト
10.4.1 DevSecOps
10.4.2 DevSecOpsの6つの柱
10.4.3 実用的なDevSecOps
10.4.3.1 シフトレフトとセキュリティの組込
10.4.3.2 SecOps：WebアプリケーションファイアウォールとDDoS
10.5 サーバーレスとコンテナ化されたアプリケーションの考慮事項
10.5.1 サーバーレスとコンテナのアプリケーションセキュリティへの影響度
10.5.1.1 サーバーレスの考慮事項
10.5.1.2 コンテナの考慮事項

まず、「10.1 セキュアな開発ライフサイクル」において、CSA DevSecOps WGが活動の柱としてきたセキュアソフトウェア開発ライフサイクル（SSDLC）に焦点を当ている（関連情報（https://cloudsecurityalliance.org/blog/2023/03/25/the-5-stages-to-devsecops））。CSAのSSDLCは、以下の5つのステージから構成される。

• セキュアなデザインとアーキテクチャ
• セキュアコーディング（Developer IDEとCode Repository）
• 継続的なビルド、統合、およびテスト
• 継続的なデリバリーとデプロイメント
• 継続的なモニタリングとランタイムディフェンス

SSDLCは、後述の「10.4 DevSecOps：CI／CDとアプリケーションテスト」につながる重要な枠組となっている。

次に、脅威モデリングに関して、具体的なフレームワークを例示している。脅威モデリングとは、組織の資産に対する潜在的なセキュリティ脅威を特定、評価、低減するために、利用される構造化プロセスと定義している。これには、システムアーキテクチャの理解、セキュリティ目標の特定、これらの目標に影響を及ぼす可能性のある潜在的脅威の分析が含まれる。脅威モデリングを実行することによって、重大度と確率に基づいて、特定された脅威の優先順位を付けることができるとしている。

この脅威モデリングのうち、セキュリティリスクを特定・分類するフレームワークとして、以下の6つから構成されるSTRIDEフレームワークを例示している。

1. 偽造（Spoofing）：不正アクセスを行うために、ユーザーやシステムのように誰か他人のふりをする攻撃者が含まれる（例. ログイン資格情報を盗み出すために、攻撃者が合法サイトを真似たところでのフィッシング攻撃）
2. なりすまし（Tampering）：データやメッセージの不正な変更のこと。これが、転送時やストレージシステム内部で起きて、データの完全性が損なわれる可能性がある。
3. 否認（Repudiation:）：これは、そうしたにも関わらず主体が行為を否定した時に起きる。これにより、行為を正しいソースに帰するシステムの能力が弱体化して、責任が複雑化する。
4. 情報開示（Information Disclosure）：これには、機密情報への不正アクセスが含まれる。手法には、セキュアでない通信上での盗み聞き、機微データにアクセスする脆弱性の悪用が含まれる。
5. サービス拒否（Denial of Service）：これは、システムの可用性欠如につながるようなシステムリソースの消耗である。これにより、オペレーションが破壊され、重大なダウンタイムを招く可能性がある。
6. 特権昇格（Elevation of Privilege）：攻撃者が、許可されたレベル以上の高度なアクセスを取得した場合、より特権の高いアカウント用に指定した行動を実行するために、アクセス制御をバイパスする。

• クラウドアプリケーション設計のセキュリティ原則と技術的対策

その上で、CSAガイダンスV5では、「10.1.3 セキュアな設計と開発」について説明している。ここでは、クラウドアプリケーション設計時のセキュリティ原則として、以下の3点を挙げている。

• PaaSサービスは、より多くのセキュリティ上の責任をCSPに委ねて、顧客が、セキュアで、完全にパッチ当てされ、設定されたサーバーやサービスを維持する必要性を減らすか、なくす可能性がある。
• すべてのアプリケーションコンポーネントおよびPaaSサービス向けに最小特権のアイデンティティ／アクセス管理（IAM）を実装する。
• インターネットに面した露出を低減するために、ロードバランサーや非常に制限されたセキュリティグループのようなCSPサービスを利用する。

伝統的なPaaSと比較して、クラウドユーザーの負荷が低減する反面CSPの責任が重くなるサーバーレスコンピューティングのFaaS（Function as a Service）への展開を意識した内容になっている。

そして、具体的なテスト手法として、以下のような例を挙げている。

[デプロイ前テスト]

1. 静的アプリケーションセキュリティテスト（SAST）
   • 手動セキュリティコードレビュー
2. ソフトウェア構成分析（SCA）
3. 静的脆弱性スキャニング

[デプロイ後テスト]

1. 動的脆弱性スキャニング
2. 動的アプリケーションセキュリティテスト（DAST）
   • 動的分析（ファジング）
   • インタラクティブアプリケーションセキュリティテスト（IAST）
3. ペネトレーションテスト
4. バグバウンティプログラム

このように、CSAガイダンスV5では、デプロイ前およびデプロイ後に分けて、テスト手法を列挙するようになった。

加えて、技術的対策として、「10.2 セキュアなクラウドアプリケーションアーキテクチャ」において、Infrastructure as Code（IaC）やAPIセキュリティを、「10.3 アイデンティティ／アクセス管理のアプリケーションセキュリティ」において、特権アクセス管理に代表されるIAMや秘密管理を取り上げている。

クラウドネイティブアプリケーション開発を支えるDevSecOpsとシフトレフト

さらにCSAガイダンスV5で拡充されたのが、「10.4 DevSecOps：CI／CDとアプリケーションテスト」の部分である。DevSecOpsについては、SSDLCを通してセキュリティの統合を自動化するような開発、セキュリティ、運用を短縮したものであり、DevOpsパイプラインに「セキュリティ」の部分を導入するものだとしている。

そして、セキュアなソフトウェアを効率的に開発することを目的として、セキュリティをDevOpsプラクティスに統合するための包括的フレームワークとして、DevSecOpsの6つの柱を掲げている。参考までに、6つの柱については、下記のCSA DevSecOps WG発行ドキュメントで詳説している。

• 「DevSecOpsの6つの柱：集団的責任」（2020年2月21日公開）
  • （原版：https://cloudsecurityalliance.org/artifacts/devsecops-collective-responsibility）

「DevSecOpsの6つの柱：コラボレーションと統合」（2024年2月20日公開）

• （原版：https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-collaboration-integration）

• 「DevSecOpsの6つの柱：実践的な実装」（2022年12月14日公開）
  • （原版：https://cloudsecurityalliance.org/artifacts/six-pillars-devsecops-pragmatic-implementation）
• 「DevSecOpsの6つの柱：コンプライアンスと開発の橋渡し」（2022年2月8日公開）
  • （原版：https://cloudsecurityalliance.org/artifacts/devsecops-pillar-4-bridging-compliance-and-development）
• 「DevSecOpsの6つの柱：⾃動化」(2020年7月6日公開)
  • （原版：https://cloudsecurityalliance.org/artifacts/devsecops-automation）
  • （日本語訳版：https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/04/DevSecOps-Automatio-ja.pdf）
• 「DevSecOpsの6つの柱：測定、監視、報告および⾏動」
  • （原版：https://cloudsecurityalliance.org/artifacts/the-six-pillars-of-devsecops-measure-monitor-report-and-action

DevSecOpsを実用的なものにするために、CSAガイダンスV5では、以下の通り、セキュリティをDevOpsプロセスに統合するための構造化アプローチを提示している。

• 検知（Detect）：警戒する見張り役のように行動するリアルタイムモニタリングシステムを実装して、セキュリティの課題や脅威、設定ミスをできるだけ早くスキャン・特定し、迅速な対応を保証する。
• 自動化（Automate）：技術を活用して、パッチのデプロイから構成管理まで、独立して運用するスマートシステムのように、繰り返されるセキュリティタスクを自動化し、セキュリティ対策が常に最新で一貫して強制されていることを保証する。
• 配備（Deliver）：馴染のツールを通して、セキュリティアラートが適切な専門家に到達することを保証する、効率的で直接の通信プロトコルを確立し、反応時間やチームの活動の効率性を最適化する。
• 修復（Fix）：ルーティンの清掃が、レストランの衛生基準を維持しているのと同じように、セキュリティの維持を毎日のルーティンに統合し、定期的でプロアクティブな運用の一部として、セキュリティ課題を解決する。

実用的なDevSecOpsと合わせて、CSAガイダンスV5では、シフトレフト戦略とセキュリティの組込を掲げている。シフトレフトは、セキュア・バイ・デザインやセキュア・バイ・デフォルトの製品であることを保証するために、SSDLCの早期フェーズに、セキュリティを移行させるべきだと示すために利用される言葉である。この手法は、SSDLCの下流フェーズの追加的セキュリティと比較して、費用対効果に優れているおり、脆弱性の早期検知に役立つとしている。

クラウドネイティブなアプリケーションセキュリティ対策としてのWAF

加えて、Webアプリケーションをデプロイ後まで保護する対策として、ゲートウェイサービスや、分散サービス拒否（DDoS）攻撃防止、Webアプリケーションファイアウォール（WAF）の実装を挙げている。これらのツールは、アプリケーションが正当なユーザーにアクセス可能であることを保証するために設計されており、効率的にWebトラフィックの流入を管理し、過負荷による潜在的クラッシュに対して保護することができる。特に、WAFは予防的防御であって、選択的制御や、貧弱に開発されたアプリケーション向けの保護策ではない点を強調している。

その上で、IaaS／PaaSサービスにおけるWAF／DDoS保護のための4つの共通デプロイシナリオを示している。

1. エージェントのデプロイ：IaaSの仮想マシンをWebサーバーとして利用する時、WAFエージェントを、OSの上位にインストールすることができる。通常、このオプションには、DDoS低減機能はない。
2. クラウドプロバイダーサービス：IaaS／PaaSプロバイダーは、通常ロードバランサーサービス上にデプロイされる、WAFとDDoS保護の統合型サービスを提供する。
3. サードパーティマーケットプレイスサービス：IaaS／PaaSマーケットプレイスは、専用VMにデプロイされた、様々なサードパーティ製商用WAFソフトウェアを提供する。WAFをデプロイし、ルーティングやリダンダンシー、ロードバランシングを保証するのは、顧客の責任である。
4. WAF／DDoS as a Service：DNSリダイレクトを利用して、消費者のトラフィックは、サードパーティWAFにルーティングされ、検証・フィルタリングした上で、クラウドプロバイダー環境にルーティングされる。

クラウドネイティブな新技術ならではの課題に注目

アプリケーションセキュリティの章の後半では、サーバーレス／コンテナの考慮事項を整理している。これらの技術はセキュリティプラクティスを変革する一方、新たなクラウドネイティブ環境ならではの課題への適応も求めている。具体的には、以下のような考慮事項を提示している。

[サーバーレスの考慮事項]

• 攻撃面の削減：サーバーレス機能の一時的な性質は、単独で、持続的なストレージのない短期運用を行い、本質的に攻撃に対する露出を抑制する。
• 依存性のリスク：製品製造時の既知の安全性記録を有するサードパーティコンポーネント利用に似たような、外部のコードまたはサービスへの依存。
• IAMの複雑性：サーバーレス機能の一時的で分散化した性質は、多数の継続的に変化するアクセスポイント全体のセキュリティ維持に匹敵する、複雑なアクセス管理を必要とする。

[コンテナの考慮事項]

• 分離のリスク：侵入者が簡単に入れる通路を可能にするコネクテッドルームの不適正な分離と同様に、コンテナ化環境における不十分な分離は、セキュリティ侵害をもたらし得る。
• 不可変インフラストラクチャ：コンテナは、デプロイ後不可変的になるように設計されており、一貫性を促進し、証拠改ざん防止パッケージのようにリスクを低減する。
• 複雑な構成管理：スケールが拡大するにつれて、コンテナの複雑なセキュリティ構成が課題となっており、複数施設に渡る先進的なセキュリティシステムの複雑なネットワークを監視するのに似ている。

最後に、アプリケーションセキュリティの章ではまとめとして、以下のような推奨事項を提示している。

[CSAセキュア開発ライフサイクル(SSDLC)]

• セキュアなデザインとアーキテクチャ：セキュリティを早期に統合するために、設計フェーズの間、技術やツールを適用して、費用の上昇や後のボトルネックを回避する。
• 継続的なビルド、統合、テスト：セキュリティ侵害を防止するため、デプロイ前に、脆弱性をテストするツールやプロセスを導入する。
• 継続的なデリバリーとデプロイ：アプリケーションがセキュアなインフラストラクチャ上にデプロイされていることを保証するために、デプロイ前安全性チェックを実行する。
• ランタイム防御とモニタリング：デプロイ前に、脆弱性や非効率性を継続的に特定・低減するためのプラクティスを実装する。

[構造化脅威モデリングの採用]

• 脅威を分類するためにSTRIDEフレームワークを適用する：偽造、なりすまし、否認、情報開示、サービス拒否、特権昇格

[セキュアなクラウド設計へのフォーカス]

• セキュリティの責任をプロバイダーに引き渡すために、PaaS（Platform as a Service）およびその他のCSPサービスを利用する。
• すべてのコンポーネントについて、最小特権およびアイデンティティ／アクセス管理（IAM）を実装する。
• インターネットへの露出を最小化するために、ロードバランサーやセキュリティグループのようなCSPサービスを利用する

[セキュリティテスト手法の統合]

静的アプリケーションセキュリティテスト（SAST）：デプロイ前に脆弱性や論理的エラーを特定するために、コードレビューを自動化する

ソフトウェア構成分析（SCA）：脆弱性やライセンシングのリスクに関して、外部コンポーネントを監査し、透明性のために、ソフトウェア部品表（SBOM）を生成する。

[包括的なデプロイ後テストの実行]

• 動的アプリケーションセキュリティテスト（DAST）：外部の観点から、アプリケーションのセキュリティポスチャーを評価するために、ブラックボックステストを実行する。
• 動的分析（ファジング）：運用中にエラーや脆弱性を特定するために、予測不能なデータを入力する。
• インタラクティブアプリケーションセキュリティテスト（IAST）：コードおよびランタイム双方における脆弱性を特定するために、SASTとDASTを組み合わせる。
• ペネトレーションテスト：既知の脆弱性を悪用して、システムのレジリエンスをテストするために、攻撃シミュレーションを実行する。
• バクバウンティプログラム：脆弱性を発見して報告するために、エシカルハッカーコミュニティを有効活用する。

[アクセス制御の強化]

• 不正アクセスを最小化するために、最小特権原則を適用する。
• 異常なアクセスパターンを検知して処理するために、継続的モニタリングを実装する。
• アクセス力を希薄化し、誤用を防止するために、職務分離を利用する。
• プラットフォーム間の相互作用を簡素化・セキュア化するために、フェデレーションを採用する。

[秘密管理]

• 人的エラーを最小化するために、資格情報を自動的に供給する。
• 金庫の貴重品のように、鍵をセキュアに保存する。
• セキュアなチャネルを介して秘密をAPIと統合する。
• 共有銀行口座のように、暴露なしの秘密の共有を促進する。

[秘密のCI／CDパイプラインへの統合]

• 組込型セキュリティチェックで、継続的な統合・デプロイを実装する。
• SSDLCにおいて早期に脆弱性を特定して処理するために、シフトレフト戦略を利用する。
• 一貫した強制と迅速なアップデートを保証するために、繰り返されるセキュリティタスクを自動化する。
• 開発、運用、セキュリティチーム間のコラボレーションを促進する。

[現代的なデプロイのためのセキュリティ戦略の適応]

• サーバーレスの考慮事項
  • 一時的なサーバーレス機能による攻撃面の削減を活用する。
  • 依存性リスクを処理し、複雑なIAM環境を管理する。
• コンテナの考慮事項
• 侵害を防止するために堅牢な分離を保証する。
  • 一貫性とセキュリティを促進するために、不変的なインフラストラクチャを利用する。
  • コンテナのデプロイの規模で複雑なセキュリティ構成を管理する。

CSAジャパン関西支部リーダー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司