データの暗号化における利用者鍵管理について

データの暗号化における利用者鍵管理について

2022年2月9日
データセキュリティ WGメンバー: 諸角昌宏

本ブログでは、クラウド利用において必要となる利用者鍵管理について解説する。

  1. 利用者鍵管理の必要性について

    クラウドでは共有責任モデルとしてユーザーがデータセキュリティの責任を持ちます。そのデータを保護する技術として「暗号化」が有効な技術であることが各法規制やガイドライン等で言及されており、多くの情報システムにおいて暗号技術は活用されています。
    また暗号化技術を利用する場合には「暗号鍵」もユーザーの責任で保護する必要があり、ユーザー自身の責任で鍵管理技術を理解して実装方法を選択して運用する必要があります。」(引用: Cloud Data Protection, https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/08/Cloud_Data_Protection2_V10.pdf

    また、クラウドコンピューティングのためのセキュリティガイダンス V4.0(https://cloudsecurityalliance.jp/j-docs/CSA_Guidance_V4.0_J_V1.2_clear_20200806.pdf)では、利用者が管理できる鍵(Customer-Managed Keys)」という手法の説明として、「利用者が管理できる鍵は、クラウド事業者が暗号化エンジンを管理するのに対して、クラウド利用者が自身の暗号鍵を管理できるようにする。例えば、SaaSプラットフォームの中でSaaSデータを暗号化するのに利用者自身の鍵を使う。クラウド事業者の多くは、デフォルトでデータを暗号化するが、事業者自らの完全な管理下にある鍵を使う。一部の事業者では、利用者が自分の鍵に差し替えて事業者の暗号化システムに組み入れることを許している。利用する事業者のやり方が利用者自身の要求条件と合致するか確認する必要がある。」と記載している。

    クラウドにデータを暗号化して保存する場合において、プロバイダーが鍵を管理すると以下のような問題が発生する可能性がある:

    • クラウド側のインサイダー(管理者)による情報侵害が発生する可能性がある
    • クラウド上に暗号化データと暗号化鍵の両方が存在するため、クラウド環境が侵害された場合(例えば、利用者間の論理境界が破られるなど)に情報漏洩につながる可能性がある
    • 召喚状等によりプロバイダーが利用者データの開示を求められた場合、クラウド上に暗号化して保存していたデータであっても、プロバイダーが復号して提供することが可能になる

半面、利用者がデータを暗号化し暗号鍵を保持する場合、アプリケーション(クラウドサービス)がそのデータを処理できないという問題が発生する。IaaSにおいては、利用者がアプリケーションとデータの両方を管理できるため、利用者が暗号化鍵を管理することが可能だが、SaaS環境においてはこの問題に直面する。

そこで考えられたのが「利用者による鍵管理(以下、利用者鍵管理と呼ぶ)」という方法で、プロバイダーが暗号化エンジンを管理するのに対して、利用者が自身の暗号鍵を管理できるようにする仕組みである。本ブログでは、この利用者鍵管理についての規制等の要求事項、利用者鍵管理の手法、動作の例などについて説明していく。

  1. 利用者鍵管理に関係する規制・要求事項

    以下に、代表的な規格における利用者鍵管理の要求事項を記載する。

    • ISO/IEC 27017
      • 10.1.2:  クラウドサービスカスタマは,自らの鍵管理を採用する場合又はクラウドサービスプロバイダの鍵管理サービスとは別のサービスを利用する場合,暗号の運用のための暗号鍵をクラウドサービスプロバイダが保存し,管理することを許可しないことが望ましい。
    • CSA CCM V4
      • CEK-08: CSPはCSCがデータ暗号鍵を管理できる機能を適用しなければならない。
    • ISMAP
      • 10.1.1.9.PB: クラウドサービス事業者は、クラウドサービス利用者に、当該利用者の管理する情報の暗号化に用いる暗号鍵を当該利用者が管理し消去する機能を提供し、または、当該利用者が暗号鍵を管理し消去する機能を実装するために必要となる情報を提供する。
  1. 利用者鍵管理(BYOK、HYOK)とは?

    利用者鍵管理の構成として、前述の「Cloud Data Protection」では以下のように2つのタイプ(BYOK、HYOK)が記述されている。

    • BYOK(Bring Your Own Key)

      • ユーザー自身が暗号鍵を作成してクラウドサービスに持ち込むシステム構成
      • 持ち込んだ後の暗号鍵はクラウドサービス事業者内で管理
      • APIが公開されることが多く、オンプレミスのHSM等で作成した鍵をアプリケーションを開発することで持ち込むことが可能
    • HYOK(Hold Your Own Key)

      • クラウド事業者のサービスがユーザーの鍵管理システムを利用
      • ユーザーの暗号鍵はクラウドサービス事業者外部で管理

ここで、BYOKとHYOKの違いを明確にすると以下のようになる:

  • BYOKは、ユーザー自身が暗号鍵の作成・管理を行うが、プロバイダー側(つまり、クラウドのアプリケーション)が復号を行うにあたって、利用者から鍵を受け取る。受け取った鍵は、プロバイダー側で管理することになる。したがって、一度プロバイダーに渡された鍵を利用者が管理することはできない。
  • HYOKでは、利用者はプロバイダーの鍵管理システムを利用するが、暗号鍵の管理は利用者自らが行い、利用者の管理のもとプロバイダーは暗号鍵を扱うことができるようになる。したがって、利用者が常に鍵を管理することが可能になる。なお、このHYOKを提供する方法は、Microsoft Azureの2重キー暗号化 (Double Key Encryption) 、 Google Cloud External Key Manager、Salesforceキャッシュのみの鍵サービス(Cache-Only Key)などがあり、主なプロバイダーが提供している。

このBYOKとHYOKを明確にすることが重要であり、ここが利用者鍵管理として混同されている点である。特に、BYOKがバズワードとなっていて、利用者鍵管理=BYOK と扱われてしまっていることが問題となる。先に述べた様々な規格の要求事項は、HYOKが必要となることでありBYOKでは不十分であるということを理解する必要がある。

  1. 利用者鍵管理(HYOK)の動作例

    ここでは、HYOKの動作の1つの例を以下の図を使って説明する。

    まず、この図に表示されているそれぞれの鍵について説明する:

    • DEK(Data Encryption Key): データ暗号化鍵。データを暗号化および復号に使用
    • 暗号化DEK(Encrypted DEK) :DEKを暗号化したもの
    • KEK(Key Encryption Key):DEKの暗号化に使用される鍵
    • マスターキー:KEKの暗号化に使用される鍵

利用者から送られたデータを暗号化してストレージに保存する手順は以下になる:
(1) アプリケーションに利用者からデータが送られる
(2) アプリケーションは、KMSに対して、データ暗号化用の鍵(DEK)を要求する
(3) KMSは、DEKを作成し、KEKを使って暗号化DEKを作成し、DEKと暗号化DEKの両方をアプリケーションに送る
(4) アプリケーションは、DEKを用いてデータを暗号化し、暗号化されたデータと暗号化DEKをストレージに送る
(5) アプリケーションはDEKを削除する

次に、データを復号する手順は以下になる:
(1) アプリケーションは、ストレージから暗号化されたデータと暗号化DEKを入手する
(2) アプリケーションは、暗号化DEKをKMSに送る
(3) KMSは、KEMを用いてDEKを作成し、アプリケーションに送る
(4) アプリケーションは、DEKを使ってデータを復号する
(5) アプリケーションはDEKを削除する

以上の流れにおいて、プロバイダーがDEKを保有するのは、暗号化および復号の作業を行うときのみになる。また、一連の流れとして、利用者が鍵の管理を行うことができる。

  1. 利用者鍵管理に向けての考慮事項

    • BYOK  利用者鍵管理 について

      以上、説明してきたように、クラウド環境で必要とする利用者鍵管理はHYOKであり、BYOKでは不十分である。しかしながら、BYOKを利用者鍵管理として説明している資料も多数あるのも事実である。ここは悩ましいところであり、現状でこれを明確にしていくことはかなり難しいかもしれない。もちろん、BYOK、HYOKを正確に伝えることは重要であるが、ある程度BYOKとHYOKを区別せずに、HYOKとして必要な要求事項をベースにしてBYOKを説明することもやむを得ないと思われる。
      また、BYOKとHYOKを厳密に区別することが、逆に、利用者鍵管理は不要であるという印象を与えてしまっているケースもある。CSAが公開している「クラウドサービスの鍵管理(原書:Key Management in Cloud Services)」では、まとめとして、「いわゆるBYOK(Bring Your Own Key)や同様のモデルをクラウドサービスで使用したBYOKの意味は、通常期待される結果が得られないことを示しています。これらのいわゆるBYOKモデルを使用しようとしているほとんどの組織は、クラウドサービスプロバイダが利用者のデータを裁判所や法執行機関などの第三者に引き渡すことを強制できないことを期待しています。ただし、いわゆるBYOKモデルのほとんどのベンダーにおける実装では、クラウドサービスがデータ暗号化鍵を使用しているため、必要に応じてエクスポート用に暗号化されていないデータを生成できるので、実際にはその結果を防げません。」と記述している。これは、BYOKとHYOKを明確に区別した上でBYOKでは不十分であることを指摘しているのであるが、HYOKを含めた利用者鍵管理すべてが不十分であると理解されてしまっているところがある。この辺りは、CSAとしても明確に記述する必要があったと思われる。
      また、ISMAPのFAQ(https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010098&sys_kb_id=cfb60af91baebc1013a78665cc4bcb12&spa=1)において、「暗号鍵の管理に関するクラウドサービス事業者内部からの不正アクセス対策を別の手段で実現すること。①1.2(権限分離)、②7.2.1(従業員・契約相手へのセキュリティ)及び③9.2.3(特権的アクセス権の制限)を適切に実施…」という代替策を記述している。しかしながら、この代替案では、先に挙げたプロバイダーが鍵を管理する場合の問題点に対する対策にはならない可能性が高く、あくまでリスク管理上可能であれば取れる代替案であることを理解しておく必要がある。

    • SaaSにおける利用者鍵管理の実装について

      SaaSプロバイダーが利用者鍵管理を提供する場合、以下の2つのケースが考えられる:

      • SaaSプロバイダーが、第三者ベンダーが提供している利用者鍵管理機能を実装する。
      • SaaSプロバイダーが、インフラとして利用しているIaaS/PaaSプロバイダーが提供している利用者鍵管理を用いて実装する。

なお、SaaSプロバイダーが利用者鍵管理を評価・実装するには、ユースケースを含めた詳しい情報が必要であると思われる。利用者鍵管理を提供しているベンダーおよびIaaS/SaaSプロバイダーは、利用者鍵管理に関する情報を積極的に発信していただきたい。本ブログにおいても、今後、できるだけ情報発信できるようにしていきたい。

6. 暗号化の代替手段

これまで、利用者鍵管理について記述してきたが、利用者鍵管理が必要となるそもそもの暗号化について、その代替手段として以下の2つが考えられる。

  • トークン化

    トークン化はクレジットカードの保護等で実績がある仕組みであり、従来からの暗号化技術と同様検討に値する技術である。
    暗号化の問題は、アプリケーションが暗号化されたデータを処理できないという点である。利用者鍵管理の問題以前に、クラウド上のアプリケーションは、何らかの形で復号しないと処理できないという根本的な問題を抱えており、クラウドのマルチテナントを維持しなければならない環境において問題となる。トークン化されたデータは、元のデータと同じサイズ/形式で保管されるため、トークン化されたデータを保管するためにデータベースのスキーマやプロセスを変更する必要はない。データのトークン化により、クラウドやビッグデータ、外部委託環境に移行する際も、制御機能やコンプライアンスを維持することが可能である。ここでは、トークン化について詳しく述べないが、1つの代替手段と考えられる。

  • 完全準同型暗号

    アプリケーションが、暗号化データを復号せずに処理できる方法として、(完全)準同型暗号が考えられる。まだ、あまり一般に商用化されていないが、今後、幅広く利用されてくる可能性もある。今後の展開に注目したい。

以上、クラウド上のデータの暗号化として必要となる利用者鍵管理について記述した。これから先、新たな情報が得られれば、また、情報発信していきたい。

以上

Log4Shellとゼロトラスト

本ブログは、CSA本部のブログを著者の許可を得て翻訳したものです。本ブログの内容とCSA本部のブログとに相違があった場合には、CSA本部のブログの内容が優先されます。

Log4Shellとゼロトラスト

このブログは、Appgateのこちらの記事を元にしています。
著者:Jason Garbis、Appgate

Log4Shellの脆弱性が発覚してからわずか数週間しか経っていませんが(関連する問題はまだいくつか残っています)、世界中のセキュリティチームは、診断、検証、更新、コミュニケーションのために奔走しています。一歩下がって振り返るにはまだ少し早いかもしれませんが、私はいくつかの考えをコミュニティと共有したいと思います。

Log4Shellは、悪用が容易であるだけでなく、一般的に攻撃対象がすべてのユーザーに利用可能であり、非常に陰湿な脆弱性です。多くの場合、そのユーザーは認証前の状態です。場合によっては、悪意ある者がウェブサイトのログインページから直接攻撃を仕掛けて成功させることも可能です。さらに、このエクスプロイトは、通常、信頼されたゾーンの企業ネットワーク上で動作するロギングサーバー自身によって実行されます。ロギングサーバーは、インターネット上の悪意のあるサイトにアウトバウンドのリクエストを行い、悪意のあるコードを取得し、ローカルで実行します。

この種の脆弱性に対しては、ゼロトラストセキュリティとその中心的な考え方である最小権限の原則を実施することの重要性を示しています。それは、不必要にインターネットにさらされているアプリケーションがあまりにも多いからです。ZTNA(Zero Trust Network Access)技術を使用すると、ユーザーがアクセスを許可され認証されない限り、すべてのリソースを見えなくし、攻撃対象を減らすことができます。

Log4Shellは、認証のみのセキュリティではあまりにも弱すぎることを示す好例で、悪意のあるアクターにログイン画面を見せるだけでも悪用されてしまいます。ゼロトラストの最小権限の原則は、プライベートなアプリケーションがネットワーク上に隠れていることを保証し、悪用される可能性を最小限にします。

もちろん、会社のWebサイトのように、公開しなければならないアプリケーションやWebサイトもあります。しかし、企業はセキュリティの考え方を変えることで、顧客専用のWebアプリケーションに対しては、実際の顧客にしかアクセスできないようにすることを検討すべきです。

例えば、ビジネス向けの出荷・物流サービスを提供している企業であれば、顧客のログインページをあらゆる攻撃者に公開する理由はありません。ゼロトラスト方式を採用すれば、正当なお客様だけがログインを試みることができ、攻撃者がログインサイトを悪用することを防ぐことができます。このような安全性の高いアクセス方法をお客様に要求することは、合理的であるだけでなく、お客様に対するビジネスのセールスポイントにもなり得ます。

一般に公開する必要のあるサーバーやサイトについては、組織はゼロトラストの原則である最小権限モデルを適用しなければなりません。これらのサーバーは、広い範囲の社内ネットワークにアクセスできないようにする必要があります。すべてのアクセスはデフォルトでは拒否され、定義されたポリシーに基づいて明示的に許可されたアクセスのみが許可されなければなりません。このモデルは、インターネットへのアウトバウンドアクセスにも適用する必要があります。

企業は、ネットワーク上で稼働しているリソースだけでなく、それらのリソースが何にアクセスすることを許可されているのかを明確に把握し、明確に定義されたゼロトラストポリシーによってアクセスを許可する必要があります。これは、内部のサーバー間のアクセスについても、正当かつ合理的な要件です。セキュリティチームは、必要なアクセスを許可するためのポリシーを文書化し設定する責任をITチームやアプリケーションチームに負わせなければなりません。また、セキュリティチームは、それ以外のすべてのアクセスを制限する責任も負わなければなりません。

管理者からサーバーへのアクセス(アップデートや設定変更など)には、ITサービスマネジメント(ITSM)のビジネスプロセスに基づいてアクセスを制御するゼロトラストシステムを用いて、定義されたメンテナンスウィンドウを使用すべきです。さらに進んだ組織では、サーバーをペットではなく家畜のように扱うDevOpsのアプローチを検討する必要があります。つまり、サーバーのアップグレードやメンテナンスは行わず、マスターイメージを更新して新しいサーバーをデプロイすることになります。

サーバーからインターネットへのアクセスの場合、ほとんどのサーバーは任意のインターネットサイトにアクセスする正当な必要性はなく、むしろアクセスを許可することはセキュリティ上の弱点となります。組織は、このようなアクセスをブロックするか、許可された厳格なサイトに制限する必要があります。DNSやNTPなどのコアネットワークやインフラサービスは、企業が管理する内部システムに限定する必要があります。

Log4Shellはまた、ソフトウェアサプライチェーンのセキュリティと完全性に関するもっともな疑問を提起していますが、これについては別のブログ記事で取り上げます。ソフトウェアをどの程度信頼しているかにかかわらず、「侵害を想定する」というゼロトラストの原則に基づいて運用する必要があります。オープンソース、ベンダーから提供されたソフトウェア、または独自に作成したソフトウェアが危険にさらされていると想定する場合、最低限、ソフトウェアのインバウンドとアウトバウンドを制限し、すべてのアクセスがポリシーによって明示的に制御されていることを確認し、実際の動作を記録して監視する必要があります。

今日のリモートワークの世界における複雑な脅威の状況、脆弱性が発生する頻度、ハイブリッド環境の複雑さ、デバイスの急増を考慮すると、多くの企業や政府機関は、ゼロトラストへの移行に急速に乗り出しています。ZTNAソリューションは、以下の方法で移行をスムーズに行うことができます:

  • 例えば、SPA(Single Packet Authorization)を使用して、ポートを積極的に隠蔽し、インターネットに接続されたサーバーを権限のないユーザーから見えないようにします。
  • デバイスとユーザーのリスクへの対応:きめ細かなZTNAポリシーは、限られたリスクに基づいてユーザーデバイスに適切な権限を調整し付与することができます。
  • サーバーやユーザーデバイスとの間のトラフィックを制御します。多くのZTNAソリューションは、「アップルール」(例えば、ユーザーのモバイルデバイスがデータベースにアクセスする必要がある場合など)として知られる、リソースのやり取りに対するユーザー/デバイスのポリシーを必要とするユースケースでうまく機能します。しかし、「ダウンルール」、つまりサーバー、サービス、リソースから「下方向」のユーザーデバイスとのやりとりを扱うこともサポートされるべきです(例:リモートデスクトップのサポートやエンドポイントプロテクションの集中管理プラットフォーム)。この両方をサポートするZTNAプラットフォームを見てください。
  •  幅広いITおよびセキュリティエコシステムの統合をサポートします。ZTNAは、脅威インテリジェンスツール、SIEM(Security Incident and Event Management)ソリューション、EDR(Endpoint Detection and Response)プラットフォーム、ITSMソリューションなどと統合する必要があります。
  • エンタープライズスケールとスピードでの運用。多くの組織は単一のユースケースからスタートしますが、最終的には、ZTNAソリューションは、組織全体のアクセスコントロールの全負荷に対応できなければならず、また、ネットワークやクラウドエコシステム全体のすべてのアプリケーションを含む、拡大するフットプリント内の負荷レベルの増加にも対応できなければなりません。

この数週間は、情報セキュリティに携わる多くの人々にとって困難な時期でした。あなたが実務者であれば、その献身的な努力に感謝します。もしあなたが組織のビジネスサイドにいるのであれば、企業を守るために夜も週末も働いているセキュリティチームやネットワークチームに、どうか辛抱強く対応していただきたいと思います。

Log4Shellは、これまでに見たことのない最悪の脆弱性であり、セキュリティに対するゼロトラストアプローチの必要性とその価値を明確に示しています。この事件をきっかけにして、ゼロトラストへの移行を始めたり、加速させたりしてください。無駄にする時間はありません。ゼロトラストの原則とアプローチは、明らかに優れたセキュリティを提供することが証明されており、あなたには組織をより良い場所へと導く責任があります。今こそ、始める時です。

クラウドにおける遠隔医療のデータリスク管理

クラウドにおける遠隔医療のデータリスク管理

英語では、「遠隔医療」を意味する単語に、「Telemedicine」と「Telehealth」がある。前者は、ICTを活用した臨床診断やモニタリングなど、狭義の遠隔医療を指しているのに対して、後者は、臨床医療に限らず、健康増進や介護福祉など、幅広いサービスを包含するような広く定義を有しており、遠隔で医療提供者を患者につなげるために、キオスクや、webサイトモニタリングアプリケーション、モバイルフォン、ウェアラブル機器、ビデオ会議などの革新的な技術を利用する。

ここでは、「遠隔医療」について、情報通信技術を活用した健康増進、医療、介護に資する行為と定義する。遠隔医療を大別すると、専門医師が他の医師の診療を支援するDoctor-to-Doctor(D2D)分野と、医師が遠隔地の患者を診療するDoctor to Patient (D2P)分野が含まれる。

在宅医療の普及に伴い、D2P分野の研究開発が急展開してきたが、新型コロナウイルス感染症(COVID-19)緊急対応下における外来診療の代替手段として一気にニーズが高まり、米国政府の「コロナウイルス支援・救済・経済保障(CARES)法」に基づく遠隔医療推進目的の経済インセンティブ施策が追い風となっている。

サイバーセキュリティの領域では、米国立標準技術研究所(NIST)傘下の国立サイバーセキュリティセンターオブエクセレンス(NCCoE)が、遠隔患者モニタリング(RPM)など、遠隔医療機能を活用する医療提供組織(HDO:Healthcare Delivery Organization)が直面するセキュリティ/プライバシーリスクの研究に取り組んでいる。具体的な活動としては、2021年5月6日に「NIST SP 1800-30 遠隔医療の遠隔患者モニタリングエコシステムのセキュア化」草案第2版 (https://csrc.nist.gov/publications/detail/sp/1800-30/draft) などを公開している。 続きを読む

医療におけるブロックチェーン利用

2021年3月4日、米国のモデルナとIBMは、ブロックチェーン技術を利用して、新型コロナウイルス感染症(COVID-19)ワクチンのサプライチェーンおよび輸送データの共有における連携する計画を発表した。このような医療分野のブロックチェーン利活用に向けた動きは、医療機関や保健医療行政機関、医療保険者の間でも本格化している。

医療機関から見たブロックチェーン技術の機能と特徴

医療ブロックチェーンに関連して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2021年7月、ブロックチェーン技術を利用する医療機関を対象として、「医療におけるブロックチェーン利用」(https://cloudsecurityalliance.org/artifacts/the-use-of-blockchain-in-healthcare/)を公開している。同文書は、以下のような構成となっている。

・イントロダクション
・ブロックチェーン
・全般
・研究
・サプライチェーン
・財務管理
・施設・エネルギー管理
・遠隔医療
・患者管理
・医療のケースにおけるブロックチェーン
・ディスカッション
・結論 続きを読む

日本語での評価レポートの公開方法およびLevel1セルフアセスメントの重要性について

本ブログでは、STAR Level1セルフアセスメントの重要性および日本語での評価レポートの公開方法について記述します。

2021年10月20日
CCM/STAR WGメンバー 諸角昌宏

クラウドサービスプロバイダが、提供するクラウドサービスのセキュリティ情報を公開することは非常に重要です。クラウドセキュリティにおける責任共有モデルにおいては、クラウドサービス利用者は、自身が管理するセキュリティとプロバイダが管理するセキュリティの両方を把握し説明責任を果たすことが必要で、そのためには、利用するクラウドサービスのセキュリティレベルを把握する必要があります。これは、利用者がプロバイダに直接確認することで行えますが、たくさんの利用者を抱えているプロバイダが、利用者ごとの問い合わせに対応することは非効率です。そこで、プロバイダが、提供しているクラウドサービスのセキュリティ情報をあらかじめ公開することで、利用者は公開された情報に基づいてクラウドサービスのセキュリティレベルを把握することができます。また、プロバイダは、利用者からの個別の問い合わせに対応する作業を削減することができますし、セキュリティ情報を積極的に公開することにより、セキュリティをビジネス上の差別化要因とすることができます。

STAR Level1セルフアセスメントは、CSAが提供しているCAIQ(Consensus Assessment Initiative Questionnaire)に、プロバイダが自己評価した結果を記述し、それを公開するウエブサイト(CSA STAR Registry: https://cloudsecurityalliance.org/star/registry/)を提供しています。このCSA STAR Registryには、STAR認証が提供する3つのレベルの情報が公開されていますが、CAIQの評価レポートは、STAR Level1 セルフアセスメントとして公開されています。STAR Level1 セルフアセスメントのようなセキュリティの透明性に対する取り組みは、特に欧米のプロバイダは積極的に行っています。CSA STAR Registryには、1000以上のクラウドサービスが登録されていますが、その大部分がSTAR Level1セルフアセスメントとしてCAIQ評価レポートを公開しています。

CSAジャパンでは、日本のプロバイダが積極的にセキュリティ情報を公開できるように支援していきます。以下の2つのアプローチになります。

  1. 日本語CAIQ評価レポートの登録手順を日本語で提供
    STAR Level1 セルフアセスメントの登録手続きは、英語で行う必要があります。会社名やクラウドサービス名、およびそれらの概要等は、英語で記述する必要があります。CSAジャパンでは、日本語CAIQ評価レポートの作成から、STAR Level1 セルフアセスメントの登録までの一連の手順を日本語で記述しました。以下のウエブサイトを参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005
  2. 日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開
    CSA STAR Registryには、すべてのクラウドサービスの情報がアルファベット順にリストされています。この中から、日本語CAIQ評価レポートを公開しているプロバイダ及びクラウドサービスを探すことは難しいです。そこで、CSAジャパンでは、CSAジャパンのウエブサイトから、日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開することとしました。以下のウエブサイトになります。
    https://www.cloudsecurityalliance.jp/site/?page_id=19811
    なお、日本語 CAIQ評価レポートを公開されているプロバイダ及びクラウドサービスをすべて把握することが難しく、このサイトの情報はCSAジャパンが把握できているもののみになります。日本語 CAIQ評価レポートを公開されていて、このサイトにリストされていないものがありましたら、以下のメールアドレスまでご連絡ください(注意: @の前後のクオーテーションを削除してください)。 info’@’cloudsecurityalliance.jp

以上

CSAの認証制度:STAR認証について

STAR認証について

2021年10月7日
CCM/STAR WGメンバー: 諸角昌宏

本ブログでは、CSA(Cloud Security Alliance)が提供するSTAR(Security, Trust & Assurance Registry)認証について、その概要、特徴、利用方法、CSAジャパンの活動について説明します。特に、STARレベル1(セルフアセスメント)について、プロバイダがクラウドサービスの自己評価レポートをCSA本部のウエブサイトより公開する方法について記述します。

  1. STAR概要

    STARは、CSAが提供するクラウドセキュリティの認証制度です。大きなフレームワークは以下の図1で示すように、3つのレベルを持っています。また、それぞれのレベルに対して、「セキュリティ認証」と「プライバシー認証」の2つのカテゴリーがあります。

    図1 STARフレームワーク

まず、「STAR認証レベル」について説明します。

  • STAR Level1

    STAR Level1はセルフアセスメントです。これは、クラウドサービスプロバイダが、CSAが提供しているCAIQ(Consensus Assessment Initiative Questionaire)に基づいて、自身が提供するクラウドサービスのセキュリティを独自に評価し、CSAのウエブサイト(https://cloudsecurityalliance.org/star/registry/)から公開するものです。CAIQは、CSAが提供するクラウドセキュリティの管理策集であるCCM(Cloud Control Matrix)のそれぞれの管理策について、いくつかの質問形式にブレークダウンしたものです。質問形式になっているため、クラウドサービスプロバイダは「YES」「NO」で回答することができます。また、回答に対するコメントを入力し、追加の情報を記述することができます。
    STAR Level1の特徴は、クラウドサービス利用者が、利用しようとしているクラウドサービスが自組織のセキュリティ要求事項を満たしているかどうかを、公開されている情報をもとに確認できることです。つまり、プロバイダの透明性が実現できているということになります。また、プロバイダの立場では、セキュリティ情報を積極的に公開することで、たくさんの利用者に対して統一したメッセージを出すことができますし、この情報をビジネス上の差別化要因として利用することもできます。
    STAR Level1の登録方法について、以下のウエブサイトに日本語で記述していますので参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005

 

  • STAR Level2

    STAR Level2は、第三者評価になります。クラウドセキュリティの評価としてCCMを使用しますが、以下の示す他の業界認定や標準を基にして、クラウドセキュリティを評価しています。

    • CSA STAR CERTIFICATION: ISO/IEC 27001
    • CSA STAR ATTESTATION: SOC2
    • CSA C-STAR: GB/T22080-2008

STAR Level2の特徴は、認証だけでなく成熟度も評価していることです。クラウドサービスの成熟度を「ブロンズ」「シルバー」「ゴールド」のレベルとして認定します。
以下の図はSTAR CERTIFICATIONを表しています。

図2 CSA STAR CERTIFICATION 成熟度モデル

  • STAR Level3

    STAR Level3は、継続的モニタリングです。認証取得後も、その対応状況を継続的にモニタリングし保証する制度で、FedRAMPなどのハイレベルの情報を扱う際に要求されているものです。こちらは、まだ準備中になりますので、提供され次第ご案内できると思います。

それから、Level1、Level2には、Continuous Self-assessmentがあります。これは、通常の1年に1回の認証に対して、より頻度を上げた認証を行うようにしたものです。

次に「セキュリティ認証」と「プライバシー認証」について説明します。

  • セキュリティ認証

    セキュリティ認証は、上記で記述したように、CCMあるいはCAIQを用いて認証を行うものです。

  • プライバシー認証

    プライバシー認証は、クラウド環境におけるデータ保護法令遵守に必要な要件を定義した管理策であるCode of Conduct for GDPRを使用して認証を行うものです。GDPR向けの行動規範に準拠しているかどうかを認証します。

 

  1. STAR認証の特徴

    STAR認証では、今までの認証制度の課題として以下の3点を挙げ、それぞれに対して取り組んでいます。

    • 認証の継続性

      認証は「ある時点 (point-in-time)」あるいは「ある期間 (period-of-time)」を対象とするアプローチです。これは、変化の激しいクラウド環境においては不十分であることが指摘されています。STAR Level1/Level2 Continuous Self-assessmentでは、頻度を上げた形での認証を行うことで、より現実に近い認証を行っています。これにより、クラウドサービス利用者に対して、セキュリティ管理策の実施状況に関する詳細な最新情報を提供できるようになります。また、STAR Level3が提供されるようになると、よりリアルタイムに近い認証が実現できることになります。

    • 認証の透明性

      第三者認証(STAR認証ではLevel2)では、クラウドサービスの可視化を高いレベルで確保することが難しいです。STAR認証の各レベルは、それぞれ独立して運用するのではなく、組み合わせることでより高いレベルの認証を実現できます。たとえば、Level1とLevel2を組み合わせることで、高い保証(第三者認証)と高い透明性(セルフアセスメント)の両方を実現できます。以下の図は、STAR認証の各レベルの関係を表現したものです。

      図3 保証と透明性

    • 相互認証スキーム

      STAR認証のベースになるCCMは、数多くの国単位/分野単位の基準/規格へのマッピングを提供しています。CCMでは、各規格とのマッピングとリバースマッピングを提供し、それぞれの規格との差異(ギャップ)を分析し、その情報を公開しています。理想としては、1つの認証を取得することで、その他の認証に関してはギャップ分だけやればよいことになり、1つの認証の取得から別の認証の取得までの労力を最小化することができます。あくまで最小化のレベルであり、これで相互認証できるというわけではないことは注意が必要ですが、様々な組織(EU-SECやFedRAMPなど)とのフレームワークの検討が進んでいますので、その進捗に期待したいと思います。

  2. STAR認証に対するCSAジャパンの取り組み

    CSAジャパンでは、以下の取り組みを行っています。

    • STAR認証に関する情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=429

    • CCM/CAIQの日本語化および情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=2048#ccm

    • STAR Level1(セルフアセスメント)の日本語での公開

      CAIQの評価レポートを日本語で作成し、それを公開する手順について以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=1005

    • 日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの公開

      CSAジャパンでは、STAR Level1 セルフアセスメントの登録において、日本語CAIQ評価レポートを登録されたプロバイダおよびそのクラウドサービスに関する情報を公開しています。CSA本部のSTAR Registryでは、CAIQ評価レポートとして日本語で提供されているかどうかを判断するのが難しいです。そこで、CSAジャパンでは、日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの情報を公開することで、日本の利用者が利用できるようにしています。
      公開ウエブサイトは以下になりますので参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=19811

以上

 

MS、アマゾン、グーグルらがクラウドデータの保護など目指す「Trusted Cloud Principles」について

Microsoft、Amazon、Googleらが、「Trusted Cloud Principles」という新たな業界イニシアチブを発表しました。これから関わってくる可能性が高いと思われるので、その内容について翻訳してみました。なお、ここの翻訳は、あくまで個人的に行ったものであり、正式な形で翻訳の承認を取ったものではないことに注意してください。ここの訳はおかしいよというところがありましたらご指摘ください。
原文は、こちらです。

Trusted Cloud Principles(信頼できるクラウドの原則)

原則

世界中の組織は、イノベーションを推進し、セキュリティを向上させ、新しいデジタル経済で競争力を維持するためにクラウドテクノロジーを採用しています。クラウドサービスプロバイダとして、国境を越えて利用されるサービスとインフラストラクチャを運用することにより、あらゆる規模の企業、公共部門のエンティティ、非営利団体を含むこれらの組織をサポートします。

Trusted Cloud Initiativeは、イノベーション、セキュリティ、プライバシを妨げる国際的な抵触法を解決し、クラウドにデータを保存および処理する組織の基本的な保護を確立および確保するために、世界中の政府と組んでいくことを目指しています。このイニシアチブを通じて、私たちは政府と協力してデータの自由な流れを確保し、公共の安全を促進し、クラウド内のプライバシとデータセキュリティを保護することを約束します。

このイニシアチブは、社内の人権影響評価を実施するなど、この分野で各企業が行った既存の取り組みに基づいています。これは、企業が取り組むベースラインとして機能します。

クラウドプロバイダとして、以下を主張します;

  • グローバルクラウドサービスを使用する個人および組織の安全性、セキュリティ、プライバシ、および経済的活力を保護することへの世界中の政府の関心を認識します。
  • 国際人権法がプライバシの権利を大事にしていることを認識します。
  • 利用者の信頼と、利用者のデータの管理とセキュリティの重要性を認識します。これには、利用者がクラウドで所有するデータの保護と、その信頼を確立、維持、強化する製品とポリシーの作成の両方が含まれます。
  • 国際的に認められた法の支配と人権基準を遵守する透明なプロセスを通じて、政府がデータを要求できるようにする法律をサポートします。
  • データアクセス、プライバシ、および主権に関連する抵触法を解決するための国際的な法的枠組みをサポートします。
  • データアクセス、プライバシ、および主権に関連する抵触法を解決するための国際的な法的枠組みをサポートします。
  • クラウド利用者の安全性、プライバシ、セキュリティ、およびデータの所有権を保護する、国内および国際レベルでの改善された規則と規制をサポートします。
  • 政府のデータ要求に関する集計統計を詳述する透明性レポートを定期的に公開することの重要性を認識します。

私たちの目的を達成するために、私たちは世界中の技術部門、公益団体、および政策立案者と協力し、特にデータセンタとクラウドインフラストラクチャを運用または運用する予定の国で、法律とポリシーが実質的に次の原則に沿っていることを確実にします。

政府は、狭い例外を除いて、最初に利用者を関与させる必要があります。政府は、例外的な状況を除いて、クラウドサービスプロバイダではなく、企業の利用者から直接データを手に入れようとする必要があります。

利用者は通知を受ける権利を持っている必要があります。政府がクラウドサービスプロバイダから直接利用者データにアクセスしようとする場合、そのクラウドサービスプロバイダの利用者は、データへの政府アクセスの通知を事前に通知を受ける権利を有する必要があります。その通知は、例外的な状況においてのみ遅らせることができます。

クラウドプロバイダーは、利用者の利益を保護する権利を持っている必要があります。関連するデータ保護当局への通知を含め、クラウドサービスプロバイダーが利用者のデータに対する政府のアクセス要求に異議を申し立てる明確なプロセスが必要です。

政府は法の抵触に対処する必要があります。政府は、ある国でのクラウドサービスプロバイダーの法令遵守が別の国での法律違反にならないように、相互の対立を提起し解決するメカニズムを作成する必要があります。

政府は国境を越えたデータの流れをサポートする必要があります。政府は、イノベーション、効率、セキュリティのエンジンとして国境を越えたデータの流れをサポートし、データの常駐要件を回避する必要があります。

クラウドにおける医療ビッグデータのプライバシー保護/セキュリティ管理(後編)

(前編)はこちら

医療ビッグデータライフサイクルとGDPRに準拠したプライバシー保護

次に本文書では、以下の6つのステージから成るクラウド環境のデータライフサイクルを提示している。

  1. 生成(Create):データが生成、獲得、修正される
  2. 保存(Store):データがストレージレポジトリに委ねられる
  3. 利用(Use):データが他の種類の活動で処理、閲覧、利用される
  4. 共有(Share):データや情報が他にアクセス可能なようにする
  5. 保管(Archive):データが長期ストレージに置かれる
  6. 破壊(Destroy):データが必要でなくなった時、物理的に破壊される

その上で、プライバシーの定義について、情報の適正なアクセス、利用、変更に関する意思決定に関係したものであり、誰が適正に情報にアクセスし変更すべきかを決定するフレームワークを確立するものとしている。

患者のプライバシーに対する侵害は、情報システムに対する持続的標的型(APT)攻撃や標的型攻撃の出現とともに、医療ビッグデータ分析における重大な課題と認識されている。医療ビッグデータの価値は、個人情報の収集に関連していることが多く、その結果が個人によく理解されていない可能性がある。従って、ビッグデータのベネフィトを享受すると同時に、各個人のプライバシーを保護することが必須の課題となる。また、プライバシー保護に際しては、個人の選択権を認めると同時に、効果的なリスク低減策を提供する必要がある。

特に、欧州連合(EU)の一般データ保護規則(GDPR)は、EUのデータ主体の個人データが保護されていることを保証し、個人データに対するEUのデータ主体の権利が拡大することを目的としている。EUのデータ主体のデータを収集、処理、保存する企業は、企業のロケーションに関わらず、GDPRを遵守しなければならない。ライフサイクル全体を通したデータ管理は、GDPR遵守に必要なだけでなく、米国の「医療保険の相互運用性と説明責任に関する法律(HIPAA)」で規定された保護対象保健情報(PHI)の要求事項をクリアするためにも有効だとしている。

また、企業に対しては、ユーザーの情報を利用目的・方法などについて説明したプライバシーポリシーを設定することが求められる。本文書では、以下のような点に留意するよう推奨している。

  • 企業およびその代表者の連絡先詳細が含まれる
  • 企業がデータを収集する理由を記述する
  • どれだけの期間、情報がファイルに保持されるかを述べる
  • ユーザーが有する権利を説明する
  • 簡単な言語で文書化する
  • 個人データの受取人の名前を明記する(企業が他組織とデータを共有する場合)

NISTプライバシーフレームワークを活用したデータリスク管理

本文書では、前述のデータライフサイクルのうち「共有」に関連して、異なる組織との間でデータが共有される方法を記述した「データ処理エコシステム」を取り上げている。このエコシステムは、複雑で多方向的な関係性を持った主体や役割から構成されており、責任共有モデルのベースとなる医療機関・クラウドサービスプロバイダー間の正式な同意書/契約書の締結が不可欠だとしている。

その上で、米国立標準技術研究所(NIST)プライバシーフレームワーク1.0版を利用したリスク管理手法を紹介している。同フレームワークでは、共通のプライバシーリスク対策の「コア」、組織が行うプライバシーリスク対策の「As Is(Current)」と「To Be(Target)」をまとめた「プロファイル」、プライバシーリスクへの対策状況を数値化し、組織を評価する基準である「インプレメンテーション・ティア」が基本概念の柱となっている。

コア機能には、「特定(Identify-P)」、「統治(Govern-P)」、「制御(Control-P)」、「通知(Communicate-P)」、「防御(Protect-P)」があるが、ここでは、特定(Identify-P)機能のうち、「ID.DE-P:データ処理エコシステム・リスクマネジメント」に従って、エコシステム内のプライバシーリスクを特定、評価、管理するプロセスを導入している。

データ処理エコシステム・リスクマネジメントとは、組織の優先順位付け、制約、リスクの許容範囲、仮定で、データ処理エコシステム内におけるプライバシーリスクおよびサードパーティの管理に関連するリスク意思決定を支援するために設定・利用されるものであり、以下のようなサブカテゴリーから構成される。

  • ID.DE-P1: データ処理エコシステム・リスクマネジメントのポリシーやプロセス、手順が、組織のステークホルダーによって特定、確立、評価、管理、同意される
  • ID.DE-P2: プライバシー評価プロセスを利用して、データ処理エコシステムの主体(例.サービスプロバイダー、顧客、パートナー、製品メーカー、アプリケーション開発者)が特定、優先順位付け、評価される
  • ID.DE-P3: 組織のプライバシープログラムの目的を満たすように設計された適切な遺作を展開するために、データ処理エコシステム主体との契約が利用される
  • ID.DE-P4: データ処理エコシステムのプライバシーリスクを管理するために、相互運用性フレームワークまたは同様のマルチパーティ手法が利用される
  • ID.DE-P5: 契約、相互運用性フレームワークまたはその他の責務を満たしていることを確認するために、監査、テスト結果またはその他の評価形態を利用して、データ処理エコシステム主体が日常的に評価される

プライバシーには、誰が情報にアクセスし、利用し、変更できるかに関する意思決定が含まれており、それに従って、セキュリティの選択肢や条件が展開される。セキュリティは、情報とプライバシーの間のインタフェースとなり、プライバシー権を推進して実行に移す役割を果たす。

医療機関は、大容量のデータを保存、処理、共有しており、医療産業を支援するためにビッグデータ分析で利用されている。データは重要な資産であり、データのセキュリティを維持し、医療の責務を遵守するために、医療機関は、セキュリティソリューションを展開する必要がある。米国では、HIPAAに加えて、連邦取引委員会(FTC)が所管する個人識別情報(PII)に対するセキュリティ要件も満たす必要がある。

サーバーレス環境の医療ビッグデータ基盤のリスク管理

2018年7月24日、米国立衛生研究所(NIH)は、商用クラウドサービスプロバイダーと提携して、生体医学の進歩を加速させるために、大規模生体医学データセットにアクセスして計算処理を行う際の経済的・技術的障害を取り除くことを目的とする「発見・実験・持続可能性のための科学技術研究インフラストラクチャ(STRIDES)イニシアティブ」を発表し、第一弾としてGoogle Cloudとの戦略的提携をスタートさせた(NIHプレスリリース参照(https://www.nih.gov/news-events/news-releases/nih-makes-strides-accelerate-discoveries-cloud))。その後NIHは、同年10月23日、Amazon Web Service (AWS)との戦略的提携を発表し(NIHプレスリリース参照(https://www.nih.gov/news-events/news-releases/amazon-web-services-joins-nihs-strides-initiative-harness-latest-cloud-technologies-biomedical-researchers))、さらに2021年7月20日には、Microsoft Azureとの戦略的提携を発表している(NIHプレスリリース参照(https://www.nih.gov/news-events/news-releases/nih-expands-biomedical-research-cloud-microsoft-azure))。

これらの医療ビッグデータベースには、サーバーレスなど最新鋭のクラウドネイティブ技術が実装されており、実際にビッグデータ分析を利用する医療エコシステムにも、位相高度なプライバシー/セキュリティリスク管理策が要求されつつある。

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

クラウドにおける医療ビッグデータのプライバシー保護/セキュリティ管理(前編)

医療ビッグデータセキュリティに関連して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2020年7月に「クラウドにおける医療ビッグデータ」(https://cloudsecurityalliance.org/artifacts/healthcare-big-data-in-the-cloud/)を公開している。この文書では、新型コロナウイルス感染症(COVID-19)対応下の医療分野におけるビッグデータのユースケースを紹介した上で、クラウド環境におけるプライバシー保護/セキュリティ管理策を整理している。

ビッグデータの特徴と分析機能

本文書では、まずビッグデータについて、従来の手法を利用して処理することが難しい大規模なデータ容量と定義し、以下の通り、6つのビッグデータの特徴(6Vs)を挙げている。

容量(Volume):生成されたデータのサイズは通常膨大で、1ペタバイト以上の容量になる。医療においては、電子健康記録(EHR)だけで大容量のデータとなる。加えて、このデータは、新たなテストデータとして導入される度に変更することができ、国際疾病分類(ICD)コードのようなものが更新される。

  • 速度(Velocity):データユーザーが、データにアクセスし、分析することができる速度。医療においては、医療提供者がタイムリーな方法で、データを交換・利用できるようにするために、速度が必要である。
  • 多様性(Variety):構造化、半構造化、非構造化など、データの種類。医療は、マルチメディア、ソーシャルメディア、金融取引など、多様なデータソースを有している。
  • 正確性(Veracity):生成されたデータの品質。生死に関する意思決定は正確な情報に依存するため、医療データは、適切で、信頼性があり、エラーのないものでなければならない。
  • 価値(Value):既存データの分析から得られる価値であり、ビッグデータの最も重要な側面である。現段階では、医療データの価値は、大半が研究に限定されている。
  • 可変性(Variability):時を超えたデータの一貫性に関することとみなされる。

そして、医療ビッグデータの基本的な分析機能として以下の4つを挙げている。

  1. 記述的分析:医療に関する意思決定を理解し、新たな情報に基づく意思決定を行うために、データを検証する。そのモデルは、有益な情報を抽出するために、データをカテゴリー化、特定、結合、分類するのに利用することができる。
  2. 予測的分析:将来を予測するために推定可能な関係性のパターンを特定する目的で。古いまたは要約された医療データを検証する。医療データに隠れたパターンを特定して、医療リスクを予期し、患者に関するアウトカムを予測し、健康関連サービスを向上させるために、データマイニングを利用することができる。
  3. 処方的分析:多くの代替手段を含む課題を解決し、記述的/予測的分析を実行不可能にするために、情報や健康医療知識を利用する。
  4. 発見的分析:データから未知の事実を特定し、将来を向上させるために、知識に関する知識を利用する。新しい病気や病状、医薬品、治療法を発見するのに役立てることができる。

台湾に学ぶ医療ビッグデータにおける予測的分析の有効活用

医療ビッグデータの代表的なユースケースとして、電子健康記録(EHR)がある。電子健康記録には、病歴や検査画像結果、人口統計などの情報が含まれており、各患者の変更状態および医療記録を継続的に追跡して、検査の重複および関連する費用を削減する役割を果たす。

また、医療機関の電子健康記録は、クラウド上にある地域医療情報連携ネットワークに接続され、すべての医療機関が患者情報にアクセスできるようになっている。消費者中心の環境への医療の移行とともに、電子健康記録のデータを、継続的に患者データをクラウドに送信するウェアラブル機器と連携させて、院内の処置を削減し、費用のかかる入院を回避することも可能となっている。さらに、一般住民の健康状態を評価し、パターンを特定するために、ビッグデータを利用することも可能である。

このように、医療機関のIT化や地域医療情報連携ネットワークの整備が進んだところでは、医療ビッグデータ利活用のユースケースが生まれている。たとえば、台湾の新型コロナウイルス感染症(COVID-19)パンデミック対応時には、公衆衛生当局が、旅行歴や臨床症状に基づいたビッグデータ分析を利用し、迅速な対応に当たっている。加えて、フライト情報や旅行歴に基づいて感染症リスクを分類し、リスクの低い患者に対しては入国審査を許可する一方、リスクの高い患者に対しては、自宅で隔離し、潜伏期間中はモバイルフォン経由で追跡する措置をとるなど、データに基づく意思決定を行っている。

台湾のケースは、予測的分析をうまく活用しながら、早期認識や日々のブリーフィング、健康メッセージにより、迅速・正確で透明性のある疫学情報を提供することによって、社会が迅速な危機への対応を実現し、パンデミック期の市民の利益保護を確実なものにする方法を示している。

(後編は後日公開)

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

クラウド接続した医療機器のサイバーセキュリティ対策

医療機器サイバーセキュリティに関連して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2020年3月に「クラウドに接続した医療機器のためのリスク管理」(https://cloudsecurityalliance.org/artifacts/managing-the-risk-for-medical-devices-connected-to-the-cloud/)を公開している。この文書は、患者への近接性(Proximity)に基づいて、クラウドに接続した医療機器のリスク管理という考え方を提示し、医療機器向けのクラウドコンピューティング利用におけるセキュリティ強化のためのプラクティスを紹介することを目的としている。

医療機器と患者の近接性で異なるセキュリティ責任共有モデル

HIM-WGは、機器と患者の近接性を表す隔たりの程度について、機器が患者と相互作用する方法に基づいており、機器が埋め込まれているか、完全に分離しているかによって、以下の0~5の段階を設定している。

・段階0=機器が患者に埋め込まれている
(機器サポート責任:ベンダーおよび/または医師・医療スタッフ)

・段階1=機器が患者に接触する
(機器サポート責任:ベンダーまたは臨床工学)

・段階2=機器は患者に接触しないが、患者の生命兆候または体液、データを測定する
(機器サポート責任:ベンダーまたは臨床工学)

・段階3=機器は患者に接触しないが、適切な患者診断に重要なことを行う可能性がある
(機器サポート責任:ベンダーまたは臨床工学)

・段階4=機器は患者から離され、診断/臨床機器よりも運用ツールである
(機器サポート責任:ベンダーまたはIT)

このように、患者との近接性によって、医療機関側の機器サポート責任が異なる点が、医療機器サイバーセキュリティの特徴である。

早期段階からの文書化がセキュリティリスク管理の要

次に、本文書では、医療機器セキュリティライフサイクルの観点から、「調達前」、「調達後/展開前」、「展開/運用管理」、「使用停止/廃棄」の各ステージを挙げている。

このうち「調達前」ステージでは、以下の通り、医療機器サイバーセキュリティに関する文書化について、米国食品医薬品局(FDA)の医療提供組織向け推奨事項を挙げている。

1.機器に関連するサイバーセキュリティリスクについてのハザード分析、低減、設計上の考慮事項

2.考慮されたリスクに対するサイバーセキュリティコントロールに紐付いたトレーサビリティのマトリックス

3.機器ライフサイクルを通して、検証済の更新やパッチを提供するための計画

4.ソフトウェアの完全性を保証するのに適切なセキュリティコントロールの概要

5.サイバーセキュリティコントロールに関する仕様を含む指示

個々の文書は、医療提供組織が機器調達に関するリスクベースの意思決定を行うために必要な情報を提供するが、実際の機器調達に際しては、これらのセキュリティ要求事項を契約書に盛り込む必要がある。

次に、「調達後/展開前」ステージでは、医療提供組織のネットワークやクラウドに接続する前に要求される機器テストの手法として、以下のようなアプローチを推奨している。

1.構成のレビューや、調達前評価の間に収集した構成情報の検証:文書には、すべての相互接続とデータフローダイアグラムに関する一覧表が含まれる。

2.利用するすべての公開ポートおよびプロトコルを特定するための「Nmap」のスキャン:「Nmap」は、オープンソースのネットワーク探索・監査ツールである。

3.「Nessus」や「Qualys」のような製品を利用した脆弱性スキャン:

4.構成スキャン:

5.ペネトレーションテスト:発見した脆弱性を有効活用するために、セキュリティエンジニアは、侵害された機器からのインストール、マルウェア、検索、ダウンロードなどのデータや、機能無効化の試みについて調査すべきである。

アイデンティティ/アクセス管理と信頼性保証は共通の難題

さらに、「展開/運用管理」では、患者との近接性を表す0~5の段階に応じて、様々な医療機器を管理する手法を概説している。

「段階0」の埋め込み医療機器をインターネット/クラウドに接続する場合、埋め込み機器に加えて、インターネット/クラウドに接続するベースステーションおよびそれに接続する中間機器など、複数の機器が使用されるため、個々の機器ごとに、アップグレードやパッチ当てを実行する必要がある。

ただし、医療提供組織が、これらの全テストを完了し、すべての脆弱性を低減したとしても、以下のような課題が残る。

1.個々の機器は、どのようにして、アイデンティティ/アクセス管理を遂行するか?
2.医療提供組織は、どのようにして、発見された追加的な脆弱性が是正されたかを保証するか?

これらアイデンティティ/アクセス管理や信頼性保証は、他の1~5の段階に該当する機器にも共通する課題であるが、解決は容易でない。

最後に、本文書では、以下のような推奨事項を挙げている。

・リスク評価やセキュリティレビューを実施したら、認証に関する機器の機能を強化する
・証明書が機器の真正性を裏付ける場面では、PKI(公開鍵インフラストラクチャ)を利用する
・医療機器における信頼レベルを保証するデジタル証明書と、インフラストラクチャをモニタリングするアプリケーションを組み合わせて、資格のない機器へのアクセスを特定し、防止する
・ユーザーのスマートデバイス経由でインターネット/クラウドに接続する医療機器には、多要素認証(MFA)を導入する
・認証機能のない医療機器の場合、認証ゲートウェイを使用する
・継続的モニタリングにより、医療提供組織およびクラウドプロバイダーの双方が望ましいセキュリティ動態を維持していることを保証する
・医療提供組織は、CASBを活用して、どの機器がクラウドに接続しているか、どのデータがクラウドに送信されているか、データが送信されているのはどのクラウドプロバイダーかを把握する
・医療情報保護など、すべての規制上の要求事項を充足していることを保証する
・クラウドセキュリティアライアンスの「クラウドコンピューティングの重大脅威」を参照する

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