タグ別アーカイブ: CSAジャパン

2024: クラウドセキュリティ・ティーンエイジャーにとって重要な年

2024: クラウドセキュリティ・ティーンエイジャーにとって重要な年(2024: A Critical Year for the Cloud Security Teenager)

本ブログは、2024年のスタートに当たって、CSA本部のCEO Jim Reavis のメッセージとして以下のブログに掲載された内容の日本語訳になります。本ブログは、Jim Reavis の許可のもとに公開していますが、本ブログの内容とCSA本部のブログとに相違があった場合には、CSA本部のブログの内容が優先されます。

https://cloudsecurityalliance.org/blog/2023/12/29/2024-a-critical-year-for-the-cloud-security-teenager/

Blog Article Published: 12/29/2023
Written by Jim Reavis, Co-founder and Chief Executive Officer, CSA.

2024年、クラウドセキュリティアライアンスは15周年を迎えます。この間、私たちは世の中の様々な変化、技術シーンの移り変わり、そしていくつかのクラウドセキュリティベンチャーの誕生と消滅を見てきました。これほどダイナミックな世界では、企業もかつてのような長寿ではありません。テクノロジーの移り変わりを通してベストプラクティスのリーダーシップに焦点を当てた非営利組織として、私たちはまさに10代の若者のように感じています。私は、「次はどうなるのですか」と尋ねるスタッフやその他の人々に、CSAは100年間ミッションを継続する構造になっていると話すのが好きです。

クラウドの歴史(A Quick History of the Cloud)

2024年は非常に興味深い年になるでしょう。私はこのブログを使って、今年私たちが取り組んでいくこと、私たちが対応し対処しようとしている主なトレンドを書いていきたいと思います。私にとって、これを説明する良い方法は、クラウドの歴史を世代別に簡単に説明することです。

クラウド0、あるいはプリクラウドとは、コンピューティングの歴史の中で、クラウドにつながるいくつかの発展を意識したものです。メインフレームコンピュータとその仮想マシンおよびタイムシェア機能が良い例です。1980年代のIntel 80836プロセッサは、PCに仮想マシン機能をもたらしました。より最近の歴史では、アプリケーションサービスプロバイダ(ASP)が、他人のコンピューターで仕事ができる素晴らしい例であり、SaaSの先駆けでした。

クラウド1.0は、私たちが今日使っているクラウドコンピューティングの最初のバージョンと認識しているもので、本質的には、前述の仮想マシンやストレージといった従来のITサービスを、革新的な新しいビジネスモデルで提供するものでした。私たちは、この初期にCSAに着手し、2007年に計画を立て、最終的に2009年のRSAで発表しました。

クラウド2.0は、クラウドネイティブと呼ばれる、クラウド特有の技術やフレームワークの出現を表しています。コンテナ、サーバーレス機能、DevOpsなどのほか、Cloud Security Posture Management(CSPM)などのクラウドネイティブセキュリティソリューションが挙げられます。

クラウド2.0の始まりの時期についてはいろいろな意見があります。長い間開発が進められていたクラウドネイティブが主流になったのは2016年頃で、これが始まりと私は考えています。2020年には、パンデミックによって在宅勤務が急増し、バーチャルで仕事をし、バーチャルで考えるということに対して、従来のセキュリティアーキテクチャや戦略がいかに破綻しているかが露呈しました。クラウドへの移行が加速し、cloud sprawl(クラウドの無秩序)を保護する戦略としてゼロトラストが再発見され台頭してきました。

クラウド3.0は2022年に始まりました。サイバーセキュリティの景気後退がこの歳の中頃に見られ、IPOが中止され、資金が枯渇し始めました。生成AIと大規模言語モデル(LLM)は、2022年後半にLLMプロンプトをクラウドサービスとしてリリースし注目を集め始めました。

私は、クラウドとAIに赤ちゃんが生まれ、それをChatGPTと名付けたと冗談を言うのが好きです。私にとっては、クラウド3.0は生成AIとクラウドネイティブの融合であり、今後何年にもわたって私たちが使うことになるクラウドのバージョンになることを約束するものです。私たちの業界により具体的に言えば、すべてのベンダーと企業のセキュリティチームは、クラウドセキュリティを新たに作り出すための自動化、拡張、ブレークスルーの創出に生成AIを活用しようとする「コパイロット化」の段階を迎えています。

2024年に何が起こるか(What’s Coming in 2024)

クラウドセキュリティアライアンスは、明日の問題を今日解決するために最善を尽くすよう努めています。そのため、これらのトレンドを理解し、業界に適切なサポートを提供できるようにしたいと考えています。以下に、2024年に向けての私たちの着目点を概説したいと思います。

