次世代シーケンサーや再生医療に代表されるバイオ技術／バイオ製造の領域では、電子制御技術／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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

米国のバイオ／医療領域では、クラウドサービスの利用が拡大するとともに、様々な機器やシステムから集約されるデータの利活用やリスク管理における前提条件として、相互運用性の標準化動向に注目が集まっている。

CSAが医療データの相互運用性に関するレポートを公開

クラウドセキュリティアライアンス（CSA）のヘルス・インフォメーション・マネジメント・ワーキンググループ（HIM-WG）は、2022年9月26日に「医療の相互運用性」（https://cloudsecurityalliance.org/artifacts/healthcare-interoperability/）を公開している。「相互運用性（Interoperability）」という言葉は、医療ITシステムが相互に継ぎ目なくデータを交換する場合に参照される。受け取った電子健康記録（EHR）が読み取り可能で受け入れられることを認識したところで、標準化されたフォーマットを利用して情報を移転させる時、相互運用性が発生する。本文書では、共有するデータが、受け取る側の医療機関にとって、正確にデータを表現するコンテンツとコンテキストについての十分な評価を有することを目標としている。このようなデータは、正確な患者ケアだけでなく患者安全にとっても、非常に有益である。

「医療の相互運用性」は、以下のような構成になっている。

• 謝辞
• 要約
• イントロダクション
• 相互運用性
• 相互運用性の現状
• クラウドにおける相互運用性
• 今後の進め方
• 結論
• 参考文献

CSA-HIM WGは、相互運用性について。「情報を交換し、交換した情報を利用するための2つ以上のシステムまたはコンポーネントの能力」と定義している。言い換えると、相互運用性は、異なるタイプの情報通信技術（ICT）システムが、読み取り可能で使えるフォーマットで、データを正確に、効率的に、一貫して交換する能力である。この文書では、相互運用性について、以下の4つのレベルを提示している。

1. 基礎的（レベル1）：システムまたはアプリケーションが、安全にデータを伝達し、他からのデータを受け取るための相互接続性を定義する
2. 構造的（レベル2）：解釈のためのデータフィールドのレベルなど、データ交換のフォーマット、構文、組織を定義する
3. 意味的（レベル3）：公に入手可能な値設定やコーディングの語彙からの標準化された定義を持つデータ要素の利用など、共通の基本的モデルやデータの成文化のために提供し、理解の共有やユーザーに対する意味を提供する
4. 組織的（レベル4）：組織や主体、個人の内部や相互間の、安全で、継ぎ目のない、タイムリーなデータ通信を促進するためのガバナンスやポリシー、社会的、法的、組織的な考慮事項を含む

電話に匹敵するようなレベルの総合運用性が医療に適用できれば、誰が機器やシステムを作ったか、どこに設置されているかに関わらず、医療機関がやりとりできる機能を持つことができる。加えて、医療機器からのデータを直接EHRにとりこむことができれば、患者のアウトカムや患者安全に様々なベネフィットを提供することができる。

「医療の相互運用性」では、EHRのユースケースとして、以下のような事例を挙げている。

• 医療機関は、異なるEHRを利用する可能性がある他の医療機関に記録を送付する機能が必要である。データの構造と完全性を維持しながら、この種の転送を遂行しなければならない。
• 外部ソースからのEHRコピーの要求と、オリジナルの詳細を保持するような標準的なフォーマットによる記録の返却。
• 標準的なフォーマットによるHIEへの情報提供により、医療機関が他の医療機関からの患者記録の閲覧を可能にする。これには、患者の病歴を有する医療機関が含まれ、アウトカムの改善における重要な要因となる。

米国政府による医療データの相互運用性標準化推進策

なお、米国保健福祉省（HHS）は、病院の医療情報へのアクセス向上を通じで患者に権限を付与するとともに患者の電子健康記録へのアクセスを改善し、供給者が簡単に患者との時間を費やせるようにすることを目的とした「相互運用性の促進（Promoting Interoperability）」ルールの標準化を推進している。

その一環としてHHSは、2020年3月9日、「国家医療IT調整室（ONC）21世紀治療法最終規則（ONC規則）」 （https://www.hhs.gov/about/news/2020/03/09/hhs-finalizes-historic-rules-to-provide-patients-more-control-of-their-health-data.html）と「メディケア・メディケイド・サービス・センター（CMS）相互運用性および患者アクセス最終規則（CMS規則）」 （https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index）を公表している。ONC規則では、国際HL7協会が策定した電子保健医療情報の相互運用性に関わる標準規格であるHL7 FHIR（Fast Healthcare Interoperability Resources)4.0.1版を採用し、認証電子健康記録技術プログラムの一部であるアプリケーション・プログラミング・インタフェース（API）の利用を支援することによって、患者が、スマートフォンを利用しながら、医師のEHRから、重要な医療情報にアクセスすることを可能にするとしている。また、CMS規則では、規制対象となるすべての保険者が、患者アクセスAPI経由で請求・照合データの患者による利用（PHR）を可能にすることによって、患者が必要な時に必要な方法でPHRを利用しながら、医療におけるよりよい意思決定者や知識に基づくパートナーとなることを促進するとしている。一般のデジタルヘルススタートアップ企業でも、HL7 FHIR ベースで電子医療記録（EMR：Electric Medical Record）やEHRとデータ連携すれば、経済インセンティブの恩恵を受けられることから、相互運用性標準化の加速要因となっている。

