患者記録には、他の誰にも解除できない暗号化を

すべてのヘルスITベンダーは「患者データは暗号化されている」と主張します。しかし、その主張が本当にデータを守るかどうかを決めるのは「誰が鍵を持っているか」です。もしベンダーが鍵を保持していれば、暗号化は外部からのアクセスを防ぐだけで、ベンダー自身や、法的にベンダーに復号を強制できる第三者からは患者記録を守れません。

これは、特別なカテゴリの患者データをサードパーティプラットフォームでやり取りするヘルスシステムにとって、仮定の話ではありません。鍵付きの書類キャビネットも、ベンダーが合鍵を持ち、要請があればすぐに渡してしまうなら意味がありません。本記事では、鍵の管理権限がヘルスシステムにもたらす実際の違い、なぜ多くのセキュリティレビューでこの点が見落とされがちなのか、そして本当の「顧客所有鍵管理」に必要な実践について解説します。

要約

ヘルスITプラットフォームのセキュリティレビューは、暗号化アルゴリズムや鍵長の確認で終わることが多く、「AES-256なら安全」と思われがちです。しかし、実際に患者データが守られているかどうかを決めるのは「誰が鍵を管理しているか」です。鍵を持つ者がデータを支配できるため、暗号化の有無に関わらず、ベンダーが鍵を生成・保管・管理していれば、ヘルスシステムが知らない理由や同意していない理由でも、いつでも患者記録を閲覧できてしまいます。ハードウェアによる顧客所有鍵管理は、この可能性を完全に排除します。ヘルスITリーダーにとって、暗号化は単なるコンプライアンス項目ではなく、「ベンダーが患者データを復号できるか否か」という具体的かつ検証可能なアーキテクチャの事実へと再定義されます。

主なポイント

1. 暗号化は、鍵を持たない第三者からしかデータを守れません。ベンダーが鍵を持つ場合、患者データの保護は暗号化そのものではなく、ベンダーの意思に依存します。
2. BYOK（Bring Your Own Key）モデルは、ベンダーの復号能力を完全に排除します。ベンダー管理の鍵では、アルゴリズムやマーケティング表現に関係なく、復号能力がそのまま残ります。
3. ハードウェアセキュリティモジュール（HSM）は、鍵の所有をポリシーではなく物理的な事実にします。ヘルスシステム自身のHSMで生成・保管された鍵は、プラットフォーム運営側が管理者権限を持っていても抽出できません。
4. オンデマンドでの鍵ローテーションは、本当の所有権の一部です。疑わしい侵害後に自分のタイミングで鍵をローテーションできない場合、患者データを完全にコントロールしているとは言えません。
5. 暗号化の強度は、誤った相手が鍵を持っていれば無意味です。患者の信頼にとって重要なのは「誰が復号できるか」であり、「暗号の強さ」ではありません。

なぜ暗号化の強度だけでは患者データの本質的な安全性を問えないのか

セキュリティレビューでは暗号化について頻繁に質問され、その回答はほとんどが「保存時はAES-256、転送時はTLS 1.3」などアルゴリズムの説明に終始します。しかし、これは本質から外れています。

暗号化データにも必ず鍵の所有者がいる

暗号化された患者記録と平文の間に立ちはだかるのは、ただ一つ「鍵」です。鍵を持つ者はデータを閲覧でき、他者のために復号したり、法的手続きで復号を強制されたりします。暗号アルゴリズムの強さは、この事実に影響しません。強力な暗号であってもベンダーが鍵を持っていれば、弱い暗号と同じく、ベンダーが望めば（または命令されれば）データを読めてしまいます。

なぜベンダーはこの違いを強調しないのか

ヘルスシステム向けのベンダー資料は、「業界標準アルゴリズムで保存・転送時ともに暗号化」といった、包括的に聞こえる表現が多く使われます。これは正確ですが不十分です。誰が鍵を生成し、どこに保管し、ベンダーのインフラからアクセス可能かどうかには触れていません。暗号化の主張だけを鵜呑みにし、鍵管理の問いを別途立てなければ、最も機密性の高いデータに対する誤った安心感を持ってしまいます。

本当の顧客所有鍵管理に必要な条件

鍵の所有は単なる機能ではなく、複数の条件がすべて満たされて初めて成立します。どれか一つでも欠ければ、ヘルスシステムの鍵管理は理論上の話に過ぎなくなります。

