2023年1月30日、クラウドセキュリティアライアンス（CSA）のIoTワーキンググループ／健康医療情報管理ワーキンググループ／クラウドインシデント対応ワーキンググループは、「遠隔手術机上演習ガイドブック」(https://cloudsecurityalliance.org/artifacts/telesurgery-tabletop-guide-book/)を公開した。ここでは、脅威モデリングの観点から、ロボット支援手術(RAS)システムに代表されるクラウドコンピューティングを利用した医療機器のサイバーセキュリティについて考察する。

米国の医療機器市販後安全管理策に位置づけられた脅威モデリング

脅威モデリングに関連して、米国食品医薬品局(FDA)は、2016年12月28日に「医療機器におけるサイバーセキュリティの市販後管理 – 業界および食品医薬品局スタッフ向けガイダンス」(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices)を公開している。本ガイダンスは以下のような構成になっている。

Ⅰ. イントロダクション
Ⅱ. 背景
Ⅲ. スコープ
Ⅳ. 定義

A.補完的な制御
B. 制御されたリスク
C. サイバーセキュリティの日常的なアップデートとパッチ当て
D. サイバーセキュリティの兆候
E. 悪用
F. 患者の害
G. 救済策
H. 脅威
I. 脅威モデリング
J. 制御されないリスク
K. 脆弱性

Ⅴ. 一般原則

A. 市販前の考慮事項
B. 市販後の考慮事項
C. 安全性と不可欠なパフォーマンスの維持

Ⅵ. 医療機器サイバーセキュリティリスク管理

A. サイバーセキュリティ脆弱性の悪用可能性の評価
B. 患者の害の重大度の評価
C. 患者の害のリスクの評価

Ⅶ. サイバーセキュリティ脆弱性の救済策と報告書作成

A. 患者の害の制御されたリスク
B. 安全性と不可欠なパフォーマンスに対して制御されないリスク

Ⅷ. PMA(市販前承認)時系列報告書に含むのに推奨されるコンテンツ
Ⅸ. ISAO(情報共有・分析組織)における製造業者による活発な参加を明確化するための基準
Ⅹ. 附表: 有効な市販後サイバーセキュリティプログラムの要素

A. アイデンティ
ⅰ. 安全性と不可欠なパフォーマンスの維持
B. 保護／検知
ⅰ. 脆弱性の特徴づけと評価
ⅱ. リスク分析と脅威モデリング
ⅲ. 脅威ソースの分析
ⅳ. 脅威検知能力の取込
ⅴ. すべての機器に関する影響度評価
C. 保護／対応／復旧
ⅰ. 補完的制御の評価(検知／対応)
D. 安全性と不可欠なパフォーマンスのリスク低減策

　このうち、「Ⅴ. 一般原則」の「A. 市販前の考慮事項」では、医療機器市販前の考慮事項として、以下のような点を挙げている。

• 資産、脅威、脆弱性の特定
• 機器の機能とエンドユーザー／患者における脅威や脆弱性の影響度評価
• 脅威や脆弱性が悪用される確率の評価
• リスクのレベルと適切な低減戦略の決定
• 残存リスクと許容リスクの基準の評価

また、B. 医療機器市販後の考慮事項」では、以下のような点を挙げている。

• サイバーセキュリティの脆弱性とリスクの特定・検知に関するサイバーセキュリティ情報ソースのモニタリング
• 以下のようなメカニズムを含む堅牢なソフトウェアライフサイクルプロセスの維持
  • -機器のトータル製品ライフサイクルを通した新たな脆弱性の関するサードパーティ製ソフトウェアコンポーネントのモニタリング
  • -汎用(OTS)ソフトウェア関連など、脆弱性の救済に利用されるソフトウェアのアップデートやパッチに関する検証やバリデーションの設計
• 脆弱性の存在や影響度に対する理解、評価、検知
• 脆弱性の取込や処理に関するプロセスの確立と伝達
  • (注: FDAは、「ISO/IEC 30111:2013: 情報技術 – セキュリティ技法 – 脆弱性対応手順」を認知してきた)
• サイバーセキュリティリスクから保護、対応、復旧する低減策の構築によって、機器の安全性および不可欠なパフォーマンスを維持する方法を明確に規定するための脅威モデリング利用
• 協調的脆弱性開示ポリシーおよびプラクティスの採用(FDAは、「ISO/IEC 29147:2014: 情報技術-セキュリティ技法- 製造業者にとって有益な可能性がある脆弱性開示」を認知してきた)
• 初期および悪用される前にサイバーセキュリティリスクに取組む低減策の展開

なおFDAの市販後ガイダンスでは、「脅威モデリング」について、目標と脆弱性を特定し、システムに対する脅威の影響を防止または低減する対策を明確にすることによって、ネットワーク／アプリケーション／インターネットセキュリティを最適化するための手法と明記している。医療機器の場合、生産ラインにある製品や、患者に害を引き起こす可能性がある組織のサプライチェーンから、特定製品に対する脆弱性や脅威を明らかにすることによって、セキュリティ強化のために脅威モデリングを利用できるとしている。

そして、製造業者に対し、個々の機器向けの脅威モデリングを含むサイバーセキュリティリスク分析を実行し、これらの分析を経時的にアップデートするよう推奨している。脅威モデリングは、伝統的なリスクマネジメントと故障モード分析のパラダイム、そして、活発な敵対者／悪意ある利用からの脅威を評価するフレームワークを提供するものである。個々の脆弱性に関して、リスク分析と脅威モデリングの情報を簡潔に要約したサマリーレポートを作成すべきだとしている。また、分析の周期的な性質上、情報は、関連した文書化に追跡可能であるべきだとしている。

参考までに、日本の厚生労働省が、2023年3月に公表した「医療機器のサイバーセキュリティ導入に関する手引書(第2版)」(https://www.mhlw.go.jp/content/11120000/001094636.pdf)をみると、「5. 市販前の考慮事項」の「5.1. セキュリティ要求事項及びアーキテクチャ設計」の中で、脅威モデリングに関する記述があるが、「6. 市販後の考慮事項」にはそのような記述が見当たらない。

MITREの医療機器向け脅威モデリングガイダンス

FDAのガイダンスを受けてMITREは、2021年11月30日、医療機器イノベーションコンソーシアム（MDIC）と共同で「医療機器脅威モデリングプレイブック」(https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices)を公開している。このプレイブックは、FDAの資金助成を受けて、MITRE、MDIC、脅威モデリングの第一人者であるアダム・ショスタック氏が連携し、医療機器エコシステムを通して脅威モデリングに関する知識と理解を向上させるために実施した脅威モデリングブートキャンプの知見に基づいて開発されたものである。

プレイブックでは、「脅威モデリング」について、セキュリティ及びプライバシーの特性に関する懸念に焦点を当てたシステム表現の分析だとしている。ハイレベルでみると、脅威モデリングを行う際に、以下の4つの設問に答えることが必要だとしている。

設問1. 我々は何に関する作業を行っているのか？

設問2: 何が悪い結果をもたらし得るか?

設問3: 我々はそれに関して何をしているか？

設問4: 我々はよい仕事をしたか?

そして、各ステークホルダーが以下に挙げるような活動を行う際に、プレイブックを役立てることができるとしている。

• 製品ラインマネージャーが、脅威モデリングを既存のプロセスに適合させる方法を理解する
• システムエンジニアが、脅威モデリングを設計要求事項の中で周知する方法を理解する
• 設計エンジニアやアーキテクトが、脅威モデリングを設計上の選択に周知する方法を理解する
• 設計検証／妥当性確認(V＆V)エンジニアが、設計テスト戦略に脅威モデルを利用する方法を理解する
• 規制専門家が、脅威モデルを表現し、文書化する方法を理解する
• 脅威モデリングの経験がない可能性がある外部委託先製造業者やコンサルタントと契約する

プレイブックでは、脅威モデリングを実行する時、システムにどんな問題が起こり得るかを認識し始めることになるとしている。また、システムのライフサイクルにおける早期段階か、それとも全体を通してかどうかなど、低減策を必要とするような設計・実装時の課題を指摘することを可能にする。脅威モデルのアウトプットは、脅威として知られており、あとに続く設計、開発、検証、実装後フェーズにおいて行う可能性がある意思決定に必要な情報を提供するものとなる。

なお、「医療機器脅威モデリングプレイブック」は、以下のような構成になっている。

1. イントロダクション

1.1. プレイブックの開発

1.2. プレイブックの利用

2. 脅威モデリングの概要

2.1. 架空の事例1: 脳卒中向け足関節モニター予測機器(AMPS)

2.2. 4つの設問(概要)

2.3. 設問1. 我々は何に関する作業を行っているのか？

2.3.1. データフローダイアグラムによる構造化モデリング

2.3.2. スイムレーン図と状態遷移図による構造化モデリング

2.3.3. 多重モデリング手法の活用

2.3.4. 次の段階に移行する時を知るためのティップス

2.4. 設問2: 何が悪い結果をもたらし得るか?

2.4.1. STRIDEによる脅威の特定

2.4.2. (事例) STRIDEのAMPSシステムへの適用

2.4.3. アタックツリーによる脅威の特定

2.4.4. キルチェーンとサイバー攻撃ライフサイクルによる脅威の特定

2.4.5. ATT&CKフレームワーク

2.4.6. 想定と結果の文書化のためのティップス

2.5. 設問3: 我々はそれに関して何をしているか？

2.5.1. 除去のアプローチ

2.5.2. 低減のアプローチ

2.5.3. 受容のアプローチ

2.5.4. 転嫁のアプローチ

2.5.5. リスク低減戦略のトラッキング、文書化、評価

2.5.6. 脅威からのリスクの決定と順位付け

2.6. 設問4: 我々はよい仕事をしたか?

2.6.1. “よい仕事”向けのフィードバック・ソース

2.6.2. 文書化における”よい仕事”の評価向けのチェックリスト

3. 脅威モデリング実装のための考慮事項

3.1. 脅威モデリングと製品安全リスク管理(品質システム)

3.1.1. 脅威モデリングとサイバーセキュリティリスクモデリング

3.1.2. 脅威モデリングのセキュリティリスク評価へのマッピング

3.2. 組織の採用

3.2.1. 組織的アプローチ

3.2.2. 課題と現行のプラクティス

4. 要約

附表A. 追加的な架空の医療機器事例

A.1.1. 架空事例2: 脳卒中向け神経情動撮影システム(SNAP)

A.1.2. 架空事例3: 脳卒中向け足関節・つま先運動エクササイズ機器(SKATE)

附表B. 架空の医療機器事例からの追加的考慮事項

附表C. 参考文献

プレイブックでは、データフローダイアグラム(DFD)、スイムレーン図、状態遷移図、STRIDE (S:なりすまし、T: 改ざん、R:否認、I:情報漏えい、D:サービス拒否、E:権限昇格）、キルチェーンといった脅威分析手法を医療機器セキュリティの領域に適用している。

また、「3. 脅威モデリング実装のための考慮事項」では、「ISO 14971:2019(JIS T 14971:2020) 医療機器 – リスクマネジメントの医療機器への適用」に準拠しながら、脅威モデリングを製品安全リスクマネジメントプロセスに統合する方法に焦点を当てている。ここでは、危険および危険な状態の特定に基づいて、医療機器の安全性のリスクを評価するためのプロセスや、害をもたらす可能性がある一連のイベントを定義している。個々の危険な状態は、危険の重大度と危険が発生する確率の組合せで推定される。サイバーセキュリティのリスク評価も似ているが、必ずしも同じではない。サイバーセキュリティリスクが害をもたらす確率や可能性を推定することは困難であり、悪意のあるアクターの評価ができないために、誤った方向に導かれる可能性がある。

このような状況下で、脅威モデリングは、医療機器およびそれが稼働するネットワーク化された臨床環境に対するサイバーセキュリティ脆弱性や弱点、脅威をシステマチックに特定する有益なアプローチを提供する。また、脅威モデリングは、悪用の可能性、そして順番に緊急の必要性を評価するのに役立つ。製造業者は、機器のリスク管理全体へのインプットとして、脅威モデルを利用することができる。たとえば、サイバーセキュリティリスクを特定し、これらのリスクを制御するための最善のアプローチを決定し、リスクが安全上の懸念を示す可能性がある時を決定し、セキュリティや安全性の制御によってもたらされる潜在的リスクを評価することが可能である。

「AAMI TIR57: 医療機器サイバーセキュリティの原則 – リスクマネジメント」および米国医療・公衆衛生セクター調整委員会(HSCC)・共同サイバーセキュリティワーキンググループの「医療機器・医療IT共同セキュリティ計画(JSP)」の双方とも、サイバーセキュリティリスク管理とリスク評価向けに、ISO 14971リスクマネジメント原則適用のためのフレームワークを推奨している。一般的に、リスク管理プロセスは、リスク分析から始まり、リスク評価が続いて、必要があれば、制御対策を実装する。このプロセスで重要なのは、リスク制御対策が、新たなリスク源をもたらさないよう保証することだとしている。その他のリスク管理プロセスには、設計要求事項のバリデーション・検証と、市販後モニタリングが含まれる。

加えて、「附表B. 架空の医療機器事例からの追加的考慮事項」では、以下のような考慮事項を挙げている。

• 故障モードは、必ずしも直ちに表面化するとは限らない
• サイレントリスクの転嫁を回避する
• 外部主体との間で確立されたコネクションに細心の注意を払う
• クラウドは、必ずしも排他的に外部主体であるとは限らない
• 重要なデータフローをエンドツーエンドで特定し、文書化する
• セキュリティ制御が最も効果的に実装された可能性のある信頼境界に焦点を当てる
• すべての特定された脅威が文書化されていることを保証する
• 脅威に取組むための戦略の強さを過大評価しない
• 脅威モデリングプロセスの脅威モデル
• すべてのモデルが誤っていても、中には有益なモデルがあることを忘れてはならない

専門チームによるクラウド固有の考慮事項に配慮した脅威モデリングが必要

クラウド環境の脅威モデリングに関連して、CSAのトップスレッドワーキンググループは、2021年7月29日、「クラウド脅威モデリング」(原文: https://cloudsecurityalliance.org/artifacts/cloud-threat-modeling/、日本語版: https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/10/Cloud-Threat-Modeling_J.pdf)を公開している。本文書は、クラウドのアプリケーション、サービス、およびセキュリティに関する意思決定において、脅威モデリングを可能にし、推奨することを目的としており、以下のような構成になっている。

• はじめに
• 目的
• 想定読者
• 主な論点
• 脅威モデリング
• 脅威モデリングの目的：
• コアとなる脅威モデリングの取り組み：
• クラウド脅威モデリング
• クラウド脅威モデリングの目的は、非クラウド脅威モデリングとは異なりますか？
• クラウド脅威モデリングプロセス
• クラウド脅威モデルの作成
• どのようにしてゼロから始めるか
• クラウド脅威モデルリファレンス
• おわりに
• 付録1：脅威モデリングレポート作成に関する詳細なガイダンス
• 付録2: クラウド脅威モデリングカード

クラウド環境の脅威モデリングでも、オンプレミス環境時と同様の手法を利用するが、以下のようなクラウド固有の考慮事項に配慮する必要があるとしている。

• 範囲: クラウドのシステムやサービスの脅威モデリングの範囲に関する考慮事項として、アイデンティティ管理、クラウドサービス構成、さらには基盤となるクラウドアカウントについて考慮する
• 資産: データ、主要なシステムコンポーネント、金銭的な価値のある機器、及びアイデンティティに加えて、クラウドアカウント、SaaS サブスクリプション、サービスといった新しい資産も導入されている
• 脅威: クラウドシステム、アプリケーション、および環境に対する脅威に加えて、インスタンスメタデータサービスやクロスアカウント IAM アクセスフェデレーションなどの新技術が登場しており、様々な攻撃がそれらに対して実行可能である
• 実施されるコントロール: クラウドのシステムやサービスは、組み込まれたコントロールの恩恵を受けるが、クラウドサービスプロバイダー(CSP)に組み込まれている場合もあれば、CSP の責任範囲から外れている場合もある
• 格付け: クラウドを範囲内にするかどうかに関係なく、重大度による脅威の格付けは必要であり、同じ考慮事項が適用される(システムが特定の脅威に対してどれほど脆弱であるか、どの資産が影響を受けるか、そしてどの程度か。クラウドアカウント、システム、およびサービス品質によって、クラウドにおいて本質的に深刻な脅威もあれば、そうでないものもある)
• 提案される緩和策: 異なる脅威にさらされていることから、クラウドのシステムやアプリケーションによって大きく異なり、特定のクラウドシステムやアカウントでしか利用・適用できない対策(例. AWS アカウントのサービスコントロールポリシー)や、新しい独自技術(例.メタデータサービス保護、CSPM5）も考慮に入れる必要がある

クラウド脅威モデリングの成果物やアウトプットは、オンプレミス環境の場合と同様であり、以下のようなものがある。

1.  脅威モデル(Excel シートまたはツリー型マッピングなどのビジュアルモデルを介して提示される)
2.  優先順位がランク付けされた緩和コントロール
3. セキュリティとデザイン上の決定、またはより明確かつ詳細な実施項目

クラウド脅威モデルの構築に関しては、システムの全体的なアーキテクチャ、コンポーネント／サービス、インフラストラクチャ、ビジネス状況の理解と、対象システムまたは設計に関連する敵対的な視点を有するセキュリティとクラウドの専門人材から構成されるチームが、責任を持つべきだとしている。

クラウドを利用した医療機器やロボット支援手術システム、SaMD(Software as a Medical Device)などの脅威モデリングにおいても、同様のことが当てはまるが、日本国内の研究開発や臨床開発の現場では、それに必要な人材や経験、知見が圧倒的に不足している。

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

ゲノムデータベース利活用のエコシステムでは、産官学の様々な組織・コミュニティの専門家がアクセスし、共同作業を行う形態が多く見られる。そこで大きな課題となるのがアクセス制御に代表されるアンデンティティ／アクセス管理である。

CSAガイダンスからみたアンデンティティ／アクセス管理

はじめに、クラウドセキュリティアライアンス(CSA)が2011年11月に公開した「クラウドコンピューティングのためのセキュリティガイダンス V3.0」(https://www.cloudsecurityalliance.jp/j-docs/csaguide.v3.0.1_J.pdf)では、　「第12章 アイデンティティ、権限付与、アクセス管理」において、以下のような内容で概説している。

12.1 この文書で使用する用語
12.2 クラウド環境におけるアイデンティティ序論
12.3 クラウド用のアイデンティティアーキテクチャ
12.4 アイデンティティ連携
12.5 アイデンティティと属性のプロビジョニングとガバナンス
12.6 権限付与プロセス
12.7 承認とアクセス管理
12.8 アイデンティティと属性の提供者とインタフェースするためのアーキテクチャ
12.9 アイデンティティと属性の信頼レベル
12.10 クラウドシステム上のアカウントプロビジョニング
12.11 Identity-as-a-Service
12.12 コンプライアンスと監査 (IDaaS)
12.13 アイデンティティのためのアプリケーション設計
12.14 アイデンティティとデータ保護
12.15 利用者化とアイデンティティの挑戦
12.16 アイデンティティサービス提供者
12.17 推奨事項

次に、CSAが2017年7月26日に公開した「クラウドコンピューティングのための
セキュリティガイダンス v4.0」(https://cloudsecurityalliance.jp/j-docs/CSA_Guidance_V4.0_J_V1.1_20180724.pdf)では、「DOMAIN 12 アイデンティティ管理、権限付与管理、アクセス管理」において、以下のような内容で概説している。

12.0 はじめに
12.0.1 クラウドにおけるIAMの違いは何か
12.1 概要
12.1.1 クラウドコンピューティングにおけるIAM標準
12.1.2 クラウドコンピューティングのためのユーザ、アイデンティティ管理
12.1.3 認証と資格情報
12.1.4 権限付与管理とアクセス管理
12.1.5 特権ユーザ管理
12.2 推奨事項

• CSAガイダンス v4.0では、以下のような、アイデンティティ管理、権限付与管理、アクセス管理の推奨事項を提示している。
• 組織は、クラウドサービスでアイデンティティと認可を管理するための包括的かつ公式な計画とプロセスを開発する必要がある。
• 外部のクラウド事業者に接続する場合は、可能であれば ID 連携を使用して、既存のアイデンティティ管理を拡張する。内部のアイデンティティに結びついていないクラウドプロバイダ固有のアイデンティティ管理を最小限に抑えるようにする。
• 適切であれば 、アイデンティティブローカの使用を検討する。
• クラウド利用者は、アイデンティティプロバイダを管理しアイデンティティと属性を定義する責任を負う。
• これらは権威のあるルートソースに基づくべきである。
• オンプレミスのディレクトリサーバが利用できないあるいは要件を満たしていない場合、分散した組織ではクラウドホスト型のディレクトリサーバの使用を検討する必要がある。
• クラウド利用者は、すべての外部のクラウドアカウントに対して多要素認証(MFA)を選択し、認証連携を使用する場合にはMFAステータスを属性として送信するべきである。
• 特権を持つアイデンティティは、常にMFAを使用することが望ましい。
• クラウド事業者とプロジェクト毎に、メタ構造や管理プレーンへのアクセスに重点をおいた権限付与マトリクスを開発すること。
• クラウド事業者またはプラットフォームでサポートされている場合は、権限付与マトリクスを技術ポリシーに組み入れること。
• クラウドコンピューティングではロールベースアクセス制御(RBAC)より属性ベースアクセス制御(ABAC)を優先すること 。
• クラウド事業者は、オープンな標準に基づく内部アイデンティティと ID連携の両方を提供する必要がある。
• 魔法のプロトコルはない。まず、ユースケースを取り上げて制約条件を洗い出し、次に適切なプロトコルを見つけること 。

米国防総省の調達基準としての多層防御型ICAM戦略

他方、アクセス制御に関連して米国防総省(DoD)は、2020年3月30日、「アイデンティティ・資格情報・アクセス管理(ICAM)戦略」(https://dodcio.defense.gov/Portals/0/Documents/Cyber/ICAM_Strategy.pdf)を策定している。

この中で国防総省は、イデンティティ・資格情報・アクセス管理(ICAM)について、デジタルアイデンティティの生成および関連する属性の維持に関連する幅広い範囲の活動であり、人間／人間以外の主体向けの資格情報の発行、資格情報を利用した認証、認証されたアイデンティティおよび関連する属性に基づくアクセス管理制御に係る意思決定だとしている。その上で、以下のようなICAM戦略の目標を掲げている。

・目標1: データ中心のアプローチを実装して、アイデンティティおよびその他の属性を収集、検証、維持、共有する

• 目標1.1: 収集時の属性データを検証するための標準規格を設定して、属性データの正確性を維持し、すべてのローカルデータレポジトリの改ざんに対して属性値を保護する
• 目標1.2: 属性データの共有に関する意思決定をする際に、データレポジトリを利用するためのプロセスやサービスレベルアグリーメント(SLAs)の言語を設定する
• 目標1.3: 信頼されるレポジトリへの書込みアクセス向けの標準規格を設定する

・目標2: 共通の標準規格、共有サービス、連携を通して、DoDネットワークおよびリソースへの認証を向上し、可能なものにする

• 目標2.1: アプリケーションオーナーが、DoDおよび外部の資格情報を活用して、DoDネットワークやリソースにアクセスするためのリスクベースのガイドラインを開発・維持する
• 目標2.2: DoD従業員、外部委託先、退職者、扶養家族など、すべてのタイプのユーザおよびすべての環境向けに資格情報を提供するケーパビリティを実装する
• 目標2.3: クラウドサービスをサポートするためのICMケーパビリティを実装する
• 目標2.4: DoDネットワークの境界で、連携した外部信用情報を介して、米国政府、米国以外の政府、商用パートナーなど、認証されたミッションパートナー向けの共有サービスを実装する

・目標3: 共有サービスを実装して、エンタープライズICAMの導入を促進する

• 目標3.1: 法律、規制、ポリシー、ミッション、リソースへのアクセスを統治するローカルの要求事項を統合するデジタルポリシーフレームワークを設定する
• 目標3.2: DoDリソースへのアクセスのためのコアのデジタルポリシールールを実装するために必要な属性および値を設定する
• 目標3.3: DoD内部およびミッションパートナーとの間双方で属性を交換するためのシンタックスおよびセマンティックを定義する
• 目標3.4: 属性交換、デジタルポリシー管理、ポリシー意思決定など、プロビジョニング自動化・動的アクセス制御を導入するために、エンタープライズ共有サービスを実装する

・目標4:インサイダー脅威および外部攻撃を検知するために、一貫したモニタリングとロギングを可能にする

• 目標4.1: 情報リソース、ミッション、データに対するアクセス、特権、リスクの評価および考慮をサポートするために、DoDマスタユーザレコードを設定し、進化させる
• 目標4.2: 認可データを提供して、特別なインシデント、不適切な認可、行動異常の周りで協働するための監査体制を認める
• 目標4.3: 現代化した監査のケーパビリティに対するICAMインフラストラクチャのサポートを進化させる
• 目標4.4: ミッションパートナーとともに、協働型監査をサポートする

・目標5:エンタープライズICAMソリューションの開発・採用を促進するために、ガバナンス構造を強化する

• 目標5.1: エンタープライズICAMソリューションの定義・実装に関するDoD CIOやUSCCと、サービスおよび政府機関の責任を定義する
• 目標5.2: サービスおよび政府機関のステークホルダー間のコミュニケーションや協力関係を促進するために、統合プログラムチーム(IPT)を構築する
• 目標5.3: コアのジョブ機能としてICAMを促進するために、トレーニングおよびパフォーマンス管理を特定する
• 目標5.4: 現行のICAM関連活動の実装・維持への支出に関するエンタープライズ全体の見積を策定する

・目標6:アイデンティフィケーション、資格証明、認証、認可のライフサイクル管理向けの要求事項を明確に定義するために、DoDポリシーおよび標準規格を構築する

• 目標6.1: 外部発行の資格情報との相互運用性など、リスクのレベルおよび環境的な制約上、適切な資格証明技術の利用をサポートするために、既存のDoDポリシーをアップデートする
• 目標6.2: 情報システムが　資格証明、認証、認可向けのDoDエンタープライズソリューションの利用をサポートすることを実現するために必要なDoDポリシーを構築する
• 目標6.3: 連携、相互運用性、資格証明、認証、認可、予期せぬユーザ向けサポートに関する国防総省全体の技術標準規格を定義し、維持する
• 目標6.4: データへのアクセスを許可するために、属性やデジタルポリシールールを活用する際に、リスク管理および責任のためのDoDポリシーを構築する
• 目標6.5: すべての情報システム向けの調達プロセスへのICAM標準規格の強制を取り入れる
• 目標6.6: エンタープライズICAMの達成に向けて、進歩を実証・追跡するメトリクスを特定し、収集する

・目標7: ミッションの目標を実行するというDoDコンポーネントのニーズと、DoDリソースを確保するというDoDエンタープライズのニーズをサポートするために、ICAM活動の実行と進化を維持する

• 目標7.1: ミッションの目標をサポートするICAMケーパビリティの統合を保証するために、DoDエンタープライズICAMサービスの実装を調整する
• 目標7.2: ミッションの目標を達成し、特定された要求事項を優先順位付けし、適切な実装向けエンタープライズサービスと要求事項を調整するために、DoDコンポーネントが必要とするICAM関連要求事項を収集し、関係づけるようなプロセスを設定し、維持する
• 目標7.3: 継続的な改善手法をICAMエンタープライズサービスに取り入れることによって、技術進歩を取り入れるとともに、進化するDoDコンポーネントのミッションの要求事項に取組むために、維持モードにおけるサービスを評価して改善できるようにする
• 目標7.4: ICAM関連プロセスおよび技術: ICAM関連プロセスおよび技術を専門とするサイバー労働力の開発・維持に投資する
• 目標7.5: 作戦保全(OPSEC)を、ICAM関連活動の計画策定、実行、評価に統合する

国防総省は、ICAM戦略を調達基準の一部と位置づけて、属性ベースアクセス制御(ABAC)に必要な基盤構築や、マルチステークホルダーエコシステムを前提とする監査対応準備など、多層防御的なソリューションを積極的に実装・運用している。

ICAM実装支援のための参照設計書を開発・提供

ICAM戦略を受けて、国防総省CIO室(DoD CIO)は、2020年6月に「DoDエンタープライズのアイデンティティ・資格情報・アクセス管理(ICAM)参照設計」(https://dodcio.defense.gov/Portals/0/Documents/Cyber/DoD_Enterprise_ICAM_Reference_Design.pdf) を策定している。本参照設計書では、以下のような目的を掲げている。

• ミッションのオーナーが、ミッションパートナーによる認可されたアクセスの実現など、ミッションのニーズを満たせるように、ICAM要求事項を理解し、現状および計画におけるDoDエンタープライズICAMサービスを記述することによって、ICAM実装に関する意思決定を可能にするよう支援する
• DoDエンタープライズICAMサービスのオーナーやオペレーターが、これらのサービスを有効に相互作用させてICAMケーパビリティをサポートできるよう支援する
• DoDエンタープライズサービスがミッションのニーズを満たさない場合、DoDコンポーネントが、DoDエンタープライズICAMサービスを利用する方法や、DoDコンポーネント、COIまたはローカルレベルのICAMサービスを運用する方法を理解する際にサポートする

その上で、本参照設計書は、以下のような構成になっている。
（DISA＝国防情報システムセンター、DMDC＝国防マンパワーデータセンター、NSA＝国家安全保障局）

1.イントロダクション

• 1.1目的
• 1.2適用
• 1.3 DoDコミュニティ
• 1.3.1. DoD内部コミュニティ
• 1.3.2. 外部ミッションパートナー・コミュニティ
• 1.3.3. 受益者
• 1.3.4. 他の主体
• 1.4 DoDの計算処理環境
• 1.5参考文献

2. ICAMケーパビリティの概要

• 2.1 トランスフォーメーションの目標
• 2.2 ICAMケーパビリティ分類の概要(DoDAF CV-2)
• 2.2.1. コアICAMケーパビリティ
• 2.2.1.1 アイデンティティ管理
• 2.2.1.2 資格情報管理
• 2.2.1.3 アクセス管理
• 2.2.2. アクセス説明責任ケーパビリティ
• 2.2.2.1 ログ収集と集約
• 2.2.2.2 アクセスのレビュー
• 2.2.2.3 アイデンティティの解決
• 2.2.3. コンタクトデータ・ケーパビリティ
• 2.2.3.1 コンタクトデータの収集
• 2.2.3.2 コンタクトデータ・ロックアップ
• 2.3 DoDエンタープライズICAMサービスの利用
• 2.3.1. DoDエンタープライズICAMサービスの利用からのDoDエンタープライズのベネフィット
• 2.3.2 DoDエンタープライズICAMサービスの利用からの情報システムのベネフィット
• 2.3.3 DoDエンタープライズICAMサービスの利用に対する課題の低減

3. ICAMデータフロー

• 3.1 コアICAMケーパビリティ
• 3.1.1. アイデンティティ管理
• 3.1.1.1 人間主体
• 3.1.1.2 人間以外の主体(NPE)
• 3.1.1.3 連携主体
• 3.1.2. 資格情報管理
• 3.1.2.1 内部資格情報管理
• 3.1.2.2 外部資格情報登録
• 3.1.3. アクセス管理
• 3.1.3.1 リソースアクセス管理
• 3.1.3.2 プロビジョニング
• 3.1.3.3 認証
• 3.1.3.4 認可
• 3.2 アクセス説明責任ケーパビリティ
• 3.2.1. ログの収集と集約
• 3.2.2. アクセスのレビュー
• 3.2.3. アイデンティティの解決
• 3.3 コンタクトデータ・ケーパビリティ

4. ICAMパターンと関連するユースケース

• 4.1 アイデンティティと資格情報のパターン
• 4.1.1. 非機密エンタープライズDoDの内部初期登録
• 4.1.2. 非機密エンタープライズミッションパートナー主体の登録
• 4.1.3. 利害関係ユーザコミュニティの登録
• 4.1.4. 利害関係人間主体アイデンティティプロバイダの登録
• 4.1.5. DoDおよび連邦政府機関向け機密エンタープライズ登録
• 4.1.6. 連邦政府機関以外のミッションパートナー主体向けの機密エンタープライズ登録
• 4.1.7. 短期の人間以外の主体(NPE)の登録
• 4.1.8. DoD受益者の登録
• 4.1.9. DoD応募者の登録
• 4.2 アクセス管理のパターン
• 4.2.1. DoD管理下のリソースへのアクセス
• 4.2.2. 予期せぬ主体向けのアクセス
• 4.2.3. 特権ユーザアクセス
• 4.2.4. ゼロトラスト
• 4.2.5. Software as a Service (SaaS)クラウドマネージドシステムへのアクセス
• 4.3 アクセス説明責任のパターン
• 4.3.1. ロギングとモニタリング
• 4.3.2. アクセスのレビュー
• 4.3.3. アイデンティティの解決
• 4.4 コンタクトデータ・ルックアップ

5. DoDエンタープライズICAMサービス

• 5.1 DoD ICAMエンタープライズサービスの概要
• 5.2 プロダクションDoD ICAMエンタープライズサービス
• 5.2.1. 個人データレポジトリ(PDR) (*DMDCが運用)
• 5.2.2. アイデンティティ解決サービス(*DMDCが運用)
• 5.2.3. トラステッド・アソシエイト・スポンサー・プログラム(TASS) (*DMDCが運用)
• 5.2.4. DoD公開鍵インフラストラクチャ(PKI)(*DISAとNSAが運用)
• 5.2.5 リアルタイムの自動本人確認システム(RAPIDS) (*DMDCが運用)
• 5.2.6. 非機密インターネットプロトコルルータ(NIPRNet)エンタープライズ代替トークンシステム(NEATS)／代替トークン発行管理システム(ATIMS) (*DMDCが運用)
• 5.2.7. Purebred (*DISAが運用)
• 5.2.8. DoDセルフサービス(DS)ログオン(*DMDCが運用)
• 5.2.9. エンタープライズアイデンティティ属性サービス(EIAS) (*DMDCが運用)
• 5.2.10. アイデンティティ同期サービス(IdSS)(*DMDCが運用)
• 5.2.11. milConnect(*DMDCが運用)
• 5.2.12. エンタープライズディレクトリサービス(EDS)(*DISAとDMDCが運用)
• 5.2.13. グローバルディレクトリサービス(GDS)(*DISAが運用)
• 5.3 計画されたDoD ICAMエンタープライズサービス
• 5.3.1. ミッションパートナー登録(MPR)(*DMDCが開発中)
• 5.3.2. アイデンティティプロバイダ(IdP)(*DISAが開発中)
• 5.3.3. 多要素認証(MFA)登録サービス(*DMDCが開発中)
• 5.3.4. EIAS(強化型)
• 5.3.5. バックエンド属性交換(BAE) (*DMDCが運用)
• 5.3.6. DSログイン(強化型)
• 5.3.7. 自動アカウントプロビジョニング(AAP) (*DISAが開発中)
• 5.3.8. マスタユーザレコード(MUR) (*DISAが開発中)

6. ICAM実装責任

• 6.1 DoD ICAM共同プログラム統合室(JPIO)の責任
• 6.2 DoD ICAMサービスプロバイダの責任
• 6.3 DoDコンポーネントの責任
• 6.3.1. DoDコンポーネントレベルのICAMガバナンス
• 6.3.2. DoDエンタープライズICAMサービスのサポート
• 6.3.3. DoDエンタープライズICAMサービスの利用
• 6.3.4. COIとローカルICAMサービスの運用
• 6.4 外部連携ICAMサービスプロバイダに関連する責任

7. ICAMサービスギャップの概要

上記からわかるように、国防総省は、様々なアイデンティティ／アクセス管理関連サービスを開発・運用している。複数サービスが並列する中で、関与する各ステークホルダーの組織的責任体制を明確化しており、国防総省関連のバイオ技術・バイオ製造プロジェクトにおける外部委託先となるユーザ企業にとって参考になる点も多い。

加えて国防総省は、2021年7月29日、「国防総省(DoD)クラウドネイティブ・アクセスポイント(CNAP)参照設計(RD)第1.0版」(https://dodcio.defense.gov/Portals/0/Documents/Library/CNAP_RefDesign_v1.0.pdf)を策定している。CNAPは、ゼロトラストアーキテクチャ(ZTA)を活用して、どこでも、いつでも、どのデバイスからも、認可されたDoDユーザやエンドポイントによる、商用クラウド環境内のDoDリソースへの安全な認可されたアクセスを提供することを目的としている。

この参照設計書は、CNAP内部における一連のケーパビリティ、基盤コンポーネント、データフローを記述し、定義することを目的としている。本書は、CNAPを実装、接続、運用するための論理的設計パターンおよび派生的な参照実装を提供するものであり、戦闘軍司令官、軍事機関、国防情報システム局(DISA)およびその他の国防機関、商用クラウドおよび政府クラウドにおいてDoDリソースへのアクセスを必要とするミッションパートナーを対象としている。

内容

• 1.1. 目的
• 1.2. スコープ
• 1.3. 対象読者
• 1.4. ハイレベルのユーザストーリー

2. 想定と原則

• 2.1 想定
• 2.2 原則

3. ケーパビリティの概要

• 3.1. CNAPケーパビリティ分類の概要(DoDAF CV-2)
• 3.2. コアCNAPケーパビリティ
  • C.1 – 認証・認可された主体
  • C.2 – 認証されたIngress
  • C.3 – 認可されたEgress
  • C.4 – セキュリティのモニタリングとコンプライアンスの強制
  • 3.2.4.1 モニタリングと救済策
  • 3.2.4.2 コンプライアンス監査と強制
  • 3.2.4.3 CSSP／DCOによる統合型可視性
  • 3.2.4.4 継続的な運用認可(cATO)

4. データフロー

• 4.1. CSPポータルアクセス
• 4.2. SaaSアクセス
• 4.3. 認可されたIngress
• 4.4. 認可されたEgress
• 4.5. セキュリティのモニタリングとコンプライアンスの強制

5. 論理的設計パターン

• 5.1. ミッションオーナー(MO)のクラウドエンクレイブへのアクセス
• 5.2. SaaSサービスへのアクセス

6. 実装責任

• 6.1. DoDエンタープライズの責任
• 6.2. ミッションオーナー(MO)の責任
• 6.3. ミッションパートナー
• 6.4. クラウドサービスプロバイダ(CSP)の責任

7. 参考文献

• 附表A – 頭字語
• 附表B – 用語集
• 附表C – 推奨されるポリシーのアップデート

なお、CSAのゼロトラストリサーチ・ワーキンググループでは、ZTワークストリーム・アイデンティティ(ZT3)が、「IAM向けのゼロトラスト原則とガイダンス」を作成中であり、近日中に公開予定である（https://cloudsecurityalliance.org/artifacts/zero-trust-principles-and-guidance-for-iam/）。この作成作業においても、国防総省の各種ドキュメントが参照されている。これに先立ちCSAでは、「ゼロトラストアーキテクチャにおける医療機器」(https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/05/Medical-Devices-In-A-Zero-Trust-Architecture_050423-J.pdf)を公開している。

米国の場合、連邦政府機関のみならず、大規模な医療施設や教育・研究機関においても、ゼロトラストアーキテクチャの実装に向けた動きが活発化している。ゼロトラストアーキテクチャは、アクセス制御と密接に関わっており、この領域での新たなソリューション開発に対する期待が高まりつつある。

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

次世代シーケンサーや再生医療に代表されるバイオ技術／バイオ製造の領域では、電子制御技術／OTと情報通信技術／ITの融合が進む一方、セーフティとサイバーセキュリティの両面でリスクをどのように管理するかが大きな課題となっている。

大統領令で加速した米国のバイオ技術／製造R&D推進策

2022年9月12日、米国大統領行政府は、「持続可能な安全でセキュアな米国のバイオエコノミーのために進化するバイオ技術／バイオ製造に関する大統領令」（関連情報）を発表した（https://www.whitehouse.gov/briefing-room/presidential-actions/2022/09/12/executive-order-on-advancing-biotechnology-and-biomanufacturing-innovation-for-a-sustainable-safe-and-secure-american-bioeconomy/）。この大統領令は、以下のような構成になっている。

第1条．政策
第2条．調整
第3条．さらなる社会的目標に向けたバイオ技術／バイオ製造R&Dの利用
第4条．バイオエコノミーのためのデータ
第5条．活気のある国内バイオ製造エコシステムの構築
第6条．バイオベース製品の調達
第7条．バイオ技術／バイオ製造の労働力
第8条．バイオ技術規制の明確性と効率性
第9条．バイオセーフティとバイオセキュリティの進化によるリスクの低減
第10条．バイオエコノミーの評価
第11条．米国のバイオエコノミーに対する脅威の評価
第12条．国際的な関与
第13条．定義
第14条．一般規定

サイバーセキュリティ／プライバシー保護の観点から大統領令をみると、「第1条．政策」の中で、以下のような政策を掲げている。

（b）バイオ技術／バイオ製造のイノベーションを進化させる生物学データエコシステムを促進する一方、セキュリティ、プライバシー、責任ある研究規範の原則を順守する
（j）脅威やリスク、潜在的脆弱性（外国の敵対者によるデジタル侵入、操作、流出の取組など）を評価、予想することによって、また、技術的リーダーシップや経済的競争力の保護目的で共同してリスクを低減するために、民間セクターおよびその他の主要なステークホルダーと連携することによって、前向きでプロアクティブなアプローチを採用し、米国のバイオエコノミーをセキュアにし、保護する
（k）米国の原則や価値と一貫した方法で、また安全でセキュアなバイオ技術／バイオ製造の研究やイノベーション、製品開発、利用のためのベストプラクティスを促進する方法で、バイオ技術R&Dにおける協力関係を強化するために、国際的なコミュニティに関与する

さらに、「第4条．バイオエコノミーのためのデータ」では、セキュリティ、プライバシーおよびその他のリスク（悪意のある誤用、操作、流出、削除など）を特定し、これらのリスクを低減するためのデータ保護計画を提供するとしている。また、国土安全保障省長官は、国防総省長官、農務省長官、商務省長官（NIST長官を通じて行動する）、保健福祉省長官、エネルギー省長官、行政管理予算局（OMB）長と調整しながら、国家サイバーセキュリティの向上に関する大統領令第14028号（2021年5月12日付）（https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/）および関連する法律に従って、連邦政府情報システムに保存された生物学的データ向けの適切なサイバーセキュリティベストプラクティスを特定し、提供するとしている。さらに、商務省長官は、NIST長官を通じて行動し、保健福祉省長官と調整しながら、大統領令第14028号の規定に従って、米国連邦政府に販売するソフトウェア開発向けベースラインセキュリティ標準規格を設定する際に、研究器具、計装機器、データマネジメント向けソフトウェアを含むバイオ関連ソフトウェアを考慮すべきであるとしている。

米国防総省のバイオ推進策に組み込まれたサイバーセキュリティ強化

この大統領令を受けて、国防総省（DoD）は、同月14日、「新たなバイオ技術大統領令は、米国の経済・国家安全保障のために国防総省のバイオ技術を進化させる」（https://www.defense.gov/News/Releases/Release/Article/3157504/new-biotechnology-executive-order-will-advance-dod-biotechnology-initiatives-fo/）と題した声明文を発表している。

その中で国防総省は、バイオ製造向けに総額12億米ドルの新規投資を行うことを発表した。新たなバイオ製造能力は、国防総省の複数のミッション領域に渡る物流課題への取組を支援するとしている。具体的なメリットとしては、以下のような点を挙げている。

• 脆弱なサプライチェーンに依存することなく、重要な材料を国内で供給する
• 極超音速機から潜水艦まで、新たな特性を有する材料を開発する
• 材料やエネルギー製品の開発のために、必要なポイントで製造することにより、物流や再供給のタイムラインを大幅に削減する

また、国防総省は、今後5年間で総額10億米ドルをバイオ産業の国内製造インフラストラクチャに投資し、米国のイノベーターがアクセス可能な国内バイオ産業の製造基盤構築を促進する計画を発表した。これが、民間および国防双方のサプライチェーンにとって重要な製品の製造能力を拡大するための官民連携パートナーシップに対するインセンティブとなるとしている。加えて、これらの施設のバイオセキュリティやサイバーセキュリティのポスチャーを強化するために、総額2億米ドルを投入するとしている。

さらに国防総省は、バイオ技術におけるプロトタイピングや運用の実証、迅速な生産を加速させるために、以下のような施策を踏襲するとしている。

• バイオ技術ソリューションをミッションのニーズに結びつけて提供する
• データ共有、標準的なワークフロー、自動化能力を実現する共有基盤により、迅速なプロトタイプのパイプラインを構築する
• バイオ倫理、バイオセーフティ、バイオセキュリティにおいてリードする
• 将来に向けて、多様で学際的な労働力を育成する
• 産業やアカデミック、国際的なパートナーと効果的に連携する

特に、バイオ技術の進化において重要な役割を担うのが、国防総省傘下の製造イノベーション研究所（MIIs）である。ここでは、2016年12月、国防長官府により創設された先進再生製造研究所（ARMI）傘下のBioFabUSA（https://www.armiusa.org/）と、2020年10月に創設されたバイオ産業製造・設計エコシステム（BioMADE）（https://www.biomade.org/）を挙げている。

米国防総省がバイオ製造戦略および付随するRFIを公表

その後2023年3月22日、国防総省傘下の研究工学担当国防次官室は、「国防総省バイオ製造戦略」（https://www.defense.gov/News/Releases/Release/Article/3337235/dod-releases-biomanufacturing-strategy/）を発表した。国防総省のバイオ戦略は、以下の3つの原則より構成される。

• 早期段階のイノベーションのために移行パートナーを確立する：
  本戦略は、バイオ製造能力を求めるDoD顧客の確立がDoD技術投資を導く。早期段階の科学が、作戦指揮官のミッション達成に役立つような能力の進化を目的としている点を保証するために、正式な要求事項の構築プロセスなどを活用する。
• イノベーションの実践と適用を通して、バイオ製造を構築する：
  本原則は、国防総省が、バイオ製造業を国内で構築し、同盟者やパートナーとともに、自立した国内バイオ製造エコシステムを構築して、国防上のニーズを満たすだけでなく、現場における米国の継続的な競争力を保証するよう仕向けるものである。
• バイオ製造エコシステムをマッピングし、将来の国防総省によるバイオ製造R&Dの取組を支援するようなメトリクスを追跡する：
  バイオ製造エコシステムは、比較的新しいため、現行のエコシステムを評価し、構築に合わせて変更を追跡することが不可欠である。それにより、将来の投資を優先順位付けし、導入リスクを低減するのに役立つような知識を提供する。

これと合わせて国防総省は、バイオ製造戦略の支援措置として、国防上のニーズへの取組を支援し、国防総省の投資により開発および商用化の取組が可能となるようなバイオ製造製品およびプロセス能力に関して、正式な情報提供依頼（RFI）（https://sam.gov/opp/8fec24f77b6046c9ae28dc99b2417e42/view）を発出している（募集期間：2023年4月23日まで）。具体的には、バイオ製造に関して、以下のようなソリューションに関する情報を求めている。

• 国防総省が必要とする特殊化学品・素材（例．バイオ製造燃料およびエネルギー前駆体、スパイダーシルク、ポリマー、天然ゴム／ラテックスゴム、溶媒などの生合成ファイバー）を、利用可能で手頃な方法により製造する
• バイオ複合・生体材料（例．強化特性を備えた調整可能な素材、自己修復型素材）を通じた、物流の費用、時間、エネルギーの削減を可能にする
• 持続的な人体及び環境のインテリジェンス（例．水質モニタリング向けセンサー、海事システムにおけるバイオベースのエネルギー採取）のために、一貫したセンシング能力を維持する
• パフォーマンスや保護に影響を及ぼす人間拡張システム（例．テーラーメイドのタンパク質）
• 製品パフォーマンスの要求事項を充足または越えながら、環境面のインパクトを低減するような方法で、国防関連材料の製造を可能にする

国防総省がバイオ技術／製造関連企業に求めるセキュリティ調達要件

政府調達時のサイバーセキュリティ基準からみると、国防総省を含む連邦政府機関のサプライヤーとなる企業は、前提条件として、「NIST SP 800-53 連邦政府情報システム、および連邦組織のためのセキュリティ管理策とプライバシー管理策」(https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)の遵守が不可欠である。加えて、国防総省は、契約企業および再委託先企業に対して、国防総省調達規則附則（DFARS） の要求事項を遵守するよう求めている。国防総省傘下の教育・研究機関や医療施設とバイオ関連製品・サービスについて契約する企業も適用対象となる。

代表的なDFARSとしては、以下のようなものがある。

• DFARS 252.204-7012 適用対象国防情報の保護とサイバーインシデント報告（https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting.）
• DFARS 252.204-7019 NIST SP 800-171 国防総省評価要求事項の通知（https://www.acquisition.gov/dfars/252.204-7019-notice-nistsp-800-171-dod-assessment-requirements.）
• DFARS 252.204-7020 NIST SP 800-171 国防総省評価要求事項（https://www.acquisition.gov/dfars/252.204-7020-nist-sp-800-171dod-assessment-requirements.）
• DFARS 252.204-7021 サイバーセキュリティ成熟度モデル認証要求事項（https://www.acquisition.gov/dfars/252.204-7021-cybersecuritymaturity-model-certification-requirements.）

DFARSが参照する代表的な標準規格としては、「NIST SP 800-171 非連邦政府組織およびシステムにおけるCUI（管理対象非機密情報）の保護」（https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final）や、サイバーセキュリティ成熟度モデル（CMMI）フレームワーク（https://dodcio.defense.gov/CMMC/）がある。なお、NIST SP 800-171については、現在改訂第3版の改定作業が行われており（https://csrc.nist.gov/publications/detail/sp/800-171/rev-3/draft）、今後の動向を注視する必要がある。

国防総省独自のクラウドセキュリティ認証制度とFedRAMPの関係

クラウドセキュリティに関して、国防総省では、連邦情報セキュリティマネジメント法（FISMA）に基づくFedRAMP（Federal Risk and Authorization Management Program）（https://www.fedramp.gov/）とは別個に、国防情報システム局（DISA）が、国防総省指示に基づく「クラウドコンピューティングセキュリティ要求事項ガイド（SRG）」（最新版は2022年1月14日に発行されたVersion 1, Release 4）（https://public.cyber.mil/dccs/）に準拠した認証制度を運用している。最新版のSRGは、以下のような構成になっている。

1. イントロダクション

1.1 目的と対象読者
1.2 権限
1.3 スコープと適用可能性
1.4 SRGs／STIGs
1.5 SRGとSTIGの配分
1.6 文書改定と更新のサイクル
1.7 文書の構成

2. 背景

2.1 重要な用語
2.2 クラウドコンピューティング、クラウドサービスとクラウドデプロイメントモデル
2.3 クラウドサービスプロバイダー（CSP）とクラウドサービスオファリング（CSO）
2.4 国防総省リスク管理フレームワーク（DoD RMF）
2.5 連邦リスク認証管理プログラム（FedRAMP）
2.6 FedRAMP Plus
2.7 国防総省暫定認証

3 情報セキュリティ目標／インパクトレベル

3.1情報インパクトレベル

4. クラウドサービスオファリングのリスク評価／認証

4.1 エンタープライズ利用向け商用および国防総省以外のクラウドサービスの評価
4.2 国防総省編成＆運用部門クラウドサービスおよびエンタープライズサービスアプリケーションの評価
4.3 クラウドサービスオファリングとミッションオーナーのりスク管理
4.4 CSPのCC SRGバージョン／リリースから最新のCC SRGバージョン／リリースへの移行
4.5 RFPへの対応と契約締結に関連する国防総省暫定認証：DFARSの翻訳
4.6 クラウドサービス対マネージドITサービス

5. セキュリティ要求事項

5.1 国防総省のセキュリティ制御関連ポリシー
5.2 法的考慮事項
5.3 継続的評価
5.4 CSPの国防総省公開鍵インフラストラクチャ（PKI）利用
5.5 ポリシー、ガイダンス、運用上の制約
5.6 物理的施設と人員の要求事項
5.7 データ漏えい
5.8クラウドサービスオファリングからの終了のためのデータ検索と破壊
5.9ストレージメディアとハードウェアの再利用と廃棄
5.10 アーキテクチャ
5.11 商用クラウドストレージにおける保存データの暗号化
5.12 バックアップ
5.13 国防総省の契約企業／国防総省コンポーネントのミッションオーナーのパートナーによるクラウドサービスオファリング利用
5.14 クラウドにおける国防総省ミッションオーナーのテストと開発
5.15 ポート、プロトコル、サービス、管理とクラウドベースのシステム／アプリケーション
5.16 モバイルコード
5.17クラウドベースのシステム／アプリケーション向けのレジストリとコネクション
5.18 サプライチェーンリスク管理評価
5.19 電子メールの保護

6. サイバー空間防衛とインシデント対応

6.1 サイバー空間防衛の概要
6.2 クラウドコンピューティング向け情報インパクトレベルの概念変更
6.3 サイバー空間防衛活動
6.4 サイバー空間防衛の役割と責任
6.5 サイバーインシデント報告と対応
6.6 警告、戦術指令と命令
6.7 継続的モニタリング／行動計画とマイルストーン（POA＆Ms）
6.8 計画的停止の通知
6.9 サイバー空間防衛目的のPKI
6.10 脆弱性・脅威情報の共有

附表A. 参考文献
附表B. 用語集
附表C. 役割と責任
附表D. 暫定認証向けCSP評価パラメーター値
附表E. プライバシーオーバーレイ比較のコントロール／コントロール強化表と数値表

当初SRGのインパクトレベルは6段階が設定されていたが、現在はレベル2・4・5・6の4段階が使われている。各レベルの概要は以下の通りである。

• インパクトレベル2：管理対象外非機密情報（FedRAMPモデレートベースライン（MBL）認証）
• インパクトレベル4：管理対象非機密情報または管理対象外陽機密情報（インパクトレベル2認証＋管理対象非機密情報固有のテーラーメイド設定による認証、またはFedRAMPハイベースライン（HBL）認証）
• インパクトレベル5：管理対象非機密情報および非機密国家安全保障情報（U-NSI）／国家安全保障システム（NSS）（インパクトレベル4認証＋国家安全保障システム（NSS）固有のテーラーメイド設定により認証する）
• インパクトレベル6：機密情報でSECRET扱いの国家安全保障システム（NSS）（インパクトレベル5認証＋機密情報のオーバーレイにより認証する）

その他、サイバーセキュリティのベストプラクティスに関連して、米国防総省傘下の国防情報システム局（DISA）は、「セキュリティ技術導入ガイド(STIGs)」（https://public.cyber.mil/stigs/）を公開している。国防総省は、「国防総省指令8500.01」により、DISAに対して、セキュリティ技術導入ガイド（STIG）のほか、コントロール相関識別子（CCI）、セキュリティ要求事項ガイド（SRGs）、そして国防総省のサイバーセキュリティポリシー、標準規格、アーキテクチャ、セキュリティコントロール、バリデーションの手順とともに導入した、一貫性のあるモバイルコードリスクカテゴリ・利用ガイドを構築・維持することを求めている。また同指令は、国防総省コンポーネントに対して、国防総省管轄下のすべてのITが、適用されるSTIGs、セキュリティ構成ガイド、SRGsを遵守するよう求めている。これらの規定は、国防総省向けにバイオ技術／バイオ製造関連製品・サービスを提供するサプライヤー企業にも適用される。

米国立衛生研究所（NIH）で、バイオ技術／バイオ製造領域のサイバーセキュリティに関わる専門家をみると、その多くが国防総省出身者であることがわかる。ミリタリーグレードのサイバーセキュリティ専門家をインハウスに抱えるNIHと同等レベルの体制を、日本国内に構築・運用することは容易でない。ここでキャッチアップできなければ、プラットフォーム力における日米間格差はさらに拡大することになる。日本のバイオテクノロジーは、まさに正念場を迎えている。

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

前編に引き続き、クラウドセキュリティアライアンス（CSA）のヘルス・インフォメーション・マネジメント・ワーキンググループ（HIM-WG）が、2021年10月15日に公開した「医療における情報技術のガバナンス、リスク、コンプライアンス」（https://cloudsecurityalliance.org/artifacts/information-technology-governance-risk-compliance-in-healthcare/）を概説する。

データライフサイクルを起点とする医療のセキュリティリスク管理

前編で取り上げたように、医療提供組織は、データライフサイクルの6ステージを起点として、リスク管理を行うことになる。

1. 生成：新たなデータが生成された時または既存のデータが修正された時
2. 保存：データは、ストレージのレポジトリに関わる
3. 利用：どんな活動でも、データを処理、閲覧または利用する時
4. 共有：データや情報を他者がアクセスできるようにする
5. アーカイブ：長期ストレージに置かれたデータ
6. 破壊：データが必要なくなった時、物理的に破壊する

この文書では、リスクについて、金銭的損失の可能性と捉えており、イベントが収益の減少をもたらす確率だとしている。サイバーセキュリティリスクは、ビジネスリスクのサブセットであり、ビジネス用語で語るべきものだとしている。医療提供組織にとって、情報リスクは組織的リスクの一部であり、その制御の目的はリスクの低減にある。ただし、100％安全な情報システムは存在しないので、受容できるレベルまでリスクを最小化することが目標になる。

リスク選好度（Risk Appetite）／リスク許容度（Risk Tolerance）

リスク選好度は、組織がリスクに対して有する許容範囲であり、組織がどの程度のリスクを受け入れられるか、組織がリスクを管理するためにどの程度の投資や支出ができるかが焦点になる。他方、リスク許容度は、組織が受け入れ可能なリスクの程度または不確実性の程度であり、組織的なリスクの枠組みの不可欠な要素である。組織のリスク許容度のレベルは、受け入れ可能なレベルまでリスクをとれるデータやシステムの量で決まる。明確なリスク許容度のレベルがあれば、経営層が、機密性、完全性、可用性の侵害に対する保護に関して、セキュリティプログラムで組織に要求するレベルを理解していることを意味するとしている。

脅威（Threats）

脅威は、情報の不正アクセス、破壊、開示および／またはサービス拒否（DoS）を介したシステムを通じて、組織の業務や資産、個人またはその他の組織にマイナスの影響を及ぼす可能性がある状況やイベントのことである。医療提供組織は、脅威イベントを理解することによって、特定の脅威ソースに関連する機能を検討することができ、潜在的な攻撃の意図や標的を知ることによって、最も関連する脅威イベントに絞り込むことができるとしている。

脆弱性（Vulnerability）

脆弱性は、脅威ソースにより悪用される可能性がある情報システムやシステムセキュリティ手順、内部統制、実装の弱点である。脆弱性があるからといって攻撃者が利用するとは限らないし、悪用がなければ潜在的な問題にとどまる。情報システム内にある脆弱性は、組織的なガバナンス構造、環境、外部との関係を通じて発見することができる。脆弱性の例としては、以下のようなものがある。

1.  物理的：施錠していないスイッチのある部屋
2. 環境的：洪水
3. 外部との関係：通信障害

イベントが脆弱性を利用するとリスクが発生する。医療提供組織は、脅威モデルを利用して、脅威ソースが脆弱性を悪用する方法を示すことが必要である

発生可能性（Likelihood）

発生可能性は、イベントが発生する確率であり、確率は不確実なイベントの発生可能性または機会である。リスク分析において、脆弱性を悪用する脅威の発生可能性を決定する際には、複数の要因を考慮する。リスク分析者は、脅威インテリジェンスをレビューして、発生確率を決定する際に、脅威の能力、動機づけ、悪用可能性、実装されたこの情報を制御および利用を理解する。分析者は、発生確率を推計するために、以下のような質問に答える必要がある。

1. 悪用は可能か？
   1. 悪用を実行するためには、どんな技術的スキルが要求されるか？　技術的スキルがなくても、誰かが実行できるか、それとも高度なスキルが必要か？
   2. 悪用は、遠隔で実行できるか？
2. 動機は何か？
   1. 活動家からの脅威は？
   2. 悪用は利益のためか？
3. 脆弱性を低減するために、制御を設定しているか？

このような質問への回答により、分析者は悪用の確率を理解できる。本文書では、以下のような数値を評価に当てはめて定量化する手法を提示している。

• 数値：相対的評価指標（説明）
• 0.1：非常に低い（可能性が非常に低い）
• 0.3：低い（可能性が低い）
• 0.5：中程度（やや可能性がある）
• 0.7：高い（可能性が高い）
• 0.9：非常に高い（ほぼ確実）

参考までに、医療における定量的なリスク管理については、米国保健福祉省（HHS）傘下の保健セクター・サイバーセキュリティ調整センター（HC3）が、「医療サイバーセキュリティ向けの定量的なリスク管理」（2020年5月7日）（https://www.hhs.gov/sites/default/files/quantitative-risk-management-for-healthcare-cybersecurity.pdf）を公表している。

影響度（Impact）

確率に加えて重要なファクターが影響度であり、リスクを分類して優先順位付けするのに役立つ。中には、影響度が高いがまれにしか起きないリスクがあり、中程度の影響度だが頻繁に起きるリスクがある。もし、脅威が現実化すれば発生し得る害の大きさが、脅威の影響度である。

医療提供組織は、侵害のように、潜在的に不利益な行動によって影響を受ける方法を明確に定義すべきである。そして、影響を受けたデータに基づいて影響度を決定すべきであるとしている（例．公的に開示可能な情報を含むシステムへの影響度は、機微情報を含むシステムへの影響度よりも小さい）。

リスクプロファイル（Risk Profile）

情報リスクプロファイルには、発生確率が相当高く、それが実現すると保健医療組織の業務に重大な影響を示すような特定の情報リスクファクターに関する現状分析が含まれるべきである。また、リスクの説明は、簡潔で、ビジネスおよび技術双方のリーダーに認識・理解できる言葉で表現されるべきだとしている。

現状の説明には、医療提供組織のリスク管理に対する見方や期待、要求事項（例．ビジネスリーダーやステークホルダーの意見、情報リスク・セキュリティに対する見方、現在のビジネス状況の説明、現在の脅威・脆弱性分析の結果、外部ステークホルダーの期待）を含めるべきであるとしている。

また、医療提供組織には数多くのビジネスプロセスがある反面、それらを保護するリソースや帯域幅には限界があるので、情報リスクプロファイルの中で、業務に重大な影響を及ぼす可能性があるような、最も重要なビジネスプロセスやケーパビリティを特定することが不可欠だとしている。

情報を保護する費用は価値を越えるべきでないというのが、情報リスク管理の基本原則である。情報リスクプロファイルは、データ資産の適正価値を定量化する必要はないが、適正なレベルの分類や制御を定義できるように、一般的な値の説明を作成する必要がある。

情報管理を簡素化するためには、データ処理の要求事項を特定する制御目標や責務に関連した、理解しやすいコンテナに分類することが不可欠である。このための分類スキーマは、情報リスクプロファイルや一般的な医療提供組織の活動に役立つように、できるだけ簡単であるべきである。情報リスクプロファイルには、医療提供組織のデータ分類スキーマと、制御の要求事項および関連する目標の概要を含むべきであるとしている。

参考までに、具体的なサイバーセキュリティ／プライバシー制御に係るリスク管理については、米国標準技術研究所（NIST）の「SP 800-53A Rev. 5 情報システムと組織におけるセキュリティ／プライバシー制御の評価」（2022年1月25日）（https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final）で詳述している。

法令遵守／コンプライアンス（Compliance）

医療の法令遵守は、すべての法的、倫理的、専門的な標準規格を充足するための継続的なプロセスである。すべての医療提供施設は、機密の保健医療情報を取扱うので、米国の医療保険の携行性と責任に関する法律（HIPAA）や欧州連合（EU）の一般データ保護規則（GDPR）に準拠したポリシーの策定・統合が要求される。加えて、医療提供組織は重要インフラに該当するので、データのロケーションや越境移転に関連する法規制を注視する必要がある。

また米国では、新型コロナウイルス感染症（COVID-19）パンデミック緊急対応時に、ホワイトハウスや保健福祉省傘下のメディケア・メディケイド・サービス・センター（CMS）が、医療施設への訪問なしで医師からの医療サービスが受けられる遠隔医療へのアクセス拡大を促進する施策をとった。医療提供組織のサイバーセキュリティポリシーや手順は、このような変化も反映させるべきだとしている。

ここでは、HIPAA規則の遵守項目として、以下のような例を挙げている。

＜リスク評価の実施＞
1. プロジェクトリスク評価を実施する
2. 処理・保存・転送するHIPAAデータを特定する
3. 脆弱性、脅威、リスクを特定する
＜暗号化＞
4. いかなる期間も保護対象保健情報（PHI）を保持する場合、暗号化する
＜システム構成＞
5. PHIにアクセスするシステムはすべて、利用前にハードニングしなければならない
＜ソフトウェア開発プロセス＞
6. アプリケーション開発を内製化する時は、厳格な開発プロセスやセキュアなコーディングガイドラインを利用する
＜セキュアなユーザーアクセス＞
7. すべてのアクセスが固有のアカウント情報を要求することを保証する
8. ソフトウェア展開のアクセス制御を保証する
9. すべての遠隔アクセスに多要素認証が利用されることを保証する
＜ソフトウェアテスト＞
10. 脆弱性スキャニングを実行する
11. ペネトレーションテストを実行する

医療機関の外部委託先としてのクラウド事業者への要求事項

なお、医療提供施設におけるクラウド利用時のセキュリティ／プライバシー対策については、米国保健福祉省（HHS）が、「HIPAAとクラウドコンピューティングに関するガイダンス」（2016年10月7日）（https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html）を公開している。同ガイダンスはQ&A形式で、以下のような構成になっている。

1. HIPAAの適用対象主体（CE）または事業提携者（BA）は、電子保護対象保健情報（ePHI）を保存または処理するために、クラウドサービスを利用可能か？（回答＝Yes）
2. クラウドサービスプロバイダー（CSP)が暗号化されたePHIのみを保存し、復号化鍵を持たない場合、それはHIPAAの事業提携者か？（回答＝Yes）
3. CSPを、郵便サービスのような「導管」であり、従ってHIPAA規則の遵守義務がある事業提携者でないと考えることはできるか？（回答＝No）
4. どのCSPが、HIPAA遵守のクラウドサービスを提供しているか？（回答＝NA）
5. HIPAAの適用対象主体(または事業提携者）が、最初にCSPとの間で事業提携契約書（BAA)を締結することなく、CSPを利用してePHIを維持した場合、どうなるか？（回答＝NA）
6. CSPが、HIPAAの適用対象主体または事業提携者のePHIを含むセキュリティインシデントを経験した場合、そのインシデントを適用対象主体または事業提携者に報告しなければならないか？（回答＝Yes）
7. HIPAA規則は、クラウド上でePHIにアクセスするために、医療提供者がモバイル機器を利用することを認めるか？（回答＝Yes）
8. HIPAA規則は、適用対象主体または事業提携者向けサービスの提供を終了した後の一定期間、CSPに対して、ePHIの維持を要求するか？（回答＝No）
9. HIPAA規則は、適用対象主体または事業提携者が、米国外のサーバー上にePHIを保存するCSPを利用することを認めるか？（回答＝Yes）
10. HIPAA規則は、事業提携者であるCSPに対し、適用対象主体または事業提携者である顧客のセキュリティプラクティスについて、文書化の提供を要求したり、監査を認めたりするか？（回答＝No）
11. CSPが、HIPAAプライバシー規則に従って非識別化された情報のみを受け入れ維持する場合、それは事業提携者に該当するか？（回答＝No）

加えて、事業提携者としてのCSPに対するアクセス制限に関連して、以下のような留意点を挙げている。

• 顧客がePHIへのアクセスを認証する責任を有すると両者間で同意していても、CSPに対して、情報システムの運用に重要なリソース（例：ストレージ、メモリ、ネットワークインタフェース、CPU）を管理する管理ツールへの認可されたアクセスだけを保証するために、適切な内部制御の実装を求める可能性がある。
• 事業提携者であるCSPは、リスク分析およびリスク管理プロセスの一部として、システム運用に影響を及ぼし、顧客のePHIの機密性、完全性、可用性に影響を及ぼす可能性がある、システム管理ツールへの不正アクセスの悪意ある行為者のリスクを考慮して処理する必要がある。
• CSPは、パッチを当てていない時代遅れの管理ツールを利用するリスクを考慮する必要がある。
• 各自がセキュリティ規則の要求事項に取り組む方法について、事業提携契約書またはその他の文書のいずれかの書面で確認する必要がある。

評価（Measurement）

ビジネスプロセスと同様に、評価も最重要のテーマである。コンプライアンス報告書は、コンプライアンス活動において、医療提供組織内で規制や内部統制を効果的に充足する領域やそうでない領域を明確化するものである。コンプライアンス指標や重要業績評価指標（KPI）は、医療提供組織の組織的ポリシー（内部および外部）や政府規制と協調する能力を評価するものである。

通常のコンプライアンス機能としては、内部監査、コンプライアンストレーニング、ポリシー強制、リスク管理、コンプライアンスKPIなどがある。このようなことを知ることによって、医療提供組織のリーダーシップが、リソースの割当や、リスク管理、将来の戦略的計画に関する効果的な意思決定を行うことができるとしている。

モニタリングと報告書作成（Monitoring and Reporting）

モニタリングは、基礎的なレベルで、組織の業務が進むべき方向に機能していることを保証するものである。加えてモニタリングは、法令を遵守していない領域を特定することができる。モニタリングは、コンプライアンスのパフォーマンスまたはその他のプロセスを強化するために不可欠な最初のステップであり、コンプライアンスの現状の理解は重要なスタート地点となるとしている。

他方、報告書作成手法には、NISTサイバーセキュリティフレームワーク（CSF）（https://www.nist.gov/cyberframework/framework）やプライバシーフレームワーク（PF）（https://www.nist.gov/privacy-framework）を利用した、医療提供組織における現状のプライバシーおよびセキュリティのポスチャの特定が含まれる。このプロセスを通じて、医療提供組織は、現在のポスチャ（As-Is）と将来のポスチャ（To-Be）を比較することが可能になる。2つのフレームワークは、医療提供組織が、ビジネス要求事項、リスク許容度、リソースを装備して、プライバシーおよびセキュリティの活動を調和させ、優先順位付けをするのに役立つ。また、標準規格、ガイドライン、有効なプラクティスを組み合わせることによって、プライバシーとセキュリティにアプローチするための共通ストラクチャを提供する。このようにして、医療提供組織のリーダーシップ向けに、標準的な報告書作成手法を提供するとしている。

医療クラウドにおけるGRCの管理手法

ガバナンス、リスク、コンプライアンス（GRC）のポリシーが有効であることを保証するために、医療提供組織は、最初に、適用される法律や規制を理解する必要がある。コンプライアンスからスタートすることによって、確固たる基盤を持ったプログラムの構築を確実なものにする。

第２ステップとして、包括的なリスク評価とギャップ分析を実行する。リスク分析では、医療提供組織が、(1) コンプライアンスの要求事項を充足する、(2) 適切なセキュリティを提供する の2点についてどう表現しているかが焦点になる。リスクとコンプライアンスのギャップを完全に認識したら、医療提供組織は、組織的ポリシーや手順の欠点に取り組んでいることを保証すべきだとしている。本文書では、例として、「NIST SP 800-53 連邦政府情報システムおよび連邦組織のためのセキュリティ管理策とプライバシー管理策」（https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final）を参照している。

医療提供組織は、同様のプロセスに従って、この制御に関連するプライバシーポリシーを作成する。このプロセスでは、コンプライアンス要求事項、セキュリティおよびコンプライアンスの双方を提供するセキュリティ制御、制御を実装するためのポリシーを有する。最後のステップは、ポリシーがビジネスミッションと整合している点を保証することである。今日の競争的な医療環境では、ITオペレーションとビジネス戦略およびITリスク管理の連携が責務となっている。ITガバナンスは、ITミッションの連携を達成する手法だと言える。

なお、クラウドセキュリティアライアンスは、2010年11月17日、CloudAudit、Cloud Controls Matrix（CCM）、Consensus Assessments Initiative Questionnaire（CAIQ）の3つから構成される「GRC Stack」を公表している（https://cloudsecurityalliance.org/press-releases/2010/11/17/cloud-security-alliance-unveils-governance-risk-management-and-compliance-grc-stack/）。

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

医療提供組織は、デジタル革命の真只中にある。この傾向は、医療提供組織が健康記録のデジタル化を開始した数年前に始まっており、ビジネスや保健医療データに対する需要も拡大し続けている。加えて、最近の新型コロナウイルス感染症（COVID-19）パンデミックが、データへの需要を拡大させ、遠隔医療の開発を加速させた。医療提供組織にとって、このようなデータおよび関連するプロセスを管理する能力が必要となる。ITガバナンス・リスク・コンプライアンス・プログラムの開発と実装は、適用可能な法規制を遵守するとともに、医療提供組織の情報とリスクの管理への関与を強化する

医療提供組織に求められるIT-GRCとは？

クラウドセキュリティアライアンス（CSA）のヘルス・インフォメーション・マネジメント・ワーキンググループ（HIM-WG）は、2021年10月15日に「医療における情報技術のガバナンス、リスク、コンプライアンス」（https://cloudsecurityalliance.org/artifacts/information-technology-governance-risk-compliance-in-healthcare/）を公開している。本文書は、ガバナンス、リスク、コンプライアンスそれぞれのプログラムの構築方法を提示し、単一のまとまりのある有効なプログラムに統合することを目的としており、以下のような構成になっている。

• 謝辞
• 概要
• イントロダクション
  • ガバナンス
  • 生成
  • 保存
  • 利用
  • 共有
  • アーカイブ
  • 破壊
• リスク管理
  • リスク選好
  • リスク許容度
  • 脅威
  • 脆弱性
  • 確率
  • 影響度
  • リスクプロファイル
• コンプライアンス
• 対策
• 監視・報告
• ガバナンス、リスク、コンプライアンス
  • 例1 HIPAA規則
  • 例2 GDPR規則
• 結論
• 参考文献

COVID-19を受けたGRCプロセスの標準的なフレームワーク

本文書では、GRCプロセスのうち、ガバナンスについて、以下のようなプロセスを挙げている。

• 法令／規制：（例）法律、法典、規制
• 標準規格：（例）ISO、NIST
• ポリシー：（例）組織、情報技術（IT）、情報セキュリティ
• 契約書／コミット：（例）PCI、顧客契約書、B2B同意書
• プロセス＆手順：（例）NISTサイバーセキュリティフレームワーク、ISO、組織
• 制御：管理的、物理的、技術的

リスクについてみると、以下のようなプロセスを挙げている。

• リスク評価：
  • Tier 1 組織
  • Tier 2 ビジネスライン
  • Tier 3 資産

さらにコンプライアンスについてみると、以下のようなプロセスを挙げている。

• 監視：（例）脅威動向、実装済制御、インサイダー行動分析
• 自己評価：システム、プロセス、監査準備
• 外部監査：規制監査、標準規格監査（例．ISO）、契約監査（例．PCI）
• 報告：内部、規制主体、顧客

このようなプロセスを踏まえた上で、優れたGRCプログラムは、以下のようなベネフィットを提供するとしている。

• 患者のケアの質を向上させる
• データ品質を向上させた結果、公衆衛生の向上をもたらす
• 運用の効率性と有効性を拡大する
• 医療提供組織がリスクベースの意思決定を行い、自らのリスクを管理することを可能にする

ガバナンス・リスク・コンプライアンス管理を通じて、組織は、重要なリスクデータを収集・管理すると同時に、コンプライアンスを保証・検証し、結果を管理層に報告することが可能になる。このデータにより、管理層は、予算を設定し、リスクベースの意思決定を行い、コンプライアンスを管理することができる。加えて、GRCプログラムは、医療提供組織のリスクやコンプライアンスのポスチャを明らかにして、データライフサイクルを通したリソースアロケーションやリスク低減に関するリスクベースの慎重な意思決定を行うリーダーシップに力を与えるとしている。

医療提供組織は、幅広いタイプのデータ（例．個人識別情報（PII）、決済カード産業（PCI）データ、保護対象保健情報（PHI））を管理しなければならない。以下に示す通り、有効なGRCプログラムは、医療提供組織が、リスクやコンプライアンスをビジネスプロセスと統合することを可能にするとしている。

• ガバナンスは、管理情報と階層的な管理制御構造を利用して、経営層が組織全体を指揮・制御する経営アプローチである
• 組織のコアビジネス機能の実現に影響を及ぼす可能性があるリスクを特定、分析して（必要なところで）対応するために利用される一連のプロセスである
• コンプライアンスは、法律、規制、標準規格、契約、戦略、ポリシーによって定義される記載要件を遵守することを意味する

COVID-19パンデミック緊急対応下、遠隔医療に関わるルールは、劇的に変化した。医療提供組織がこのような変化を捉えて遵守するためには、有効なGRCプログラムを必要とする。医療提供組織が、パンデミックからの復旧期間を通じて運用する – 特に、ビッグデータ分析と遠隔医療について、急速に進化する需要と規制要求事項を考慮するためには、有効なGRCプログラムが不可欠である。GRCプロセスを確立すれば、現行のリスクポスチャを維持しながら、新たな要求事項をシームレスに遵守することが可能になる。本文書では、ガバナンス、リスク、コンプライアンスを個別に検証した上で、結合力のあるGRCプログラムに統合する方法を説明するとしている。完全なGRCプログラムは、医療提供組織全体及びすべてのビジネスプロセスをカバーするが、ここでは、情報技術に関連するGRCに焦点を当てる。

データライフサイクル管理を起点とする医療のITガバナンス

情報ガバナンスは、保健医療組織が遵守すべき構造、ポリシー、手順、法律、規制を定義し、情報の価値と、データライフサイクルを通して管理する方法を抽出することを追求する。時間とともにデータの価値は下がっていくので、データライフサイクル管理は重要だが、データ保存には費用がかかる反面、リスクの暴露にはかからない。データライフサイクルを見直す際には、クラウドコンピューティングで定義された用語を利用することが有効だとしている。標準的なデータライフサイクル用語には、以下のようなものがある。

1. 生成：新たなデータが生成された時または既存のデータが修正された時
2. 保存：データは、ストレージのレポジトリに関わる
3. 利用：どんな活動でも、データを処理、閲覧または利用する時
4. 共有：データや情報を他者がアクセスできるようにする
5. アーカイブ：長期ストレージに置かれたデータ
6. 破壊：データが必要なくなった時、物理的に破壊する

[ステージ1：生成]

データライフサイクルの最初のフェーズは、生成・修正である。医療提供組織は、財務、サプライチェーン、人事、患者ケアなど、多数のトピックに関わる様々なデータを生成・収集する。このステージにおける重要なガバナンスのファクターは、以下の通りである。

1. データは、どのようにして生成・収集・修正されたか？　外部ソースが生成したデータか？　他のデータソース向けにデータを収集して、生成されたものか？　キーボード入力、モバイルアプリケーション、またはデータ結合によって生成されたものか？　医療提供組織は、すべてのデータの起源を知る必要がある。
2. データは、何のために利用されるか？ PIIやPHIの法律は、医療提供組織に対して、データ収集の理由をデータ主体に告知するよう求めるので、この参照は必要不可欠である。
3. 誰がデータの生成または収集をできるか？　誰がデータを生成または収集できるかを特定することは、データがPHIを含む場合特に重要である。この状況における「誰」は、データの完全性を反映している。
4. データの分類やカテゴリー分けは何か？　データ分類は、データのタイプに関する機密性の要求事項に関連する。たとえば、データは内部利用のみを目的としたものであり、ビジネスやPHIに対してセンシティブである可能性がある。連邦政府情報処理基準（FIPS）199で定義されたカテゴリー分けは、3つの潜在的な影響度のレベル（低、中、高）を設定している。これらのレベルは、3つのセキュリティ目標（機密性、完全性、可用性）において、情報セキュリティや情報システムとの関係性が強い。

データソースを理解することにより、組織は、堅牢なガバナンス基盤を構築することができる。

[ステージ2：保存]

医療提供組織のストレージ管理ポリシーは、ストレージのリソースを効率的に管理しながら、適用可能な法規制を遵守できるようにすることが求められる。ただし、ストレージの要求事項を決定する前に、医療提供組織は、保存するデータの容量や種類を理解する必要がある。保存のステージでは、以下のような点に留意する必要がある。

1. データをどこに保存するか？　それはクラウドか、組織のデータセンターか、ローカル保存か、それともリムーバブルメディアか？　それぞれ異なる要求事項があるので、医療提供組織は、ストレージのタイプごとに影響を考慮する必要がある。
2. クラウドベースのデータについて、どこに保存するか？　データの保存場所（プライマリーおよびバックアップの双方）を知ることは重要である。データをオフショアに保存しているか？　規制の要求事項は、ストレージのロケーションによって異なる可能性がある。
3. どれくらいの期間、データを必要とするか？　維持に関する要求事項が、ストレージの手法を決定する可能性がある。
4. 保存時のデータ暗号化に関する要求事項はあるか？　データの機微性のニーズにより、暗号化に関する規制／ビジネスの要求事項がある可能性がある。

どんなデータが保存されているか、どこに保存されているか、どれくらいの期間かを知ることによって、医療提供組織は、データストレージ向けの適切なポリシー・手順を構築することが可能になる。

[ステージ3：利用]

データ利用における最初のステップは、データおよびその利用方法について理解することである。医療提供組織は、以下のような点に留意する必要がある。

1. データの利用者は誰か？
2. データの目的は何で、どのように利用されるのか？
3. データのタイプや規制の要求事項に基づいて、利用は適正か？
4. データは、将来、どのような方法で利用されるか？

データ収集の速度や規模が拡大するにつれて、これらのデータセットを処理するために利用される分析手法もより洗練されたものになっており、データ使用法の多様化が進んでいる。ビッグデータ分析は、保健医療研究における適用の相当な可能性など、保健医療データの使用法を継続的に拡張させる。その一方で、データの損失や悪用を防止するために、適切な処置を講じる必要がある。医療におけるデータガバナンスは、ポジティブなアウトカムを実現し、ネガティブな結果を防止するために取組んでいる。加えて透明性は、医療データガバナンスに対して、複雑な課題を示している。医療提供組織は、プライバシーやセキュリティを維持しながら、データの利用方法に関して透明でなければならない。

[ステージ4：共有]

長年の間、医療提供組織は、データが制限され孤立したところで、ストーブの煙突のようなデータレポジトリを構築してきた。このようなシステムの利用により、データの複製が促進された。優れたデータガバナンスは、データを効率的に共有するために要求されるプロセスを提供できる。有効なガバナンスなくして、医療提供組織は、共有されたデータや情報が、最新で、正確で、適切なものであることを確信することができない。医療提供組織は、データガバナンスにより、どのデータを共有できて共有すべきであるかを明確化するようなポリシーや手順の構築を実現できる。加えて、ガバナンスは、誰がデータを共有できるか、データを共有する理由、データ共有のための手法（電子メール、インターネット、クラウドなど）、共有されるデータをセキュア化するためのプロセスの要求事項について、明確に表現する必要がある。

[ステージ5：アーカイブ]

実際に利用されないデータは、将来のニーズや規制の要求事項に準じて、破壊もしくはアーカイブ化すべきである。データが長期間のアーカイブ化を必要とするかについて理解することは不可欠であるが、このステップには相当の財務的・技術的なハードルがある。医療提供組織は、数年間データを維持するための要求事項に合わせて、高度に規制されたデータを構築する。ただし、データストレージには費用がかかる。データのアーカイブ化は、ストレージ費用を削減し、長期ストレージは短期ストレージよりも安価である。医療提供組織は、データ成長率を制御できない反面、将来のアクセスに対するニーズや費用削減のために提供される有効なアーカイブソリューションの計画を策定することは可能である。

アーカイブソリューションを含む念入りなデータガバナンス戦略は、規制遵守の取組を支援し、データアクセスや検索を可能にする。ただし、データのアーカイブ化は、様々な維持期間を可能にするアプローチを要求するので、医療提供組織は、データ維持に関する要求事項を詳細に研究する必要がある。

[ステージ6：破壊]

情報ガバナンスの観点から見落としがちなのが、データ破壊である。古くなり制限されたデータの破壊に関する明確で適正なポリシー・手順に対するニーズはますます高まっている。このような課題に取り組むためには、有効で防御可能なデータ破壊ポリシーが要求される。医療提供組織は、以下のような点に留意する必要がある。

誰にデータ破壊の責任があるか？

• 同一データのために複数のロケーションを検索することを避けるために、どのようにして情報のレポジトリを最小化・簡略化できるか？
• どれくらいの頻度で、潜在的な削除のために、スペースが枯渇するアイテムをスキャンすべきか？
• データが本当になくなり復旧不可能であることを保証するために、どのような破壊対策を設定するか？
• データは、訴訟ホールドにより、ホールドの結論がでるまでの間、その状態で保全されているか？

さらに注意しなければならないのは、どのようにして、クラウドデータの破壊を保証するかである。クラウドデータは、マルチテナント環境で保存可能なため、他のテナントのデータを破壊することなしに、メディアを消去することは不可能である。そこで、データ破壊を保証する有効な手法としてデータの暗号化がある。データがもはや必要ない時には、鍵を破壊することになる。そうすれば、データが物理的にクラウド上にある時でも利用できなくなる。この手法を採用する場合、医療提供組織は、契約上の義務を通じて、各テナントが暗号化のために異なる鍵を保有することを保証しなければならない。

(後編に続く)

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

(前編はこちら)

現在、米国連邦政府と欧州委員会は、2022年3月25日に発表した新たな環大西洋データプライバシーフレームワーク（プライバシーシールド2.0）（https://www.whitehouse.gov/briefing-room/statements-releases/2022/03/25/united-states-and-european-commission-joint-statement-on-trans-atlantic-data-privacy-framework/）に基づいて、米国・EU間の越境データ移転に係る十分性認定採択に向けた最終作業を行っている。バイオ／医療データの相互運用性を支える役割を果たすのがプライバシーエンジニアリング／プライバシー強化技術である。

米国NISTのプライバシーエンジニアリング標準化に向けた取組

米国立標準技術研究所（NIST）は、2010年4月6日、「SP 800-122 個人識別情報の機密性を保護するためのガイド」（https://csrc.nist.gov/publications/detail/sp/800-122/final）を公表している。そこでは、個人識別情報（PII）について、「(1) 名前、社会保障番号、生年月日・出生地、母親の旧姓、生体記録など、個人のアイデンティティを識別または追跡するために利用できるようなあらゆる情報、(2) 医療、教育、金融、雇用情報など、個人に紐づけしたまたは紐づけ可能なその他の情報を含む、機関が維持する固有に関するすべての情報」と定義している。

また経済協力開発機構（OECD）のプライバシー原則を参照した上で、PIIの機密性を保護する対策として、以下のようなものを挙げている。

• 運用上の保護策
  1. ポリシーと手順の構築
  2. 認識、トレーニング、教育
• プライバシー固有の保護策
  1. PIIの利用、収集、保持の最小化
  2. プライバシー影響度評価の実行
  3. 情報の非識別化
  4. 情報の匿名化

NISTは、プライバシーリスクへの取組を支援するフレームワークやリスクモデル、ガイドライン、ツール、標準規格を構築するために、計測科学やシステムエンジニアリングの原則を適用した「プライバシーエンジニアリングプログラム（PAP）」を展開している。その一環として、2017年1月4日に「連邦政府システムにおけるプライバシーエンジニアリングとリスクマネジメントの導入」（https://csrc.nist.gov/publications/detail/nistir/8062/final）を公表している。

そこでは、プライバシーエンジニアリングについて、「個人に個人識別情報(PII)を処理する際にシステムから生じる、受容できない結果をもたらす問題を起こし得る状況を免れることに焦点を当てた、システムエンジニアリングの専門分野を意味する」と定義している。そして、連邦政府システムにおけるプライバシーエンジニアリングの構成要素として、以下の5つを挙げている。

1. 法律、規制、公正情報実務諸原則(FIPPs)
   • プライバシー要求事項
2. リスクモデル：
   • リスク評価
3. プライバシーエンジニアリングとセキュリティの目標
   • システム機能／要求事項のマッピング
   • システムが要求事項を満たし、リスクに取り組んでいることの評価
4. リスクマネジメントフレームワーク
   • コントロールの選定など
5. プライバシー影響度評価
   • 特定されたリスク
   • 展開されたコントロール
   • システムが要求事項を満たす方法

また、プライバシーエンジニアリングの目標として、以下の3つを挙げている。

• 予測可能性（Predictability）：個人やオーナー、運用者による個人識別情報（PII）および情報システムによる処理についての信頼できる想定を可能にする
• 管理性（Manageability）：PIIのきめの細かい管理（変更、削除、選択的解除など）のための機能を提供する
• 非関連性（Disassociability）：システムの運用的要求事項を越えて個人やデバイスに関連付けることなく、PIIまたはイベントの処理を可能にする

さらにNISTは、2020年1月16日に公表した「NISTプライバシーフレームワーク1.0版」（https://www.nist.gov/news-events/news/2020/01/nist-releases-version-10-privacy-framework）の中で、上記の3つの目標と、プライバシーフレームワーク・コアの関連する機能を、以下のようにマッピングしている。

• 予測可能性（Predictability）：特定（Identify-P）、統治（Govern-P）、制御（Control-P）、通知（Communicate-P）、防御（Protect-P）
• 管理性（Manageability）：特定（Identify-P）、統治（Govern-P）、制御（Control-P）
• 非関連性（Disassociability）：特定（Identify-P）、統治（Govern-P）、制御（Control-P）

なお、医療分野の匿名化に関連して、米国保健福祉省・公民権室（OCR）が、「医療保険の携行性と責任に関する法律（HIPAA）プライバシー規則に準拠した保護保健情報の非識別化方法に関するガイダンス」（2020年6月）（https://www.hhs.gov/guidance/document/guidance-regarding-methods-de-identification-protected-health-information-accordance-0）を公表している。

プライバシー強化技術は米国の国家戦略の柱

「プライバシーエンジニアリング」と類似した用語に「プライバシー強化技術」がある。2022年6月9日、米国大統領府科学技術政策局（OSTP）は、国家科学技術会議のネットワーキング・情報技術研究開発（NITRD）小委員会、国家人工知能イニシアティブ室、NITRD国家調整室の先進的プライバシー保護データ共有・分析ファストトラックアクション委員会を代表して、「プライバシー強化技術の進化に関する情報提供依頼書（RFI）（https://www.federalregister.gov/documents/2022/06/09/2022-12432/request-for-information-on-advancing-privacy-enhancing-technologies）を発出し、関連する政策イニシアティブと合わせて、国家プライバシー保護データ共有・分析戦略の構築を周知するのに役立つパブリックコメントの募集を開始した（募集期間：2022年7月8日まで）。

OSTPは、プライバシー強化技術（PETs）について、このRFIのスコープ内にある、プライバシーを保護する幅広い技術だとしている。特に、非関連性や機密性を維持しながら、参加主体の間でのデータ共有・分析を可能にする一連の技術やアプローチを説明したプライバシー保護データ共有・分析に関心があるとしている。このような技術には、秘匿マルチパーティ計算（MPC）、準同型暗号、ゼロ知識証明、連合学習、セキュアエンクレーブ、差分プライバシー、合成データ生成ツールなどが含まれる。

そして、PFIを通じて求める情報として、以下の10項目を挙げている。

1. PETsを進化させるような特定の研究機会
2. PETsに関する特定の技術的観点または限界
3. 特にPETsの採用からの恩恵を受けるような分析に係る特定のセクター、適用またはタイプ
4. PETsを進化させるために利用、修正または導入が可能な特定の規制または当局
5. PETsを進化させるために利用、修正または導入が可能な特定の法律
6. 上記以外で、PETsを進化させるために利用、修正または導入が可能な特定のメカニズム
7. PETsの採用に関連するリスク
8. PETsの採用に有益な既存のベストプラクティス
9. 上記以外で、PETsの採用に対する既存の障壁
10.  PETsの採用に関連したその他の情報

2023年1月26日には、NISTが「人工知能リスクマネジメントフレームワーク（AI-RMF）第1.0版」（https://www.nist.gov/news-events/news/2023/01/nist-risk-management-framework-aims-improve-trustworthiness-artificial）を公表し、その中で、AIのリスクと信頼性の特徴として、以下のような点を挙げている。

1. 妥当性があり信頼できる
2. 安全性がある
3. セキュアで強靭性がある
4. 説明責任と透明性がある
5. 説明可能であり翻訳可能である
6. プライバシーが強化されている
7. 公平性がある – 有害なバイアスが管理されている

このうち「4. プライバシーが強化されている」でプライバシー強化技術に言及しており、、AI向けのプライバシー強化技術が、特定のモデルのアウトプット向けの非識別化や集約のようなデータ最小化のテクニックと同様に、プライバシー強化型AIシステムの設計をサポートできる。ただし、少量のデータのような特別な状況下では、プライバシー強化技術が正確性の低下をもたらして、公平性およびその他の価値に関する判断に影響を及ぼす可能性があるとしている。

プライバシー強化技術をめぐる環大西洋連携の取組

国際連携の観点からみると、米国政府は、2022年7月20日、英国政府の間で、金融犯罪や公衆衛生上の緊急事態といったグローバルな社会課題に取組むために、プライバシー強化技術に関するイノベーション・プライズ・チャレンジで協力する計画を発表した（https://www.whitehouse.gov/ostp/news-updates/2022/07/20/u-s-and-u-k-launch-innovation-prize-challenges-in-privacy-enhancing-technologies-to-tackle-financial-crime-and-public-health-emergencies/）。この計画は、民主主義を支える技術の国際グランドチャレンジの一環として、「民主主義サミット」で発表されたものであり、米国側はOSTP、米国立科学財団（NSF）、NISTが省庁間イニシアティブを主導し、英国側はデータ倫理イノベーション・センターが主導している。

このチャレンジでは、各チームが、以下の2つのトラックのいずれかまたは双方を選択して参加する。

• トラック1：金融犯罪防止の変革
• トラック2：パンデミック対応機能強化のための予測

その後11月10日、第１フェーズの入賞者が発表された（https://www.nist.gov/news-events/news/2022/11/winners-announced-first-phase-uk-us-privacy-enhancing-technologies-prize）。入賞者は以下の12チームである

• [米国側]
  • Team MusCAT
  • Team IBM Research
  • Team Secret Computers
• [英国側]
  • Corvus Research Limited
  • Diagonal Works
  • GMV
  • Faculty
  • Featurespace Limited
  • OpenMined and DeepMind
  • Privitar Limited
  • University of Cambridge
  • University of Liverpool

現在、入賞チームは、第２フェーズにおけるプロトタイプ開発に取り組んでおり、今後の動向が注目される。

GDPR遵守を起点とする欧州のプライバシー保護技術

一方、英国を含む欧州地域においては、以下のような一般データ保護規則（GDPR）第25条に基づく「データ保護バイデザイン」および「データ保護バイデフォルト」の考え方が、プライバシーエンジニアリング／プライバシー保護技術を支える共通概念となっている（https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-by-design-and-default/）。

1. 技術水準、実装費用、取扱いの性質、範囲、過程及び目的並びに取扱いによって引きこされる自然人の権利及び自由に対する様々な蓋然性と深刻度のリスクを考慮に入れた上で、管理者は、本規則の要件に適合するものとし、かつ、データ主体の権利を保護するため、取扱いの方法を決定する時点及び取扱いそれ自体の時点の両時点において、データの最小化のようなデータ保護の基本原則を効果的な態様で実装し、その取扱いの中に必要な保護措置を統合するために設計された、仮名化のような、適切な技術的措置及び組織的措置を実装する。
2. 管理者は、その取扱いの個々の特定の目的のために必要な個人データのみが取扱われることをデフォルトで確保するための適切な技術的措置及び組織的措置を実装する。この義務は、収集される個人データの分量、その取扱いの範囲、その記録保存期間及びアクセス可能性に適用される。とりわけ、そのような措置は、個人データが、その個人の関与なく、不特定の自然人からアクセス可能なものとされないことをデフォルトで確保する。
   3. 第42 条により承認された認証方法は、本条の第1 項及び第2 項に定める要件の充足を証明するための要素として用いることができる。

欧州連合サイバーセキュリティ庁（ENISA)は、2022年1月27日、「データ保護エンジニアリング – 理論から実践へ」（https://www.enisa.europa.eu/publications/data-protection-engineering）というレポートを公表している。本レポートの構成は以下のようになっている。

1. イントロダクション
   1. データ保護バイデザイン
   2. スコープと目的
   3. 文書の構成
2. データ保護エンジニアリング
   1. データ保護バイデザインからデータ保護エンジニアリングへ
   2. DPIAとの関係
   3. プライバシー強化技術
3. 匿名化と仮名化
   1. 匿名化
   2. k-匿名化
   3. 差分プライバシー
   4. 匿名化スキームの選択
4. データマスキングとプライバシー保護計算
   1. 準同型暗号
   2. 秘匿マルチパーティ計算
   3. 信頼できる実行環境
   4. プライベート情報検索
   5. 合成データ
5. アクセス、通信とストレージ
   1. 通信チャネル
   2. プライバシー保護ストレージ
   3. プライバシー強化型アクセス制御、認証、認可
6. 透明性、明瞭性とユーザー制御ツール
   1. プライバシーポリシー
   2. プライバシーアイコン
   3. 粘り強いポリシー
   4. プライバシープレファレンスシグナル
   5. プライバシーダッシュボード
   6. コンセント管理
   7. コンセント収集
   8. コンセント管理システム
   9. アクセスの権利の行使
   10. 消去の権利、訂正の権利の行使
7. 結論
   1. 最も適用可能な技術の明確化
   2. 最先端の設定
   3. 法令遵守の明示と保証の提供
8. 参考文献

本レポートでは、最初に、一般データ保護規則（GDPR）第25条に基づく「データ保護バイデザイン」および「データ保護バイデフォルト」を挙げている。その上で「データ保護エンジニアリング」と「プライバシー強化技術」について、以下のように定義している。

• データ保護エンジニアリング：
  データ保護バイデザイン／バイデフォルトの一部として捉えられる。それは、特別なデータ保護原則を満たすために適切な技術的・組織的対策の選定、展開、構成をサポートすることを目的としており、最終的にはデータ主体の権利や自由の保護に寄与するものである。データ保護影響度評価（DPIA）は、GDPRに基づいて導入された要求事項の1つであり、データ保護バイデザイン／バイデフォルトアプローチの一部として捉えられる。
• プライバシー強化技術（PETs）：
  情報システムの機能性を失うことなく、個人データを消去または低減したり、個人データの不必要および／または望まれない処理を防止したりすることによって、プライバシーを保護するようなICT対策の首尾一貫したシステムである。PETsは、データ保護原則およびGDPR第25条の責務の充足に向けたビルディングブロックとして、またデータ保護エンジニアリングのビルディングブロックの要素として捉えることができる。

PETsは、コンテキストやスコープ、処理業務自体によって、単一の技術的ツールから全体の展開まで異なる可能性があるので、万能な方法は存在せず、異なるPETSに渡って分類する必要がある。そこで、処理されるデータに関連して利用される技術の特徴に基づいて、以下のようなカテゴリーを提示している。

• 真実保護（Truth-preserving）：プライバシーエンジニアリングの目標は、識別力を低減しながらデータの正確性を保持することにある。この目標は、たとえば、データのきめの細かさ（例．生年月日から年齢まで）を薄めることによって達成できる。このようにして、データは依然として正確だが、最小化された方法であり、危機に瀕した時の目的には適切だ。暗号化は、逆方向に適用された場合、プロセスに不確実性をもたらすことなく、オリジナルデータを完全に保存するので、真実保護技術と見なされる場合がある。
• 明瞭性保護（Intelligibility-preserving）：本当のデータ主体の属性を公開することなく、管理者にとって意味のあるフォーマットでデータが維持される。たとえば、入院日へのオフセットの導入は、年月日のフォーマットを維持するが、識別された患者の本当のデータとのリンクを破る。また、ノイズの付加は、データの外観や操作感を変えることなく、本当のデータに機密性の保護策を提供するので、明瞭性保護技術となる。
• 操作可能技術（Operable Technology）：数学的・論理学的操作（例．総和、比較）は、アプリケーションの結果に実行可能である。暗号化されたドメインで正確に実行可能な操作を利用して、その結果が直接操作できるような暗号化技術群があるので、操作可能性は、必ずしも、明瞭性を伴わない。

本レポートでは、匿名化／仮名化、データマスキング／プライバシー保護計算など、データ保護エンジニアリングの具体的技術を紹介した上で、以下のような推奨事項を提示している。

• データ保護規制当局は、適切な技術やテクニックの最新ソリューションに関連するEU全体のグッドプラクティスについて議論し、促進すべきである。EUの機関は、適切な公に利用できる文書により、このようなグッドプラクティスを促進することが可能である。
• 研究コミュニティは、ポリシーガイダンスや研究資金調達に関するEU機関の支援を受けながら、データ保護原則の実用的な展開をサポートできるようなセキュリティのテクニックや技術の展開を継続的に探究すべきである。
• 規制当局や欧州委員会は、GDPR第42条の下で、適正なデータ保護エンジニアリングを保証するために、適切な認証スキームの創設を促進すべきである。

なおENISAは、匿名化に関連して「ビッグデータにおけるプライバシー・バイ・デザイン」（2015年12月）（https://www.enisa.europa.eu/publications/big-data-protection）、仮名化に関連して「仮名化のテクニックとベストプラクティス」（2019年12月）（https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices）および「仮名化テクニックの展開」（2022年3月）（https://www.enisa.europa.eu/publications/deploying-pseudonymisation-techniques）を公表している。

医療クラウド利用時のプライバシー・バイ・デザイン

医療分野のクラウド利用に関連して、ENISAは、2021年1月18日、「医療サービス向けクラウドセキュリティ」（https://www.enisa.europa.eu/publications/cloud-security-for-healthcare-services）と題するレポートを公表している。このレポートは、クラウドセキュリティのサイバーセキュリティ・リスクを評価し、欧州の医療セクターへのセキュアな統合のためのグッドプラクティスを提供することを目的としており、以下のようなユースケースを提示している。

• 電子健康記録（EHR)：患者情報、医療検査結果など、健康データの収集、保存、管理、転送にフォーカスしたシステム
• 遠隔診療：遠隔による患者ー医師間の診療を支援する遠隔医療のサブセット
• 医療機器：医療機器データを異なるステークホルダー向けにまたは機器監視に利用できるようにするような、医療機器の運用を支援するクラウドサービス

そして、医療におけるクラウドセキュリティの課題として以下のような点を挙げている。

• クラウドソリューションの信頼性の欠如
• セキュリティや技術の専門知識の欠如
• サイバーセキュリティ投資の優先度が低い
• クラウドサービスプロバイダーの法令遵守の証明
• クラウドとレガシーシステムの統合の困難さ

また、クラウドにおけるデータ保護の課題として以下のような点を挙げている。

• プライバシー・バイ・デザインのテクニック
• データ管理
• データ削除
• データポータビリティ
• 暗号化

このうち、「プライバシー・バイ・デザインのテクニック」では、具体的な対策として、認証、属性ベース資格情報、セキュアなプライベート通信、匿名化／仮名化、統計的開示制御、プライバシー保護計算などを挙げている。

アプリケーションコンテナ、マイクロサービス、サーバーレスアーキテクチャに代表されるクラウドネイティブ環境が普及しても、プライバシーエンジニアリング／プライバシー保護技術の重要性は変わらない。また、クラウドコンピューティングを利用したプライバシー保護ソリューションの開発も進んでおり、米国・EU間のプライバシーシールド2.0の実現や、国境を越えたヘルスデータ利活用の波が、今後の投資促進要因となるか注目されている。

現在、クラウドセキュリティアライアンス（CSA）のDevSecOps WGでは、DevSecOpsプロセスにおけるプライバシー・バイ・デザインの導入・運用に関するドキュメントの策定作業を行っており、近日中に公開する予定である。

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