レポート専用モードでのメール誤送信防止機能の展開

すべての送信者に適用されるコントロールを有効化する際は、誰にも不快感を与えない計画が必要です。警告が頻繁に表示されると無視されやすくなり、無視されるコントロールは誰も守れません。メールのエラー防止が成功するかどうかは、その導入方法にかかっています。

Kiteworks Agent and Human Error Prevention（AHEP）は、管理者に明確な導入方法を提供します。ポリシーは「レポートのみ」モードで運用でき、すべてのメッセージを評価・記録しつつ、アラートは一切表示されません。リスクはこの段階を飛ばすことであり、新しいポリシーはデフォルトで「オン」になり、保存と同時に強制適用されるため注意が必要です。

本記事では、プラットフォームの準備、ポリシー作成、ベースラインの確認、SuggestからWarnへの移行まで、順を追って展開方法を解説します。

エグゼクティブサマリー

合理的なAHEP導入は5つの段階を踏みます。まずプラットフォームの前提条件を確認し、ポリシーを「レポートのみ」ステータスで作成、数週間ベースラインを取得し、高リスクグループでSuggestをパイロット、その後データに基づき選択したポリシーをWarnへ移行します。既存のKiteworksユーザーは追加のベンダー不要で、AHEPは既存プラットフォームのData Policy Engineの機能です。結果として、自社メールに最適化されたポリシー群、アラートを実際に体験したパイロットグループ、セキュリティ・プライバシー責任者向けの監査証跡が得られます。

主なポイント

1. 設定前にプラットフォームの前提条件を確認。AHEPはリリース9.5と、Kiteworksテクニカルサポートが有効化するコンテナ化サービス層のValidation Serviceが必要です。
2. 保存前にステータスを「レポートのみ」に設定。新規ポリシーはデフォルトで「オン」となり即時適用されるため、安全策としてまずステータス欄から設定を始めましょう。
3. 「レポートのみ」でユーザー影響なしのベースライン取得。すべてのメッセージが評価・記録されるため、数週間のデータでリスクの所在が明らかになります。
4. まずSuggest、データが裏付ける場合のみWarn。Suggestは送信者に通知するだけで妨げず、Warnは十分な根拠が得られた段階で意識的な判断を求めます。
5. 部門への約束前にクライアント対応状況を把握。アラートはKiteworks WebアプリとOutlook Classicで動作するため、他クライアント利用者も考慮した計画を立てましょう。

AHEP導入のためのプラットフォーム準備

ポリシー作成前に、プラットフォームの準備が必要です。AHEPはリリース9.5以降で利用可能なため、旧バージョンの顧客はまずアップグレードが必要で、以降の計画もアップグレード時期に合わせて立てましょう。メッセージを評価するValidation Serviceは、Kiteworksのコンテナ化サービス層（RKE2）のアプリケーションノード上で稼働し、Kiteworksテクニカルサポートが有効化します。

リクエストの申請

設定作業前に、Kiteworksコミュニティポータルからリクエストを申請してください。サービスが有効化されていない状態でポリシーを作成しても機能せず、部門にパイロットを発表した後で気付くと大きな失態となります。

必要なロール

Data Policiesアプリでポリシーを作成するには、System、Application、Compliance、Policy Managerのいずれかのロール、またはData Policiesへのアクセス権を持つカスタムロールが必要です。プロジェクト責任者とポリシー作成権限者が異なる場合も多いため、早い段階で社内の担当者を確認しましょう。

ポリシー作成と「レポートのみ」からの開始

Data Policiesアプリで「新規ポリシー」を選択し、「Agent and Human Error Prevention」またはAHEPテンプレート（BCC推奨が事前選択済み）から開始します。保存前に必ずステータスを「レポートのみ」に変更してください（デフォルトは「オン」）。BCCポリシーの場合は、外部受信者のしきい値も同時に設定します。

ベースラインの確認

数週間ポリシーを稼働させましょう。すべてのメッセージが評価・記録され、送信者にはアラートが表示されません。ポリシーごとの検知数、誤検知、関与した送信者やチームを確認します。インシデントログや同期間のDLP検知とも比較しましょう。ベースラインにより、優先すべきポリシーや調整が必要なしきい値が明確になります。

時間を節約する2つのポイント

ユーザープロファイル名が「姓 名」や「名,姓」など標準フォーマットで統一され、ビジネスアドレスがfirstname.lastname@companyのような形式だと検知精度が向上します。特に個人アドレスポリシー（受信者と送信者の照合）で重要です。

SuggestからWarnへの移行

最も価値の高いポリシーを選び、パイロットグループでSuggest指示付きで「オン」にします。法務や財務部門は誤送信時の損失が大きいため、開始に適しています。Suggestは送信者に通知するだけで業務を妨げず、パイロットで現場の反応を確認できます。

Warnが有効なタイミング

Warnは送信前に送信者がアラートを解決または却下する必要があります。データが裏付ける場合にのみ、選択したポリシーをWarnへ移行しましょう。却下操作も記録されるため、却下率からしきい値や教育の見直しポイントが分かります。すべてのBCCアラートを却下する部門があれば、しきい値の再検討が必要です。

証拠をセキュリティ・プライバシー責任者へ提示

AHEPポリシーは、Audit Log and Reportsアプリの「Report by Policy」リストに表示されます。これにより、CISOやデータ保護責任者は、自社メールから得られた検知・指示・判断の記録を確認でき、ベンダーの推定値ではなく実データに基づく証跡が残ります。

Kiteworksデータ制御プレーン全体でのエラー防止有効化

AHEPの展開は、別ベンダーや専用コンソール・ログを必要とする独立したプロジェクトではありません。既存のKiteworksデータ制御プレーンの拡張です。Data Policy Engineはメール、ファイル共有、SFTP、MFT、フォームを統合管理し、AHEPは人やAIエージェントが送信先を選択するタイミングでデータ転送時の受信者チェックを追加します。イベントは改ざん防止の監査ログに記録され、SIEMツールへの連携も可能。既存のDLPやIAMツールとも補完し合います。

既存のKiteworksユーザーの方は、当社チームとの有効化セッションをご予約ください。9.5アップグレード、Validation Serviceリクエスト、「レポートのみ」ベースラインの計画を一緒に立て、最初のアラートが現場で最適化済みの状態になるようサポートします。