月別アーカイブ: 2023年3月

クラウドネイティブにおける新しい責任共有モデルとセキュリティの考え方

コメントをどうぞ

クラウドネイティブにおける新しい責任共有モデルとセキュリティの考え方

2023年3月29日
CSAジャパン　クラウドセキュリティ自動化WG　諸角昌宏

クラウドの責任共有モデルは、サービスモデル（IaaS, PaaS, SaaS）に基づいて説明されてきた。しかしながら、新たに登場してきたコンテナ、サーバーレス等を用いたクラウドネイティブの環境における責任共有モデルを考えた場合、既存のサービスモデルに基づいた考え方ではカバーしきれないのではないかという懸念がある。CSA Silicon Valley Chapterでは、クラウドネイティブにおける新しい責任共有モデルの考え方を説明した” The Evolution of Cloud Computing and the Updated Shared Responsibility”というブログを2021年2月に公開した。これはCSAジャパンにより日本語化され「クラウドコンピューティングの進化と新たな責任共有モデル」として公開されている。
ここでは、上記資料で説明されている新しい責任共有モデルに対して、CSAが公開した以下の資料におけるセキュリティの考え方を対応させることで、クラウドネイティブの責任共有モデルの考え方とそのセキュリティの考え方について統合して理解できるようにしたい。

なお、このクラウドネイティブの責任共有モデルは、標準として定められているものではなく、あくまで現段階における1つの考え方として提供されているものであるということは注意していただきたい。今後、NISTやISOにおいて、標準としてのクラウドネイティブの責任共有モデルが定義された際は、その標準に基づいて改めて考えていく必要がある。

  1. クラウドネイティブにおける新しい責任共有モデルの概要
    ここでは、まずクラウドネイティブにおける新しい責任共有モデルについて、「クラウドコンピューティングの進化と新たな責任共有モデル」の下図を用いて説明する。なお、ここで記述されているモデルをここからは便宜上「CNCFモデル」と呼ぶことにする。また、ここでは要点だけ説明するので詳細は上記資料を参照していただきたい。なお、下図は上記資料では英語で表記されているが、分かりやすくするため日本語に翻訳して表記している。
    図1　CNCFモデル（「クラウドコンピューティングの進化と新たな責任共有モデル」より引用、作成）

