6社のベンダー、1つのポリシーギャップ：あらゆるチャネルを個別に保護しても、必ず抜け漏れが生まれる理由

はじめに

一般的なエンタープライズのデータ交換スタックは、次のような構成になっています。メールセキュリティのベンダーが1社、マネージドファイル転送のベンダーが2社目、セキュアなファイル共有のベンダーが3社目、フォームのベンダーが4社目、DLPが5社目、そして最新のチャネル用に6社目が追加されます。それぞれのベンダーは自社のチャネルを十分に保護していますが、他の5社が何をしているかは知りません。

これは6層の防御ではありません。同じ意図のポリシーが6つの異なるコンソールで、それぞれ別々に定義されているだけです。しかも、これらはお互いに連携していない担当者によって書かれ、6つのシステムがそれぞれ独自のルールで運用されています。この構成の数学的な帰結として、どこかに必ずギャップが生じます。これは特定のベンダーが弱いからではなく、重複するデータを6つの独立したポリシーで管理することで、必ずどこかで食い違いが生まれ、その境界部分には誰も責任を持たないからです。本記事では、チャネルごとにベンダーが乱立することでなぜこのような構造的な問題が発生するのか、そしてそれをどう解決するかを解説します。

• ポイント1：ベンダーが増えるごとに、同じポリシーを再定義する場所が増えます。あるベンダーのコンソールで正しく適用されたルールも、他のすべてのベンダーで手作業で複製し、同期し続けなければなりません。
• ポイント2：同じデータをカバーする6つの独立したポリシーは、時間とともに必ず食い違いが生じます。独立運用による設定のズレは例外ではなく、むしろ通常発生します。
• ポイント3：ベンダー間の境界部分には誰も責任を持ちません。実際にデータが漏洩するのはまさにこの部分です。各ベンダーは自社のチャネルだけを担当し、データが次のチャネルに移る際の責任は誰も持ちません。
• ポイント4：ベンダーが増えるほどログも増え、しかもフォーマットが異なるため、証拠として活用しにくくなります。6つのシステムのうち3つに関わるインシデントが発生した場合、3種類の異なる監査記録を手作業で突き合わせなければなりません。
• ポイント5：ポリシー適用を1つのエンジンに統合することは、チャネルカバレッジを犠牲にすることではありません。同じルールが該当するすべての場所で一貫して適用されるという意味です。6つの近似的なルールを使い分ける必要がなくなります。

エグゼクティブサマリー

ポイントプロダクトによるセキュリティスタックは、個別の調達判断ごとに構築され、それぞれのチャネルの課題を最適に解決します。しかし、その集合体はセキュリティが加算されるわけではありません。独立して運用されるポリシーが必然的にズレていき、システム間でコンテキストが共有されないため、ベンダー間の境界ごとに必ずギャップが生じます。セキュリティやコンプライアンスの責任者にとって本当に重要な監査は「各ベンダーが安全か」ではなく、「6社すべてが同じデータに対して同じポリシーを適用しているか」です。実際には、これが完全に一致することはほとんどありません。ベンダー数を減らすこと自体が目的ではなく、同じ機密データをカバーする独立したポリシー定義の数を減らすことが重要です。

なぜベスト・オブ・ブリードのスタックでは完全なカバレッジにならないのか

各チャネルごとに最適なツールを選ぶのは合理的な調達判断です。しかし、それは各チャネル単体での最適化にとどまり、チャネル間で何が起きるかは考慮されません。

各ベンダーは自社チャネルの最適化のみ、組織全体のポリシー最適化はしない

一流のメールセキュリティベンダーは、メールの保護には非常に優れています。しかし、同じ機密ファイルがメールから別のベンダーが保護するファイル共有プラットフォームに移った後、一貫して取り扱われているかどうかには関心も可視性もありません。最適化はチャネル単位で行われ、データの全体的な流れに対する最適化は誰もしていません。

6つのコンソールは、ポリシーが静かにズレる6つのポイント

たとえば「機密データの特定カテゴリを外部に持ち出させない」という同じ意図でも、6つの管理コンソールで個別に設定しなければなりません。最初は同じ設定でも、運用の中で徐々にズレていきます。インシデント後に1つのコンソールでルールを更新しても、他の5つに反映されることは稀です。なぜなら、6つすべてを覚えて手作業で反映する必要があるからです。

