メールの誤送信防止とメタデータの自社環境内保持

公共部門のセキュリティアーキテクトにメール誤送信防止ツールについて尋ねると、最初の質問は検知精度ではなく、「どこで分析が行われるか」です。メッセージをチェックする際に、そのメタデータが外部サービスに渡される場合、ツールは機密情報の流出先を増やすことになり、導入目的が損なわれてしまいます。

主権要件が課されている組織にとって、この依存関係はパイロット開始前の時点で導入不可の理由となることが多いです。多くの誤送信防止ツールは、メール環境の上にSaaSレイヤーとして動作します。それぞれが新たなベンダー、データフロー、統合管理を追加します。

本記事では、Kiteworks AgentおよびHuman Error Prevention（AHEP）がどこでバリデーションを実行するのか、主権審査でベンダーに確認すべき質問、導入前に計画すべきポイントについて解説します。

エグゼクティブサマリー

AHEPは、お客様自身のKiteworks環境内でメッセージをバリデーションします。AHEPソリューションブリーフによれば、メールのメタデータは環境外に出ることがなく、バリデーションはオンプレミスまたはプライベートクラウド内で完結します。メールは引き続きクライアントからメールサーバーへ直接ルーティングされ、すべてのアラートや判断はKiteworksの監査ログに記録されます。アーキテクトや主権管理者にとって、データフローの疑問は早期に解消されますが、前提条件として、コンテナ化サービスレイヤー、Validation Service、サポートされているクライアントの定義が必要です。

主なポイント

1. 誤送信防止ツールに関する最初の質問は、分析がどこで実行されるかです。評価が自社環境外で行われる場合、ツールは主権要件が許容しないデータ依存性を追加します。
2. AHEPのバリデーションはKiteworks環境内で実行されます。Validation Serviceは、少なくとも1つのアプリケーションノード上のコンテナ化サービスレイヤーに配置され、外部分析サービスは関与しません。
3. メールフローとメッセージ評価は分離されています。メールはクライアントからメールサーバーへ直接送信され、Validation Serviceはメッセージ作成中に評価を行い、独自に何かを送信することはありません。
4. 1つの監査ログでAHEPおよび他の管理チャネルをカバーします。すべてのアラート（表示・却下・解決）は、メール、ファイル共有、SFTP、MFT、フォームのイベントとともに記録されます。
5. 展開を約束する前に前提条件を計画してください。AHEPにはコンテナ化レイヤーとKiteworksテクニカルサポートによるValidation Serviceの有効化が必要で、アラートは現時点で2つのクライアントで動作します。

主権アーキテクチャにおけるメール誤送信防止の実行場所

主権審査はデータの流れを追跡します。情報がどこで処理され、誰が閲覧でき、どのような記録が残るかを確認します。宛先や添付ファイルを検査するツールは、誰が誰に、どんな内容で、どのファイルを送っているかという機密メタデータを必然的に扱います。そのため、分析の実行場所はベンダー選定の詳細ではなく、アーキテクチャ上の重要な判断事項となります。

データフローに関する疑問

ツールがメッセージのメタデータを分析のためにクラウドサービスへ送信する場合、脅威モデルに外部プロセッサが1つ追加されます。一部の組織では契約で許容されることもありますが、厳格な主権や機密区分規則の下で運用する場合は認められず、機能リストが変わっても結論は変わりません。

レイヤードツールが依存関係を増やす理由

メール環境の上に配置されたスタンドアロン製品は、新たなベンダー、統合、個別のログを追加します。また、問題発生時に確認すべき場所が増えます。既にデータを管理しているプラットフォームに組み込まれたコントロールであれば、こうした重複を避け、発生した事象の記録も一元化できます。

AHEPがバリデーションを自社環境内で完結させる仕組み

Validation Serviceは、Kiteworksのコンテナ化サービスレイヤー（RKE2）上の少なくとも1つのアプリケーションノードで稼働します。メッセージは作成中にそこで評価されます。メールは引き続きクライアントからメールサーバーへ直接ルーティングされるため、AHEPが配送経路を変更することはなく、自身でメールを送信することもありません。

主権審査で確認すべき3つの質問

評価はどこで実行されるか？どのメタデータが環境外に出るか？コントロールはどんな記録を残すか？AHEPの場合、回答は「自社インフラ内」「ソリューションブリーフによれば外部流出なし」「Kiteworks監査ログ」です。すべてのアラート（表示・却下・解決）は、ポリシー、指令、受信者、タイムスタンプ、ユーザーの判断とともに記録されます。このログは、Data Policy Engineで管理される他のチャネルもカバーしています。

基盤となるプラットフォーム

AHEPはKiteworksプラットフォームの機能であり、スタンドアロン製品ではありません。プラットフォーム自体が独立したセキュリティ認証やアテステーションを取得しており、それらはAHEPの基盤となる部分を示しています。自社要件と照らし合わせて、アーキテクトが最新の認証リストを確認してください。

導入前に計画すべきこと

AHEPにはコンテナ化サービスレイヤーとValidation Serviceが必要で、いずれもKiteworksテクニカルサポートによって有効化されます。アラートはKiteworks WebアプリとOutlook Classicで動作します。他のクライアントも計画中ですが、本記事ではリリース時期は明記しません。標準フォーマットの氏名やfirstname.lastname@companyのようなビジネスアドレスで検知精度が最も高く、すべての個人アドレスが検知されるわけではありません。

実践的な第一歩

AHEPソリューションブリーフのアーキテクチャ図を、自社のセキュリティアーキテクトと一緒に確認してください。短時間のミーティングでデータフローの疑問を解消でき、パイロット予算を使う前に方向性を固められます。その後、ポリシーを「レポートのみ」で運用し、ユーザーにアラートを表示せずに検知状況を測定しましょう。

Kiteworksデータコントロールプレーンで機密データをローカル管理

ポスチャーツールは機密データの所在を示し、アクセスツールは誰がアクセスできるかを決定します。しかし、人やAIエージェントが次にどこへデータを送るかを選択する瞬間は保護できません。Kiteworksデータコントロールプレーンは、データが移動するその段階をカバーします。AHEPはData Policy Engineに組み込まれているため、ファイル共有、SFTP、MFT、フォームに適用するデータ認識型ポリシーの隣で宛先チェックが実行されます。バリデーションは自社インフラ内で完結し、改ざん防止の監査ログはSIEMツールへの連携も可能です。

既存のアーキテクチャを置き換えるのではなく、補完する形で導入できます。Validation Serviceの導入について自社アーキテクトと確認したい場合は、カスタムデモを予約いただければ、データフローを一つひとつご説明します。