図の左で「CNCFレイヤー」と記載されているのはCloud Native Computing Frameworkとして、既存のサービスモデルのレイヤーに新たに追加されたクラウドネイティブのレイヤーである。これらのレイヤーは以下の内容になる。

  • プロビジョニングサービスプレーン
    このレイヤーは、コントロールプレーンにあたる。ここでは、Kubernetesで説明されているが、Dockerコントロールプレーンでも同様に扱うことができる。プロビジョニングサービスプレーンでは、コンテナの稼働や停止等の運用や、コンテナの配置、デプロイ時のコンテナ入れ替えや仮想ネットワークの提供等を行う。
    セキュリティの観点からは、コンテナのセキュリティを実装されるために必要となる機能およびアーキテクチャを提供するレイヤーとなる。
    このレイヤーは、IaaSを除くすべてのモデル（K8s-aaS, CaaS, FaaS, NoCode, SaaS）においてプロバイダの責任となる。IaaSにおいては、このレイヤーにあたるKubernetesやDockerを利用者がインストール・設定・運用・管理を行うため、利用者側の責任となる。
  • マネージドサービスランタイム
    このレイヤーは、データプレーンにあたる。コンテナが稼働する実行環境、もしくはサーバーインスタンスそのもので、コンテナランタイムを管理する。コントロールプレーンが提供する機能を実際にコンテナランタイムに対して実施するレイヤーとなる。
    サーバーレスの観点では、コントロールプレーンとデータプレーンの両方をプロバイダが管理することで、利用者はコンテナクラスタや仮想マシンなどのインフラストラクチャを管理しなくてもクラウドネイティブサービスに簡単に移行できるようになる。したがって、このマネージドサービスランタイムのレイヤーまでをプロバイダが管理するモデル（CaaS, FaaS, NoCode）がサーバーレスのモデルということになり、K8s-aaSはサーバーレスではないことになる（注：SaaSはアプリケーションを含むクラウド全体をプロバイダが管理するので、サーバーレスのカテゴリーからは除くこととする）。
  • アプリケーションビルドとパッケージ化
    このレイヤーは、コンテナイメージの作成、コンテナ環境への移動・実施といういわゆるビルドチェーンを管理する。クラウドネイティブの観点では、このレイヤーを利用者が管理する（CaaS）のか、あるいはプロバイダが管理する（FaaS, NoCode）のかということになり、サーバーレスの責任共有を考える上では重要なレイヤーとなる。後ほどサーバーレスの章で説明する「コンテナイメージベースのサーバーレス」（CaaS）と「機能ベース（ファンクションベース）のサーバーレス」（FaaS, NoCode）として、それぞれの責任を明確にすることが必要となる。
  • アプリケーション定義と開発
    このレイヤーは、アプリケーションのコードロジックを定義・開発する。アプリケーションの仕様と構成からコードを生成する際に、利用者が自身でコードロジックを作成する（FaaS）のか、あるいは、プロバイダが利用者の作成した仕様と構成からコードを生成する(No-Code)に分類される。クラウドネイティブの観点からは、この2つのモデルの差はあまりなく、FaaSの場合には利用者がビジネスロジックを直接コード化する（Python等を用いる）のに対して、No-Codeの場合にはプロバイダが提供するGUI等を用いてドラグ&ドロップなどによってコードロジックを作成する。No-Codeに対してLow-Codeという方法もありこれはGUIだけでなく一部のコードロジックについては直接作成する。
    セキュリティの観点では、このレイヤーは基本的に利用者が管理を行うが、No-Codeの場合にはGUIを提供する部分がプロバイダの責任となる。責任共有の観点からはあまり区別する必要は無いと思われる。
  1. コンテナセキュリティ
    ここでは、CSAが公開している「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」に基づいてコンテナセキュリティについて説明する。この資料では、コンテナのセキュリティについてアプリケーションの開発者および運用者の観点で書かれているので、上記のモデルのK8s-aaSを対象として考えるのが分かりやすい。つまり、この資料の登場人物である「開発者」を利用者、「運用者」をプロバイダと読み替えることで、K8s-aaSの責任共有モデルとして表現できる。

    • CNCFレイヤーとコンテナセキュリティ
      まず、本資料で記述しているコンテナセキュリティの構成要素をCNCFレイヤーに対応付けると以下になる。

      • プロビジョニングサービスプレーン
        プロビジョニングサービスプレーンを構成しているのは、プラットフォーム管理、コンテナ管理で、運用者がこれらの機能を提供している。
      • マネージドサービスランタイム
        プロビジョニングサービスプレーンで提供されている機能を用いて、開発者がコンテナランタイムの管理を実施する。
      • アプリケーションビルドとパッケージ化、アプリケーション定義と開発
        この2つのレイヤーは、アプリケーションの設計、開発、ビルド、実行を行うもので、開発者が管理する。
    • コンテナセキュリティの内容
      ここでは、コンテナセキュリティについて、主なポイントとなる点を説明する。詳細については上記資料を参照していただきたい。

      • 開発者のアプリケーションセキュリティ
        • 開発環境全体（開発、品質保証、テスト、本番）のコードプロモーションのセキュリティ対策として、コンテナイメージに署名し信頼の起点（root of trust）を確立する。
        • 開発プロセスの一部として脆弱性スキャンを行う。
        • イメージの中には必要なコンポーネントのみを入れる。
        • アプリケーションにログ機能、フォレンジック機能を含める。
        • アプリケーションにシークレット管理機能を取り込む。
        • コンテナイメージの暗号化、保存データの暗号化を行う。
      • 運用者のアプリケーションセキュリティ
        • ビルドチェーンの完全性を確保するため、デジタル署名を使用し検証するための機能を提供する。
        • 署名され承認されたイメージだけを使用許可するための機能を組み込む。
      • 運用者のホストセキュリティ（ホストセキュリティは開発者は無し）
        • 通信の暗号化を行う。
        • コンテナを特権モードで実行しない。
        • 基本的に、コンテナランタイムにホストファイルシステムへのアクセスを許可しない。
        • 限定的なcapability設定でコンテナを起動する。ユーザが必要な機能以外を使用できないようにする。
      • 開発者のプラットフォームセキュリティ
        • コンテナで実行されるアプリケーションのバージョン管理を行う。
      • 運用者のプラットフォームセキュリティ
        • ログの送信、集中管理の基盤を提供する。
        • コンテナのライフサイクル（起動から破棄まで）のイベントを開発者に通知できるようにする。これにより、開発者は適切な対応が取れるようになる。
        • リソースの消費を監視し、最適化する。
      • 開発者のコンテナセキュリティ
        • ホストとコンテナ間の通信の機密性（暗号化）および双方向TLS等の相互認証メカニズムを使用する。
        • ネットワーク監視機能を使用する。
        • コンテナのフォレンジック機能、ログ機能を、アプリケーションにログ機能を含める。
        • データのバックアップとして、データの保存場所の特定、バックアップの定期的な実施、また、コンテナが消滅する前にバックアップされることを確認する。
      • 運用者のコンテナセキュリティ
        • ホストとコンテナ間の通信の機密性（暗号化）および双方向TLS等の相互認証メカニズムを提供する。
        • コンテナのフォレンジック機能、ログ機能を提供する。
        • コンテナのトラストチェーンの維持。OS およびコンテナイメージの完全性検証、脆弱性検査を実施する。
        • コンテナのリソース管理、ボリューム監視を行う。
        • 通信トラフィックの分離を行う。
        • シークレット管理機能を提供する。
        • データのバックアップとして、データの保存場所の特定、バックアップの定期的な実施、また、コンテナが消滅する前にバックアップされることを確認する。

