医療業界のチャネル乱立問題を、ひとつのコンソールで解決
一般的な病院では、メールセキュリティ、ファイル共有、EHR、フォームといった各分野ごとに異なるベンダーを利用しています。それぞれが自分のチャネルを一定レベルで保護していますが、他の5つが何をしているかは把握しておらず、実際に患者データが漏洩するのはその境界部分です。
これは6層の防御ではなく、同じ目的に対して6つの異なるポリシー定義が存在し、それぞれが独自のルールで運用されています。重複する患者データをカバーする6つの独立したポリシーは、どこかで必ず食い違いが生じ、その境界部分には誰も責任を持ちません。
エグゼクティブサマリー
病院のポイントプロダクト型セキュリティスタックは、個別の調達判断ごとに構築されています。その結果、独立して管理される複数のポリシーが生まれ、必然的に食い違いが発生し、ベンダー間の境界ごとにギャップが生じます。コンプライアンス責任者にとって重要なのは、6つのベンダー全てが同じ患者データに対して同じポリシーで合意しているかどうかという点です。
主なポイント
- ポイントプロダクトベンダーが増えるたびに、同じ患者データに対してポリシーを再定義する場所が増えます。
- 同じデータをカバーする6つの独立したポリシーは、時間とともに必ず食い違い、整合し続けることはありません。
- ベンダー間の境界部分には誰も責任を持たず、まさにその部分で患者データが実際に漏洩します。
- ベンダーが増えるほどログ形式も多様化し、規制調査時に活用できる証拠が減少します。
- ポリシーエンジンを一元化しても、各チャネルのカバレッジを失うことにはなりません。
ベスト・オブ・ブリード型スタックでは完全なカバレッジにならない理由
各チャネルごとに最適なツールを選ぶと、それぞれのチャネル単体の最適化にはなりますが、チャネル間で何が起きているかは無視されます。
各ベンダーは自社チャネルの最適化のみを重視し、病院全体のポリシーには目を向けない
最高水準のEHRベンダーであっても、同じ患者記録が別のベンダーによるメール添付として外部に出た際に一貫して取り扱われているかどうかは把握できません。
6つのコンソールは、ポリシーが静かに食い違う6つのポイント
同じ目的の設定を6つのコンソールで個別に行う必要がある場合、インシデント後に1つのコンソールでルールを更新しても、他のコンソールにはほとんど反映されません。
実際のギャップが生じる場所
ベンダーAの契約はベンダーAのチャネルのみをカバーしています。どちらの契約も、患者データが一方から他方へ移動する瞬間はカバーしていません。
ベンダーが増えるほど、ログ形式も多様化
3つのチャネルにまたがるインシデントが発生した場合、それぞれ異なる構造の3つのログを、時間的な制約の中で突き合わせる必要があります。
データコントロールプレーンが6つのポリシーを1つに統合する仕組み
Kiteworksのデータコントロールプレーンは、メール、ファイル共有、SFTP、マネージドファイル転送、フォーム、API、さらにAIエージェントまで、すべてを単一のデータ認識型ゼロトラストポリシーエンジンで統制します。一度定義した分類は、すべてのチャネルで同一に適用され、全てのアクションは単一の改ざん防止・無制限の監査ログに記録され、SIEMツールへ直接連携されます。
現在のスタックでいくつの独立したポリシーが運用されているかを確認したい医療機関は、カスタムデモを予約できます。
よくあるご質問
各ベンダーは自分のチャネルだけを保護し、独立したポリシーを維持しているため、同じ患者データのルールがシステムごとに個別に再定義されます。これらのポリシーは時間とともに必ず食い違い、ベンダー間の境界部分でギャップが生じ、誰もその引き継ぎ部分に責任を持ちません。
インシデント後に1つのコンソールでルールを更新しても、他のコンソールにはほとんど反映されず、ポリシーが静かに食い違っていきます。その結果、メール、ファイル共有、EHRなど複数チャネルにまたがる患者データで一貫性のない運用が生じます。
複数の独立したポリシーを、メール、ファイル共有、SFTP、マネージドファイル転送、フォーム、APIを統合管理するデータ認識型ゼロトラストポリシーエンジンに置き換えます。一度定義した分類がすべてのチャネルで同一に適用され、全アクションが1つの改ざん防止監査ログに記録されます。
ベンダーが増えるほど、異なる形式のログが増加し、インシデントが複数チャネルにまたがる場合に証拠の突き合わせが困難になります。そのため、コンプライアンス審査や調査時に活用できる監査データが減少します。