すべてのチャネルを個別に守っても、必ず抜け道が生まれる
典型的な請負業者は、メールセキュリティ、ファイル共有、MFT、フォームなど、それぞれ異なるベンダーを利用しています。それぞれのチャネルは個別に適切に保護されていますが、他のベンダーが何をしているかは把握しておらず、その継ぎ目こそがCUIが実際に漏洩するポイントです。
これは6層防御ではなく、同じ意図を持つ6つのポリシー定義が、ルールブックを共有しない6つのシステムで個別に適用されているだけです。重複する管理データをカバーする6つの独立したポリシーは必ずどこかで乖離し、その継ぎ目には誰も責任を持ちません。
エグゼクティブサマリー
防衛請負業者のポイントプロダクト型セキュリティスタックは、1つ1つの調達判断によって構築されています。その結果、独立して管理されるポリシー群が生まれ、必然的に乖離し、ベンダー間の継ぎ目ごとにギャップが生じます。プログラムのセキュリティ責任者にとって重要なのは、6つすべてのベンダーが同じ管理データに対して同じポリシーで合意しているかどうかという点です。
主なポイント
- ポイントプロダクトベンダーが増えるごとに、同じ管理データに対してポリシーを再定義する場所が増えます。
- 同じデータをカバーする6つの独立したポリシーは、時間とともに乖離し、整合性を保てません。
- ベンダー間の継ぎ目には誰も責任を持たず、そこがまさにCUIが漏洩するポイントです。
- ベンダーが増えるほど、異なるフォーマットのログが増え、評価時に活用できる証拠が減少します。
- ポリシーエンジンに統合しても、チャネルのカバレッジを失うことにはなりません。
ベスト・オブ・ブリード型スタックが完全なカバレッジにならない理由
各チャネルごとに最適なツールを選択すると、個々のチャネル単体では最適化されますが、チャネル間の連携や隙間は無視されます。
各ベンダーは自社チャネルの最適化に集中し、プログラム全体のポリシーには目を向けない
最高クラスのファイル共有ベンダーであっても、同じ管理ファイルが、まったく別のベンダーによって保護されたメール添付として送信された後、一貫して取り扱われているかどうかは把握できません。
6つのコンソールは、ポリシーが静かに乖離する6つのポイント
同じ意図を6つのコンソールで個別に設定しなければならない場合、インシデント後に1つだけルールを更新しても、他のコンソールにはほとんど反映されません。
ギャップが実際に生じる場所
ベンダーAの契約はベンダーAのチャネルのみをカバーします。どちらの契約も、管理データが一方から他方に移動する瞬間はカバーしていません。
ベンダーが増えるほど、ログの形式も増える
3つのチャネルにまたがるインシデントが発生すると、それぞれ異なる構造の3つのログを、時間的なプレッシャーの中で突き合わせる必要があります。
データコントロールプレーンが6つのポリシーを1つに統合する方法
Kiteworksのデータコントロールプレーンは、メール、ファイル共有、SFTP、マネージドファイル転送、フォーム、API、さらにAIエージェントまで、すべてを単一のデータ認識型ゼロトラストポリシーエンジンで統制します。一度定義した分類はすべてのチャネルで同一に適用され、すべてのアクションは単一の改ざん防止・無制限の監査ログに記録され、SIEMツールに直接連携されます。
現在のスタックでいくつの独立したポリシーが存在しているか確認したい請負業者は、カスタムデモを予約できます。
よくあるご質問
各ベンダーが同じ管理データに対して独自のポリシーを個別に管理しており、これらは時間とともに必ず乖離します。ベンダー間の継ぎ目には誰も責任を持たず、そこがまさにCUI漏洩のギャップとなります。
個々のチャネルごとにツールを最適化しても、チャネル間の一貫性が無視されます。同じポリシー意図を複数のコンソールで再定義する必要があり、静かに乖離が進み、管理データの流れを完全にカバーできなくなります。
6つの独立したポリシーを、メール、ファイル共有、SFTP、MFT、フォーム、APIすべてにわたり同一に分類を適用するデータ認識型ゼロトラストポリシーエンジンに統合し、単一の改ざん防止監査ログを提供します。
ベンダーが増えるごとに互換性のない形式のログが増え、複数チャネルにまたがるインシデントや評価時に、時間的制約の中で複雑な突き合わせ作業が必要となり、活用できる証拠が減少します。