以上のようなポイントを考慮してコンテナのセキュリティを考えていくことが必要である。

  1. サーバーレスセキュリティ
    サーバーレスは、CNCFモデルではCaaS, FaaS, No-Codeの各モデルが対象となる。サーバーレスのセキュリティとしてCSAが公開している資料は、「安全なサーバーレスアーキテクチャを設計するには」であり、ここではこの資料とCaaS, FaaS, No-Codeの各モデルをマップして説明する。サーバーレスセキュリティの基本的な考え方は、クラウド利用者（注：「安全なサーバーレスアーキテクチャを設計するには」では「アプリケーションオーナー」と表記）がデータの保護およびアプリケーションの保護のみの責任を持つ。一方、クラウドプロバイダ（注：「安全なサーバーレスアーキテクチャを設計するには」では「サーバーレスプラットフォームプロバイダ」と表記）がサーバーの立ち上げ、OSのパッチ適用、アップデート、シャットダウンなどのサーバーやそのセキュリティの管理の責任を持つ。これにより、アプリケーションオーナーはインフラの管理を気にせずにアプリケーションに集中することができる。「安全なサーバーレスアーキテクチャを設計するには」では、サーバーレスを2つの名称に分けて表現しており、1つは「コンテナイメージベースのサーバーレス」で、もう1つが「機能ベース（ファンクションベース）サーバーレス」である。この２つの名称をCNCFモデルに当てはめると以下のようになる。

    • コンテナイメージベースのサーバーレス：　CaaS
    • 機能ベースのサーバーレス：　FaaS, No-Code

機能ベースのサーバーレスにFaaS, No-Codeの2つのモデルを当てはめているが、FaaS, No-Codeの違いは「アプリケーション定義と開発」レイヤーにおける責任の一部の違いであり、サーバーレスのセキュリティを考える上では同じものとして扱うことで問題ないと考える。

これをCNCFレイヤーとサーバーレスのセキュリティを対応付けると以下になる。

  • アプリケーションビルドとパッケージ化
    コンテナイメージベースのサーバーレス（CaaS）ではアプリケーションオーナー（利用者）の責任となるが、機能ベースのサーバーレス（FaaS, No-Code）ではサーバーレスプラットフォームプロバイダ（プロバイダ）の責任となる。
  • アプリケーション定義と開発
    コンテナイメージベースのサーバーレス（CaaS）、機能ベースのサーバーレス（FaaS, No-Code）のどちらにおいても利用者の責任となる。

この責任の考え方については、「安全なサーバーレスアーキテクチャを設計するには」で表現されている以下の２つの図が分かりやすい。「コンテナイメージベースのサーバーレス（注：この図では「イメージベースのサーバーレスの責任共有モデル」と表現）」（左図）では、コンテナイメージの責任がアプリケーションオーナー、つまりクラウド利用者となっているのに対して、「機能ベースのサーバーレス(注：この図では機能ベースのサーバーレス(FaaS)の責任共有モデル」と表現)」（右図）では、このコンテナイメージの責任がサービスプロバイダとなっている。この違いは、CNCFモデルにおける「アプリケーションビルドとパッケージ化」レイヤーの責任の違いとなる。

図2　「安全なサーバーレスアーキテクチャを設計するには」より引用

