タグ別アーカイブ: CSA関西

医療におけるITガバナンス・リスク・コンプライアンス(IT-GRC)(前編)

医療提供組織は、デジタル革命の真只中にある。この傾向は、医療提供組織が健康記録のデジタル化を開始した数年前に始まっており、ビジネスや保健医療データに対する需要も拡大し続けている。加えて、最近の新型コロナウイルス感染症(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日、第1フェーズの入賞者が発表された(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

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

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とヘルスケアアプリケーションに対する理解と利用を加速させるとしている。

  • どのようにして個人が、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日)を参照しながら、「特定」、「保護」、「検知」、「対応」、「復旧」のカテゴリーをベースに、議論を展開している。

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

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

サードパーティベンダーを特定したら、提供するサービスや処理するデータの重要性などを考慮しながら、各ベンダーのリスクを評価し、優先順位(例.重要(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利用の実態を把握することが、サードパーティベンダーリスク管理の第1歩とならざるを得ないので要注意だ。

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

 

 

バイオ/医療サプライチェーンのサイバーセキュリティリスク管理(後編)

クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)が2022年5月11日に公開した「医療サプライチェーンのサイバーセキュリティリスク管理」(https://cloudsecurityalliance.org/artifacts/healthcare-supply-chain-cybersecurity-risk-management/)について、前編では、サプライヤーに対するリスク管理や継続的なモニタリングの重要性を提示した、後編では、実務的なサプライチェーンリスクの取扱や対応計画策定上の留意事項、欧米のサプライチェーンセキュリティ標準化動向などについて概説する。

サプライチェーンリスクの取扱と情報共有

医療機関は、組織の規模に見合ったサプライチェーンリスク管理のためのプログラムを設置する必要がある。サプライチェーンリスク管理(SCRM)プログラムは、組織の規模に関係なく不可欠であり、ひと度リスクを特定したら、効果的にリスクを低減するために管理する必要がある。

その際には、サプライチェーンベンダーを関与させながら、リスク管理に必要な戦術およびシステムのセキュリティパフォーマンス評価に取組む必要がある。また、リスク管理パフォーマンス基準を満たすために求められるサプライチェーンを維持することによって、リスクの露出を抑制しなければならない。そして、ベンダーに対する迅速かつ適切で実用的なフィードバックは、サプライチェーンベンダーが的確なことを実行するために、強力な動機付けとなる。加えて、医療機関は、サプライチェーンベンダーに対して、リスクにより優先順位付けされた行動計画を提供する必要がある。

なおCSAは、サプライチェーンリスクの取扱に関連したベストプラクティスとして、以下のような対策を挙げている。 続きを読む

バイオ/医療サプライチェーンのサイバーセキュリティリスク管理(前編)

医療分野では、医療機関の委託を受けた臨床検査サービス機関やオンラインストレージベンダーなどから、患者の個人情報が外部流出するインシデントが続発している。また、新型コロナウイルス感染症(COVID-19)ワクチン開発に関わる研究開発組織や製造・物流施設、市販前/市販後規制当局、公衆衛生行政機関など、ワクチンサプライチェーン全体を狙った高度標的型(APT)攻撃に対して、世界各国・地域の当局が共同で注意喚起を発出するケースも起きている。

医療サプライチェーン全体に渡るリスク管理プログラムの必要性

このように、世界レベルで医療のサプライチェーンセキュリティに注目が集まる中、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2022年5月11日に「医療サプライチェーンのサイバーセキュリティリスク管理」(https://cloudsecurityalliance.org/artifacts/healthcare-supply-chain-cybersecurity-risk-management/)を公開している。この文書は、医療分野のサプライチェーンに潜むサイバーリスクを最小化するために、医療機関が、適切なリスク管理プラクティスを実践し、サプライヤーやサードパーティベンダーに対するリスク評価を行う際の課題や対策の方向性を示したものである。

本文書では、最初に、医療分野においてサプライチェーンリスク管理プログラムが失敗する理由として、以下のような点を挙げている。 続きを読む

医療におけるAI利用とクラウド(後編)

後編では、医療機関における人工知能(AI)の利活用とともに顕在化するリスク課題のうち、倫理的・法律的側面やクラウド環境特有のセキュリティ・プライバシー課題を取り上げる。

サイバーセキュリティ/プライバシーと密接に関わる医療AI倫理

米国保健福祉省(HHS)は、2021年1月に公表した「人工知能(AI)戦略」の中で、「AIに即応した労働力を開発しAI文化を強化する」、「保健のAIイノベーションと研究開発(R&D)を推奨する」、「基礎的なAIツールとリソースを民主化する」と並んで、「倫理的で信頼されるAIの利用と開発を促進する」を注力領域に掲げている。そこでは、組織の枠を超えて、市民のプライバシーやデータセキュリティを尊重した、信頼性があり、説明可能で、バイアスのない、セキュアなAIシステムを展開すると同時に、既存のサイバーセキュリティフレームワークのAIユースケースへの適用を促進・支援し、適用されたAIの正確性や有効性、健康の公平性に関する評価を推進する姿勢を打ち出している。

このような背景を反映して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)の「医療における人工知能」(https://cloudsecurityalliance.org/artifacts/artificial-intelligence-in-healthcare/)でも、医療AIの倫理的課題を取り上げている。具体的には、以下の3点を挙げている。 続きを読む

医療におけるAI利用とクラウド(前編)

医療は、人工知能(AI)の有望な利活用領域として期待されており、世界各国・地域が積極的な研究開発投資を行っている。クラウド環境を利用したAIアルゴリズムの開発や、臨床現場向け診断・治療支援ソリューションの提供・運用も拡大しつつあるが、バイアス、倫理、法務、セキュリティ、プライバシーといったリスク課題も抱えている。

米国政府が積極的に推進する医療AI

米国の医療分野では、2019年2月11日に制定された「人工知能(AI)分野における米国の優位性を維持し一層促進するための大統領令」に基づき、保健福祉省(HHS)が、2021年1月に「人工知能(AI)戦略」を発表し、チーフAIオフィサー室(OCAIO)を新設している。

同戦略では、AIについて、「日常的なタスクを自動化し、データに基づく洞察を引き出し、人間行動を拡張させることができるソリューションを提供するために、通常は人間のインテリジェンスを要求するようなタスクを遂行できるコンピュータシステムの理論および開発」と定義している。その上で、HHSは、アカデミアや産業界、政府機関のパートナーとともに、AIを活用して、米国の人々の健康・ウェルビーイングにおける進化を継続的に先導することによって、従来解決できなかった課題を解決し、保健福祉サービスのエコシステムにわたるAI利用に対応し、部門を越えた信頼できるAI採用をスケーリングすることを目標に掲げている。 続きを読む

医療クラウドにおけるランサムウェア攻撃予防対策(後編)

前編はこちら

NISTの「重要インフラのサイバーセキュリティを向上させるためのフレームワーク1.1版」(日本語訳:https://www.ipa.go.jp/files/000071204.pdf)では、フレームワーク・コアの機能(Function)として、「特定(Identify)」「防御(Protect)」「検知(Detect)」「対応(Respond)」「復旧(Recover)」を定義している。以下では、CSAが各機能ごとに整理した、医療クラウドならではのマルウェア対策上の留意事項を紹介する。

特定(Identify):

  • 資産、ビジネス環境、ガバナンス、リスク管理、サプライチェーンの特定は、医療機関のサイバーセキュリティプログラム構築の基盤となる。医療機関がクラウド上にデータを保存する場合、ランサムウェア攻撃被害の復旧対策上、データがどこに保存され、その場所でどんな規制が適用されるかを把握しておかないと、データ損失の事態を招きかねない。そのためには、すべての文書や手順、プロセスを確実に文書化しておくことが求められる。

続きを読む