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