（前編はこちら）
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サイバーセキュリティフレームワークに準拠しながら取組むべきリスク低減策を紹介することを目的としている。
医療機関を標的にしたランサムウェア被害が続出する米国では、2021年3月2日、連邦政府の支援を受けた非営利団体MITREが、ランサムウェア対策支援センター「Health Cyber」（https://healthcyber.mitre.org/）を公開Web上に開設したことを発表している。
Health Cyberは、医療機関の経営管理部門、臨床技術部門、IT／セキュリティ実務家の3つのカテゴリーに合わせたコンテンツ作成・発信を行っている点が特徴である。たとえば、経営管理部門向けには、以下のようなメニュー構成の情報発信を行っている。
2022年2月9日
データセキュリティ WGメンバー： 諸角昌宏
本ブログでは、クラウド利用において必要となる利用者鍵管理について解説する。
「クラウドでは共有責任モデルとしてユーザーがデータセキュリティの責任を持ちます。そのデータを保護する技術として「暗号化」が有効な技術であることが各法規制やガイドライン等で言及されており、多くの情報システムにおいて暗号技術は活用されています。
また暗号化技術を利用する場合には「暗号鍵」もユーザーの責任で保護する必要があり、ユーザー自身の責任で鍵管理技術を理解して実装方法を選択して運用する必要があります。」（引用： 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環境においてはこの問題に直面する。
そこで考えられたのが「利用者による鍵管理（以下、利用者鍵管理と呼ぶ）」という方法で、プロバイダーが暗号化エンジンを管理するのに対して、利用者が自身の暗号鍵を管理できるようにする仕組みである。本ブログでは、この利用者鍵管理についての規制等の要求事項、利用者鍵管理の手法、動作の例などについて説明していく。
以下に、代表的な規格における利用者鍵管理の要求事項を記載する。
利用者鍵管理の構成として、前述の「Cloud Data Protection」では以下のように2つのタイプ（BYOK、HYOK）が記述されている。
ここで、BYOKとHYOKの違いを明確にすると以下のようになる：
このBYOKとHYOKを明確にすることが重要であり、ここが利用者鍵管理として混同されている点である。特に、BYOKがバズワードとなっていて、利用者鍵管理＝BYOK と扱われてしまっていることが問題となる。先に述べた様々な規格の要求事項は、HYOKが必要となることでありBYOKでは不十分であるということを理解する必要がある。
ここでは、HYOKの動作の１つの例を以下の図を使って説明する。
まず、この図に表示されているそれぞれの鍵について説明する：
利用者から送られたデータを暗号化してストレージに保存する手順は以下になる：
(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を保有するのは、暗号化および復号の作業を行うときのみになる。また、一連の流れとして、利用者が鍵の管理を行うことができる。
以上、説明してきたように、クラウド環境で必要とする利用者鍵管理は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プロバイダーが利用者鍵管理を提供する場合、以下の2つのケースが考えられる：
なお、SaaSプロバイダーが利用者鍵管理を評価・実装するには、ユースケースを含めた詳しい情報が必要であると思われる。利用者鍵管理を提供しているベンダーおよびIaaS/SaaSプロバイダーは、利用者鍵管理に関する情報を積極的に発信していただきたい。本ブログにおいても、今後、できるだけ情報発信できるようにしていきたい。
これまで、利用者鍵管理について記述してきたが、利用者鍵管理が必要となるそもそもの暗号化について、その代替手段として以下の２つが考えられる。
トークン化はクレジットカードの保護等で実績がある仕組みであり、従来からの暗号化技術と同様検討に値する技術である。
暗号化の問題は、アプリケーションが暗号化されたデータを処理できないという点である。利用者鍵管理の問題以前に、クラウド上のアプリケーションは、何らかの形で復号しないと処理できないという根本的な問題を抱えており、クラウドのマルチテナントを維持しなければならない環境において問題となる。トークン化されたデータは、元のデータと同じサイズ/形式で保管されるため、トークン化されたデータを保管するためにデータベースのスキーマやプロセスを変更する必要はない。データのトークン化により、クラウドやビッグデータ、外部委託環境に移行する際も、制御機能やコンプライアンスを維持することが可能である。ここでは、トークン化について詳しく述べないが、1つの代替手段と考えられる。
アプリケーションが、暗号化データを復号せずに処理できる方法として、（完全）準同型暗号が考えられる。まだ、あまり一般に商用化されていないが、今後、幅広く利用されてくる可能性もある。今後の展開に注目したい。
以上、クラウド上のデータの暗号化として必要となる利用者鍵管理について記述した。これから先、新たな情報が得られれば、また、情報発信していきたい。
以上