AI Safety Initiativeについてはすでにご存知でしょう。我々のグローバルなフットプリントを活用して、クラウドのために行ってきたAIに関する研究、教育、認証機能のすべてを提供することを期待しています。重要なことは、私たちはAIを次の光り輝くものとして移行しようとしているのではなく、AIがクラウドに到来し、クラウドを変革しつつあるということです。フロンティアであるLLMやハイパースケーラー、そして事実上すべてのSaaSソリューションがAIを提供することで、究極のセキュリティ責任共有シナリオが生まれつつあります。

私がサイバーセキュリティの同僚に印象づけられることが1つあるとすれば、悪意のある行為者によるAIの採用(AIのコードスキャンを考えてみましょう)は、大きな課題を生み出すということです。AIの採用については慎重を期すことができるかもしれませんが、悪意のある行為者とそれに必要な対策とが交差するところではそうはいきません。

CSAは2023年末に、幅広いゼロトラストの知識を証明する業界初の資格、Certificate of Competence in Zero Trust(CCZT)を導入しました。これは、2024年に私たちにとって大きな重点分野となります。戦略として、ゼロトラストはあらゆるタイプのコンピュートシステムのセキュリティを強化するために使用され、全体として最も一般的な戦略になると考えています。私は以前、ゼロトラストを次のバージョンのインターネットのセキュリティ設計図と見ていると述べました。私たちは、これまで明らかにしてきたベストプラクティスを基に、AI向けの具体的なゼロトラストのユースケースなど、新たな分野でイノベーションを起こすつもりです。

CSAのSecurity, Trust, Assurance and Risk (STAR)プログラムは、クラウドプロバイダの保証表明の世界最大のリポジトリを提供しています。STAR は、最も人気のある調査成果物であるクラウド・コントロール・マトリックス(CCM)で構成されています。

STARは2011年に発行されたにもかかわらず、2023年に最も成長した成果物です。多くの企業のベンダー管理の中心的存在であり、多くの国や業界で標準となっています。私たちは、IT GRCの近代化の最前線にいることを確認するために、いくつかのプロジェクトを進行中です。AIの保証および保証のためのAIの活用の両方が取り上げられています。管理策の継続的なモニタリングは重要です。業界、国、テクノロジーセグメントによって使用されている多くのコンプライアンスフレームワークを調和させることが重要です。

歴史のあるCertificate of Cloud Security Knowledge (CCSK)プログラムが2024年半ばにバージョン5に更新されることをお知らせできることを大変嬉しく思います。クラウドセキュリティプロフェッショナルのための業界標準であるこのプログラムは、テクノロジーとプラクティスの適切なバランスを備え、クラウド3.0がサイバーセキュリティにとって何を意味するかを示す生きた見本となります。私たちは、CCSK v5の立ち上げにおいて、既存の資格保有者に最も簡単なパスを提供することをお約束します。皆様のご愛顧に感謝いたします。

これらは2024年における主な優先事項ですが、CSAらしく、私たちは野心的で、コミュニティに対応し、皆さんにとって重要な問題を幅広くカバーすることに重点を置いていきます。私たちと交わる機会はたくさんあります。CSAのバーチャルイベントや直接参加できるイベントにぜひお越しください。支部に参加しましょう。リサーチワーキンググループに参加しましょう。オンラインコミュニティ「circle」に登録しましょう。年寄りの私は、私たちの業界が文字通り一つの部屋に収まることができた頃を覚えています。幸いなことに、それはもはや不可能であり、我々は世界のビジネスの多くで重要な役割を果たしています。2024年、この責任をしっかり果たしていきましょう。

以上

グローバルプロバイダが日本語CAIQ評価レポートを登録する方法

2023年4月3日
CSAジャパン 諸角昌宏

本ブログは、すでに英語のCAIQ自己評価レポートをCSAのSTAR Registryに登録しているプロバイダ(グローバルにクラウドサービスを展開するプロバイダ)が、日本語でのCAIQ自己評価レポートをSTAR Registryに登録する方法について記載します。

  1. 日本語CAIQとSTAR Registryの状況
    まず、STAR Registryへの日本語CAIQ評価レポートの登録についての状況について説明します。

    • STAR Registryへの登録に必要なCAIQ評価レポートの内容(EXCELシートに書き込む言語)は、英語でも日本語でも可能です。
    • STAR Registryのサイトは英語でできているため、登録方法、運用はすべて英語になります。登録時の手順(ウエブの登録用画面等)はすべて英語になります。また、STAR Registryの検索等の運用もすべて英語になります。