このような動きと並行して、ONCは、2020年10月30日、「2020-2025年連邦医療IT戦略計画」（https://www.healthit.gov/topic/2020-2025-federal-health-it-strategic-plan） を公表している。2020-2025年計画では、以下のようなビジョンとミッションを掲げている。

• ビジョン：情報を利用して、個人を関与させ、費用を低減し、高い品質のケアを提供し、個人および全住民の健康を向上させる健康システム
• ミッション：それが最も重要な時や場所で、アクセス可能な技術・健康情報を利用して、個人やコミュニティの健康とウェルビーイングを向上させる

その上で、以下のような目標および目的から成るフレームワークを提示している。

目標1：保健とウェルネスを促進する

目的1a：個人の利用可能な保健情報へのアクセスを向上させる
目的1b：医療ITを通じて健康で安全なプラクティスを進化させる
目的1c：保健と福祉サービスの情報を統合する

目標2：ケアの提供と経験を強化する

目的2a：医療ITを活用して臨床プラクティスを向上させ、安全で高品質のケアを促進する
目的2b：医療ITを利用して、アクセスを拡張し、患者をケアにつなぐ
目的2c：医療における競争、透明性、負担可能性を育む
目的2d：提供者における規制や管理の負担を低減する
目的2e：医療ITリソースの効率的管理と、自信を持って医療ITを利用した国全体の労働力を可能にする

目標3：研究とイノベーションを加速させるためにセキュアなデータ駆動型エコシステムを構築する

目的3a：個人および人口レベルの保健データ移転を進化させる
目的3b：個人および人口レベルで医療ITとデータを利用した研究と分析を支援する

目標4：医療を健康データとつなぐ

目的4a：医療IT機能の開発と利用を進化させる
目的4b：データ共有への期待を創出する
目的4c：技術と通信のインフラストラクチャを強化する
目的4d：個人のプライバシーを保護するセキュアな保健情報プラクティスを促進する

バイオ／医療R&Dで重視されるAPIと相互運用性の標準化

ONCは、医療IT戦略計画の一環として、バイオ／医療R&D 領域におけるAPIの開発・標準化への取組をリードしながら、電子健康情報へのアクセスや交換、利用の負荷を低減することを目的として、以下のようなステークホルダー向け報告書を公表している。

• 「科学的発見に向けて加速するAPI：消費者の視点」（2020年11月）（https://www.healthit.gov/sites/default/files/page/2020-11/Accelerating_APIs_Consumer_Perspective.pdf）
• 「科学的発見に向けて加速するAPI：研究者の視点」（2021年3月）（https://www.healthit.gov/sites/default/files/page/2021-03/Accelerating-APIs-For-Scientific-Discovery-Researcher-Perspectives.pdf）
• 「科学的発見に向けて加速するAPI：アプリケーション開発者とデータイングレーターの視点」（2022年3月）（https://www.healthit.gov/sites/default/files/page/2022-06/App-Developer-and-Integrator-Perspectives.pdf）
• 「科学的発見に向けて加速するAPI：医療機関の視点」（2022年6月）（https://www.healthit.gov/sites/default/files/page/2022-08/Accelerating_APIs_Provider_Perspective.pdf）

各報告書とも、以下のような点に注目することによって、標準化されたAPIとヘルスケアアプリケーションに対する理解と利用を加速させるとしている。

• どのようにして個人が、APIで可能になるアプリケーションを利用して、セキュアに自分のEHRデータにアクセスできるか
• どのようにしてAPIが、研究者のために保健医療データへのアクセスを改善するか
• どのようにしてデータアグリゲーターやデータインテグレーター、アプリケーション開発者が、APIを通して市場におけるイノベーションや競争を牽引できるか
• どのようにして医療機関が、APIを利用してさらにケアを支援できるか

たとえば、「科学的発見に向けて加速するAPI：アプリケーション開発者とデータイングレーターの視点」は以下のような構成となっている。

• イントロダクション
  • より大きな相互運用性へのシフト
  • 手法
• 調査結果
  • 採用と利用の現状
    • 標準化されたAPI利用の動機づけ要因
    • 拡張されたデータセットとユースケース
    • モバイルプラットフォーム統合
    • 開発者ツールとリソース
  • 展開と統合の課題
    • 展開と検証サンドボックス
    • 独自APIとカスタム統合
    • データマッピングとデータの完全性
  • APIプロセス向上の機会
    • 集中型ツールとリソース
    • 業界教育と連携
    • 医療組織向けガイダンス
  • プライバシーとセキュリティの考慮事項
    • 粒度の細かいコンセントとワークフロー
    • データガバナンス
    • データセキュリティリスクと責務
• 結論
• 参考文献