なお、これらをAWS、Azure、Googleのサービスに照らし合わせると以下になる。

  • コンテナイメージベースのサーバーレス（CaaS）
    AWS Fargate、Azure Container Instances（ACI）、GoogleCloudRunなど
  • 機能ベースのサーバーレス（FaaS, No-Code）
    FaaS: AWS Lambda、Azure Functions、Google CloudFunctions
    No-Code: Azure Power Apps、Google AppSheet、AWSHoneycode

これをCNCFレイヤーとサーバーレスのセキュリティを対応付けると以下になる。

  • アプリケーションビルドとパッケージ化
    コンテナイメージベースのサーバーレス（CaaS）ではアプリケーションオーナーの責任となるが、機能ベースのサーバーレス（FaaS, No-Code）ではプロバイダの責任となる。
  • アプリケーション定義と開発
    コンテナイメージベースのサーバーレス（CaaS）、機能ベースのサーバーレス（FaaS, No-Code）のどちらにおいてもアプリケーションオーナーの責任となる。

「アプリケーションビルドとパッケージ化」におけるセキュリティは、「2. コンテナセキュリティ」で説明した内容となるのでそちらを参照していただきたい。あくまで、これがアプリケーションオーナーの責任になるかプロバイダの責任になるかの違いである。
「アプリケーション定義と開発」におけるセキュリティについて、「安全なサーバーレスアーキテクチャを設計するには」では、アプリケーションオーナー（つまり、利用者）のセキュリティとして、ワークロードへの脅威の観点で以下の3点を挙げている。

  • セットアップフェーズの脅威
    アプリケーションオーナーがワークロードを準備し、コード、イメージ、CI/CD作業、デプロイに関する脅威のことを言う。最小特権原則を維持していない呼び出し、およびセキュアでない構成管理の問題となる。
    サーバーレスにおいてはワークロードが小さな呼び出し可能なユニットに分割され、それぞれにセキュリティを管理する一連のパラメータ（ユーザの認証情報/アクセス件、呼び出し可能なユニットの認証情報/アクセス権、モニタリングなど）が設定される。これらに対して、最小権限の原則を維持することが必要である。また、この分割が増えることで、サプライチェーンの脆弱性の問題が起こる。ベースイメージの脆弱性、リポジトリに対する不正アクセス、ビルド/デプロイツールに対する攻撃などへの対応が必要である。
  • デプロイフェーズの脅威
    アプリケーションオーナーによるワークロードのデプロイフェーズでの脅威のことを言う。
    サーバーレスでは、様々なリソースからの膨大なイベントを利用する。イベントの一部として呼び出し可能なユニットに渡される情報はデータインジェクションの脅威となる。また、呼び出し可能なユニットが必要とするトークン、シークレットなどはグローバルコンテキストを必要とし、このグローバルコンテキストのリークが発生する脅威がある。
    また、サーバーレスで使用するコンピュートリソースは従量課金であるため、適切な感じと処理を行わないとリソースの枯渇等の問題が発生する。
    サーバーレスのワークロードは、データと制御パスの一部をサービスプロバイダにオフロードするため、開発とテストをクラウド上で行う必要がある。デバッグなどが制限される可能性もある。したがって、エラーメッセージが重要になる。
  • サービス事業者による脅威
    サービスプロバイダが使用するコンポーネントスタック全体および関連サービスの脅威が含まれる。
    まず重要なのがマルチテナントを維持するための隔離の問題である。サーバーレスでは、プロバイダが分離を確立する必要がある。また、インスタンスの起動／終了のオーバーヘッドを削減するために呼び出し可能なユニットの再利用を行う場合があるため、呼び出し可能なユニットの呼び出し間の漏洩および残留データの漏洩というサーバーレス固有の脅威もある。
    また、責任共有の問題として、サーバーレスではコードの設計、ランタイムのセキュリティの責任をアプリケーションオーナーが持つが、その中で機能ベースのサーバーレスの場合、プロバイダが提供する呼び出し可能なユニットの脆弱性が発生する可能性がある。コードの設計やイベントシステムのセキュリティだけでなく両者の相互作用についても考える必要がある。

以上が、アプリケーションオーナーのワークロードへの脅威の観点でのサーバーレスのセキュリティとなるが、「安全なサーバーレスアーキテクチャを設計するには」ではKubernetesのセキュリティからアプリケーションのセキュリティまでを詳細に記述している。Kubernetesのセキュリティは、「2. コンテナセキュリティ」でも記述されている部分になるが、より詳しくKubernetesの機能に基づいて記述しているので、参照していただきたい。

  1. まとめ
    以上、CNCFモデルをベースに、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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司