この状況を踏まえて、CSAジャパンでは、「日本語での評価レポートの公開方法およびLevel1セルフアセスメントの重要性について」というブログで、日本語で評価したCAIQをSTAR Registryに登録する方法を紹介しています。しかしながら、こちらはあくまで日本のプロバイダがSTAR Registryに登録する場合を想定していますので、すでにCAIQを英語で登録されているプロバイダが日本語CAIQを追加する方法が分かりません。そこで、その方法について説明したものが本ブログになります。

  1. すでに英語版のCAIQ評価レポートを登録されている場合の日本語CAIQ評価レポートの登録方法CSAグローバルに確認したところ、複数言語に対して、以下の対応を行っています。
    STAR Registryの登録ページの以下のDocument Upload ページで、Supporting Documentにアップロードすることでできます。

    以下のようにすることで、英語版と日本語版の両方をアップすることができるとのことです。
    Primary Document: 英語版CAIQ
    Supporting Document #1: 日本語版CAIQ

    STAR Registryそのものはマルチリンガル対応していないのですが、複数のCAIQ評価レポートを公開する仕組みはできているので、これを使うことが可能になるということです。
    なお、登録自体は本社(英語版を登録した部署)の方でSTAR Registryを担当されている方と共同して行っていただく必要があります。

  2. 日本語版CAIQ評価レポート登録後のCSAジャパンの支援
    STAR Registryでは、日本語でCAIQ評価レポートを登録しているのを検索することができません。つまり、プロバイダが日本語で公開しているかどうかは、STAR Registryで該当するプロバイダの登録内容を確認してみないと分からないということになります。そこで、CSAジャパンでは、日本語でCAIQ評価レポートを公開しているプロバイダが一目でわかるように、また、日本語でCAIQ評価レポートを公開していることを周知できるように、以下のように支援しています。

    • CSAジャパンの以下のウエブページから、日本語版CAIQ評価レポートを公開しているプロバイダを紹介します。https://www.cloudsecurityalliance.jp/site/?page_id=19811
      現在、「準備中」ということで、プロバイダの情報が整い次第公開を開始します。
    • CSAジャパンのホームページの新着情報として紹介します。
    • CSAジャパン会員及び連携団体向けメールニュース配信を行います。
    • CSAジャパンのフェースブックグループから紹介します。
  1. 今後について
    CSAジャパンは、上記の方法による登録について、CSA本部の担当者およびSTAR/CCM/CAIQの責任者と連絡を取って対応します。従いまして、何か問題が発生した場合には、CSA本部と連携を取りながら対応していきます。
    それから、STAR Registryそのものをマルチリンガル対応にしていくことが必要と考えています。これに関しても、CSA本部と協議を進めていきたいと考えています。

以上

 

 

 

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

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

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) などを公開している。 続きを読む

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

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

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

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

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

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

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

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

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

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

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

医療機器サイバーセキュリティに関連して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

FY21 CSA関西活動計画

今期のCSA関西の活動は、「ヘルスケア」をメインテーマとして活動をしてまいります。

皆さんご存じの通り、ウェルネスへの注目はますます高まり、また、デジタルを活用した「デジタルヘルスケア」も非常に進んできています。これらの状況も含めて、DX推進における、ウェルネス、ヘルスケアは、デジタルによって大きく変わる分野になるでしょう。

ヘルスケアのデジタル活用の課題
デジタルを活用する事により、ヘルスケアの分野が大きく進化する事は期待が持てますが、課題も多くあります。

・クラウド上の膨大なヘルスケアデータの管理
デジタル化に伴い膨大なバイタルデータ含む個人情報を扱う事になります。 それらの膨大なデータはおそらくクラウドを中心に管理される事になります。

・デバイスのインターネット接続によるサイバー攻撃のリスク
また、今まではインターネットに接続されていなかった、各種医療機器や医療情報を取り扱う端末が、インターネット接続される事による、サイバー攻撃のリスクも大きくなります。

・セキュリティ人材
別の側面として、人の課題もあります。従来クラウドセキュリティやサイバーセキュリティを専門としていなかった、医療システム開発エンジニアや医療機器開発エンジニアの方の、これらの分野の知識の向上が急務になります。

・参入ベンダーのヘルスケアガバナンス
加えて、ヘルスケア業界に参入される、システム開発、機器ベンダーの方々が、ヘルスケアにおけるガイドライン、ガバナンスを理解、習得する必要もあります。

CSA関西のヘルスケアにおける活動
上記の課題を、CSA関西の活動を通じて少しでも解決に向けてご支援ができればと考えて今期の活動を計画しています。

CSA関西のヘルスケア今期活動予定
今期の活動予定として、下記の6つのテーマに関する、ブログの発信と勉強会をセットで実施をいたします。また、勉強会については、下記のテーマに加えて毎回、関連の団体、企業、ベンダーの方にもお話いただけるセッションを合わせて実施する予定です。

デジタルヘルスケア全般およびセキュリティ対策にご興味のある方はどなたでも、是非今後の活動にご注目いただき、ブログをご覧いただき、勉強会にもご参加ください。
また、ご参加に限らず、是非ご一緒に情報の発信や上記課題解決に向けた活動を実施していきましょう。

お問い合わせ:
クラウドセキュリティアライアンス関西支部
運営チームリーダー
夏目道生