CSA-HIM WGも、API利用をバイオ／医療データの相互運用性の中核に据えている。APIは、異なるアプリケーションから、アプリケーションの機能やデータにアクセスすることを可能にするエントリーポイントである。HL7 FHIRには、完璧な相互運用性ソリューションを構築するために拡張されたWeb標準規格と現代的な情報交換に基づくAPI向けの仕様が含まれる。APIとEHRの統合件数は増加傾向にあるが、FHIRデータ交換をサポートするAPIの割合は横ばい傾向にある。アプリケーションの中には、データ交換規格向け支援機能を利用・記述していないものがある点が、この要因と考えられる。加えて、FHIRリソースは、特定のデータ要素の交換を促進するにとどまっており、FHIRサポートのバリエーションに寄与していない可能性がある。特に、初期バージョンのFHIR標準規格にこれが当てはまる。FHIRリソースおよびサポートされたデータ要素の数が増えれば、FHIR向けのサポートも成長するとみている。

ただし、EHRと比較して医療機器の場合、事情が異なってくる。過去10年間多くのソリューションが推進され、標準規格が構築され、製品ソリューションも生産されてきたが、臨床現場の医療機器はEHRと通信するだけでなく、相互間で交換可能であることから、相互運用性がより複雑になっている。相互運用性によってケアが改善する可能性がある反面、データを生成する各機器やEHRシステムとの間を効率的にやりとりできるとは限らないので、注意が必要だ。

医療クラウドの普及がAPIや相互運用性に及ぼす影響と課題

さらに、バイオ／医療分野におけるクラウドコンピューティングの導入によって、データを供給し、利用可能なフォーマットで組み合わせることが可能になってきた。医療機関は、医療産業をサポートするデータ分析で利用する大容量データを保存・加工・共有することができる。

ただし、地理的に分散した場所にある様々なシステムにおいて、異なるソースから複数のデータタイプを有する医療データをクラウド上に集約すると、相互運用性のあるシステムを構築することがますます難しくなる。このような課題を解決するために、クラウドサービスプロバイダー側も、FHIR向けAPIとの相互運用性確保に向けて取組んでいる。また、クラウドは、臨床情報とともに、医用画像や医療機器からのメタデータを提供するので、より強力な結果をもたらすことも可能になる。

CSA-HIM WGは、相互運用性のあるシステムを構築するためには、以下のようなものが必要だとしている。

• 共通のデータスキーム
• 病院が大量のリアルワールドデータを共通のデータスキームにもたらすメカニズム
• 共通のデータスキームに対する質問に答えるメカニズム

2011年、共通のFHIRデータモデルやAPI標準規格が、業界内で同じデータ言語と会話できる単一のデータスキーマに対する回答として提供されて以降、Google、AWS、Azureに代表される大規模クラウドサービスプロバイダー（CSP）は、医療機関が複雑なデータセットを収集し、検索できる手段を提供する技術プラットフォームの開発に尽力してきた。

医療機関がクラウドベースのサービスに移行するにつれて、ポイントツーポイントのカスタマイズなしで、アプリケーションやサービスを迅速に開発・接続・稼働するための機能が必要になってくる。FHIR向けAPIは、医療機関の情報技術チームが自らの製品を強化する際に役立つ。このようなソリューションによって、医療機関は、FHIRの標準化されたAPIで統合することによって、データをモバイル機器やWebポータルに素早く転送することができるとしている。

モバイル機器やWebブラウザ上で稼働するアプリケーションの多くは、API向け基盤として、REST（Representational State Transfer）情報交換規格を利用する。FHIRは、APIにおけるデータ交換向け基盤としてRESTを利用する。医薬品、観察、患者といった保健医療データのタイプは、自らのリソースによって表現される。このようなリソースについては、必要となる正確な情報を発見し、取得するために利用できる検索や要求のような相互作用に加えて、RESTFul HTTP APIコマンドを介してリクエストすることができる。サーバーは、FHIR APIがサポートできるリソースや相互作用のタイプによってプログラミングされる。FHIR APIを利用するサードパーティアプリケーションは、EHRに統合することによって、医療機関のワークフローに直接送り込むことが可能となる。

FHIR APIを利用した個々のリクエストは、リソースや、必要となるデータを特定するインディケーター、コマンドまたはパラメーターを提供する。FHIRのリクエストは、単独の患者のような情報ソースを返して、患者に関連する医療保険や医薬品または全患者のデータのような大量データの束に代表される情報の束を返す。リクエストは、どのタイプの、どれくらいのデータが必要かをアプリケーションに伝えるために、構造化される。

クラウドを利用することにより、医療機関は保健医療データをセキュアに管理できるようになる。FHIR向けAPIは、ネイティブなFHIRフォーマットにより、HIPAAの保護対象保健情報（PHI）の管理・保存向けに、拡張性のある安全な環境を提供するHL7 FHIR仕様に基づいており、一貫性のあるRESTful APIを介したデータ交換を可能にする。このようなFHIR向けAPIの特性により、EHRからの臨床データや、臨床医・患者ダッシュボード、遠隔モニタリングプログラム、医療機関の外部にあるデータベースを統合・正規化し、機械学習を適用するツールとして利用することもできる。

