タグ別アーカイブ: ヘルスケア

コンテナ/マイクロサービス/サーバーレスセキュリティと自動化/AI(技術編)(後編)

クラウドセキュリティアライアンス(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つの柱:コラボレーションと統合」(2024年2月20日公開)

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ジャパン関西支部リーダー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

コンテナ/マイクロサービス/サーバーレスセキュリティと自動化/AI(技術編)(前編)

クラウドセキュリティアライアンス(CSA)は、2024年7月15日、「クラウドコンピューティングのためのセキュリティガイダンス V5」(https://cloudsecurityalliance.org/artifacts/security-guidance-v5)を公開した。CSAガイダンスV5では、コンテナ/マイクロサービス/サーバーレスセキュリティの扱いが大幅に増えたのが特徴である。前編では、コンテナ、サーバーレス/FaaS、AIワークロードに関連する新ガイダンスの技術動向について概説する。

「仮想化とコンテナ技術」から「クラウドワークロードセキュリティ」へ

CSAガイダンスV4.0では、「仮想化とコンテナ技術」の章において、「コンピュート」、「ネットワーク」、「ストレージ」と並ぶ仮想化技術領域として「コンテナ」が取り上げられていた。そこでは、以下の通り、コンテナに係るクラウド事業者およびクラウド利用者向けの推奨事項を提示していた。

[クラウド事業者のための推奨事項]

  • 仮想化に使われる基盤となるインフラの全てをそれ自体でセキュアにする
  • テナント間のセキュリティ面の隔離を保証することに注力する
  • 仮想化レイヤにおいて十分なセキュリティ機能を提供し、クラウド利用者がその資産のセキュリティを適切に確保できるようにする
  • 物理インフォストラクチャと仮想化プラットフォームを攻撃者と内部不正に対してしっかりと防御する
  • クラウド利用者が管理する全ての仮想化機能に対し、デフォルトでセキュアな設定を実装する

[クラウド利用者のための推奨事項]

  • 利用しているクラウド事業者の提供する機能とセキュリティ上のギャップを確実に認識する
  • 仮想化サービスを、クラウド事業者のガイダンスと業界の実践規範に沿って適切に設定する
  • 利用するコンテナプラットフォームとその下のOSのセキュリティのための隔離機能を把握し、適切な設定を選択する
  • コンテナ間の隔離の実施には物理マシンまたは仮想マシンを用い、同一の物理/仮想ホスト上の同一のセキュリティ要件のコンテナはグループ化する
  • 配備対象となるのは、確実に、承認済みで認知済みでセキュアなコンテナのイメージかコードだけとなるようにする
  • コンテナの統合化・管理およびスケジューラのソフトウェアのセキュリティを適切に設定する
  • 全てのコンテナとリポジトリ管理に対して、適切なロールベースのアクセス管理と、強度の高い認証を実装する

これに対してCSAガイダンスV5では、「仮想化とコンテナ技術」から「クラウドワークロードセキュリティ」へと章の名称が変わった。参考までにCSAガイダンスV5の「8 クラウドワークロードセキュリティ」の章は、以下のような構成になっている。

8.1 クラウドワークロードセキュリティへの導入

  • 8.1.1 クラウドワークロードのタイプ
  • 8.1.2 クラウドワークロード:短期と長期
  • 8.1.3 伝統的なワークロードセキュリティ制御への影響
  • 8.1.4 ソフトウェア構成分析

8.1.5 ソフトウェア部品表(SBOM)

8.2 仮想マシン

  • 8.2.1 仮想マシンの課題と低減策
    • 8.2.2 ファクトリーによるセキュアな仮想マシンイメージの生成
  • 8.2.2.1 VM向けに推奨されるツールとベストプラクティス
  • 8.2.3 デプロイメントパイプラインによるセキュアなイメージの生成
  • 8.2.4 スナップショットと公的暴露/抽出

8.3 コンテナのセキュア化

  • 8.3.1 コンテナイメージの生成
  • 8.3.2 コンテナネットワーキング
  • 8.3.3 コンテナオーケストレーション&管理システム
  • 8.3.4 コンテナオーケストレーションのセキュリティ
    • 8.3.4.1 アーティファクトレポジトリのセキュア化
    • 8.3.4.2 セキュアなレポジトリ利用に関するベストプラクティス
  • 8.3.5 コンテナ脆弱性の管理
  • 8.3.6 コンテナ向けのランタイム保護

8.4 PaaSセキュリティ

  • 8.4.1 一般的なPaaS向けのセキュリティプラクティス
  • 8.4.2 暗号化とアクセス制御
  • 8.4.3 特定のPaaSのセキュア化

8.5 サーバーレス/FaaS(Function as a Service)のセキュア化

  • 8.5.1 FaaSセキュリティの課題
  • 8.5.2 サーバーレス向けIAM
  • 8.5.3 ネットワーク接続とアクセスパターン
  • 8.5.4 環境変数と秘密

8.6 AIワークロード

  • 8.6.1 AIシステムの脅威
  • 8.6.2 AI低減戦略

CSAガイダンスV5では、クラウドワークロードについて、クラウドコンピューティング環境で稼働する様々なタスク、アプリケーション、サービス、プロセスであり、仮想マシン(VMs)、コンテナ、サーバーレス/FaaS (Function as a Service)、AI、PaaS(Platform as a Service)など、幅広いリソースをカバーするものだとしている。

そして、クラウドワークロードと従来型環境の違いとして以下の3点を挙げている。

  • 動的で拡張的:

データやワークロードが静的な従来型環境と異なり、クラウドは、継続的に進化する、動的で拡張的な背景を有している。このような環境の流動的な特性は、アジャイルで順応性があるセキュリティアプローチを必要とする。クラウドに挑むセキュリティ専門家にとって、これは、標準的なセキュリティ対策を再考して、関与のルールが継続的に書き換えられるような背景に適応することを意味する。

  • 複雑性と多様性:

固有の要求事項を有する様々な種類のワークロードが存在するため、セキュリティに対する汎用的なアプローチは機能しない。

  • 完全性、機密性、可用性:

クラウドワークロードセキュリティの中核は、データの完全性、機密性、可用性というサイバーセキュリティの基盤となる原則の維持にある。クラウドでは、データが変更できないこと(完全性)、認可されたユーザーだけがアクセスできること(機密性)、必要な時に利用可能なこと(可用性)の保証が重要である。

ガイダンスV5では、仮想マシンからコンテナ、サーバーレスアーキテクチャに至るまで、クラウドワークロードの開発・実装プロセス全体において、統合ソフトウェア構成分析(SCA)やソフトウェア部品表(SBOM)の役割を統合することによって、セキュリティだけでなく信頼性やコンプライアンスを保証できるとしている。進化するサイバー脅威動向に対してクラウド運用のセキュア化を図ろうとする組織にとって、このようなプラクティスは必要不可欠なものとなりつつある。

サーバーレス/FaaSとAIワークロードが表舞台に登場

CSAガイダンスV5では、クラウドワークロードのタイプとして、以下の5つを挙げている。

[仮想マシン(VMs)とインスタンス]

  • クラウドサービスプロバイダー(CSP)が管理するハイパーバイザおよびその他の管理プレーンコンポーネントにより強制された、別個のOSを通して分離を提供する。
  • ハイパーバイザは、クラウドサービスプロバイダー(CSP)が維持する重要なコンポーネントであるが、個々のVM内のゲストOSのセキュリティは、通常、クラウドサービスカスタマー(CSC)が取扱うので、周到な構成とパッチ当てが必要となる。
  • さらに、VMスプロールは、重大なセキュリティリスクを示す可能性がある。
  • 加えて、スナップショットやイメージの管理は、機微データの漏えいを防止するために重要であり、厳格なガバナンスを必要とする。

[コンテナ]

  • コンテナは、ホストOSのカーネルを共有する、分離したランタイム環境であるが、自らのファイルシステムやライブラリ、構成を備えた別個の自己完結型プロセスとして稼働する。
  • コンテナは、軽量で効率的なVMの代替品を提供するが、異なるセキュリティ課題を示す。コンテナは、ホストOSカーネルを共有するので、本質的に弱い分離を提供する。
  • コンテナ化した環境におけるセキュリティは、正確にOSレベルの制御を構成し、コンテナイメージのセキュリティを維持し、コンテナのランタイム環境が適切に構成されていることを保証するように決定される。
  • Kubernetesのようなオーケストレーターのセキュリティ強化における利点にも関わらず、オーケストレーターは、侵害防止のために注意深く切り抜けなければならないような追加的複雑性をもたらす。

[PaaS(Platform as a Service)]

  • PaaSは、より効率的でオーバーヘッドの少ないアプリケーションの開発、実装、管理を促進するような、一連のツールおよびサービスを提供することによって、クラウドプラットフォームの機能を拡張する。
  • データベースやメッセージングシステムから、コンテンツデリバリーネットワーク(CDN)に至るまで、様々なサービスに基づいたセキュリティ考慮事項を示す。

[サーバーレス/FaaS(Function as a Service)]

  • FaaSは、開発者が、基盤となるインフラストラクチャの管理なしに、イベントやリクエストに対応して実行されるような個々の機能を書いてデプロイするクラウドコンピューティングモデルである。
  • サーバーレスモデルは、セキュリティ責任のより多くの部分をCSPに委ねる。この信頼性の再割り当てにより、CSPの特別なセキュリティ専門知識と先進的な保護対策を活かして、攻撃表面を最小化する。CSPによる強制された分離とともに、実行環境の短期的な性質が、固有のセキュリティの利点を提供する。
  • サービス拒否(DoS)攻撃や自動スケーリングによる経済的疲弊など、不正アクセスや潜在的攻撃に対するサーバーレスアプリケーションの保護のために、最小特権による秘密の管理と機能の構成が最も重要である。

[AIワークロード]

  • AIワークロードは、膨大な量の学習用データを処理して、意思決定を行い、予測を提供する。敵対的攻撃に対する保護、モデルの盗難の防止、プロンプトインジェクションに対する保護を特に強調しながら、データの完全性とプライバシーを保証することが最も重要である。
  • このような脆弱性にも関わらず、AIワークロードは、先進的な計算処理リソースとクラウド環境の拡張性を活用する。

一般的に、クラウドワークロードになると、特にサーバーレスコンピューティングのようなモデルにおいて、管理責任がCSP側にシフトする。攻撃表面が消失する可能性がある反面、可視性、制御、ガバナンスの課題は持続する。従って、セキュリティモニタリングやガバナンスは、すべてのクラウドワークロードに渡って堅牢なセキュリティポスチャを維持する際に重要となり、運用が妨げられることなく維持でき、データ保護規制を遵守していることを保証するとしている。

CSAガイダンスV4.0と比較すると、V5では、サーバーレス/FaaSやAIワークロードといった新トピックを網羅している点が注目される。

クラウドワークロードセキュリティの推奨事項

最後に、CSAガイダンスV5の「クラウドワークロードセキュリティ」では、以下のような推奨事項を提示している。

[クラウドワークロード管理]

  • 集中型クラウドデプロイメントレジストリの生成:効率的なトラッキングと管理のために、すべてのクラウドワークロードおよびデプロイメントの包括的なインベントリを維持する
  • 複数のデプロイメントを利用した組織階層の定義:セキュリティおよび管理の制御の向上のために組織ユニットを反映するクラウド環境を構築する
  • 新たなデプロイメント生成のための低摩擦プロセスのサポート:運用効率性を妨げることなくセキュリティポリシーの遵守を保証するためにプロセスを簡素化する

[仮想マシンセキュリティ]

  • 安全なベースVMイメージの強制:集すべてのデプロイメント向けに、中管理でバージョン化された、不変のベースイメージを利用する
  • イメージファクトリーの実装:一貫性とセキュリティを保証するために、VMイメージの生成、テスト、デプロイメントを自動化する
  • VMイメージの脆弱性スキャン:セキュリティリスクを低減するために、定期的にスキャンし、VMイメージをアップデートする
  • 短期間稼働のVMの採用:長期間稼働のインスタンスに関連するリスクを低減するために、不変のインフラストラクチャと一時的なVMを利用する
  • 構成管理とIaC(Infrastructure as Code)の利用:望ましい状態を維持し、構成ドリフトを防止する

・ホストベースのファイアウォールとSSHハードニングの実装:ネットワークアクセスを制御し、VMインスタンス上のSSH構成をセキュアにする

[コンテナオーケストレーションセキュリティ]

  • オーケストレーション向けのCSPサービス利用:セキュリティ強化のためにKubernetes-as-a-Serviceのようなマネージドサービスを有効活用する
  • オーケストレーションサービスのハードニング:不必要な機能を無効化し、最小特権アクセスを保証して、ネットワークポリシーおよびファイアウォールを実装する
  • 定期的なパッチ当てとアップデート:コンテナ、ホスト、オーケストレーションプラットフォーム向けパッチ管理の自動化
  • セキュリティポリシーの定義と強制:Kubernetes Security Policy、PodSecurityPolicy(注:Kubernetes 1.25では削除)、NetworkPolicyのようなツールを利用する
  • セキュリティベンチマークとツールの有効活用:Kubernetesの安全な構成を保証するために、CISベンチマークをフォローする
  • クラスターのホストとストレージの保護:ホストOSをハードニングし、保存時および転送時のデータの暗号化を適用して、アクセス制御リスト(ACL)を利用する

[モニタリングと評価]

  • CSPMツールの有効活用:クラウドセキュリティポスチャー管理(CSPM)ツールを利用して、クラウドセキュリティポスチャーを継続的にモニタリングする
  • 継続的モニタリングの実装:ワークロードの活動を追跡し、潜在的なセキュリティインシデントを迅速に検知するために、リアルタイムモニタリングツールを利用する
  • SCAツールの利用:依存性を管理し、脆弱性を早期に特定するために、ソフトウェア構成分析(SCA)ツールをCI/CDパイプラインに統合する
  • SBOMの生成と維持:透明性、セキュリティ対応、規制遵守を強化するために、すべてのワークロード向けにソフトウェア部品表(SBOM)を生成する
  • エンドポイント検知・対応(EDR)エージェント:ランタイムモニタリングを実行し、脆弱性評価をサポートする
  • セキュリティ情報・イベント管理(SIEM):リアルタイムのモニタリングとレポーティングを提供する

[トレーニングと意識]

  • 定期的なセキュリティ演習の実行:チームがリアルワールドインシデントの準備をするために、シナリオベースの演習や机上訓練を実行する
  • 安全文化アプローチの推奨:セキュリティインシデントに関して過度の責任を負わせることなく、全体的な向上と説明責任に焦点を当てる

[PaaSセキュリティ]

  • 定期的なセキュリティ監査:潜在的脅威を特定し低減するために、脆弱性評価を実行する
  • 包括的なロギングとモニタリング:疑いのある行動を検知して対応する
  • 最小特権の原則:ユーザーやサービスに必要最小限のアクセスレベルを付与する
  • 多要素認証(MFA):MFAでアクセス制御を強化する
  • 定期的なアクセスレビュー:適正なアクセスレベルを保証するために、定期的に、アクセス許可を再評価する

[サーバーレス/FaaS(Function as a Service)セキュリティ]

  • サードパーティサービスとAPIの点検:不正な構成やデータ漏えいを回避するために、それらがセキュアで信頼できることを保証する
  • 脆弱な依存性の管理:脆弱性や悪意のあるコードに関して、外部ライブラリを定期的にアップデートし、チェックする
  •  設定ミスの修正:セキュリティ設定が機能の展開およびアクセスを適切に制限していることを保証する
  • 機能に関するアイデンティティ/アクセス管理(IAM)特権の制限:不正アクセスやデータ漏えいのリスクを低減するために、必要最小限の許可を付与する
  • インターネットへの直接アクセスの制御:機能が直接インターネットにアクセスすることを防止するために、ネットワークセグメンテーションとACLを実装する

[AI低減戦略]

  • データセキュリティ:データを保護するために、暗号化、差分プライバシー、セキュアなマルチパーティ計算を利用する
  • モデルセキュリティ:敵対的な攻撃に対してモデルをハードニングし、堅牢なトレーニング手法を利用し、盗難防止のために固有識別子を組み込む
  • インフラストラクチャセキュリティ:割当・レート制限を実装し、クラウドサービスに関するベストプラクティスをフォローする
  • サプライチェーンセキュリティ:サイバーセキュリティポリシーを定義し、定期的にサードパーティの依存性を監査し、信頼されたリソースを利用する

特に、サーバーレス/FaaSセキュリティについてみると、厳格なアイデンティティ/アクセス管理(IAM)に始まるように、セキュリティへの集中的なアプローチが求められる。不正アクセスに対するAPIのエンドポイントセキュリティを強化し、高度な監視下で秘密を管理することが暴露を防止する鍵になるとしている。

後編では、CSAガイダンスV5の中でマイクロサービスのセキュリティに関連が深いアプリケーションセキュリティの新技術動向について概説する。

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

コンテナ/マイクロサービス/サーバーレスセキュリティとDevSecOps(組織編) (後編)

クラウドセキュリティアライアンス(CSA)では、旧アプリケーションコンテナ/マイクロサービスWGが、クラウドネイティブなコンテナ/マイクロサービスのセキュリティから、CI/CDパイプラインの自動化、DevSecOpsの発展に焦点を当てる一方、旧DevSecOps WGが、DevSecOpsによるアプリケーションの迅速なデリバリーとビジネス価値の創出(=プラットフォームエンジニアリング)をめざすべく、AIに代表される新技術の活用に着目した活動を行っている。

コンテナ/マイクロサービスのセキュリティからDevSecOpsへの発展

旧CSAアプリケーションコンテナ/マイクロサービスWGは、米国立標準技術研究所(NIST)の「SP 800-180(Draft): NIST マイクロサービス、アプリケーションコンテナ、システム仮想マシンの定義」(2016年2月)(https://csrc.nist.gov/pubs/sp/800/180/ipd)より、以下のような定義に準拠して各文書を作成してきた。

  • アプリケーションコンテナ:共有OS上で稼働するアプリケーションまたはそのコンポーネントとしてパッケージ化し、稼働するように設計された構成物
  • マイクロサービス:アプリケーション・コンポーネントのアーキテクチャを、疎結合のパターンに分解した結果生まれる基本的要素であり、標準的な通信プロトコルや明確に定義された API を利用して相互に通信する自己充足型サービスを構成し、いかなるベンダー、製品、技術からも独立している

CSAの「安全なアプリケーションコンテナとマイクロサービスにおける課題」(2019年7月16日)(https://cloudsecurityalliance.org/artifacts/challenges-in-securing-application-containers-and-microservices)では、「NIST SP 800-160 システムセキュリティエンジニアリング:信頼された安全なシステムのエンジニアリングにおける分野横断的なアプローチのための考慮事項」(最新版:第1巻改訂第1版(2022年11月16日)(https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final))を参照しながら、以下の通り、「開発者」、「運用者」、「アーキテクト」の観点を設定している。

  • 開発者:クラウドサービス開発者は、クラウドサービス実装の設計、開発、検証、維持に責任があるようなクラウドサービスパートナーの副次的役割である。これには、既存のサービス実装からのサービス実装の構想も含めることができる。
  • 運用者:ITサービスをデプロイして管理する一連のプロセスに責任を有する個人または組織。運用者は、ネットワークインフラストラクチャ、サーバーとデバイスの管理、コンピューター運用、ITインフラストラクチャライブラリ(ITIL)管理、ヘルプデスクサービスなど、内部および外部の顧客に対するアプリケーションのデプロイをサポートするようなインフラストラクチャおよび運用環境の円滑な機能を保証する。
  • アーキテクト(マイクロサービス):戦略的設計の推奨事項に責任のある個人または組織。アーキテクトは、クラウド、コンテナ、マイクロサービスのコンポーネントに関する知識をビジネス課題に適用して、ビジネスの戦略的ニーズを満たす最善のアーキテクチャを決定する。加えて、ソリューションロードマップを構築・維持し、効率的で効果的なソリューションの実装を保証するために、開発者や運用者と協働しながら採用を監督する。

その上で、信頼性のある安全なシステムのエンジニアリングにおいて、アプリケーションコンテナやマイクロサービスのセキュリティに取組む際の課題を特定している。

CSAの「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」(2019年7月26日)(日本語訳版:https://cloudsecurityalliance.org/artifacts/best-practices-for-implementing-a-secure-application-container-architecture-japanese-translation)では、開発者および運用者の観点から、アプリケーションコンテナを安全にするための課題として、以下の17項目を挙げている。

  1. 環境全体のコードプロモーション
  2. ホストをセキュアにする
  3. プラットフォーム/ホストからのコンテナ継続性監視
  4. コンテナネットワーク – ホストとコンテナ間の通信
  5. コンテナネットワーク – コンテナ間通信
  6. イメージの完全性とセキュリティレベルの検証
  7. コンテナのフォレンジック
  8. コンテナによるトラストチェーン
  9. コンテナのボリューム管理
  10. コンテナのシークレット管理
  11. プラットフォーム管理 -ライフサイクルイベント通知
  12. プラットフォーム管理 – リソース要求
  13. プラットフォーム管理 – コンテナリソース管理
  14. コンテナ管理 – コンテナリソースのスケーリング
  15. コンテナ管理 – データのバックアップとレプリケーション
  16. コンテナ管理 – CMP間のコンテナのホスト変更
  17. コンテナの暗号化

この文書では、特に開発者、運用者の双方が関係する課題およびその低減策として、以下を挙げている。

5. コンテナネットワーク – コンテナ間通信
(低減策)アプリケーションは、安全なネットワーク通信プロトコルを使用する必要がある
6. イメージの完全性とセキュリティレベルの検証
(低減策)開発者は開発プロセスの一部として脆弱性スキャンツールを使用する必要がある
8. コンテナによるトラストチェーン
(低減策)開発者はイメージのビルドプロセスの一部としてイメージに署名し、イメージを使用開始前に検証すべきである
開発者は開発プロセスの一環として脆弱性スキャンツールを使用すべきである
17. コンテナの暗号化
(低減策)開発者と運用者は標準的な、一般的に利用されている認証システムを採用するべきである

このようにアプリケーションコンテナが、従来のIaaS/PaaS/SaaSに代表されるクラウドサービスと異なるのは、アプリケーションの開発とデプロイの自動化を実現するために、開発者チーム(Dev)と運用者チーム(Ops)の間の協力やコミュニケーションの強化が必要不可欠となる点である。

CSAの「クラウドコンピューティングのためのセキュリティガイダンス v4.0」日本語版1.1(2018年7月24日)(https://cloudsecurityalliance.jp/j-docs/CSA_Guidance_V4.0_J_V1.1_20180724.pdf)では、「Domain 8:仮想化とコンテナ技術」において、DevOpsに関して以下のように説明している。

  • アプリケーションの開発とデプロイを自動化することにフォーカスした、アプリケーション開発の新しい方法論であり考え方である
  • 開発チームと運用チームの間の協力とコミュニケーションを改善してより深く結びつけることを意味し、特にアプリケーションのデプロイとインフラストラクチャの運用の自動化に焦点を当てている
  • コード堅牢化、変更管理、本番アプリケーションのセキュリティを改善するだけでなくセキュリティ運用全般をも強化してくれる

そのうえで、DevOpsのセキュリティへの波及効果/長所として、以下のような点を挙げている。

  • 標準化:DevOps では、本番に組み込まれるものはすべて、承認済みのコードと設定用テンプレートに基づき、継続的インテグレーション/継続的デプロイ(CI/CD)パイプラインによって生み出される。開発、テスト、本番(のコード)はすべて完全に 同一のソースファイルから派生しており、周知となっている優れた標準からの逸脱を防いでいる。
  • 自動化されたテスト:広範な種類のセキュリティテストは、必要に応じて補助的に手動テストを加えることで、CI/CD パイプラインに組み込むことが可能である。
  • 不可変性(immutable):CI/CD パイプラインは、素早く確実に、仮想マシンやコンテナ、インフラストラクチャスタックのマスターイメージを生成する。これにより配備の自動化と不可変(immutable)なインフラストラクチャを実現する。
  • 監査と変更管理の改善:CI/CD パイプラインはソースファイルにある 1 文字の変更に至るまでの全てを追跡調査できる。バージョン管理リポジトリに格納され たアプリケーションスタック(インフラストラクチャを含む)の全履歴と共に、その変更は変更を行った人物と紐づけられる
  • SecDevOps/DevSecOps とRugged DevOps:SecDevOps/DevSecOps は セキュリティ運用を改善するために DevOps の自動化技術を使う。Rugged DevOps はアプリケーション開発過程にセキュリティテスティングを組み入れることを意味し、より強固で、よりセキュアで、より障害耐性の高いアプリケーションを生み出す。

このように、コンテナ/マイクロサービスを支えるCI/CDパイプラインをベースに、アプリケーションのデプロイとインフラストラクチャ運用の自動化をめざす中で、DevOpsからDevSecOpsへと進化していった。

CSAにおける再帰的セキュリティからDevSecOpsへの展開

他方、CSAの旧アプリケーションコンテナ/マイクロサービスWG と並行して、旧 DevSecOps WGは、2019年8月1日、「再帰的セキュリティを通じた情報セキュリティ管理」を公開している(https://cloudsecurityalliance.org/artifacts/information-security-management-through-reflexive-security )。その中で、「再帰的セキュリティ」について、組織のセキュリティのスタンスおよび配布物を保護するために必要な、セキュリティ、開発、運用の間の相互関係に基づいた、新たなセキュリティ管理手法と定義している。

その上で、DevOpsについて、集団的コラボレーションのような開発のベストプラクティスをインフラストラクチャの運用に適用させるプラクティスであり、特にクラウド環境における開発・運用チームの効率性にポジティブなインパクトを示してきたとしている。その採用を強化するためには、情報セキュリティ自体へのインパクトを考慮し、情報セキュリティ管理領域へのプラクティスの適用に目を向ける必要があるとしている。

その直後の2019年8月7日、旧DevSecOps WGは、「DevSecOpsの6つの柱:セキュリティ、開発、運⽤の統合による再帰的セキュリティの実現」を公開している(原版:https://cloudsecurityalliance.org/artifacts/six-pillars-of-devsecops)(日本語訳版:https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/11/The-Six-Pillars-of-DevSecOps-Achieving-Reflexive-Security-Through-en_us-ja.pdf)。

この文書は、ソフトウェアの開発と公開における複雑さを軽減し、既知の信頼できるコンポーネントとサービスのみを使⽤するようにし、開発⼿法に直接統合されたセキュリティリソース(⾃動化されたものと⼈の⼿によるものの両⽅)をソフトウェア開発チームに提供し、セキュリティが⼗分に確保され、監視された開発環境を使⽤し、最終的に、設計どおりに、設計された機能のみを備えた最終製品を提供することを目標としている。

DevOpsは、集団的コラボレーションなどの開発のベストプラクティスをインフラストラクチャ運⽤に適⽤するプラクティスであり、特にクラウド環境において、今⽇の開発および運⽤チームの効率にプラスな影響を与えることが⽰されている。旧DevSecOps WGは、ISO/IEC 27000 ファミリー規格および前述の「再帰的セキュリティを通じた情報セキュリティ管理」を参照しながら、以下の通り、DevSecOps を実装し組織に統合するために不可⽋な、DevSecOps の6つの重点分野を定義している。

[第1の柱:集団的責任]

DevOpsにセキュリティを組み込む際の大きな課題の1つが、ソフトウェアセキュリティに関する組織のマインドセットや、アイデア、習慣、行動の変更である。セキュリティのDevOps組織への導入により、セキュリティは、他の誰かの責任としてみなすことができなくなっている。それは、誰か他の業務が完了した時のみに取組むべき補足事項と考えるべきでない。加えて、セキュリティは、ビジネス目標から切り離し、区別して見ることができない。最後に、セキュリティは、いくらか一時的なもので、進化や貢献が評価できない。

組織のセキュリティのスタンスに関して、誰もが責任を有する。CSO(クラウドセキュリティオフィサー)は、組織内の情報セキュリティに関して、リーダーおよび羊飼いの役割を果たすが、個々人は、自身のセキュリティ責任を有しており、組織のセキュリティのスタンスに対する自身の貢献を認識しなければならない。エッジのユーザーや開発者は、単に”セキュリティの認識がある”のではなく、防御の第一線にいる。これが再帰的セキュリティフレームワークの「集団的責任」に対応している。

[第2の柱:コラボレーションと統合]

開発、運⽤、セキュリティの各分野において、ソフトウェア業界には膨⼤なスキル(知識)と⼈材(リソース)のギャップが存在する。セキュリティの導⼊に関して組織全体が協⼒しなければ、成功は限られたものになる。セキュリティは、対⽴ではなく協⼒によってのみ達成できる。すべての機能チームのメンバーが潜在的な異常を報告できるようにするためには、セキュリティを意識した協⼒的な⽂化が必要です。⼈的要因はしばしば最も弱いリンクであり、実際に、セキュリティインシデントのほとんどは、単純なヒューマンエラーによって引き起こされることを覚える必要がある。これが「再帰的セキュリティ」のフレームワークの「協⼒と統合する」に対応している。

[第3の柱:実践的な実装]

DevSecOpsでは、ポイントソリューションが数多く提供されている。組織は、ソフトウェアライフサイクルの中でアプリケーションセキュリティを実装するために、さまざまなツールやソリューションを選択できる。ソフトウェアライフサイクルは、構造、プロセス、全体的な成熟度においてそれぞれ異なるため、DevSecOpsを実装するための万能なツールは存在しない。組織はしばしば、導⼊が難しく、運⽤が困難で、結局は真のセキュリティリスクの軽減に役⽴つ、実⽤的な洞察を提供しないツールやポイントソリューションの調達に終始する。

組織は、ソフトウェアのライフサイクル、組織⾃⾝のセキュリティのニーズ、そして求める将来の状態を総合的に捉え、⾼度な統合性を提供するプラットフォームソリューションを選択する必要がある。デジタル社会における安全、プライバシー、および信頼を確保するために、アプリケーション開発に焦点を当てたフレームワークにとらわれない「デジタルセキュリティとプライバシーモデル」を使⽤することで、組織はDevOpsにおけるセキュリティに実⽤的な⽅法でアプローチできる。このモデルは、すべての利害関係者(開発、運⽤、セキュリティ)を、セキュリティが、アプリケーションとアプリケーションを⽣み出すソフトウェアライフサイクルに組み込まれる形で組み込まれるという、現状では満た
されていないニーズを満たすものである。これが、「再帰的セキュリティ」の枠組みにおける「実践的な実装」に対応している。

[第4の柱:コンプライアンスと開発の橋渡し]

リスクに関連した要求事項を、時間の経過に従って容易に評価できるセキュリティ要求事項に変換することは難しい。セキュリティチームがリスクベースの⼿法をサポートするために要件を作成するとしても、コンプライアンス要件はDevOpsや製品要件にうまく変換されていない。逆に、技術的なコントロールが実装されていても、セキュリティ要件が満たされているという証拠を得ることは容易でない。

ソフトウェア開発のパラダイムとプラクティスの急速な進化を考えると、コンプライアンスとアジャイルソフトウェア開発はもはや同じ⽴場に置くことができない。規制・コンプライアンス部⾨は、その各プロセスの実⾏を実際に監査することよりも、プロセスが存在することを証明することに関⼼がある。⼀⽅で、ほとんどのDevOpsチームは、証明はコードの中にあり、プロセスの⽂書化の中にはないと考えている。

コンプライアンスと開発の間のこのギャップに対処する鍵は、適⽤可能なコントロールを特定し、それを適切なソフトウェア対策に変換し、ソフトウェアライフサイクル内の変曲点を特定し、そこでこれらのコントロールを⾃動化して測定することにより、リスク軽減の質を向上させ、その結果、コンプライアンスを改善することである。これが、「再帰的セキュリティ」の枠組みにおける「整列と橋渡し」に対応する。

[第5の柱:⾃動化]

最⼩限のコストで迅速にセキュアな配備を実現するためのソフトウェア開発⼿法を妨げている課題のいくつかは、⼿作業による⾏き当たりばったりのコーディング、テスト、デプロイ、およびパッチの適⽤である。

⾃動化された品質チェックがなければ、⼿作業によるコーディングは容易に、⼿直しが必要なパフォーマンスの低い、セキュアでないソフトウェアになる。さらに、⼿作業やタイミングの悪いテストでは、デプロイ前に脆弱性が特定される可能性を低くする。⼿作業によるデプロイとパッチの適⽤は、セキュアでないソフトウェアを本番環境にリリースする可能性がある。

⾃動化されたセキュリティ対策は、⼿作業によるプロセスを減らし、効率化して、⼿戻りを減らすことができるため、プロセス効率の中核となる。ソフトウェアの品質は、テスト/フィードバックの徹底性、適時性、および頻度を改善することによって向上できる。⾃動化できるプロセスは⾃動化し、⾃動化できないプロセスは可能な限り⾃動化するか、廃⽌を検討すべきである。⾃動化されたセキュリティチェックは、ビルドの遅延や失敗といった新たな課題を引き起こす可能性があるが、これらは通常、ワークフローの改善や半⾃動化アプローチで対処できる。ソフトウェア開発には、「同じことを3回やったら、そろそろプログラミングの時期だ」という格⾔があり、これは、再帰的セキュリティに正⾯から当てはまる。これが、再帰的セキュリティの枠組みにおける「⾃動化」に対応する。

[第6の柱:測定、監視、報告および⾏動]

「測定できない(あるいは測定しない)ものは管理できない」という格⾔は、DevSecOpsの実装と保守によく当てはまる。⼀般的なDevSecOpsイニシアチブは、スコープと複雑さにもよるが、実装に数ヶ⽉から数年を要する。実⾏可能なメトリクスがなければ、進捗を評価することはできず、失敗をタイムリーに発⾒することもできない。

DevSecOps環境で監視すべき最も重要なメトリクスには、デプロイメントの頻度、脆弱性パッチの適⽤時間、⾃動的にテストされるコードの割合、アプリケーションごとの⾃動テストがある。DevSecOpsを成功させるためには、ソフトウェア開発中だけでなく、デリバリー後の結果も、適切な⼈々によって適切なタイミングで(継続的に)測定、監視、報告、および対処される必要がある。これが、再帰的セキュリティのフレームワークの枠組みにおける「測定と改善」に対応する。

その後、旧DevSecOps WGは、以下の通り、個々の6領域に関する成果物を公開している。

この旧DevSecOps WGと前述の旧アプリケーションコンテナ/マイクロサービスWGが統合してできたのが、現在のCSA DevSecOps WGである。

なお昨今、先進的なテクノロジーを活用したプラットフォームにより、アプリケーションのより迅速なデリバリーとビジネス価値の創出を可能にする革新的な手法として、「プラットフォームエンジニアリング」への関心が高まりつつあり、ジェネレーティブAI(生成AI)の有効活用領域としても注目されている。

現在、CSA DevSecOps WGでは、機械学習モデルをビジネスに適用したMLOps関連ドキュメントの作成準備を行っている。この領域では、CSA AI組織的責任WGが、2024年5月5日に「AIの組織的責任 – コアセキュリティ責任」(https://cloudsecurityalliance.org/artifacts/ai-organizational-responsibilities-core-security-responsibilities)と第する文書を公表しており、WGの枠を越えた連携活動を展開する予定である。

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

コンテナ/マイクロサービス/サーバーレスセキュリティとDevSecOps(組織編) (前編)

クラウドセキュリティアライアンス(CSA)ジャパンの関西支部とDevSecOps/サーバーレスWGは、2019年から2020年までの間、以下のようなワークショップを開催してきた。

  • 2019年7月16日:「アプリケーションコンテナ/マイクロサービスのセキュリティ概説」
  • 2019年9月17日:「エッジ/フォグコンピューティング環境におけるコンテナ/マイクロサービスのメリットとリスク」
  • 2019年11月12日:「北欧のリビングラボから俯瞰するスマートシティICTの現状と課題」
  • 2020年1月10日:「世界のコンテナ/マイクロサービス技術動向から俯瞰する関西の2025年」

現在、2025年大阪・関西万博開催に向けた準備が急ピッチで進む中、CSA関西支部およびDevSecOps/サーバーレスWGは、これらクラウドネイティブ技術の有効活用および安定的なDevSecOps体制の構築・運用支援に焦点を当てた情報発信および公開ワークショップを行う計画である。今回は、コロナ禍以降のアプリケーションコンテナ/マイクロサービス/サーバーレスに係るセキュリティ動向を概観する。

コロナ禍の保健医療分野で拡大したクラウドネイティブアーキテクチャ

コロナ禍の間に、コンテナ/マイクロサービス/サーバーレスに代表されるクラウドネイティブアーキテクチャが積極的に導入された事例として、欧州連合(EU)の新型コロナウイルス感染症(COVID-19)接触追跡アプリケーション越境連携ゲートウェイサービスがある。EU傘下のeヘルスネットワークが2020年6月16日に公表した技術仕様文書では、コンテナプラットフォーム(例:KubernetesベースのOpenShift)、REST API(例:Node.jsとExpress)、分散NoSQLデータベース(例:MongoDB)、ロードバランサー(例:Docker上のHAProxy)、Webサーバ(例:Docker上のNginx)から構成されるデプロイを例示している(https://health.ec.europa.eu/publications/ehealth-network-guidelines-eu-member-states-and-european-commission-interoperability-specifications_en)。

また、EUが、2021年6月1日に正式運用を開始した域内共通の「EUデジタルCOVID証明書」の技術仕様書においても、DockerやKubernetesなど、コンテナプラットフォームによるデプロイが例示されている(https://health.ec.europa.eu/document/download/c0a07892-a01c-4bc8-8e9f-1e91d9597d17_en)。さらに欧州委員会は、2023年6月5日、世界保健機関(WHO)と共同で、グローバルモビリティを推進し、パンデミックなど現在および将来の健康脅威に対する世界中の市民の保護を支援するために、「WHOグローバルデジタルヘルス認証ネットワーク(GDHCN)」を発足させることを発表した(https://www.who.int/news/item/05-06-2023-the-european-commission-and-who-launch-landmark-digital-health-initiative-to-strengthen-global-health-security)。直後の同年7月1日には、WHOが、GDHCN向けに、EUのCOVIDデジタル証明書システムを取り入れることを表明している(https://commission.europa.eu/strategy-and-policy/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-covid-certificate_en#timeline)。

GDHCNは、医療機関の間や国境を越えて証明可能な保健医療文書のポータビリティを実現するグローバルなデジタル公共インフラストラクチャであり、2024年5月時点で、75カ国以上がネットワークに参画している、COVID-19パンデミック期間中のワクチン接種証明書の検証目的で生まれたGDHCNは、WHOを事務局として、以下のような領域にユースケースを拡大する方針である。

  • 小児の予防接種記録
  • 国際的な患者サマリ
  • ワクチン接種または定期補充療法の国際的証明
  • 保健医療従事者の資格情報(免許、登録および教育)
  • 電子処方せん
  • 越境遠隔診療
  • 健康保険証

GDHCNは、以下のようなコンポーネントを提供している。

  • 保健医療文書向けのデータ標準規格(例.LH7-FHIR)
  • デジタル保健医療文書の由来を証明するために利用するコードの共有向けの公開鍵インフラストラクチャ
  • 異なるシステム間での互換を可能にするような情報を有するナレッジライブラリ

なおWHOは、EUと同様に、オープンソースソフトウェアベースの概念を採用し、GitHubなどのオープンコミュニティを通じた活動を積極的に支援している(https://github.com/WorldHealthOrganization)。

ゲノムデータ研究でも浸透するクラウドネイティブアーキテクチャ

オープンソースソフトウェアベースのクラウドネイティブアーキテクチャを活用する動きは、ゲノムデータを取扱うバイオバンクの間でも広がりつつある。

たとえば欧州では、2022年までにEU域内で少なくとも100万人のシーケンスゲノムにアクセス可能にするという、EU加盟国による2018年宣言の実現をめざす組織として、2018年4月10日に「1+MGイニシアチブ」が創設された(https://digital-strategy.ec.europa.eu/en/news/eu-countries-will-cooperate-linking-genomic-databases-across-borders)。1+MGイニシアチブでは、EUの2014年~2020年研究開発促進プログラムである「ホライズン2020」の一環として、「B1MG(Beyond 1 Million Genomes)」プロジェクトが実施された(https://b1mg-project.eu/)。その後2022年より、EUのデジタルヨーロッパプログラムの支援金を受けた「欧州ゲノムデータインフラストラクチャ(GDI)」が進行中である(https://gdi.onemilliongenomes.eu/)。

GDIは、2023年6月26日、B1MGプロジェクトからの希少疾患およびがんの概念実証(PoC)をベースに、「GDIスターターキット」をリリースした(https://gdi.onemilliongenomes.eu/news/gdi-starter-kit)。このツールは、全ての国に、国境を越えて合成ゲノムデータおよび表現型データにアクセスするための技術的ケーパビリティを付与することを目的としており、GDIが共同開発したソフトウェアアプリケーションおよびコンポーネント群をソリューションパッケージとして提供している。ここでも、Dockerに代表されるクラウドネイティブなオープンソースプラットフォームが採用されている。GDIもープンソースソフトウェアベースの概念を採用し、GitHubなどのオープンコミュニティを通じた活動を積極的に支援している(https://github.com/GenomicDataInfrastructure)。

従来のバイオバンクは、クローズドなオンプレミス環境を前提とする境界型防御に依存したセキュリティ管理策をとってきた。これに対して、クラウドネイティブアーキテクチャやオープンソースソフトウェアをベースとする標準化されたプラットフォームが続々と登場しており、責任共有モデルを前提としたマルチステークホルダー型のセキュリティ管理体制へのシフトが求められつつある。

ハードウェア駆動型生成AI向けマイクロサービスの台頭

最近、コンテナを組合せたマイクロサービスの開発・提供に積極的に取り組んでいるのが、半導体業界である。たとえばNVIDIAは、2024年3月18日、独自のAIモデルと業界標準のアプリケーションプログラミングインタフェース(API)を装備したワークフローなど、クラウドネイティブアプリケーションの構築・デプロイ向けのビルディングブロックとして機能する、医療向け生成AI関連マイクロサービス群を発表している(https://nvidianews.nvidia.com/news/healthcare-generative-ai-microservices)。

元々、NVIDIAは、グラフィックス処理装置(GPU)の利点を生かしたコンテナ技術(Docker、Podman、Kubernetesなど)の開発・実装に積極的であり、開発者向けにコンテナツールキットを提供してきた(https://github.com/NVIDIA/nvidia-container-toolkit/)。NDIVIAは、今回発表したマイクロサービス群を、先進的画像処理や自然言語処理、デジタルバイオロジーの生成・予測・シミュレーションなどに提供するとしている。加えて、ドラッグディスカバリー、医用画像処理、ゲノム分析向けの医療ワークフローを加速させるために、ソフトウェア開発キット・ツールを、ソフトウェアライブラリのマイクロサービスとしてアクセスできるようにするとしている。

世界の主要半導体メーカーは、5Gネットワークやエッジコンピューティングなどの領域向けに、ハードウェア対応型セキュリティ機能の開発・実装を進めている。そのような流れに合わせて、国立標準技術研究所(NIST)も、ハードウェア対応型セキュリティにフォーカスしたNISTIR 8320シリーズのドキュメント作成・公開を行っている。参考までに現在、NISTIR 8320シリーズとして、以下のような文書が公表されている。

  • 「NIST IR 8320 ハードウェア対応型セキュリティ: クラウド・エッジコンピューティングのユースケース向けプラットフォームセキュリティの階層型アプローチ実現」(2022年5月4日) (https://csrc.nist.gov/pubs/ir/8320/final)
  • 「NIST IR 8320A ハードウェア対応型セキュリティ:コンテナプラットフォームのセキュリティプロトタイプ」(2021年6月17日)
    (https://csrc.nist.gov/pubs/ir/8320/a/final)
  • 「NIST IR 8320B ハードウェア対応型セキュリティ:信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス」(2022年4月20日)
    (https://csrc.nist.gov/pubs/ir/8320/b/final)
  • 「NIST IR 8320C ハードウェア対応型セキュリティ:マシンアイデンティティ管理と保護(初期公開草案)」(2022年4月20日)
    (https://csrc.nist.gov/pubs/ir/8320/c/ipd)
  • 「NIST IR 8320D ハードウェア対応型セキュリティ:ハードウェアベースの秘密計算(初期公開草案)」(2023年2月23日)
    https://csrc.nist.gov/pubs/ir/8320/d/ipd

コンテナを利用したアプリケーションの設計・開発・運用を行うエンジニアおよびアプリケーションのユーザーは、ハードウェア側で対処可能なセキュリティ管理策について、確認しておく必要がある。

コンテナ/マイクロサービスセキュリティにおけるNISTとCSAの連携

米国では、NISTがコンテナやマイクロサービスのセキュリティに係る標準規格を策定し、CSAの旧アプリケーションコンテナ/マイクロサービスWG(現DevSecOps WG)がベストプラクティス集を提供するという形で連携してきた。参考までに、NISTは、以下のような文書を公表している。

コンテナ/マイクロサービスセキュリティに関連してCSAは、以下のような文書を公表している。

なお現時点で、NISTは、サーバーレスコンピューティングのセキュリティに関連した文書を策定・公表していない。CSAでは、サーバーレスWGが、下記のような文書を公表している。

サーバーレス技術を利用したクラウドサービスには、「AWS Lambda」、「Google Cloud Serverless」、「Azure Functions」などがあり、日本国内でも広く利用されているが、現時点で、公的機関によるサーバーレスセキュリティ関連文書は特に公表されていない。

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

医療/ライフサイエンスにおけるDevSecOps (後編)

前編では、米国食品医薬品局(FDA)が推進するレギュラトリーサイエンスのDevSecOpsを取り上げたが、後編では、クラウドセキュリティアライアンス(CSA)におけるDevSecOpsの取り組みを紹介する。

再帰的セキュリティの視点に立ったDevSecOpsの重要6領域

CSA DevSecOps WGは、2019年8月1日、「再帰的セキュリティを通じた情報セキュリティ管理」を公開した(https://cloudsecurityalliance.org/artifacts/information-security-management-through-reflexive-security )。その中で、「再帰的セキュリティ」について、組織のセキュリティのスタンスおよび配布物を保護するために必要な、セキュリティ、開発、運用の間の相互関係に基づいた、新たなセキュリティ管理手法と定義している。

その上で、DevOpsについて、集団的コラボレーションのような開発のベストプラクティスをインフラストラクチャの運用に適用させるプラクティスであり、特にクラウド環境における開発・運用チームの効率性にポジティブなインパクトを示してきたとしている。その採用を強化するためには、情報セキュリティ自体へのインパクトを考慮し、情報セキュリティ管理領域へのプラクティスの適用に目を向ける必要があるとしている。

その直後の2019年8月7日、CSA DevSecOps WGは、「DevSecOpsの6つの柱:セキュリティ、開発、運⽤の統合による再帰的セキュリティの実現」を公開している(原版:https://cloudsecurityalliance.org/artifacts/six-pillars-of-devsecops)(日本語訳版:https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/11/The-Six-Pillars-of-DevSecOps-Achieving-Reflexive-Security-Through-en_us-ja.pdf

この文書では、ソフトウェアの開発と公開における複雑さを軽減し、既知の信頼できるコンポーネントとサービスのみを使⽤するようにし、開発⼿法に直接統合されたセキュリティリソース(⾃動化されたものと⼈の⼿によるものの両⽅)をソフトウェア開発チームに提供し、セキュリティが⼗分に確保され、監視された開発環境を使⽤し、最終的に、設計どおりに、設計された機能のみを備えた最終製品を提供することを目標としている。

DevOpsは、集団的コラボレーションなどの開発のベストプラクティスをインフラストラクチャ運⽤に適⽤するプラクティスであり、特にクラウド環境において、今⽇の開発および運⽤チームの効率にプラスな影響を与えることが⽰されている。CSA DevSecOps WGは、ISO/IEC 27000 ファミリー規格および前述の「再帰的セキュリティを通じた情報セキュリティ管理」を参照しながら、以下の通り、DevSecOps を実装し組織に統合するために不可⽋な、DevSecOps の6つの重点分野を定義している。

[第1の柱:集団的責任]

DevOpsにセキュリティを組み込む際の大きな課題の1つが、ソフトウェアセキュリティに関する組織のマインドセットや、アイデア、習慣、行動の変更である。セキュリティのDevOps組織への導入により、セキュリティは、他の誰かの責任としてみなすことができなくなっている。それは、誰か他の業務が完了した時のみに取組むべき補足事項と考えるべきでない。加えて、セキュリティは、ビジネス目標から切り離し、区別して見ることができない。最後に、セキュリティは、いくらか一時的なもので、進化や貢献が評価できない。

組織のセキュリティのスタンスに関して、誰もが責任を有する。CSO(クラウドセキュリティオフィサー)は、組織内の情報セキュリティに関して、リーダーおよび羊飼いの役割を果たすが、個々人は、自身のセキュリティ責任を有しており、組織のセキュリティのスタンスに対する自身の貢献を認識しなければならない。エッジのユーザーや開発者は、単に”セキュリティの認識がある”のではなく、防御の第一線にいる。これが再帰的セキュリティフレームワークの「集団的責任」に対応している。

[第2の柱:コラボレーションと統合]

開発、運⽤、セキュリティの各分野において、ソフトウェア業界には膨⼤なスキル(知識)と⼈材(リソース)のギャップが存在する。セキュリティの導⼊に関して組織全体が協⼒しなければ、成功は限られたものになる。セキュリティは、対⽴ではなく協⼒によってのみ達成できる。すべての機能チームのメンバーが潜在的な異常を報告できるようにするためには、セキュリティを意識した協⼒的な⽂化が必要です。⼈的要因はしばしば最も弱いリンクであり、実際に、セキュリティインシデントのほとんどは、単純なヒューマンエラーによって引き起こされることを覚える必要がある。これが「再帰的セキュリティ」のフレームワークの「協⼒と統合する」に対応している。

[第3の柱:実践的な実装]

DevSecOpsでは、ポイントソリューションが数多く提供されている。組織は、ソフトウェアライフサイクルの中でアプリケーションセキュリティを実装するために、さまざまなツールやソリューションを選択できる。ソフトウェアライフサイクルは、構造、プロセス、全体的な成熟度においてそれぞれ異なるため、DevSecOpsを実装するための万能なツールは存在しない。
組織はしばしば、導⼊が難しく、運⽤が困難で、結局は真のセキュリティリスクの軽減に役⽴つ、実⽤的な洞察を提供しないツールやポイントソリューションの調達に終始する。

組織は、ソフトウェアのライフサイクル、組織⾃⾝のセキュリティのニーズ、そして求める将来の状態を総合的に捉え、⾼度な統合性を提供するプラットフォームソリューションを選択する必要がある。デジタル社会における安全、プライバシー、および信頼を確保するために、アプリケーション開発に焦点を当てたフレームワークにとらわれない「デジタルセキュリティとプライバシーモデル」を使⽤することで、組織はDevOpsにおけるセキュリティに実⽤的な⽅法でアプローチできる。このモデルは、すべての利害関係者(開発、運⽤、セキュリティ)を、セキュリティが、アプリケーションとアプリケーションを⽣み出すソフトウェアライフサイクルに組み込まれる形で組み込まれるという、現状では満た
されていないニーズを満たすものである。これが、「再帰的セキュリティ」の枠組みにおける「実践的な実装」に対応している。

[第4の柱:コンプライアンスと開発の橋渡し]

リスクに関連した要求事項を、時間の経過に従って容易に評価できるセキュリティ要求事項に変換することは難しい。セキュリティチームがリスクベースの⼿法をサポートするために要件を作成するとしても、コンプライアンス要件はDevOpsや製品要件にうまく変換されていない。逆に、技術的なコントロールが実装されていても、セキュリティ要件が満たされているという証拠を得ることは容易でない。

ソフトウェア開発のパラダイムとプラクティスの急速な進化を考えると、コンプライアンスとアジャイルソフトウェア開発はもはや同じ⽴場に置くことができない。規制・コンプライアンス部⾨は、その各プロセスの実⾏を実際に監査することよりも、プロセスが存在することを証明することに関⼼がある。⼀⽅で、ほとんどのDevOpsチームは、証明はコードの中にあり、プロセスの⽂書化の中にはないと考えている。

コンプライアンスと開発の間のこのギャップに対処する鍵は、適⽤可能なコントロールを特定し、それを適切なソフトウェア対策に変換し、ソフトウェアライフサイクル内の変曲点を特定し、そこでこれらのコントロールを⾃動化して測定することにより、リスク軽減の質を向上させ、その結果、コンプライアンスを改善することである。これが、「再帰的セキュリティ」の枠組みにおける「整列と橋渡し」に対応する。

[第5の柱:⾃動化]

最⼩限のコストで迅速にセキュアな配備を実現するためのソフトウェア開発⼿法を妨げている課題のいくつかは、⼿作業による⾏き当たりばったりのコーディング、テスト、デプロイ、およびパッチの適⽤である。

⾃動化された品質チェックがなければ、⼿作業によるコーディングは容易に、⼿直しが必要なパフォーマンスの低い、セキュアでないソフトウェアになる。さらに、⼿作業やタイミングの悪いテストでは、デプロイ前に脆弱性が特定される可能性を低くする。⼿作業によるデプロイとパッチの適⽤は、セキュアでないソフトウェアを本番環境にリリースする可能性がある。

⾃動化されたセキュリティ対策は、⼿作業によるプロセスを減らし、効率を⾼め、⼿戻りを減らすことができるため、プロセス効率の中核となる。ソフトウェアの品質は、テスト/フィードバックの徹底性、適時性、および頻度を改善することによって向上できる。⾃動化できるプロセスは⾃動化し、⾃動化できないプロセスは可能な限り⾃動化するか、廃⽌を検討すべきである。⾃動化されたセキュリティチェックは、ビルドの遅延や失敗といった新たな課題を引き起こす可能性があるが、これらは通常、ワークフローの改善や半⾃動化アプローチで対処できる。ソフトウェア開発には、「同じことを3回やったら、そろそろプログラミングの時期だ」という格⾔があり、これは、再帰的セキュリティに正⾯から当てはまる。これが、再帰的セキュリティの枠組みにおける「⾃動化」に対応する。

[第6の柱:測定、監視、報告および⾏動]

「測定できない(あるいは測定しない)ものは管理できない」という格⾔は、DevSecOpsの実装と保守によく当てはまる。⼀般的なDevSecOpsイニシアチブは、スコープと複雑さにもよるが、実装に数ヶ⽉から数年を要する。実⾏可能なメトリクスがなければ、進捗を評価することはできず、失敗をタイムリーに発⾒することもできない。

DevSecOps環境で監視すべき最も重要なメトリクスには、デプロイメントの頻度、脆弱性パッチの適⽤時間、⾃動的にテストされるコードの割合、アプリケーションごとの⾃動テストがある。DevSecOpsを成功させるためには、ソフトウェア開発中だけでなく、デリバリー後の結果も、適切な⼈々によって適切なタイミングで(継続的に)測定、監視、報告、および対処される必要がある。これが、再帰的セキュリティのフレームワークの枠組みにおける「測定と改善」に対応する。

その後、CSA DevSecOps WGは、以下の通り、個々の6領域に関する成果物を公開している。

・「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

アプリケーションセキュリティを起点とするOWASP DevSecOpsガイドライン

他方、医療機器サイバーセキュリティやIoTセキュリティの領域において、CSAと連携してきたOWASPは、アプリケーションセキュリティの観点から、「OWASP DevSecOpsガイドライン」を作成・公表している(https://owasp.org/www-project-devsecops-guideline/)。

このガイドラインは、セキュアなパイプラインを実装し、ベストプラクティスを利用して、このような方法で利用可能なツールを導入する方法について説明している。また、このプロジェクトは、開発プロセスにおけるシフトレフトのセキュリティ文化の促進を支援するものである。重要な目標は、”できるだけ早くセキュリティ課題(バイ・デザインやアプリケーション脆弱性)を検知する”ことである。

そして、DevSecOpsの目的・意図は。必要な安全性を犠牲にすることなく、最大のコンテキストレベルを保持する人々に対して、スピードと拡張性のあるセキュリティの意思決定を安全に提供するという目標を持った”誰もがセキュリティに責任がある”というマインドセットの上に構築されている。

このガイドラインは、以下のような構成になっている。

  • 0 – イントロダクション
    • 0-a – 概要
    • 0-b – 脅威モデリング
  • 1 – コミット前
    • 1-a – 秘密管理
    • 1-b – コードの検査(Linting)
  • 2 – 脆弱性スキャン
    • 2-a – 静的(Static)アプリケーションテスト
    • 2-b – 動的(Dynamic)アプリケーションテスト
    • 2-c – インタラクティブな(Interactive)アプリケーションテスト
    • 2-d – ソフトウェア構成分析
    • 2-e – インフラストラクチャ脆弱性スキャン
    • 2-f – コンテナ脆弱性スキャン
    • 2-g – プライバシー
  • 3 – コンプライアンス監査

OWASPでは、基礎的パイプラインにおいて、以下のようなステップで実装することを考えている。

  • 潜在的な資格情報の漏えいを見つけるためのgitスキャン
  • SAST(静的アプリケーションセキュリティテスト)
  • SCA(ソフトウェア構成分析)
  • IAST(インタラクティブなアプリケーションセキュリティテスト)
  • DAST(動的アプリケーションセキュリティテスト)
  • IaCスキャンニング(構成ミスを見つけるためのTerraform,、HelmChartコードのスキャン)
  • インフラストラクチャスキャンニング
  • コンプライアンスチェック

サプライチェーンセキュリティの視点に立った米国NISTの取り組み

さらに、ソフトウェアのサプライチェーンセキュリティの視点から、DevSecOpsの標準化に取り組んでいるのが、米国立標準技術研究所(NIST)である。NIST傘下の国家サイバーセキュリティセンター・オブ・エクセレンス(NCCoE)は、2022年11月9日、「ソフトウェアサプライチェーンとDevOpsセキュリティプラクティス:DevSecOpsに対するリスクベースのアプローチ」を公開している(https://www.nist.gov/news-events/news/2022/11/software-supply-chain-and-devops-security-practices-implementing-risk-based)。

この文書は、国家サイバーセキュリティセンター・オブ・エクセレンス(NCCoE)のプロジェクトについて記述したものであり、DevSecOpsプラクティス向けに適用されたリスクベースのアプローチや推奨事項の開発および文書化に焦点を当てている。このプロジェクトでは、「DevSecOps」について、セキュリティチームが構築したセキュリティプラクティスを、既存のパイプライン(例.継続的統合/継続的デリバリー[CI/CD])や、開発者が利用し、運用チームが管理する既存のツールチェーンに統合することとしている。NISTのアプローチは、セキュアソフトウェア開発フレームワーク(SSDF)やNISTサイバーセキュリティフレームワークで利用したものと同じである。本プロジェクトは、クラウドネイティブな方法におけるソフトウェアデリバリーの速度や容量を維持し、自動化ツールの利点を活かすことを実現するのに役立てるものだとしている。また、本プロジェクトは、NIST SSDFからのプラクティスやタスクを、DevSecOpsアプローチの一部として実装できる方法を決定するものだとしている。

NISTのこの文書は、以下のような構成になっている。

  • 1 エグゼクティブサマリー
    • 目的
    • スコープ
    • 想定/課題
    • 背景
  • 2 シナリオ
    • シナリオ 1:フリー/オープンソースソフトウェア(FOSS)開発
    • シナリオ 2:クローズドソース・ソフトウェア開発
  • 3 ハイレベルアーキテクチャ
    • コンポーネントリスク
    • 望ましいソフトウェアのケーパビリティ
  • 4 関連する標準規格およびガイダンス
    • セキュリティコントロールマップ
    • 附表A 参考文献
    • 附表B 頭字語と略語

なお、CSAと連携しているMITREや国防総省なども、DevSecOpsに関する文書やガイダンス類を作成しており、参考になる。

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

医療/ライフサイエンスにおけるDevSecOps (前編)

クラウドセキュリティアライアンス(CSA)では、アプリケーションコンテナ/マイクロサービスWGがDevSecOps WGに合流し、最新のクラウドネイティブ環境とDevSecOpsを前提としたソフトウェア開発ライクサイクル(SDLC)におけるベストプラクティスの集積に取り組んでいる。医療/ライフサイエンス領域では、米国食品医薬品局(FDA)が、トータル製品ライフサイクル(TPLC)やDevSecOpsを基盤とするデジタルトランスフォーメーション(DX)施策を展開しており、その影響が医療機器・医薬品の開発・運用を行う企業や医療機関にも及んできた。

トータル製品ライフサイクルを起点とする米国FDAの安全性対策

米国FDA傘下の医療機器・放射線保健センター(CDRH)は、2018年4月16日に公表した「医療機器安全性行動計画:患者の保護と公衆衛生の促進」(https://www.fda.gov/about-fda/cdrh-reports/medical-device-safety-action-plan-protecting-patients-promoting-public-health)の中で、市販前および市販後の専門性、データ、知識や、医療機器の開発・評価・マーケティングの各ステージにおけるすべてのツールを幅広く活用することにより、トータル製品ライフサイクル(TPLC)全体で、消費者や患者、介護者、医療機関が、予防、診断、治療に関する十分な情報を集めて意思決定するために、必要な情報にアクセスできることを保証しなければならないとしている。

またFDAは、「医療機器向けトータル製品ライフサイクル」(https://www.fda.gov/about-fda/cdrh-transparency/total-product-life-cycle-medical-devices)の中で、以下のようなトータル製品ライフサイクル(TPLC)アプローチのメリットを挙げている。

  • CDRHのスタッフに、コミュニケーションを介した機器開発からのホリスティックな視点を提供し、機器の市販前および市販後の意思決定を導くのに役立てる
  • 医療機器の市販前および市販後のレビュー活動における透明性や一貫性を促進して、機器製造業者に対する予測可能で明確な見通しを提供する
  • 市販前および市販後の活動を1つのチームに組み合わせて、FDAが迅速な方法で安全上の課題に対応するのに役立てる
  • 機器のライフサイクルを通じて、機器の安全性やパフォーマンスに関する透明性を保証し、CDRHが優れた内部向けおよび外部向けの顧客サービスを提供することを可能にする
  • 市販前データからの知識を活用することによって、市販後およびコンプライアンスの意思決定を知らしめる
  • 市販前データやコンプライアンス活動からの知識を活用することによって、よりよい情報に基づく市販前医師決定を行うのに役立てる

このような背景から、FDAは、医療機器に関する市販前データと市販後データを統合したトータル製品ライフサイクル(TPLC)データベースを構築し、オープンデータとして公開している(https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tplc.cfm)。TPLCデータベースには、以下のようなデータベースが収載されており、通常、月次で更新されている。

  • 市販前承認(PMA)
  • 人道的使用医療機器免除(HDE)
  • De Novo 分類申請
  • 市販前通知[510(k)]
  • 有害事象(医療機器不具合情報データベース(MAUDE)
  • 医療機器リコール

トータル製品ライフサイクル(TPLC)を活用した医療機器開発促進プログラム

他方、FDAは、トータル製品ライフサイクル(TPLC)アプローチを活用したイノベーション推進活動にも積極的に取り組んでいる。たとえばFDA傘下のCDRHは、2023年10月2日、トータル製品ライフサイクル諮問プログラム(TAP)パイロットおよび参加医療機器について公表した(https://www.fda.gov/medical-devices/how-study-and-market-your-device/total-product-life-cycle-advisory-program-tap)。TAPパイロットは、2023~2027会計年度医療機器ユーザー料金改定(MDUFA V)再認可の一部として、FDAと産業界が合意したコミットメントの1つであり、2023会計年度内に初期フェーズを開始する予定である。

TAPパイロットでは、公衆衛生上、安全で有効な、高品質の医療機器に対して、より迅速な開発とより迅速で幅広い患者のアクセスを奨励するのに役立てることを、長期的なビジョンとしている。FDAは、TAPパイロットを通じて、公衆衛生上必要な革新的医療機器向けに、以下のような戦略的エンゲージメントを提供するとしている。

  • より迅速な市販前の相互作用のために提供することによって、参加者とFDAとの間のエクスペリエンスを向上させる
  • 機器開発およびレビュープロセスを通して、FDAスタッフを含む全参加者のエクスペリエンスを強化する
  • 早期段階における機器開発リスクの特定、評価、低減など、機器開発中の戦略的意思決定の向上を促進する
  • 機器開発の早期段階より、FDAのレビューチーム、参加者、FDA以外のステークホルダー(例. 患者、医療機関、保険者)の間の定期的な、ソリューションに焦点を当てたエンゲージメントを促進する
  • エビデンスの生成に関するよりよい期待の一致、申請品質の向上、市販前レビュープロセスの有効性の向上のために協働する

FDAは、2023会計年度中に心血管系機器室(OHT2)向けの参加受付を開始し、2024会計年度には、神経系・理学療法系機器室(OHT5)向けの参加受付を開始した。2024年4月12日現在、TAPパイロットには、総数43件の医療機器が参加を表明している。FDAは、その後2027会計年度まで、TAPパイロットの対象機器領域を拡大していく予定である。

参考までに、医療機器だけでなく医薬品においても、FDAは、トータル製品ライフサイクルを前提とする安全性対策を講じている。たとえば、FDA傘下の医薬品評価研究センター(CDER)と生物製品評価研究センター(CBER)は、2021年5月11日、「Q12 医薬品ライフサイクルマネジメントにおける技術上・規制上の考慮事項 – 産業界向けガイダンス」(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/q12-technical-and-regulatory-considerations-pharmaceutical-product-lifecycle-management-guidance)を公表している。

”DevOps”から”DevSecOps”へと進化する米国FDAのDX

FDAは、トータル製品ライフサイクル(TPLC)に基づく安全性対策と並行して、ITモダナイゼーションへの取組を推進してきた。たとえば、2019年9月18日に公表した「技術モダナイゼーション行動計画(TMAP)」(https://www.fda.gov/about-fda/reports/fdas-technology-modernization-action-plan)の中で、FDAの公衆衛生ミッションを進歩させるために、コンピュータハードウェア、ソフトウェア、データ、分析など、技術利用のモダナイゼーションに向けた短期的実行計画を示した。この計画は、以下の3要素から構成される。

  • FDAの技術インフラストラクチャのモダナイゼーション
  • 規制のミッションを支援する技術製品を開発するFDAの機能の強化
  • システムを越えた相互運用性を有し、消費者と患者に価値を提供する技術的進歩をけん引するための、ステークホルダーとのコミュニケーションと協働

特に「FDAの技術インフラストラクチャのモダナイゼーション」は、堅牢なインフラストラクチャ、クラウド最前線の計画、明確で効率的な外部データインタフェース、サイバーセキュリティへのフォーカスなど、技術モダナイゼーション計画の最優先課題となっており、以下のような具体的アクションを掲げている。

  • クラウド戦略
  • ビジネス特有のニーズ向けに簡素化されたソフトウェア開発機能(DevOps)
  • アプリケーションプログラミングインタフェース(API)、標準規格およびその他の交換メカニズムやツール
  • データのクリーンナップとクラウド環境への移植
  • as a serviceモデルの継続的採用
  • サイバーセキュリティ・エクセレンスへの継続的な専念
  • 科学計算のエンタープライズIT計画への統合
  • エンタープライズレベルの技術組織である情報管理技術室(OIMT)内およびFDA全体にわたる組織的アラインメント
  • オペレーショナル・エクセレンスと複数年に渡る技術計画
  • 費用抑制と重複排除
  • エンタープライズITガバナンス
  • 適切な場合、レガシーシステムおよびソフトウェアアプリケーションの廃止

さらにFDAは、技術ユースケースの構築に向けて、最新技術ソリューションを生成するための技術”製品”開発ケーパビリティを構築し、情報に基づいて規制上の意思決定を行うために、新たなソリューションを効率的に評価・分類できるようにするとしている。特に、FDAが開発した技術製品は、短中期的なFDA技術ロードマップに必要なケーパビリティを証明し、実現するとともに、以下のような製品開発マインドセットを組込むとしている。

  • 異なるFDAプログラム領域に採用される可能性があるような、重要なビジネスおよびデータの要求事項に取組み、重複を削減することによって、製品に焦点を当てる
  • テスト向けの”最小限の実行可能な製品”の開発
  • ”DevOps”のマインドセットとプラクティスの採用”
  • 速く失敗する”反復と展開に対する意欲
  • FDA環境向けの”プロダクトマーケットフィット”に焦点を当てる;
  • 協働的な文化
  • ユーザーエクスペリエンス、満足度、採択の向上;
  • 短中期的に可能性があるものを紹介する機会

こうして、FDAの技術モダナイゼーション計画を担う製品開発マインドセットとして、”DevOps”の概念が組み込まれた。

さらに、米国大統領行政府が20021年5月12日に発出した「国家サイバーセキュリティに関する大統領令」(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)を受けて、2022年3月20日、FDA傘下のデジタルトランスフォーメーション室(ODT)が公表した「モダナイゼーション・イン・アクション2022」(https://www.fda.gov/news-events/fda-voices/fdas-technology-and-data-modernization-action-2022)では、前述の「技術モダナイゼーション行動計画(TMAP)」の最優先項目として「アジャイルと製品の文化」が示された。

その中で、ゼロトラストモデルや、セキュアなクラウドコンピューティング、多要素認証、暗号化、脅威検知、脆弱性管理およびその他のディフェンス機能の導入を支える標準規格・ベストプラクティスの1つとして明記されたのが、”DevSec”とセキュリティを統合した”DevSecOps” (Development, Security and Operations)である。

このようにFDAが、トータル製品ライフサイクル(TPLC)やDevSecOps、ゼロトラストモデルなどを前提とするデジタルトランスフォーメーション(DX)施策を加速させていくと、デジタル化された当局とのコミュニケーションを日常的に行う医療機器企業や、市販後対策において患者・家族との接点となる医療機関も対応せざるを得ない。

SBOMにおけるトータル製品ライフサイクル(TPLC)とDevSecOpsの融合

ここまで、米国FDAにおけるトータル製品ライフサイクル(TPLC)およびDevSecOpsの展開動向について触れてきたが、両者が融合するツールとして注目されるのが、ソフトウェア部品表(SBOM)である。

たとえば、国際医療機器規制当局フォーラム(IMDRF)が2023年4月13日に公表した「医療機器のサイバーセキュリティのためのソフトウェア部品表の原則及び実践」(https://www.imdrf.org/documents/principles-and-practices-software-bill-materials-medical-device-cybersecurity)では、「1. イントロダクション」の中で、SBOMが、市販前および市販後活動の双方(例. トータル製品ライフサイクル(TPLC))におけるサイバーセキュリティリスクマネジメントを改善するために活用できるリソースだとしている。

また、「SBOM コンポーネントの種類およびツール」の「サードパーティのソフトウェアライブラリー」において、より進んだ手順の例として、既存の開発プラットフォームとDevOp環境の活用を挙げている。特に、自動化ツール/プラグインを、1つまたは複数フェーズの開発パイプライン(DevSecOps)に組み込むことが可能だとしている。また、同じ「SBOM コンポーネントの種類およびツール」の「ファームウェア、組込みソフトウェア、PLC」において、製品ライフサイクル管理ソフトウェアやERPソフトウェアを通してBOMを管理する場合、エクスポート機能を使ってソフトウェアコンポーネントを抽出することが可能である点を指摘している。

なお、クラウドセキュリティアライアンス(CSA)のDevSecOps WGでは、企業組織がDevSecOpsを導入する際に重要な領域として、以下の6つを挙げている。

  1. :集団的責任
  2. :トレーニングおよびプロセスインテグレーション
  3. :実用的な実装
  4. :コンプライアンスと開発の間の架け橋
  5. :自動化
  6. :測定、監視、報告、および行動

これらの概要については、後編で概説する。

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

医療/ライフサイエンスにおけるハードウェア対応型セキュリティ(後編)

後編では、クラウドネイティブ技術を支えるハードウェアセキュリティモジュール(HSM)/鍵管理やハードウェア対応型セキュリティに関連したガイダンス類の概要について紹介する。

クラウドネイティブ技術の実装を推進する米国FDA

2023年9月13日、米国食品医薬品局(FDA)は、「2024~2027会計年度FDA情報技術戦略」(https://www.fda.gov/about-fda/office-digital-transformation/fda-information-technology-strategy-fy-2024-fy-2027)を公表し、以下の6つの戦略目標を掲げた。

  1. コラボレーションの強化
  2. インフラストラクチャの強化
  3. サービスの現代化
  4. データの共有
  5. AIとイノベーションの採用
  6. 人材とリーダーシップの育成

このうち「2. インフラストラクチャの強化」では、以下の4つの目標を掲げている。

  1. 柔軟なインフラストラクチャのオファリング提供
  2. クラウド採用の加速
  3. サービスの可用性の保証
  4. ゼロトラストアプローチの実装

このような医薬品・医療機器行政DXの進展とともに、医療・ライフサイエンス分野でも、ゼロトラスト環境を前提としたアプリケーションコンテナやマイクロサービス、サーバーレス、DevSecOpsに代表されるようなクラウドネイティブ技術の実装が本格化している。セキュリティの領域においても、ソフトウェア主導型の新たなサービスが次々と開発・導入されている。

その一方で、ハードウェアセキュリティモジュール(HSM)やセキュアチップに代表されるような、半導体を軸とするハードウェア対応型セキュリティ技術の開発・導入も進んでいる。特に医療現場の場合、ユーザーインタフェースや業務フローに影響を及ぼす可能性があるアプリケーションソフトウェア層よりも、プラットホームハードウェア層でセキュリティ機能の実装や運用・保守を行った方がメリットのある場合も多い。

米国NISTが推進するハードウェア対応型セキュリティの標準化

このような状況下で、米国立標準技術研究所(NIST)は、クラウドネイティブ技術に係るNIST SP 800-204シリーズと並行して、ハードウェア対応型セキュリティにフォーカスしたNISTIR 8320シリーズのドキュメント作成・公開を行ってきた。。

現在、NISTIR 8320シリーズとして、以下のような文書が公表されている。

  • NIST IR 8320 ハードウェア対応型セキュリティ: クラウド・エッジコンピューティングのユースケース向けプラットフォームセキュリティの階層型アプローチ実現」(2022年5月4日)
  • 「NIST IR 8320A ハードウェア対応型セキュリティ:コンテナプラットフォームのセキュリティプロトタイプ」(2021年6月17日)
  • 「NIST IR 8320B ハードウェア対応型セキュリティ:信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス」(2022年4月20日)
  • 「NIST IR 8320C ハードウェア対応型セキュリティ:マシンアイデンティティ管理と保護(初期公開草案)」(2022年4月20日)

以下では、NIST IR 8320シリーズの各ドキュメントの概要について説明する。

「NIST IR 8320 ハードウェア対応型セキュリティ: クラウド・エッジコンピューティングのユースケース向けプラットフォームセキュリティの階層型アプローチ実現」(2022年5月4日)
(https://csrc.nist.gov/pubs/ir/8320/final)

今日のクラウドデータセンターやエッジコンピューティングにおいて、攻撃対象領域はシフトしており、場合によっては、非常に拡大している。それと同時に、ハッキングが業態化しており、大抵のセキュリティ制御の実装が理路整然としていないか、首尾一貫していない。あらゆるデータセンターやエッジコンピューティングのセキュリティ戦略の基盤は、データやワークロードが実装され、アクセスされるプラットフォームをセキュア化すべきである。物理的プラットフォームは、あらゆる階層型セキュリティアプローチにおける第一の層を表しており、ハイレベルの層のセキュリティ制御が信頼できることを保証するのに役立つような最初の保護を提供する。この文書では、クラウドデータセンターやエッジコンピューティング向けのプラットフォームセキュリティやデータ保護を改善できるようなハードウェア対応型セキュリティの技術や手法を説明している。

NIST IR 8320は、以下のような構成になっており、附属書において、インテル、AMD、Arm、シスコ、IBMの具体的な技術を例示している。

1. 序論
2. ハードウェアプラットフォームセキュリティの概要
3. プラットフォームの完全性の検証
3.1 ハードウェアセキュリティモジュール(HSM)
3.2 チェーン・オブ・トラスト
3.3 サプライチェーン保護
4. ソフトウェアのランタイム保護メカニズム
4.1 リターン指向プログラミング(ROP)とコール/ジャンプ指向プログラミング(COP/JOP)に対する攻撃
4.2 アドレス変換攻撃
4.3 メモリ安全性違反
4.4 サイドチャネル攻撃
5. データ保護と秘密計算
5.1 メモリの分離
5.2 アプリケーションの分離
5.3 VMの分離
5.4 暗号化アクセラレーション
6. 遠隔証明サービス
6.1 プラットフォーム証明
6.2 遠隔高信頼性実行環境(TEE)証明
7. ハードウェア対応型セキュリティを活用したクラウドユースケースのシナリオ
7.1 セキュリティアーキテクチャに対する可視性
7.2 高信頼性プラットフォーム上のワークロード配置
7.3 資産のタグ付けと高信頼性ロケーション
7.4 ワークロードの機密性
7.5 鍵と秘密の保護
8. 次のステップ
参考文献
附属書A – ベンダーに依存しない技術の例
A.1 プラットフォームの完全性の証明
A.1.1 UEFIセキュアブート(SB)
A.2 キーライム
附属書B – インテルの技術の例
B.1 プラットフォームの完全性の証明
B.1.1 チェーン・オブ・トラスト(CoT)
B.1.2 サプライチェーン保護
B.2 ソフトウェアのランタイム保護メカニズム
B.2.1 リターン指向プログラミング(ROP)とコール/ジャンプ指向プログラミング(COP/JOP)に対する攻撃
B.2.2 アドレス変換攻撃
B.3 データ保護と秘密計算
B.3.1 メモリの分離
B.3.2 アプリケーションの分離
B.3.3 VMの分離
B.3.4 暗号化アクセラレーション
B.3.5 技術事例の概要
B.4 遠隔証明サービス
B.4.1 Intel Security Libraries for the Data Center (ISecL-DC)
B.4.2 技術の概要
附属書C – AMDの技術の例
C.1 プラットフォームの完全性の証明
C.1.1 AMD Platform Secure Boot (AMD PSB)
C.2 データ保護と秘密計算
C.2.1 メモリの分離
C.2.2 VMの分離
附属書D – Armの技術の例
D.1 プラットフォームの完全性の証明
D.1.1 Arm TrustZone Trusted Execution Environment (TEE) for Armv8-A
D.1.2 Arm Secure Bootとチェーン・オブ・トラスト(CoT) D.1.3 Platform Security Architecture (PSA) Functional APIs
D.1.4 Platform AbstRaction for SECurity (Parsec)
D.2 ソフトウェアのランタイム保護メカニズム
D.2.1 リターン指向プログラミング(ROP)とコール/ジャンプ指向プログラミング(COP/JOP)に対する攻撃
D.2.2 メモリ安全性違反
D.2.3 サイドチャネル攻撃に対するArmの低減策
D.3 データ保護と秘密計算
D.3.1 Armの秘密計算アーキテクチャ(CCA)
D.3.2 Armの暗号化アクセラレーション
附属書E – シスコの技術の例
E.1 プラットフォームの完全性の証明
E.1.1 シスコプラットフォームのルート・オブ・トラスト
E.1.2 シスコのチェーン・オブ・トラスト(CoT)
E.2 シスコのサプライチェーン保護
E.3 シスコのソフトウェアランタイム保護
E.4 シスコのデータ保護と秘密計算
E.5 シスコの暗号化アクセラレーション
E.6 シスコのセキュリティインフラストラクチャに対する可視性
E.7 シスコの信頼されたプラットフォームへのワークロードの配置
附属書F – IBMの技術の例
F.1 プラットフォームの完全性の証明
F.1.1 ハードウェアセキュリティモジュール(HSM)
F.1.2 IBMのチェーン・オブ・トラスト(CoT)
F.2 ソフトウェアランタイム保護メカニズム
F.2.1 IBMのROPとCOP/JOPに対する攻撃への防御
F.3 データ保護と秘密計算
F.3.1 IBMのメモリ分離技術
F.3.2 IBMのアプリケーション分離技術
F.3.3 IBMのVM分離技術
F.3.4 IBMの暗号化アクセラレーション技術
F.4 遠隔証明サービス
F.4.1 IBMのプラットフォーム証明ツール
F.4.2 IBMの継続的ランタイム証明
附属書G – 頭字語と略語
附属書H – 用語集

「NIST IR 8320A ハードウェア対応型セキュリティ:コンテナプラットフォームのセキュリティプロトタイプ」(2021年6月17日)
(https://csrc.nist.gov/pubs/ir/8320/a/final)

本文書では、マルチテナント型クラウド環境におけるコンテナデプロイメントを保護するためのハードウェア対応セキュリティの技術や手法に基づくアプローチを説明している。その中で、IaaS(Infrastructure as a Service)クラウドコンピューティング技術や、リソースアセットのタグ付けフォームにおける位置情報など、セキュリティの課題を説明した上で、これらの課題に取組むために設計された概念実証の実装(プロトタイプ)を説明している。

NIST IR 8320Aは、以下のような構成になっており、附属書において、インテル、AMI、Kubernetesの具体的な技術を例示している。また、NIST SP800-53改定第5版やNISTサイバーセキュリティフレームワーク第1.1版とのマッピングについても言及しており、これらを介してCSA STAR/CCMとの紐づけも可能になっている。

1. 序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2. プロトタイプの実装
2.1 目的
2.2. 目標
2.2.1 ステージ0:プラットフォームの証明と評価されたワーカーノードの設定
2.2.2 ステージ1:信頼されたワークロードの配置
2.2.3 ステージ2:アセットのタグ付と信頼された位置情報
3. プロトタイピングのステージ0
3.1 ソリューション概要
3.2 ソリューションアーキテクチャ
4. プロトタイピングのステージ1
4.1 ソリューション概要
4.2 ソリューションアーキテクチャ
5. プロトタイピングのステージ2
5.1 ソリューション概要
参考文献
附属書A – ハードウェアのアーキテクチャと前提条件
A.1 ハイレベルの実装アーキテクチャ
A.2 Intel Trusted Execution Technology (Intel TXT)とTrusted Platform Module (TPM)
A.3 証明
附属書B – プラットフォームの実装:AMI TruE
B.1 ソリューションアーキテクチャ
B.2 ハードウェアの記述
B.3 AMI TruEのインストールと構成
B.3.1 AMI TruE Trust Managerのインストール
B.3.2 AMI TruE Attestation Serverのインストール
B.3.3 AMI True向けファイアウォールの構成
B.3.4 デバイスアクセス鍵の構成
B.3.5 Discovery RangeとManageability Rangeの構成
B.4 信頼されたクラウドクラスターのインストールと構成
B.4.1 TruEエージェントの遠隔プロビジョニング
B.4.2 TruEエージェントの手動プロビジョニング
B.5 AMI TruEの利用
B.5.1 AMI TruEを利用した信頼状況のモニタリング
B.5.2 信頼性レポートの生成
B.5.3 AMI TruEを利用したプラットフォームのタグ付け
B.5.4 信頼性イベントアラート通知の受領
B.5.5 救済策のためのAMI TruE利用
附属書C – プラットフォームの実装:Kubernetes
C.1 プロトタイプのアーキテクチャ
C.2 ハードウェアの記述
C.3 Kubernetesのインストールと構成
C.3.1 Kubernetes Controller Nodeの構成
C.3.2 Kubernetes Worker Nodeの構成
C.3.3 Kubernetesのオーケストレーション
附属書D – NIST SP 800-53のセキュリティ制御
附属書E – サイバーセキュリティフレームワークのサブカテゴリーのマッピング
附属書F – 頭字語およびその他の略語

「NIST IR 8320B ハードウェア対応型セキュリティ:信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス」(2022年4月20日)
(https://csrc.nist.gov/pubs/ir/8320/b/final)

本文書では、マルチテナント型クラウド環境におけるコンテナデプロイメントを保護するためのハードウェア対応セキュリティの技術や手法に基づくアプローチを説明している。また、一般的なセキュリティコミュニティ向けの青写真やテンプレートとなることを意図したアプローチのプロトタイプ実装について説明している。

NISTIR 8320Bは、以下のような構成になっており、附属書において、インテル、OpenShift、TSIの具体的な技術を例示している。また、NISTIR8320Aと同様に、NIST SP800-53改定第5版やNISTサイバーセキュリティフレームワーク第1.1版とのマッピングについても言及している。

1.序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2.プロトタイプの実装
2.1 目的
2.2 目標
2.2.1 ステージ0:プラットフォームの証明と測定されたワーカーロードの設定
2.2.2 ステージ1:信頼されたワークロードの配置
2.2.3 ステージ2:アセットのタグ付と信頼された位置情報
2.2.4 ステージ3:信頼に基づくワークロードの暗号化
2.2.5 ステージ4:信頼に基づくワークロードの情報へのアクセス
2.3 追加的リソース
3. プロトタイピングのステージ0
4. プロトタイピングのステージ1
5. プロトタイピングのステージ2
6. プロトタイピングのステージ3
6.1 ソリューション概要
6.2 ソリューションアーキテクチャ
7. プロトタイピングのステージ4
7.1 ソリューション概要
7.2 ソリューションアーキテクチャ
参考文献
附属書A – ハードウェア・ルート・オブ・トラストの実装
A.1 ハイレベルの実装アーキテクチャ
A.2 ハードウェア・ルート・オブ・トラスト:Intel TXTとTrusted Platform Module (TPM)
A.3 証明:Intel Security Libraries (ISecL)
附属書B – ワークロードオーケストレーションの実装:OpenShift
B.1 プロトタイプのアーキテクチャ
B.2 OpenShiftのインストールと構成
B.2.1 VMwareベースの管理クラスター(クラスターA)
B.2.2 KVMベースのマネージドクラスター(クラスターB)
B.2.3 MCM Pak 1.3(MCM HUB – VMware)のインストール
附属書C – ワークロード暗号化の実装
C.1 プロトタイプのアーキテクチャ
C.2 ワークロード暗号化の構成
附属書D – Trusted Service Identity(TSI)
D.1 TSIの概要
D.2 TSIのインストールと構成
附属書E – NIST SP 800-53 セキュリティ制御および発行文書のサポート
附属書F – サイバーセキュリティフレームワークのサブカテゴリーのマッピング
附属書G – 頭字語およびその他の略語

「NIST IR 8320C ハードウェア対応型セキュリティ:マシンアイデンティティ管理と保護(初期公開草案)」(2022年4月20日)
(https://csrc.nist.gov/pubs/ir/8320/c/ipd)

組織は、容量が拡大するマシンアイデンティティを導入しており、一組織当たり数千または数百万の数に至る場合もよくある。秘密暗号鍵のようなマシンアイデンティティは、個々のマシンにどのポリシーを強制する必要があるかを特定するために利用できる。マシンアイデンティティの中央集中型管理は、デバイスやワークロード、環境を越えたポリシー実装の簡素化に役立つ。しかしながら、利用する機微データ向けの保護策の欠如(例.メモリにおけるマシンアイデンティティ)により、リスクに晒される。本文書では、ライフサイクルを通じたマシンアイデンティティの生成、管理、保護に関するセキュリティ課題を克服するための効果的なアプローチを提示している。そして、このような課題に取り組む概念実証(PoC)の実装、プロトタイプについて記述している。本文書は、一般的なセキュリティコミュニティが、記述された実装を検証し、有効活用するために利用できるような青写真やテンプレートとなることを意図している。

NIST IR 8320C初期公開草案の構成は以下のようになっており、附属書において、Vanafi、インテルの具体的な技術を例示している。

1. 序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2. マシンアイデンティティを保護する際の課題
3. ステージ0:エンタープライズ向けマシンアイデンティティ管理
3.1 ソリューション概要
3.2 ソリューションアーキテクチャ
4. ステージ1:ハードウェアベースの秘密計算による秘密鍵利用時の保護
4.1 ソリューション概要
4.2 ソリューションアーキテクチャ
5. ステージ2:マシンアイデンティティ管理とエンドツーエンドの保護
5.1 ソリューション概要
5.2 ソリューションアーキテクチャ
附属書A – ハードウェアアーキテクチャ
附属書B – Vanafiのマシンアイデンティティ管理の実装
附属書C – インテルの利用時秘密鍵保護の実装
附属書D – マシンアイデンティティ・ランタイム保護と秘密計算との統合
D.1 ソリューション概要
D.2 ソリューションアーキテクチャ
D.3 インストールと構成
附属書E – 頭字語およびその他の略語

ここまで、NISTのハードウェア対応型セキュリティに関連した文書を紹介してきたが、業種・業界別にみると、決済系に代表される金融業界で、具体的な技術の開発・導入に関するユースケースが多く提供されており、オンプレミス環境とクラウド環境を組み合わせたハイブリッド環境におけるセキュリティ管理策の最適化に向けたソリューション開発が加速している。さらにマシンアイデンティティ管理をみると、情報技術(IT)と制御技術(OT)の融合に係るアイデンティティ管理の効率化・自動化を想定していることが伝わってくる。

元々、クローズドな境界防御を前提として情報システムが構築・運用されていた医療・ライフサイエンス業界の場合、ゼロトラストアーキテクチャやアプリケーションコンテナに代表されるクラウドネイティブ技術の導入も、ハイブリッド環境下が中心とならざるを得ない。医療機器のIoMT(Internet of Medical Things)やバイオ製造のデジタルツインを支えるセキュリティ管理策についても、ソフトウェア、ハードウェアの両面から最適化を図る必要があるだろう。

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

医療/ライフサイエンスにおけるハードウェア対応型セキュリティ(前編)

近年、金融決済領域を中心に普及し、医療IoT(IoMT: Internet of Medical Things)などの医療・ライフサイエンスの領域でも関心が高まっている技術に、ハードウェアセキュリティモジュール(HSM)に代表されるハードウェア対応型セキュリティ(Hardware-enabled Security)がある。クラウドセキュリティアライアンス(CSA)では、「クラウドネイティブな鍵管理サービス採用のための推奨事項」(2021年9月14日発行)(https://cloudsecurityalliance.org/artifacts/recommendations-for-adopting-a-cloud-native-key-management-service)、「鍵管理ライフサイクルのベストプラクティス」(2023年12月19日発行)( https://cloudsecurityalliance.org/artifacts/key-management-lifecycle-best-practices)、「HSM-as-a-Serviceのユースケース、考慮事項、ベストプラクティス」(2024年発行予定)など、クラウド鍵管理の観点から研究が進んでいる。 ここでは、クラウドネイティブ技術を支えるハードウェアセキュリティモジュール(HSM)や鍵管理の現状、米国立標準技術研究所(NIST)におけるハードウェア対応型セキュリティの標準化動向について概説する。

金融業界を中心に普及してきたハードウェアセキュリティモジュール(HSM)

CSAでは、ハードウェアセキュリティモジュール(HSM)について、暗号化のオペレーションを実行し、鍵を保護するために、認証された信頼されるプラットフォームと定義している。それは、改ざんに対応し、侵入を防止するデバイスであり、セキュリティ暗号化アクセラレータ、ハードウェアベースの乱数発生器、プロセッサー、RAM、ストレージ、外部インタフェース(例. ネットワーク/シリアルポート)から成る。HSMは、HSMにより生成・生産された暗号鍵として、組織インフラストラクチャのセキュリティを支えるために利用されるような信頼の起点(Root of Trust)と考えられる。通常、HSMは、強力なユーザ認証と職務分離を実装する。

HSMのタイプとしては、ユースケースに従って、一般目的のHSMと決済目的のHSMの2種類がある。双方を比較すると、以下のようになる。

[一般目的のHSM]

  • 暗号化アルゴリズム: 汎用的、対称/非対称暗号化
  • 管理上の柔軟性: とても柔軟
  • セキュリティ機能: 汎用的
  • 適用可能な標準規格: ETSI TS 419 series、CEN EN 419 221、PCI DSS & 3DS、FISMA、FedRAMP、FICAM
  • ユースケース: 汎用的な暗号化署名、暗号化/復号化、TLSオフロード

[決済目的のHSM]

  • 暗号化アルゴリズム: 領域固有、対称暗号化
  • 管理上の柔軟性: いくらか柔軟
  • セキュリティ機能: 強化型
  • 適用可能な標準規格: PCI P2PE、PCI 3DS、PCI SPoC、PCI CPoC、PCI PIN
  • ユースケース: カードPINライフサイクル、カードと暗号の妥当性評価、決済資格情報の発行、鍵管理向けオペレーションのポイントツーポイント暗号化(P2PE)、EMV取引処理

医療・ライフサイエンス領域は、一般目的のHSMに含まれ、標準化された暗号化アルゴリズムや業界標準のAPIをサポートする形で技術の導入が進んでいる。

加えて、HSMには、セキュアエンクレーブ(安全な飛び地)のような派生製品のケースがあり、領域固有のアルゴリズムやビジネスロジックが、セキュアで制御されたランタイム環境上に展開されることを要求する仕組みになっている。

成長するクラウド型のHSM-as-a-Service

他方、ハードウェアセキュリティモジュール・アズ・ア・サービス(HSM-as-a-Service)は、API、Web、ローカルインタフェースを介して、ハードウェアセキュリティモジュール(HSM)へのアクセスを提供するような、クラウドベースのサービスモデル/ソリューションである。HSM-as-a-Serviceは成長市場であり、多くの組織が、鍵管理や暗号化のニーズ向けにクラウドベースのソリューションを採用している。現在、HSM-as-a-Serviceソリューションは、SaaSデリバリーモデルに参入したクラウドサービスプロバイダ(CSP)およびHSMベンダーの双方が提供している。

HSM-as-a-Serviceの採用に影響を及ぼす要因として、以下のような点が挙げられる。

  • クラウドベースのセキュリティソリューションに対する需要の拡大:
    組織の多くがアプリケーションやデータをクラウドに移行し、新たなアプリケーションがクラウドネイティブ環境に構築されるにつれて、低レイテンシーや統合のオプションなど、オンプレミス型ソリューションと同等レベルのセキュリティを提供できるようなクラウドベースのセキュリティソリューションに対する需要が拡大している。
  • コンプライアンス要求事項:
    多くの業界、特に銀行・金融サービス・保険(BFSI)セクターや、デジタルガバメント、デジタルトラストサービス・セクターでは、国レベルの標準規格や規制により強制された、厳格なコンプライアンス/プライバシー要求事項を抱えており、機微データの保護、暗号鍵の制御、デバイスのバリデーション水準に関する特別な要求事項が見込まれる。このようなコンプライアンス要求事項は、どのHSM-as-a-Serviceのサブセットが有効活用できるかに影響を及ぼす。
  • CAPEX(資本的支出)の削減:
    HSMは、通常、高額な投資と考えられている。同等のクラウドサービスは、このようなサービスの採用のために適切な計画と設計を設定する限り、実際のサービス消費量に応じた支払いを可能にすることによって、費用の削減を提供できる。
  • OPEX(事業運営費)の削減:
    HSMデバイスは、その運用維持のために、熟練したエンジニアを必要とする。HSM-as-a-Serviceの提供は、維持や日々の運用をCSPやHSMベンダーに移管して、組織が業務費用を削減し、その他のタスクにリソースを再配分することを可能にする。

ハードウェアとソフトウェアが融合するHSMの技術アーキテクチャ

HSMは、機微データや暗号鍵を保護するために設計された専用デバイスであり、、セキュアな暗号化の運用を実行する。HSMは、専用の物理的デバイスまたは仮想アプライアンスとして運用することができ、暗号鍵の生成、保存、管理のために、多層型のセキュリティアプローチを導入して、物理的・デジタル的両面の脅威からの保護を保証する。HSMの論理的アーキテクチャは、セキュアな鍵ストレージ、暗号化アルゴリズム、改ざん対応モジュールなど、様々なセキュリティの階層から成る。これらのモジュールは、改ざんに対応するよう設計されることが多く、その中に保存された機微情報に対して、不正な主体がアクセスすることが極めて困難になっている。この中には、セキュアブートプロセス、暗号化ストレージ、鍵生成・保存専用ハードウェアなどの機能が含まれることが多い。

HSMには、リアルタイム改ざん検知メカニズムのような先進的セキュリティ機能が装備されており、物理的な侵害の試みに対する保護対策(例. 物理的に侵入が検知されたら鍵を消去する)の引き金となる。さらに、HSMは、アクセス制御、保存データの暗号化、セキュアな鍵のバックアップ・復旧に関するサポートなど、包括的なセキュリティ機能を提供する。このような特性により、金融取引、デジタル署名、セキュアな通信など、様々なアプリケーションの暗号化資産の機密性、完全性、可用性を保証する際、HSMは重要なコンポーネントとなる。

そして、HSM共通のフォームファクターとして、以下のようなものが挙げられる。

  • トラステッドプラットフォームモジュール(TPM)または組み込み型HSM
  • ローカルPCI Express(PCIe)カード
  • ネットワークHSM
  • スマートカード(統合型チップカード)
  • USB備え付けデバイス

HSM-as-a-Serviceの場合、PCIeカードやネットワークHSMなど、特定のフォームファクターに複数のインスタンスを集約させることによって、サービスを構築することが可能である。

前述の一般目的であれ決済目的であれ、フォームファクターに関係なく、ハードウェア実装の観点から、以下のようなHSM共通の技術要素が挙げられる。

  • 暗号化プロセッサー:
    暗号化オペレーションだけを実行する、専用の特別なタイプのマイクロプロセッサ。通常は、対称暗号化機能、非対称暗号化機能、ハッシュ機能、乱数発生など、固有のタイプの暗号化オペレーションを担う、より小さいプロセッシングユニットに、物理的にセグメントされる。暗号化プロセッサーは、セキュアなI/Oチャネル経由でアクセス可能であり、サーキットレベルで物理的対策により保護され、追加的なレベルの改ざん対策を提供する。
  • 永続性メモリ:
    生成またはインポートされた鍵を保存するためにセキュアなスペース。永続性メモリスペースは、スロットと呼ばれる論理的パーティションに分割される。個々のスロットは、複数の鍵を保存することができる。スロットへのアクセスは、サーキットレベルでセキュア化されるだけでなく、強力な認証、アクセスと認可制御により保護される。
  • I/Oモジュール:
    HSMとその他のシステムの間の通信を確立する役割を担う。フォームファクターに依存して、I/Oモジュールには、USB、PCI、UART、CPIOなど、標準的なプロトコルに応じて様々なコネクターが含まれる。

このような技術要素に基づいてHSM-as-a-Serviceを開発・提供するベンダー/サービスプロバイダーが参照すべき標準規格として、以下のようなものが挙げられる。

  • FIPS(Federal Information Processing Standards)140
    • CAVP(Cryptographic Algorithm Validation Program)
    • CMVP (Cryptographic Module Validation Program)
  • Common Criteria (CC) for Information Technology Security Evaluation
    • EAL (Evaluation Assurance Level)
    • PP (Protection Profile)
    • CEN EN 419 221-5
  • PCI SSC (Payment Card Industry Security Standards Council) PTS (PIN Transaction Security) HSM Specification
  • ISO/IEC 27001:2022
  • ISO/IEC 27017:2015
  • CSA STAR (Cloud Security Alliance Security Trust Assurance and Risk Framework)
  • AICPA SOC (American Institute of Certified Public Accountants System and Organization Controls)
    • SOC 1: ICFR (Internal Control over Financial Reporting)
    • SOC 2: Trust Services Criteria
    • SOC 3: Trust Services Criteria for General Use

HSMの物理的・論理的セキュリティ制御と顧客の関係

上記のような標準規格をベースとして、HSM-as-a-Serviceベンダー/サービスプロバイダーに対しては、物理的セキュリティおよび論理的セキュリティの両側面から、制御策を講じることが望まれる。

HSMの物理的セキュリティ制御においては、コンスタントに、モニタリングされ、検証可能なHSMへのアクセス制御を提供することを目標としている。ベンダー/サービスプロバイダーが提供すべき物理的セキュリティ制御の基本的要素として、以下のようなものが挙げられる。

  • セキュアな境界、侵入検知、論理的アクセス制御ポリシーの強制、ビジター管理、装置のingress/egressモニタリング、アクセス制御システムの保護、要員によるモニタリング、アクセス認可の強制、すべてのアクセスのログ付け。
  • 出荷、試験、オペレーションの間など、HSMライフサイクルの置換と修正の制御
  • HSMのアクセス、置換、修正保護におけるデュアル制御の強制など、HSMオペレーションのアクセス制御
  • HSMの状態、顧客へのアロケーション、鍵のバックアップを管理するシステムに関するアクセス制御
  • 遠隔管理とセキュアな鍵のバックアップに関するアクセス制御、デバイスやスマートカード向けのセキュアなストレージ、遠隔管理活動向けの施設や安全な空間、遠隔のHSMへのアクセスと鍵のバックアップ
  • オペレーションや管理に関するコネクションなど、HSMに接続するネットワークの保護
  • アクセス制御とビデオシステム向けのセキュアな領域、システムの可用性と完全性のモニタリングなど、アクセス制御システムの保護

なお、HSM-as-a-Serviceベンダー/サービスプロバイダーが顧客の遠隔管理デバイス利用向けに提供する場合、顧客が物理的セキュリティ上の責任を有する可能性がある。その場合、顧客は、サービス利用とストレージに関する物理的制御に責任を負うことになるので、注意が必要である。

他方、HSMの論理的セキュリティ制御においては、ベンダー/サービスプロバイダーが、顧客データの分離、従業員の顧客リソースへのアクセスの制御、最小特権アクセス、最小権限(need-to-know)アクセス、アクセスの認可とレビュー、スタッフのトレーニングなど、ISO 27001やPCI DSSなどで記述された要求事項を遵守することが前提となる。その上で、デバイスや鍵の管理で必要となるHSM固有の論理的セキュリティ制御策として、以下のようなものが挙げられる。

  • 個々のHSMについて、製造からサービスにおける有効化、オペレーション、廃止・破壊に至るまでのチェーン・オブ・カストディ(CoC)の維持
  • 顧客が利用可能になる前の段階におけるHSMの論理的・暗号的検証
  • ライフサイクルを通してHSMに物理的なアクセスを行うすべてのスタッフに対するデュアル制御のためのプロセス、トレーニング、認可、規則
  • HSM固有の物理的制御を実装するための電子アクセス制御・動画など、物理的アクセス制御に関する構成、アクセス管理、モニタリング
  • 鍵管理プロセスの確立、維持、記録、モニタリング
  • 鍵の管理者やカストディアンに関する認可、アクセス管理、モニタリング
  • リソース管理、顧客の鍵のバックアップと復旧など、HSM管理プロセス自動化の確立、認可、管理、モニタリング
  • HSM管理コネクション向けTLS認証管理など、HSMに対するネットワークアクセス制御
  • HSM管理アプリケーションまたはコンソール以外のHSMへのアクセスに関するアクセス制御
  • HSMサービス管理とHSMへのアクセスに関するクラウドサービスプロバイダのアイデンティティ/アクセスの構成
  • クラウドサービスプロバイダのネットワークアクセスの構成
  • セキュアな遠隔管理デバイスの利用

医療・ライフサイエンス領域においても、ゼロトラストアーキテクチャの導入に向けた動きが始まっており、その環境で稼働する医療IoT関連機器・サービスにも、マイクロサービスやサーバーレスアーキテクチャに代表されるクラウドネイティブ技術やDevSecOpsの波が押し寄せつつある。そのような状況に、5Gから6Gへのネットワークの進化が加わってくると、ハードウェアとソフトウェアの両面からのセキュリティ管理策実現により、さらなるイノベーションが期待される。

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

医療/ライフサイエンスにおけるデータ損失防止(DLP)(後編)

2023年10月4日、クラウドセキュリティアライアンス(CSA)の健康医療情報管理ワーキンググループは、「医療におけるデータ損失防止(DLP)」(https://cloudsecurityalliance.org/artifacts/data-loss-prevention-in-healthcare/)を公開した。ここでは、その概要について概説する。

医療データシステムのクラウド化で広がるDLPの活用機会

「医療おけるデータ損失防止(DLP)」は、医療業界における患者情報の転送に焦点を当てて、DLPを有効活用する方法の概要を示すことを目的としており、以下のような構成になっている。

・謝辞
・要約
・イントロダクション
-医療におけるデータ損失防止(DLP)
-DLPクラウドはデータ転送の重要な手段
・DLPはどのように機能するか
・DLPのタイプ
・DLPのEDM(正確なデータマッチング)とIDM(インデックス文書マッチング)
-偽陽性
-データ分類
・DLPと脅威インテリジェンス
・地域別のデータ用途
・DLPの保護
・DLPのベストプラクティスがデータセキュリティを強化する
・DLPポリシー設定のベストプラクティス
・リアルタイムのDLP
・DLP成熟度の評価
・結論
・参考文献

近年のクラウドコンピューティングの普及拡大とともに、組織は、主にクラウド経由で、データを転送・共有するようになり、世界的なCOVID-19パンデミックによって、その傾向が顕著になった。反面、組織がデータを遠隔で保存し、アクセスできるようになると、権限のない個人によるアクセスの可能性や、意図しない暗号鍵の削除といった技術的問題に起因する損失など、医療データに対する新たなリスクが生まれている。

ここでは、DLPの定義について、「患者記録、個人健康情報(PHI)など、機微情報の偶発的または許可されていない損失や暴露を防止する対策」としている。PHIの侵害は、ID窃盗や治療処置に対する害など、患者に重大な結果をもたらす可能性があり、これらの対策は、医療業界において特に需要である。DLPは、検知困難なデータの流出をレビューするために、多くの組織や医療業界が検討する多面的なセキュリティソリューションであり、データ漏えいを防止し、医療データのセキュリティや完全性を保証するために、DLP戦略を設定することが重要だとしている。

DLPソリューションの技術機能とタイプ

「DLPはどのように機能するか」では、DLPソリューションで利用される技術機能として、以下の8つを挙げている。

  1. ルールベースのマッチング: 特定のルールにマッチするデータを発見するために、既知のパターンを利用する
  2. データベース指紋: EDM(正確なデータマッチング)として知られているこの手法は、ファイル内の構造化データの正確なマッチングを探し出す(例. “患者番号123”の正確なストリング向け)
  3. 正確なファイルマッチング: ここでは、ファイルコンテンツ全体よりも、ファイルコンテンツの暗号学的ハッシュ値に対してマッチングが行われる
  4. コンテキスト分析: これは、ユーザーのロール、物理的ロケーション、利用するアプリケーションなど、データ転送に関する様々な要因を考慮する際に利用され、偽陽性の削減や、ポリシー強制の正確性の改善に役立つ
  5. 部分的文書マッチング: この手法は、異なるユーザーがフォームの複数バージョンに入力する際に、あらかじめ設定されたパターンに部分的にマッチするファイルを探し出す
  6. 統計学的分析: ここでは、違反のきっかけとするために、ベイジアン分析など、機械学習またはその他の統計学的手法が利用される
  7. 事前組込型カテゴリー: あらかじめ組込まれたカテゴリーは、機微性やセキュリティ要求事項に基づいてデータを特定する、医療提供組織(HDO)のデータ分類に基づいたルールを利用する
  8. ユーザー行動分析: この手法は、疑わしいエンドユーザーの行動にフラグを立てる

次に「DLPのタイプ」では、DLPソリューションとして、以下の3タイプを挙げている。

  1. ネットワークDLP: データが移動している時に、抽出を監視、検知、ブロックする(例. 悪意あるインサイダーが、機微な企業情報を悪意のあるアクターにメール送信したり、退社時に知的財産を個人メールに送信したりする)。
  2. エンドポイントDLP: 従業員が機密データをリムーバル機器(例. USBドライブ)にコピーするのを防止する。また、エンドポイントで、ローカルに検知を実行するデータ損失ポリシーに基づいて、機微データをキャプチャするために、ファイルやネットワークの共有をスキャンする場所で、ローカルエージェントを介した保存データをスキャンする。
  3. クラウドDLP: データ抽出や偶発的なファイル共有に対して保護する。また、境界ベースのネットワークから、ユーザー・アプリケーション中心のネットワークに変換する際に、オンプレミス型DLPソリューションは、クラウドベースのDLPに置き換わっていく。これにより、アウトバウンドデータの調査が可能になり、ユーザーエクスペリエンスにマイナスの影響を与えることなくトラフィックをブロックするか否かの判断が容易になる。

医療業界の場合、世界保健機関(WHO)が管理・発行する医学的分類に関する変更を時系列的に組み込んでいく必要がある。そして、FDAが確認した医薬品、医師診療行為用語(CPT)/国際疾病分類(ICD-10コード)、医療診断用語などを含む文書の転送を追跡し、ブロックする際には、しばしば医療用語のDLPへの取込みが要求される。これらの用語は、EDM(正確なデータマッチング)やIDM(インデックス文書マッチング)のような機能を介して、取り込むことが可能である。

DLPソリューションの鍵を握るデータ分類と脅威インテリジェンス

データ分類は、特にDLPソリューションと合わせて、機微データを特定、追跡、保護する際にギャップを埋める橋渡し役を担う。DLPベンダーの多くは、各社固有のデータセキュリティソリューションを強化するために、データ分類サービスに依存しており、通常、固有の製品またはサードパーティ統合の形態で提供される。データ分類の標準規格は、成功するDLPプログラムの基盤であり、企業データの機密性を明確にして、データリスクを評価する基礎となる。適切にラベリング・タグ付けされたデータは、DLPプロセスを簡素化して、組織が機微データを機微でないデータと区別し、DLPのパフォーマンスを改善することを可能にする。このようなことから、データ分類機能は、DLPプログラムの統合コンポーネントとなり、DLP製品と組み合わせて提供する形態が増えている。

次にDLPソリューションとの連携が期待されるのが脅威インテリジェンスである。たとえば、脅威インテリジェンスチームがユーザー行動分析機能を強化すると、データの移動を認識する手段を達成して、データ抽出よりも前にフラグを立てることができる。DLPポリシーは、インサイダー脅威に関して、リスクのあるユーザーをモニタリング・警告するために設定することが可能であり、外部からデータ転送の監査や遮断などの行動をモニタリングできる。さらに、ファイルサイズを制限すると、ユーザーが閾値を超えるか、単独ユーザーによるファイル抽出のパターンが認識された場合、アラートのきっかけとすることができる。

ロケーションによるデータの取扱とIAM・IRM

コンプライアンスに関連して、複数の厳格な地域的・国際的規制(例.コロラド州プライバシー保護法(CPA)、欧州一般データ保護規則(GDPR)、フロリダ州デジタル権利法(FDBR)など)が、ロケーションに基づくデータ転送を管理している。将来のDLPソリューションがデータを自動的に分類・追跡する可能性はあるが、現時点では、予期しない漏えいの発生に備えて、ポリシーに基づいた特定の地域など、個人データの全タイプについてデータ保護とコンプライアンスの重要性を理解することが必要となっている。

データの共有が必要な場合、データに関する責任を有する組織は、セキュリティを保証しなければならない。データ利用に際しては、アイデンティティ/アクセス管理(IAM)がセキュリティ上重要となる。最低限、DLPソリューションには、データ利用状況のモニタリングを組み込むべきだとしている。DLPは、機微なデータを損失したり、誤用したりしていないかを保証するために利用される。DLPソフトウェアは、規制された機密データを分類し、組織や、HIPAA、PCI-DSS、GDPRのような規制遵守に従ってあらかじめ設定されたポリシー集の範囲内で、明らかなポリシー違反を特定する。加えて、組織は、情報権利管理(IRM)を考慮する必要がある。IRMは、不正なアクセスから、機微な情報を含む文書を保護するセキュリティ技術である。

DLPの保護策

DLPベンダーは、ネットワークゲートウェイにおける基本的なコンテンツフィルタリングから、複雑なネットワーク/ホストベースのモニタリングソリューションまでの広範囲なソリューションを提供する。組織は、機微な情報リソースを保護するために、ポリシーをモニタリング、発見、導入する。そのために必要な抽出の手段として、電子メール、Webブラウザ、クラウドファイル共有、インスタントメッセンジャー、ソーシャルメディア、ポータブルストレージデバイス、スクリーンキャプチャを挙げている。

DLPは、平文のパケットを調査し、調査時にデータが暗号化されていないことを要求するので、暗号化の戦略や要求事項と直接コンフリクトを起こす可能性がある。もしDLPが誤ったレイヤに導入されたり、不適当に構成されたりすると、実際に脅威ポイントを作り出すことになる。そこで本文書では、以下のような留意事項を挙げている。

  1. データの暗号化: データを暗号化することにより、適正な復号鍵を持たない者が判読できないようにする。暗号化は、リアルタイムで検索可能な暗号に対してクラウド上の牽引力を持つ他の手法が存在するので、機微情報に対する不正アクセスを防止するために役立てることができる。

・対称暗号 – 暗号化と復号化の双方に単一鍵を利用する。

・クラウド上でのデータ断片化 – データの復号化に必要な暗号鍵を削除することによって、データを判読不可能にする。

・トークン化、準同型暗号(PHE) – 機微なデータ要素を代替値やトークンに置き換える。

・ポリモーフィック型暗号 – 複数の鍵で保護された複数フォーマットによるデータの暗号化。

・準同型暗号 – 復号化の必要なく、暗号化データのあるところで操作や検索ができる。

  1. アクセス制御 – 不正なデータアクセスを防止するためのユーザー認証や許可。
  2. ユーザー行動分析 – ユーザー行動分析を有効活用して異常または疑わしいデータアクセスパターンを検知して、潜在的なインサイダー脅威を特定するのに役立つ。
  3. 定期的な監査の実行 – 定期監査は、データ損失に関する脆弱性や潜在的な領域を特定するのに、役立てることができる。
  4. データのモニタリングと分析: データ侵害を特定・防止するために、リアルタイムのデータモニタリングとコンテンツ分析を実行する。
  5. トレーニング – セキュリティのベストプラクティスに関する従業員向けトレーニングは、偶発的なデータ損失を防止するのに役立てることができる。たとえば、テンプレートの電子メールをユーザー宛に発行して活動を周知し、データを外部に公開するリスクに関する特別なメッセージを利用し、四半期ごとに常習者を対象としたセキュリティ意識向上トレーニングを実施する。

データセキュリティの強化に向けたDLPのベストプラクティス

本文書では、DLPのベストプラクティスについて、技術、プロセス制御、知識のあるスタッフ、従業員の意識を組み合わせたものだとして、以下の通り、効果的なDLPプログラムを構築するための指針を挙げている。

  1. 単一の中央集中型DLPプログラムの実装 – 単一の中央集中型DLPプログラムを実装することにより、一貫したデータモニタリングを保証し、よりよい可視性をデータ資産に提供して、組織全体のデータセキュリティを強化する。
  2. 内部リソースの評価 – DLP計画を実装するために、医療提供組織は、DLPリスク分析、データ侵害への対応・報告、データ保護法規、トレーニング・意識向上などの経験を有する人材を必要とする。
  3. 在庫管理や評価の実行 – DLPプログラムの実装において、データのタイプや価値の評価は重要である。評価には、どのようにデータを処理し保護するか、どのように転送し保護するか、どこに保存し保護するかなど、データやコンプライアンス(HIPAA、PCI、PII)、ビジネス上の機微性の特定が含まれる。
  4. 段階的な実装 – DLPは長期的プロセスである。段階的な実装が最善である。
  5. 分類システムの構築 – 医療提供組織は、DLPポリシーを構築・実装する前に、分類フレームワークを構築しなければならない。
  6. データ処理・救済ポリシーの設定 – 分類フレームワークの構築後に、異なるデータのカテゴリーを処理するためのポリシーを構築(または更新)する。
  7. 従業員の教育 – セキュリティポリシーや手順に対する従業員の意識や受容が不可欠である。

DLPポリシー展開のベストプラクティス

さらに、医療提供組織がDLP投資を最大化するのに役立ち、ソリューションが組織の既存のセキュリティ戦略や既存の対策に合致していることを保証するようなベストプラクティスとして、以下のようなことを推奨している。

1. 第一目的の決定 – DLPは、医療提供組織が、HIPAAのような複雑で進化するコンプライアンス基準を満たせるように、多くの医療提供組織で採用される。これは1つの重要機能であるとともに、包括的なソリューションが、データ保護、インシデント防止、可視性、インシデント対応能力など、医療提供組織に対するその他の支援を提供する。柔軟なソリューションにより、医療提供組織が優先順位に応じてカスタマイズすることが可能になる。
2. 医療提供組織のセキュリティアーキテクチャや戦略に合わせたDLPの保証 – DLPソリューションを設計・実装する時、医療提供組織は、凝縮された統合型のセキュリティアーキテクチャを保証する互換性を決定するために、ファイアウォール、モニタリングシステムなど、レガシーなセキュリティ技術注意深く評価しなければならない。
3. 規則的な頻度のセキュリティレビュー構築 – 医療提供組織は、DLPソリューションのパフォーマンスを継続的に評価する必要がある。新たな機能や能力が追加され、上市する際に評価する必要がある場合がよくある。
4. 変更管理ガイドラインの設定 – 医療提供組織は、ステークホルダー間で取り決められた構成について、実装前に統一の承認を受ける必要がある。
5. 検証 – DLPソリューションが意図通りに稼働することを保証するために、定期的な監査と包括的なテストが重要であり、対策中に潜在的な脆弱性やギャップを特定し、処理する。

ランサムウェア対策として注目されるリアルタイムのDLP

  1. リアルタイムのデータモニタリング: DLPソリューションは、医療提供組織のネットワークやシステムを通じてデータが流れる際にリアルタイムで、継続的にデータをモニタリングする。たとえば、DLPは、機微データ向けのファイル転送をモニタリングし、転送を遮断する。それは、ネットワークの出口ポイント、ユーザーのエンドポイント(例.ラップトップ、デスクトップ)、クラウドアプリケーションなど、異なる地点で遮断することができる。
  2. コンテンツ調査・分析: DLPソリューションは、コンテンツ調査を実行し、それを通してデータを分析する。機微データを発見したら、通過から遮断する。それは、明確なポリシーや分類に基づいて機微データを分類するために、キーワードマッチング、正規表現、データ指紋、機械学習アルゴリズムなど、様々な手法を利用する。
  3. コンテキスト分析: DLPソリューションは、データ転送やアクセスのコンテキストを考慮することによって、偽陽性を回避し、正確なポリシー強制を保証する。機微データの転送を発見したら、ソリューションはそれを遮断する。ソリューションは、ユーザーの役割、ロケーション、利用されるデバイス、目的地、利用されるアプリケーションなどの要因を分析する。
  4. ポリシー強制: DLPソリューションがポリシー違反を特定または潜在的に特定すると、リアルタイムに強制する。ポリシーは、機微データ転送の遮断、データの暗号化、ユーザーや管理者へのアラート、詳細な分析向けのインシデントのログ付けなど、構成の設定に合わせて様々な行動を引き起こすことができる。
  5. インシデント対応: DLPソリューションは、ポリシー違反が発生すると、インシデント対応ワークフローの引き金となる。対応には、セキュリティ要員への通知、問題のエスカレーション、リスク低減とさらなるデータ露出防止のために必要なステップをとることなどがある。
  6. 報告: DLPソリューションは、ポリシー遵守報告、インシデント報告、傾向分析hポウ国など、詳細な報告書を生成する。これらの報告は、データ保護活動、ポリシー違反、組織全体のデータセキュリティポスチャに関するインサイトを提供する。
  7. 継続的な更新と改善: DLPソリューションは、新たなパターン、出現する脅威、規制変更に対して、最新の状態を維持するために、最新のデータベースやアルゴリズムを必要とする。定期的な更新は、そのソリューションが、新たに出現するリスクを効果的に特定し、保護することを保証する。

DLP成熟度の自己評価モデル

本文書では、最後に、医療提供組織のDLPプログラムを効率化する方法を理解するために、HCLテクノロジーズが策定したDLP成熟度の自己評価モデルを紹介している。ここでは、データ損失防止プログラム成熟度の重要な要素を、以下の通り6つにカテゴライズしている。

CE1 – プログラムガバナンス – プログラムガバナンスは、DLPのビジネス利用、実装、組織ポリシーに関する戦略的・戦術的意思決定のガイダンスを組織に提供する一連の階層、プロセス、ポリシーである。
CE2 – エンタープライズカバレッジ – エンタープライズカバレッジは、組織のネットワーク、ユーザー、データ空間に渡るDLP保護の範囲である。
CE3 – ポリシーカバレッジ – ポリシーカバレッジは、組織に関連するデータのタイプのスコープ全体に渡るDLPの検知・保護の幅を表す。
CE4 – インシデント救済策 – インシデント救済策の成熟度は、妥当性のあるDLP保護ポリシーに違反したユーザー、データ、ネットワークの活動への組織的対応を定義するプロセス、要員、トレーニング、サブプログラムをカバーする。
CE5 – セキュリティ意識 – この明確な目的向けに定義されたセキュリティ意識は、セキュリティ、データセキュリティ考慮事項、DLPツーリングのセキュリティ組織的意識、必要性、価値、セキュリティに関連したDLPメトリクスやツールの内部利用に対するエンドユーザー従業員の意識を定義する。
CE6 – メトリクスと報告 – データ損失防止プログラムは、確実なROIと明白なセキュリティ改善へのデータ駆動型の道筋を保証するために、追跡可能で報告可能な成功のメトリクスを有する必要がある。

他方、これら各要素の成熟度評価指標については、前述のHCLがカーネギーメロン大学の能力成熟度モデル統合(CMMI)を適用して策定した、以下の5つの成熟度レベルを紹介している。

  1. 初期(Initial) – プロセスは、予測不能で、制御が難しく、リアクティブだとみなされる。この段階の組織は、リスクや非効率性の拡大を招くような予測不能な環境にある。
  2. 管理された(Managed) – プロセスは、プロジェクトにより特徴づけられ、リアクティブなことが多い。
  3. 明確な(Defined) – プロセスがよく特徴づけられ、よく理解されている。組織はリアクティブ以上にプロアクティブであり、組織全体の標準規格がガイダンスを提供する。
  4. 定量的に管理された(Quantitatively Managed) – プロセスが評価され、制御されている。組織は、定量データを利用して、組織の目標を満たすような予測可能なプロセスを実装する。
  5. 最適化している(Optimizing) – プロセスが安定して、柔軟性がある。組織的なフォーカスが、継続的改善と変化への対応に当てられている。

このようなことを踏まえて、結論では、データ保護が、すべての個人・組織、特に様々なコミュニケーションチャネルにおいて重要であり、データおよびその周りにある課題を認識するための堅牢なプラットフォームを設定することが鍵だとしている。デジタル化の最前線にある医療業界はDLPの重要市場の1つであり、データの境界のモニタリングやデータオーナーとの継続的な連携により、予防策を拡張するとともに、データ損失につながる攻撃面を縮小するメリットがあるとしている。

なおCSAでは、一般的なクラウド環境のデータ損失防止利用動向に関連して、2023年3月14日、「データ損失防止とデータセキュリティ調査報告書」(https://cloudsecurityalliance.org/artifacts/data-loss-prevention-and-data-security-survey-report/)を公開するなど、積極的に取組んでいる。

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

 

医療/ライフサイエンスにおけるデータ損失防止(DLP)(前編)

2023年10月4日、クラウドセキュリティアライアンス(CSA)の健康医療情報管理ワーキンググループは、「医療/ライフサイエンスにおけるデータ損失防止(DLP)」(https://cloudsecurityalliance.org/artifacts/data-loss-prevention-in-healthcare/)を公開した。ここでは、DLP導入の前提条件となるデータの分類・管理プロセスの標準化動向や、医療/ライフサイエンス分野のユースケースについて概説する。
米国NISTがデータ分類の標準化に関する文書草案を公開

2023年11月15日、米国立標準技術研究所(NIST)は、「NIST IR 8496 データ分類の概念とデータ収集向上のための考慮事項」公開草案初版を発表した(https://csrc.nist.gov/pubs/ir/8496/ipd)。この文書草案は、データ分類における基礎的な専門用語を定義し、基本的な概念を説明して、皆が利用するための共通言語とすること、そして、データ分類において考慮すべきことに対する認識を高め、組織がデータ保護アプローチの品質や効率性を向上させる際に役立てることを目的としている。最初に、データ分類の定義について、「持続性のあるラベルを利用してデータ資産を特徴付けて、それらの資産を適正に管理できるようにするために、組織が利用するプロセスである」としている。そして、データ分類のプラクティスを実装することによって、以下のようなメリットがあるとしている。

組織のデータ資産に対するサイバーセキュリティとプライバシー保護の要求事項の適用を可能にする
データ資産を、パートナー、契約先およびその他の組織と安全に共有する
特定のデータ資産に適用される、法律、規制、契約書およびその他のソースからの要求事項を知る
ゼロトラストアーキテクチャおよびその他のサイバーセキュリティ・プライバシー技術の実装をサポートするような、データ資産および個々の資産の重要性に対する認識を維持する
組織の知的財産へのアクセスおよび転送に関する制限を強制する
生成人工知能(AI)技術(例.大規模言語モデル(LLM))で消費されるデータ資産のソースに関するメタデータをキャプチャする
現時点で必要ないが、将来必要になる可能性があるような時、データ資産のメタデータを特定して記録する(例.量子対応準備や低減計画向け)

草案は、以下のような構成になっている。

1. イントロダクション
1.1. 目的とスコープ
1.2. 本書の構成
2. 背景
2.1. データライフサイクル
2.2. 構造化、非構造化、半構造化データ
2.3. データガバナンスとデータ管理
3. データ分類の機能
3.1. データ分類ポリシーの定義
3.2. 分類するデータ資産の特定
3.3. データ資産向けのデータ分類の決定
3.4. データ資産のラベリング
3.5. データ資産のモニタリング
参考文献
附表A. 記号、略語、頭字語の一覧
附表B. 用語集

このうち「2. 背景」についてみると、まず「2.1. データライフサイクル」で、組織は、以下の4段階から構成されるデータライフサイクルを通じてデータ資産を管理するとしている。
特定: 組織は、データ資産を特定する
利用: 組織は、一部またはすべてのデータ資産にアクセスして、閲覧、共有、修正する
維持: 組織は、時間とともにデータ資産を保持する
廃棄: 組織は、データライフサイクルの最後にデータ資産を廃棄する

次に「2.2. 構造化、非構造化、半構造化データ」では、データ構造の観点から、以下のように、「構造化データ」、「半構造化データ」、「非構造化データ」の3つのカテゴリーを提示している。

構造化データ: データが表現される方法や表現を翻訳すべき方法を記述した物理的データモデルに続くものである。構造化データは、データベース、または個々のデータフィールドに含まれる情報のタイプが何かを明確に示すようなその他のメカニズム(例.顧客IDまたは一部の番号)の中に見られることがある。構造化データは、意味を保証するために、データモデルに対して検証することができる。
半構造化データ: 自らのデータモデルを記述する(自己記述型)。半構造化データは、プロプライエタリなデータセットを共有するための拡張可能なマークアップ言語(XML)やJSON(JavaScript Object Notation)、機微な構成パラメーターなどのフォーマットで表現される。
非構造化データ: ビジネスモデルに対して意味のあるような詳細なデータモデルに続くものではない。非構造化データは、プロプライエタリな文書フォーマットや、標準規格ベースのビデオフォーマットなど、特別なフォーマットに保存される場合がある。たとえば、ビデオは、患者の治療手順や、人々の施設への入退室、新入職員向けのトレーニングコースなどを見せることが可能である。非構造化データを有する文書は、ほぼすべてのタイプの情報を含むだけでなく、その中に組込まれた他のデータのタイプ(画像や映像など)を有しておいる場合があり、各々は1つ以上のデータのインスタンスを含むことになる。

さらに「2.3. データガバナンスとデータ管理」では、データガバナンスおよびデータ管理の役割について、以下のように説明している。

データガバナンス: データ資産が適切に管理されていることを保証するために組織が実行する必要があるアクションを強化する。データガバナンスのために特に重要なデータ分類の視点は、組織のデータ分類ポリシーおよび関連するデータ保護の要求事項を明確化して、組織内および組織外双方における役割や責任など、これらのポリシーを実装し、強制すべき方法を決定する。
データ管理: データガバナンスから生じるポリシーやプラクティスの実装および強制である。データ管理は、データライフサイクルを通して、すべてのデータ資産に起きるべきである。メタデータはデータの形式であり、管理を必要とする。データ管理の一部としてのデータ分類の役割を理解するためには、以下のようなデータ管理領域に対する基礎的な理解が必要である。
データの定義: データ資産を管理するために、組織はまずデータを定義する必要がある。データの定義は、データ資産によって様々であるが、通常、適用可能なデータのタイプやデータモデルに加えて、データ資産の由来、性質、目的、品質に関連したメタデータを特定する作業(データカタログの作成)が含まれる。データの定義は、組織がデータ分類を確実なものにできるように、データ資産に関する十分な情報を収集するために努力している。データの定義の形式や厳格さは、データ資産の中で大幅に異なるが、それは、データ資産が構造化されているか、半構造化されているか、非構造化されているかに関係している。
データの分類: データ資産のためのデータ分類は、以下の3つのうち1つ以上に基づいて、選定され、割り当てられる: データの定義、カタログ化されたメタデータ、コンテンツのレビューまたは分析。
データの保護: 一度データ分類が割り当てられると、組織は、個々の分類に関連したデータ保護の要求事項を強制する。これらは、分類に応じて個々のデータ資産を保護するために必要なすべての制御をカバーする。事例としては、保存時および転送時にデータ資産を暗号化するために要求事項に関連したデータの分類があり、なりすましを検知するデータの完全性のメカニズムを利用して、特定グループのメンバーだけにアクセスを認め、データが取得された日付から少なくとも2年間データ資産を保持する。
データのモニタリング: データのモニタリングは、データ分類/データ保護に対する変更を必要とするようなデータ定義またはデータ資産自体に対するすべての変更を特定するために必要である。またデータのモニタリングは、データ管理を向上させる可能性があるようなリアルワールドデータの分類や保護の経験からの教訓を特定する。

その上で、「3. データ分類の機能」において、以下の通り、データ分類のプロセスに必要な5つの機能を提示している。

データ分類ポリシーの定義: データ資産のタイプの用語集と個々のタイプのデータ資産を特定するためのルールを記した、組織のデータ分類ポリシーを定義する
分類するデータ資産の特定: 組織が分類すべきデータ資産を特定する
データ資産向けのデータ分類の決定: データ資産を分析し、個々にとって適切なデータ分類を決定する
データ資産のラベリング: 個々のデータ資産に、データ分類ラベルを関連付ける(一度ラベルが割り当てられると、個々のデータ資産に対して、適用可能なサイバーセキュリティおよびプライバシーの要求事項を強制することができる)
データ資産のモニタリング: データ分類および/またはデータ分類ポリシーを更新する必要があるような変更に関して、個々のデータ資産をモニタリングする

このようなデータ分類プロセスの効率化・自動化を図るために、「Microsoft 365」(https://learn.microsoft.com/en-us/compliance/assurance/assurance-create-data-classification-framework)、「Google Workspace」(https://support.google.com/a/answer/9843931)、「Salesforce」(https://help.salesforce.com/s/articleView?id=sf.dato_harmonize_classify.htm&type=5)など、主要クラウドサービスプロバイダーは、様々なサポート機能を提供しており、その中に、データ損失防止(DLP)機能も含まれる。

以下では、医療/ライフサイエンス分野におけるデータ分類・管理に係る具体的な事例を紹介する。
事例1: 米国マウント・サイナイ・アイカーン医科大学のデータ分類参照ガイド

マウント・サイナイ・アイカーン医科大学は、米国ニューヨーク市マンハッタン区にある私立の医科大学であり、マウントサイナイ医療センター(ベッド数: 約1,200床)を併設している。参考までに、OWASP/クラウドセキュリティアライアンスの「OWASP セキュアな医療機器導入基準Version 2.0」(2018年8月発行)( https://cloudsecurityalliance.org/artifacts/owasp-secure-medical-devices-deployment-standard/)や、クラウドセキュリティアライアンスの「医療機器インシデント対応プレイブック」(2021年11月8日発行)( https://cloudsecurityalliance.org/artifacts/csa-medical-device-incident-response-playbook/)のプロジェクトリードを務めたクリストファー・フレンツ氏は、傘下のマウント・サイナイ・サウスナッソー病院の情報セキュリティ責任者である。フレンツ氏は、米国医療情報管理システム学会(HIMSS)などで、精力的に情報セキュリティやゼロトラストアーキテクチャに関する啓発活動を行っている。

同大学では、全学共通のデータ分類参照ガイド (https://icahn.mssm.edu/research/portal/resources/rit/data-classification) を策定・運用している。このガイドでは、以下のように、データの機微性のレベルに沿って4段階の分類を設定している。

[保護対象(Protected)] 機微性・最高レベル:
法規制により情報の保護が要求される、または情報への不正なアクセスがあった場合、大学に対して政府への自己報告および/または個人への通知が要求される
<データの事例>
-保護対象保健情報(PHI)
-個人識別情報(PII)
-個人/従業員データ(例.従業員の補償金、就業不能給付金請求)
-ディレクトリ情報に含まれない学生データ(例.学生ローン情報)
-ビジネス/金融データ(例.クレジットカード番号)

[機密(Confidential)] 機微性・高レベル:
マウントサイナイが所有権を有するデータ、情報、知的財産; または契約上の義務により保護されたデータ
<データの事例>
-機密または制限対象データにアクセスする情報リソース(ユーザ名とパスワード)
・アカデミック/研究情報(例.助成金申請書、被験者情報、詳細な年間予算情報)
・データ管理(例. 利益相反開示)
-ビジネス/金融データ(例.機密保持契約書によりカバーされる情報)

[制限対象(Restricted)] 機微性・中レベル:
一般的に公が利用できないデータまたは情報
<データの事例>
-ビジネス/金融データ(例.機密データを含まない金融取引)
-アカデミック/研究情報(例.未公表の研究または機密データ扱いの研究詳細/結果、プライベートファンディング情報)
-管理データ(例.医療センターの投資情報)
-システム/ログデータ(例. サーバーのイベントログ)

[公開(Public)] 機微性・低レベル:
プライバシーまたは機密性が期待されないデータ
<データの事例>
・オーナーがプライベート扱いを意図していない特定のディレクトリ/契約情報
・学生固有のもの(例.学年、キャンパス活動・スポーツへの参加)
・ビジネスデータ(例.キャンパスマップ、公開出版物リスト)

参考までに、ニューヨーク州では、2023年11月1日、同州金融サービス局(NYDFS)が、改正サイバーセキュリティ規則「23 NYCRR Part 500」(https://www.dfs.ny.gov/reports_and_publications/press_releases/pr202311011)を施行して、ビジネス/金融データに係るサイバーセキュリティ要求事項が厳格化された。州内の医療保険会社や、Healthtech/Medtechスタートアップ企業に投資するプライベート・エクイティ・ファンドも、NYDFSの監視対象である。
事例2: 米国NIHのデータ管理・共有ポリシー施行

米国立衛生研究所(NIH)は、2023年1月25日、「データ管理・共有(DMS)ポリシー」を施行した(https://grants.nih.gov/grants/guide/notice-files/NOT-OD-21-013.html)。DMSポリシーは、科学における信頼性と透明性を高めるために、研究データの利用可能性と再利用性を最大化する一方、研究データの管理・共有の規範を構築することを目的としており、NIHの研究資金を受けて、科学データを利用した研究を行うプロジェクト(米国外を含む)に適用される。

NIHは、科学データについて、「データが学術出版物をサポートするために利用されたかに関わらず、研究成果を検証し再現するために十分な品質があると、科学コミュニティに共通して受け入れられたデータ」と定義しており、研究成果を検証し、再現するために必要なすべてのデータが含まれるとしている。そしてNIHの研究資金を求める研究者に対して、以下のような要求事項を定めている。

科学データおよび付随するメタデータの管理/共有方法の概略を提示し、プロジェクトに適用される可能性がある潜在的な制限や限界を考慮したDMS計画(その他の資金調達元省庁向けのデータ管理計画と同等)を提出する
NIH内部の資金調達元研究所またはセンターが承認したデータ管理/共有計画を順守する

また、DMS計画に含まれる要素として、以下のような項目を推奨している。

データのタイプ
関連するツール、ソフトウェアおよび/またはコード
標準規格
データの保存、アクセス、関連するタイムライン
アクセス、配布、再利用の考慮事項
データ管理/共有の監視

なお、ゲノムデータを利用した研究プロジェクトについては、NIHの「ゲノムデータ共有ポリシー」(https://sharing.nih.gov/genomic-data-sharing-policy)に準拠して、以下のような対応策を講じることが推奨される

DMS計画の一部として、ゲノムデータ共有のための計画を策定し、提供する
ヒューマンデータで作業する場合、ジャストインタイムで機関認証フォームを提供する
迅速な方法で、ゲノムデータを適切なリポジトリに提出する
責任を持って、アクセス制御されたデータを利用する
発行物やプレゼンテーションでは、アクセス制御されたデータを適切に引用する

参考までに、2022年9月15日に発表された「対米外国投資委員会による国家安全保障リスクの進展に対する堅牢性の考慮の確保に関する大統領令」(https://www.whitehouse.gov/briefing-room/presidential-actions/2022/09/15/executive-order-on-ensuring-robust-consideration-of-evolving-national-security-risks-by-the-committee-on-foreign-investment-in-the-united-states/)では、特に米国の国家安全保障に影響を及ぼす領域として、マイクロエレクトロニクス、AI、バイオ技術/バイオ製造、量子コンピュータ、先進的クリーンエネルギー(蓄電池、水素など)、気候適応技術、重要な素材(リチウム、レアアース希土類元素など)、食品安全保障に影響を与える農業産業基盤の要素および米国のサプライチェーンに関する大統領令第14017号(2021年2月24日)(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/02/24/executive-order-on-americas-supply-chains/)で指定されたその他のセクターを挙げている。これらの領域で、NIHの資金助成を受けた科学データ研究プロジェクトに関わる日本の教育・研究機関や企業は、米国の国家安全保障に関する大統領令の適用範囲となる。データ侵害インシデントへの対応などを誤ると、外交問題に発展しかねないので、特に注意が必要である。

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