ギャップが実際に存在する場所

マルチベンダースタックのギャップは、特定のベンダー製品の内部にあることはほとんどありません。実際には、製品間の責任が曖昧で可視性が低い「間」に存在します。

ベンダー間の境界には責任者がいない

ベンダーAの契約はAのチャネルのみ、ベンダーBの契約はBのチャネルのみをカバーします。データがAからBに移る瞬間は、どちらの契約・製品でもカバーされません。これは特定ベンダーの設計ミスではなく、チャネルごとに個別調達する構造的な結果です。カバレッジは各ベンダーの境界で途切れ、境界同士は重なりません。

ベンダーが増えるほど、ログもフォーマットもバラバラに増える

ベンダーが増えるごとに、それぞれ独自の監査ログ、フォーマット、保持ポリシー、アクセスモデルが追加されます。3つのチャネルにまたがるインシデントが発生した場合、3種類の異なるログを、調査の時間的プレッシャーの中で手作業で突き合わせる必要があります。ベンダーが増えても証拠が増えるわけではなく、断片的な証拠が増え、それを人手で組み立てなければなりません。

統合の本質はベンダー数削減ではなくポリシーの一元化

単一プラットフォームへの集約が価値を持つのは、ベンダー数が少ないからではありません。6つの独立したポリシー定義を1つに統合し、ズレや責任のない境界を排除できるからこそ価値があります。

1つのポリシーエンジンで「機密」の定義を全チャネルに一貫適用

単一のポリシーエンジンがすべてのチャネルを管理すれば、1度定義した分類や制限が、該当するすべての場所で一貫して適用されます。6つの手作業による近似ルールを使い分ける必要はありません。どのチャネルをデータが通過しても、同じエンジンが同じルールを評価するため、ポリシーが途切れる境界がなくなります。

監査ログも1本化、証拠の突き合わせは設計で解決

すべてのチャネルをカバーする単一の監査ログがあれば、インシデント調査は断片的な記録を突き合わせるのではなく、一貫した記録から始められます。マルチベンダースタックがセキュリティチームに押し付けていた突き合わせ作業は、最初から記録が分断されていないため、設計上不要になります。

この特有の失敗モードに対するマルチベンダースタック監査方法

実務的な監査で問うべきは「各ベンダーが自社のセキュリティ基準を満たしているか」ではありません。調達段階でそれは確認済みでしょう。重要なのは、特定カテゴリの機密データを選び、それがスタック内のすべてのベンダーをまたいで移動する際、同じルールが各段階で本当に一貫して適用されているか、それとも最後にそのコンソールを更新した人の記憶頼みで近似的にしか適用されていないかを追跡することです。

データコントロールプレーンが6つのポリシーを1つに置き換える方法

このギャップを埋めるために、組織が利用するすべてのチャネルを置き換える必要はありません。すべてのチャネルを横断する単一のガバナンスレイヤーを設ければ、1つのポリシー定義、1つの分類モデル、1つの監査ログが、機密データが移動するすべての場所で一貫して適用されます。6つの独立した近似ポリシーを使い分ける必要はなくなります。

Kiteworksのデータコントロールプレーンは、メール、ファイル共有、SFTP、マネージドファイル転送、フォーム、API（AIエージェントも含む）を、6つの独立したエンジンではなく、データ認識型のゼロトラストポリシーエンジン1つで統合管理します。1度定義した分類や制限が、すべてのチャネルで一貫して適用されるため、ベンダーごとに個別設定されたポリシーがズレる「境界」がなくなります。すべてのチャネルでのアクションは、改ざん不可能かつスロットリングのない単一の監査ログに記録され、SIEMツールに直接連携されます。複数チャネルにまたがるインシデントも、断片的なベンダー固有ログを手作業で突き合わせることなく、一貫した記録から調査できます。

現在のスタックが同じ機密データに対していくつの独立したポリシー定義を持っているかを可視化したい組織は、カスタムデモを予約し、すべてのチャネルを一元管理するコントロールプレーンとの比較が可能です。