また医療機関は、無比のセキュリティインテリジェンス機能でPHIを保護することができる。データは、APIインスタンス毎に、独自のデータベースに分離して保護される。FHIR向けAPIは、階層型の多層防御と先進的なデータからの脅威保護機能を展開できる。加えて、医療機関は、連携型のロールベースアクセス制御（RBSC）機能を利用してデータを管理することができる。このように、相互運用性は、プライバシー／セキュリティの観点からも、医療機関がクラウドサービスに対するニーズを判断する際に重要な考慮事項となりつつある。

（後編に続く）

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

 

 

 

前編では、医療のサードパーティベンダーリスク管理のうち、SaaS事業者を含むサードパーティベンダーに対するリスク評価に焦点を当ててきた。後編では、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ（HIM-WG）の「医療におけるサードパーティベンダーリスク管理」（2022年7月29日公開）（https://cloudsecurityalliance.org/artifacts/third-party-vendor-risk-management/）の中で、検知、対応、復旧といった後半のフェーズを取り上げる。

検知フェーズを支える継続モニタリングと脅威インテリジェンス

サードパーティベンダーリスク管理における「検知」フェーズでは、サイバーセキュリティイベントを特定するために、適切な制御や活動を構築・展開するフェーズである。医療提供組織は、継続的モニタリングプログラムを設定して、サードパーティのリスクに対する最新の理解を維持・改善していく必要がある。医療提供組織は、ベンダーがインターネット上に露出する脆弱性を継続的に観察することによって、セキュリティ質問票への回答の妥当性を確認し、リスクの経験的・継続的なエビデンスに基づいて、プロアクティブなガバナンスプラクティスを設定することができるとしている。
CSA HIM-WGは、継続モニタリングプログラムの設定により、以下のようなベネフィットがもたらされるとしている。

• ベンダーに対するリアルタイムの洞察を通して、プロアクティブなアプローチを可能にする
• 人的ミスや不正確さを防止するために客観的なコンテキストを提供する
• 遅くて費用のかかる人手による評価を実行するのとは反対に、時間や資源を節約する
• 簡単なカスタマイズを可能にして、自動化とデータインテリジェンスを利用し、評価がベンダーや産業、コンプライアンスのニーズに合わせられる
• 最高のリスクのみに焦点を当てるのを可能にする

継続的モニタリングの一環として重要なものに、脅威インテリジェンスがある。脅威インテリジェンスでは、数多くのWebサイトやフォーラム、マーケットプレイスをモニタリングしたり、サードパーティパートナーの膨大なリスト向けに悪意のあるネットワーク活動を追跡したりする必要があるが、医療提供組織は、このようなモニタリングのためのリソースを持っていない。

そこで重要な役割を果たすのが、脅威インテリジェンスだ。脅威インテリジェンスサービスプロバイダーは、インターネット上のソース（例．公開Web／ダークWeb上のWebサイト、フォーラム、マーケットプレイス、ランサムウェア恐喝サイト、貼り付け・なりすましサイト、ニュースソース、ブログ、ソーシャルメディアアカウント、脅威インテリジェンスデータベース）から情報を引き出すために、スキルやリソースを提供する。それによって、医療提供組織は、検証可能で客観的なリスク評価情報を利用して、サードパーティベンダーリスク管理プログラムを実行することができる。

対応フェーズの指針となるインシデント対応プレイブック

サードパーティベンダーリスク管理における「対応」フェーズでは、検知されたサイバーセキュリティイベントに関する活動を構築・展開する必要がある。しかしながら、サードパーティベンダーが関わるインシデントはまちまちであり、それらへの対応も異なる。そこで、医療提供組織は、インシデント対応プレイブックを構築する必要がある。最も重要なことは、以下のような内容を含むプレイブックを実行することによって、組織における影響の損害を抑制する点にある

• アクセスを遮断する。企業は、サイバー攻撃の影響を受けるサードパーティへのアクセスを遮断できるようにする必要がある。医療提供組織は、残りのネットワークからサードパーティのサイバー資産を分離しなければならない。
• サードパーティによる侵害が自組織に影響を及ぼしたか否かを判断する。もし影響があれば、次のステップは、インシデントの範囲や影響度を理解するために、フォレンジック分析を実施することになる。
• サードパーティの侵害への関与からの信頼性を評価し、契約条件を確認する。
• 損害を低減する。これは、追加的なセキュリティタスクや、自システムへのさらなる侵入を最小化するツールを通して実現可能になる。
• 起きたことや影響度、復旧計画について、ステークホルダーに伝達する。
• インシデントに重要インフラストラクチャの侵害が含まれていたら、72時間以内に、国家安全保障省(DHS)のサイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)に報告しなければならない。これは、2022年3月に成立した法律の要求事項である。
• インシデントの再発を防止する方法を決定するために、根本原因分析(RCA)を実施する
• 何が機能したか、何が機能しなかったか、どんな改善が必要かといった組織の対応や、次回に展開するための計画を文書化する。
• 内製化を継続する。医療提供組織は、インシデントが発生した時に、内製化でサービスを稼働するための計画を持つべきである。