BYOK（顧客所有鍵）とベンダー管理鍵の違い

ベンダー管理鍵モデルでは、プラットフォームが自社インフラ内で鍵を生成・保管します。ヘルスシステムはその鍵を一度も目にしない場合もあります。一方、BYOK（顧客所有鍵）モデルでは、ヘルスシステム自身が鍵の生成・保管を管理し、通常は自社管理または専用アクセス権を持つハードウェアセキュリティモジュールを利用します。この違いは表面的なものではなく、「ベンダーが技術的に患者データを復号できるか否か」という根本的な違いです。

ハードウェアセキュリティモジュールが持つ本当の意味

ハードウェアセキュリティモジュール（HSM）は、暗号鍵を生成・保管・管理する専用物理デバイスであり、管理者権限を持つ者でも鍵の抽出が困難です。鍵管理をHSMと統合し、アプリケーションと同じソフトウェア内に鍵を保管しないことで、鍵の所有は設定項目から物理的な制約へと変わります。ソフトウェアのみの顧客鍵所有主張は、ベンダーが自社インフラに十分なアクセス権を持っていれば、密かに覆される可能性があります。HSMを正しく統合することで、このリスクをポリシーではなく設計上排除できます。

鍵ローテーションと暗号制御が所有権の真偽を決める理由

一度鍵を持っただけでは、継続的なコントロールとは言えません。運用面での2つのポイントが、本当の鍵所有と、データシート上だけの主張を分けます。

オンデマンドでの鍵ローテーション

認証情報の漏洩や従業員の退職、侵害の疑いなどで鍵の流出が疑われた場合、ベンダーのリリーススケジュールやサポート対応を待たず、即座に鍵をローテーションできることが、実運用上の鍵所有を意味します。自分のタイミングで鍵をローテーションできない場合、完全なコントロールはできていません。

細かな暗号スイート・プロトコルの制御

特定の暗号スイートの有効・無効や、許可するTLSバージョンの制御も、別の形のコントロールです。コンプライアンス期限前に非推奨暗号を廃止する必要がある場合、ベンダーの対応を待たずに自社で制御できるべきです。

ベンダー選定時の鍵管理確認ポイント

ヘルスITチームがベンダーを評価する際、実務的な確認事項はシンプルですが、時間に追われると見落としがちです。「誰が鍵を生成するか」「どこに保管されるか」「HSMが使われているか」「誰が、どのタイミングで鍵をローテーションできるか」を必ず確認しましょう。すべての工程をヘルスシステムがコントロールできる場合、堅牢な鍵管理モデルと言えます。アルゴリズムや鍵長だけの説明では、暗号化後に誰が患者データを実際に管理しているかは分かりません。

データコントロールプレーンによる鍵所有のアーキテクチャ保証

顧客所有鍵管理は、プラットフォームのアーキテクチャに組み込まれて初めて本来の効果を発揮します。多くの導入で省略されるオプション機能では不十分です。鍵管理を基盤とするデータコントロールプレーンを持つことで、ベンダーが患者データを技術的に復号できない状態が、メール、ファイル共有、API、AIエージェントなど、あらゆるデータ流通チャネルで一貫して保証されます。個別に設定したチャネルだけでなく、すべてに適用されます。

Kiteworksのデータコントロールプレーンは、顧客所有の暗号鍵をハードウェアセキュリティモジュール経由で統合し、主要なHSMプロバイダーにも対応。鍵の生成・保管はKiteworksの管理範囲外となります。ヘルスシステムはオンデマンドで鍵をローテーションでき、暗号スイートやTLSバージョンの有効化も制御可能。鍵管理は他の顧客環境と共有されないシングルテナントアーキテクチャで運用できます。その上で、データ認識型のゼロトラスト制御により、すべての送信・共有・アクセス操作を全チャネルで統制。すべての操作は改ざん防止・無制限の監査ログに記録され、SIEMツールにも直接連携されるため、鍵管理の主張はデータシート上の一文ではなく、実際の運用記録によって裏付けられます。

現在利用中のベンダーの鍵管理モデルをこの基準で検証したいヘルスシステムは、カスタムデモを予約し、自社の患者データやコンプライアンス要件に対する顧客管理HSM統合の適用例を確認できます。