医療における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):

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

続きを読む

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

医療機関を標的にしたランサムウェア攻撃対策に関連して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2021年9月に「医療クラウドにおけるランサムウェア」(https://cloudsecurityalliance.org/artifacts/ransomware-in-the-healthcare-industry/)を公開している。この文書は、医療クラウド上で拡大するランサムウェア脅威に対して、医療機関が、NISTサイバーセキュリティフレームワークに準拠しながら取組むべきリスク低減策を紹介することを目的としている。

米国MITREが医療ランサムウェア対策支援ポータルを開設

医療機関を標的にしたランサムウェア被害が続出する米国では、2021年3月2日、連邦政府の支援を受けた非営利団体MITREが、ランサムウェア対策支援センター「Health Cyber」(https://healthcyber.mitre.org/)を公開Web上に開設したことを発表している。

Health Cyberは、医療機関の経営管理部門、臨床技術部門、IT/セキュリティ実務家の3つのカテゴリーに合わせたコンテンツ作成・発信を行っている点が特徴である。たとえば、経営管理部門向けには、以下のようなメニュー構成の情報発信を行っている。

  • ランサムウェアに関する学習
  • 感染回避のためのスタッフ向けトレーニング
  • サイバー対応計画の評価
  • サイバーセキュリティ業務の評価
  • 敵対者の理解

続きを読む

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

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

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

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

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

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

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

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

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

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

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

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