医療機器インシデント対応準備におけるSBOMの役割と国際標準化

なおCSAでは、2021年11月8日に「医療機器インシデント対応プレイブック」(https://cloudsecurityalliance.org/artifacts/csa-medical-device-incident-response-playbook/)を発行している。

このプレイブックは、医療提供組織の以下のようなサイバーセキュリティスタッフおよび臨床リーダーを対象としている。

• チーフ医療情報オフィサー(CMIOs)
• チーフ看護情報オフィサー (CNIOs)
• チーフセキュリティオフィサー (CSOs)
• チーフ情報セキュリティオフィサー (CISOs)
• チーフ情報オフィサー (CIOs)
• ITディレクター
• セキュリティ管理者
• インシデント対応者
• セキュアな医療機器の実装・運用に責任があるセキュリティエンジニア
• 医用生体工学スタッフ

そして、以下のような構成になっている。

• イントロダクション
• ユースケースの例
  • ユースケース1：医用画像機器の違反
  • ユースケース2：個人向け埋込み型機器
  • ユースケース3：ネットワーク型輸血ポンプの可用性または機能の損失
• アプローチ
• 医療機器インシデント対応プロセス
  • 準備フェーズ
    • シナリオの理解
      • デバイスの棚卸しとデバイス構成の文書化
      • 機器の臨床考慮事項と影響度の分類
      • データと影響度の分類
      • データレポジトリの構築
    • チームの準備
      • インシデント対応(IR)チームとステークホルダーの組立と文書化
      • クラウド統合の文書化とSLA(Service Level Agreement)の策定
      • ツールの収集
      • チームの訓練
      • セキュリティ認識の強化
      • インシデント対応(IR)机上演習の実施
    • プロセスの準備
      • コミュニケーション手順の文書化
      • 医療機器インシデント対応のエスカレーションと通知の手順
      • 通知手順の構築
      • 協調的脆弱性開示(CVD)プログラムの設立と文書化
      • 期待される成果物の明確化
    • ネットワークの準備
      • DNSログとシンクホールの展開
      • ネットワークセグメンテーションアーキテクチャの設計とネットワークアクセス制御(NAC)の構成
      • ネットワークトラフィックのモニタリングと分析
    • 機器の準備
      • ソフトウェア／ファームウェア向けの既知で優れたバックアップまたはインストールデスクの準備
      • 機器構成バックアップの準備
  • 検知、分析、コンテキスト化
    • 脅威インテリジェンスと脅威共有プログラムの維持
    • 脆弱性管理プログラムの維持
    • セキュリティイベント向けのモニタリング
    • 行動プロファイリングと分析の展開
  • 包含、根絶、復旧
• インシデント対応(IR)の分類
  1.  患者とネットワークから機器を切断するための安全
  2. 患者ではなくネットワークから機器を切断するための安全
  3. 臨床のインパクトにおけるネットワークの結果からの切断
  4. 大規模な患者安全の意味におけるネットワークの結果からの停止または切断
  5. 患者から安全に削除できない機器
  6. 埋め込み型医療機器
  7. 遠隔医療機器
• インシデント後の分析
  • フォレンジック調査／証拠
  • 教訓
• 共有と更新
  • 技術の共有
  • 同意書の共有
  • 関係性の共有
• 計画／プレイブックの更新
• 結論
• 参考文献
• 附表1 – 医療機器インシデント対応(MDIR)フェーズとガイダンス

医療機器インシデント対応準備において、医療提供組織とサードパーティベンダーとしての医療機器企業をつなぐ役割を果たすのが、ソフトウェア部品表(SBOM)である。たとえば、上記の「医療機器インシデント対応プロセス」の「デバイスの棚卸しとデバイス構成の文書化」において、機器の構成や構造に関連するデータをSBOMから取り込むことができれば、後のプロセスにおいて、侵害される可能性があるライブラリ／バージョンを有する機器を特定するのに役立てることができる。

また、「検知、分析、コンテキスト化」の「脆弱性管理プログラムの維持」において、医療機器製造業者と連携しながら、機器で利用されるライブラリを文書化したSBOMを入手し、これらのライブラリに関連する共通脆弱性識別子(CVE)をモニタリングすることによって、新たな脆弱性を発見できる可能性がある。

なお、米国連邦政府レベルでは、2021年5月12日にホワイトハウスが発出した「国家サイバーセキュリティに関する大統領令」（https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/）に呼応して、米国医薬食品局（FDA）が2022年5月26日に「FDA CDRHと医療機器サイバーセキュリティ：連邦政府のサイバーセキュリティ向上に関する大統領令[第14028号]についてのNISTへの回答書」（https://www.fda.gov/media/149954/download）を公表し、国際医療機器規制当局フォーラム(IMDRF)や共同セキュリティ計画(JSP)と連携して、ソフトウェア部品表(SBOM)の国際標準化に取組むことを表明している。その後2022年7月、IMDRFは「医療機器サイバーセキュリティ向けソフトウェア部品表の原則と実践」草案(https://www.imdrf.org/consultations/principles-and-practices-software-bill-materials-medical-device-cybersecurity)を公表しており、日本にもSBOM国際標準化の波が押し寄せるのは時間の問題だ。

復旧フェーズで求められるマルチステークホルダーコミュニケーション

サードパーティベンダーリスク管理における「復旧」フェーズでは、どのような手段で迅速に通常業務に戻すかを考える必要がある。医療提供組織のサードパーティベンダーがインシデントから復旧する場合、患者に対するケアを継続することが必要不可欠である。インシデント対応チームがイベントを特定したら、影響を受けたベンダーが提供するサービスの代替ソースを特定するために、積極的にベンダーを関与させる必要がある。

サービスが停止しなくても、医療提供組織のデータが公開されるようなケースも想定される。法令により、定められた期間内に当局への報告や当事者への通知が求められることがあるので、インシデント対応プレイブックは、このような要求事項をカバーすべきだとしている。

復旧の取組中、コミュニケーションは重要であり、内外双方のステークホルダーと情報を共有する必要がある。復旧は、事業を迅速に再開するにとどまらず、できる限り安全性を維持することしながら、顧客や患者との信頼性を構築していくことが求められる。

サードパーティベンダーとしてのクラウド事業者をどう管理するか

最後に、「医療におけるサードパーティベンダーリスク管理」では、クラウドに関連する考慮事項として、以下のような項目を挙げている。

• データセキュリティと制御：他のサードパーティ管理者とともに、プロバイダーは、クラウドベンダーの内部統制の強度を評価しなければならない。
• データ転送：データは、インターネットや無線ネットワーク経由で転送される可能性がある。医療組織は、クラウドコンピューティングベンダーを選定する際に、すべての法令の要求事項を遵守しなければならない。データが転送・保存される場所を特定することを忘れてはならない。
• マルチテナント性：これは、医療組織に対して、共有されたハードウェア上でデータが混じり合う可能性を考慮するよう求める。
• ロケーション：データをクラウド上に移転することは、ハードウェアプロバイダーが制御できない遠隔地に資産を移転することを意味する。加えて、データは米国外に保存される可能性がある。
• 信頼性：クラウドのような共有リソースに依存する場合、医療組織は、必要な時にリソースが利用できないというリスクに直面する。
• 持続可能性：医療組織は、万一クラウドが故障した場合に業務を継続する手段を理解するために、クラウドプロバイダーの災害復旧・事業継続計画が適正であるかを判断すべきである。

加えて、医療組織に求められるセキュリティ対策として、以下のような機能を挙げている。

• 多要素認証
• 保存時・転送時双方のデータ暗号化
• 適応型アクセスやアイデンティティプルーフィングなどの連携型アクセス制御
• クラウド環境におけるユーザーの行動を管理するデータセキュリティポリシーの開発・展開

昨今は、複雑化・高度化するサードパーティベンダーリスク管理の負荷を軽減する自動化ソリューションの開発・提供も進んでいる。自動化には、以下のようなメリットがある。

• 効率性：自動化プログラムは、効率的な評価時間、制御されたプロセス、一貫したワークフロー、正確な文書化を可能にする。
• 透明性：すべてのサードパーティの記録をスクリーニング・モニタリングすることによって、医療提供組織は、現実のリスクに対応できる。自動化されたリスクベースのプログラムで重要なのは、適切にデータを利用し、リスクを上手に低減するためにリソースを適用することにある。
• ポリシーの組織化と分類：文書へのアクセスを表すために利用する構造によって、文書を分類する。構造は検索可能である必要がある。
• 迅速な通知：自動化プログラムは、違反やリスクを直ちに報告することができる。

自動化をサードパーティベンダーリスク管理に統合することは容易でないが、サードパーティに関するデータを正確に収集・スクリーニングする業務の複雑化や、デューデリジェンスの高度化を考えると、リスクを低減し、費用を削減するためには、自動化以外に選択肢はないのが実情だ。これは、医療に限った問題ではなく、業種横断的な取組が要求される。

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

 

昨今、医療・ライフサイエンス業界では、業務プロセスの一部を外部のサードパーティベンダーと契約してアウトソーシングする形態が増えている。その典型的な例が、SaaS（Software as a Service）モデルの利用である。業務効率化、費用削減といったメリットがある反面、高度化するサードパーティベンダーの契約管理、継続的なモニタリングといったリスク管理策の負荷も大きくなっている。

容易でない医療分野のサードパーティベンダーリスク管理

クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ（HIM-WG）は、2022年5月11日に「医療サプライチェーンのサイバーセキュリティリスク管理」（https://cloudsecurityalliance.org/artifacts/healthcare-supply-chain-cybersecurity-risk-management/）、2022年7月29日に「医療におけるサードパーティベンダーリスク管理」（https://cloudsecurityalliance.org/artifacts/third-party-vendor-risk-management/）を公開している。前者では、医療分野のサプライチェーンに潜むサイバーリスクを最小化するために、医療機関が、適切なリスク管理プラクティスを実践し、サプライヤーやサードパーティベンダーに対するリスク評価を行う際の課題や対策の方向性を示しており、それを受けた後者では、特にサードパーティベンダーに対するリスク評価・管理に焦点を当てている。

「医療におけるサードパーティベンダーリスク管理」は、以下のような構成になっている。

• 謝辞
• 要約
• イントロダクション
• 特定
  • サードパーティベンダーの特定と優先順位付け
  • サードパーティの関係性からの潜在的リスク
• 保護
  • リスク評価
  • セキュリティに関する質問
  • リスク処理
• 検知
  • モニタリング
• 対応
  • 対応
• 復旧
• 追加的考慮事項
  • クラウド
  • 自動化
  • プログラムの効果の追跡と改善
• 参考文献

「イントロダクション」の中で、医療におけるサードパーティベンダーリスク管理が失敗する理由として、以下のような点を挙げている。

• 手動のリスク管理プロセスにおける自動化と信頼性の欠如によって、医療で利用されるデジタルアプリケーションや医療機器のサイバー脅威と拡散に追いつくことが困難になっている
• ベンダーリスク評価は、時間と費用を要し、ごくわずかの組織だけが全ベンダーのリスク評価を行っている
• 重要なベンダー管理のコントロールやプロセスは、部分的に実装されているか、実装されていない

医療機関が取扱う電子医療データの容量が拡大し、複雑化する中、機微データの処理に関わるサードパーティベンダーの数は増えている。特に、インフラストラクチャやマネージドアプリケーション、データ管理といった領域で、サードパーティベンダーへの依存度が高まっており、アクセス管理や変更管理、データ運用管理などの業務も高度化・複雑化している。

「医療におけるサードパーティベンダーリスク管理」では、サードパーティベンダーリスク管理のフレームワークとして、「重要インフラのサイバーセキュリティを向上させるためのフレームワーク(NISTサイバーセキュリティフレームワーク)1.1版」(2018年4月16日)を参照しながら、「特定」、「保護」、「検知」、「対応」、「復旧」のカテゴリーをベースに、議論を展開している。

サードパーティベンダーの特定と優先順位付け

「特定」フェーズでは、新たな外部ベンダーや既存の外部ベンダーにおける変更を特定することが、サードパーティベンダーリスク管理プログラムの第１歩だとしている。加えて、サードパーティベンダーを評価するために、当該ベンダーが組織内で、データをどのように保存・処理・転送しているかを理解する必要があるとしている。

サードパーティベンダーを特定したら、提供するサービスや処理するデータの重要性などを考慮しながら、各ベンダーのリスクを評価し、優先順位（例．重要(Critical)、高（High）、中（Moderate）、低(Low)）を付けて分類する必要がある。

医療機関にとって、業務のサードパーティベンダーへのアウトソーシングは、事業戦略の一環である。サードパーティベンダーの役割が拡大するにつれて、医療機関は、ベンダーが直面する潜在的な脅威を低減するために、様々なリスクを継続的にモニタリングすることが不可欠となる。ここでは、医療機関が認識すべきサードパーティベンダーのリスクとして、以下のようなものを挙げている。

• サイバーセキュリティリスク：サードパーティベンダーのサイバーセキュリティ制御の不備により、組織のデータの機密性、完全性、可用性が影響を受けるリスク
• レピュテーションリスク：サードパーティベンダーが関与するインシデントが発生した場合、医療機関のブランドレピュテーションにネガティブな影響が及ぶリスク
• コンプライアンスリスク：事業を遂行するために組織が従わなければならない法律や規制、内部プロセスの違反から生じるリスク
• プライバシーリスク：サードパーティベンダーと共有する個人データに対する権限のないアクセスが可能となるリスク
• オペレーショナルリスク：サードパーティベンダーの業務は医療機関の業務と絡み合っており、ベンダーのサービス提供ができなくなると医療機関も日常活動を遂行できなくなるリスク
• 戦略的リスク：医療機関の戦略目標と合致しないビジネス意思決定をサードパーティベンダーが行った時に生じるリスク
• 財務リスク：サードパーティベンダーが医療機関の収入に損失を与えるリスク（例．製品リコール）

上記以外にも、様々なリスクが存在するので、医療機関は、将来を見越した拡張性のあるサードパーティベンダーリスク管理プログラムを構築・運用することが求められる。

サードパーティベンダーのリスク評価

次に、「保護」フェーズの柱となるのは、サードパーティベンダーに対するリスク評価であり、リスク分析（リスクの特定、推計、評価）のプロセスが重要になる。本文書では、以下のようなプラクティスを、推奨事項として挙げている。

• ベンダーの分類：サードパーティベンダーを分類する手法を開発し、個々のベンダーのリスク評価に割り当てる
• サードパーティ評価頻度の設定と固有のリスク評価に基づくスコープ：サードパーティリスク評価は、一度限りのプロセスでなく、継続的なモニタリングや再評価を必要とする
• 認識された標準規格を利用したサードパーティ評価の実施：評価をベンダーおよび内部ステークホルダーと共有し、ベンダーが課題に取組み、評価結果をリスク登録に記録することを保証する
• パフォーマンスの評価
• 財務リスクの評価
• 事業継続リスクの評価：サードパーティが中断すると、事業継続のリスクとなる可能性がある

さらに、医療機関は、ベースラインとなるサードパーティベンダー向けセキュリティ質問票を策定しておくことが望まれる。。質問には、以下のような項目も追加するよう推奨している。

• HITRUST認証
• SOC2レポート
• NISTサイバーセキュリティフレームワークなど、認識された標準規格に対するサードパーティ評価
• 内部セキュリティ統制に関する記入済質問票

サードパーティベンダーとしてのSaaS事業者に対するリスク評価

医療・ライフサイエンス業界に限らず、昨今、クラウドサービスの中で成長著しいのは、SaaSである。反面、IaaS（Infrastructure as a Service）事業者やPaaS（Platform as a Service）事業者と比較して、サードパーティベンダーとしてのSaaS事業者のリスクを評価するための指針やベストプラクティスは少ないのが現状である。そこで、クラウドセキュリティアライアンスは、2022年6月8日、「クラウド利用者のためのSaaSガバナンスのベストプラクティス」（https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/08/SaaSGovernanceBestPracticesforCloudCustomers_J.pdf）を公開している。同文書は以下のような構成になっている。

1. はじめに
2. 概要
3. 情報セキュリティポリシー
4. 情報セキュリティ組織
5. 資産管理
6. アクセス制御
7. 暗号化および鍵管理
8. 運用セキュリティ
9. ネットワークセキュリティマネジメント
10. サプライヤーとの関係
11. インシデント管理
12. コンプライアンス
13. CASBの機能と今後の展望
14. 結論

SaaSサービスを初期評価する場合、重要な要素は、「使用するSaaSサービスが、自組織のリスクプロファイルおよびエンタープライズアーキテクチャに潜在的に適合しているか」を評価することだとしている。SaaSアプリケーションは、プライベートクラウドやパブリッククラウド、ハイブリッド環境に実装され、専用または共有リソース（シングルインスタンス、マルチテナント）で提供される。複数のクラウドアプリケーションをAPI経由で連携させてサービスを提供する形態もあるが、個々のSaaSによって、責任共有モデルが異なる点に注意する必要があるとしている。

また、上記の「10. サプライヤーとの関係」の中で、サードパーティベンダーとしてのSaaS事業者に係るリスク管理ポリシーに盛り込むべき項目として、以下のような点を挙げている。

• サードパーティとの関係に対して、組織内で説明可能な単一の役割または立場
• サードパーティ製品またはサービスに依存する業務運営の重要性について、できれば定量的に、その役割または立場を担う人物が書面による評価を提供することを要件とする
• 上記で特定した重要性を考慮し、事故がそのようなサードパーティに影響を与える可能性およびそのような事故が組織の業務に与える影響を評価するための方法論
  • 外部監査およびセキュリティレビュー
  • セキュリティスコアリング／評価ベンダーのツール
  • 顧客組織による監査、侵入テスト、プロバイダの製品またはインフラに対する自動スキャンツールの使用など、直接的な技術デューデリジェンス
• 上記に基づいて設定されたリスク閾値は、サードパーティがこれを超えた場合、サードパーティ側（契約で義務付けられている）、組織自体（何らかの補償的管理を通じて）、またはその両方による是正措置の要求の引き金となる
• 上記の閾値を超えるリスクを受容する権限を有する、組織内の単一の説明可能な役割または地位、並びにそのようなリスク受容を文書化し正当化するための透明性のあるプロセス

さらに、SaaSの安全かつ信頼性の高い運用を確保するために、個々のサプライヤーに合わせた契約書の作成に際して、以下のような点に留意する必要があるとしている。

• 製品の可用性だけでなく、基礎となるデータの機密性と完全性についてのサービスレベル合意書（SLA）の作成
• 組織が監査や侵入テストなどの外部検証プロセスを受け、その結果を提供することの要求
• 客観的なリスク評価システムに基づいて、組織が特定した脆弱性を、所定の期間内に解決または低減策を特定する要求事項。
• 組織が脆弱性の重大性または悪用の可能性を低減するために代償措置を適用できるような脆弱性をサプライヤーが特定した場合，サプライヤーは特定の期間内に組織に通知するという要求事項
• 組織のデータの機密性、完全性、可用性に影響を与えた、または与える可能性のあるインシデントの調査及び是正において、サプライヤーが組織に協力するための要求事項
• データセンターの新規立地を通知し、好ましくない立地を拒否する権利をサプライヤーに求める要件

ただし実際には、サードパーティベンダーとしてのSaaS事業者の特定、優先順位付け、リスク評価といったプロセスを踏むことなく、ユーザー部門主導でSaaSを導入したケースが多く見受けられる。このような場合、シャドーIT化したSaaS利用の実態を把握することが、サードパーティベンダーリスク管理の第１歩とならざるを得ないので要注意だ。

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