Symantec™ Data Loss Prevention MTA 統合ガイド (Network Prevent ( ))

(1)

Symantec™ Data Loss

Prevention MTA 統合ガイド

(Network Prevent (Email))

(2)

Symantec Data Loss Prevention MTA 統合ガイド

(Network Prevent for Email)

マニュアルバージョン: 15.5

法的通知と登録商標

Symantec、CloudSOC、Blue Coat、Symantec ロゴ、Checkmark ロゴ、Blue Coat ロゴ、および Shield ロゴは、 Symantec Corporation または関連会社の米国およびその他の国における商標または登録商標です。その他の会社名、製品名は各社の商標または登録商標です。このシマンテック製品には、サードパーティ (「サードパーティプログラム」) の所有物であることを示す必要があるサードパーティソフトウェアが含まれている場合があります。サードパーティプログラムの一部は、オープンソースまたはフリーソフトウェアライセンスで提供されます。本ソフトウェアに含まれる本使用許諾契約は、オープンソースまたはフリーソフトウェアライセンスでお客様が有する権利または義務を変更しないものとします。サードパーティプログラムについて詳しくは、この文書のサードパーティの法的通知の付属資料、またはこのシマンテック製品に含まれる TRIP ReadMe ファイルを参照してください。本書に記載する製品は、使用、コピー、頒布、逆コンパイルおよびリバースエンジニアリングを制限するライセンスに基づいて頒布されています。Symantec Corporation および、該当する場合は、ライセンサーからの書面による許可なく本書を複製することはできません。

Symantec Corporation が提供する技術文書は Symantec Corporation の著作物であり、Symantec Corporation が保有するものです。保証の免責: 技術文書は現状有姿のままで提供され、Symantec Corporation はその正確性や使用について何ら保証いたしません。技術文書またはこれに記載される情報はお客様の責任にてご使用ください。本書には、技術的な誤りやその他不正確な点を含んでいる可能性があります。Symantec は事前の通知なく本書を変更する権利を留保します。

ライセンス対象ソフトウェアおよび資料は、FAR 12.212 の規定によって商業用コンピュータソフトウェアとみなされ、場合に応じて、FAR 52.227-19 「Commercial Computer Software - Restricted Rights」、DFARS 227.7202、 et seq.「Commercial Computer Software and Commercial Computer Software Documentation」、その後継規制の規定により制限された権利の対象となります (シマンテックによってオンプレミスまたはホストサービスのいずれで提供されたかにかかわらず)。米国政府によるライセンス対象ソフトウェアおよび資料の使用、修正、複製のリリース、実演、表示または開示は、本使用許諾契約の条項に従ってのみ行われるものとします。

(3)

Symantec Corporation 350 Ellis Street

Mountain View, CA 94043

(4)

シマンテック社のサポート

すべてのサポートサービスは、お客様のサポート契約およびその時点のエンタープライズテクニカルサポートポリシーに従って提供されます。

ナレッジベース記事と Symantec Connect

テクニカルサポートに問い合わせる前に、トラブルシューティングの記事、ハウツー記事、警告、製品マニュアルを提供するシマンテック社のオンラインナレッジベースで無料のコンテンツを検索できます。次の URL の検索ボックスに製品の名前を入力します。 https://support.symantec.com 次の URL で当社のブログやオンラインフォーラムにアクセスして、広範のトピックについて他のお客様、パートナー、シマンテック社の従業員と意見を交換できます。 https://www.symantec.com/connect

テクニカルサポートとエンタープライズカスタマーサポート

シマンテック社のサポートは、世界中で 24 時間年中無休のサポートセンターを展開しています。テクニカルサポートの主な役割は、製品の特徴や機能に関する問い合わせに対応することです。エンタープライズカスタマーサポートでは、ライセンスのアクティブ化、ソフトウェアバージョンのアップグレード、製品の使用、更新など、技術以外の質問に対処しています。シマンテック社のサポートの利用規約、ポリシー、その他のサポート情報については以下を参照してください。 https://entced.symantec.com/default/ent/supportref シマンテック社のサポートに問い合わせるには、以下を参照してください。 https://support.symantec.com/en_US/contact-support.html

(5)

シマンテック社のサポート

... 4

第 1 章

概要

... 7

Network Prevent for Email Server について ... 7

Network Prevent for Email Server の動作モード ... 8

ホスト型の Network Prevent の配備について ... 8

Network Prevent for Email の環境の互換性と必要条件 ... 9

統合アーキテクチャの選択について ... 9

第 2 章

Network Prevent for Email Server 応答ルール

... 11

Network Prevent for Email 応答ルールについて ... 11

メッセージの遮断について ... 11

メッセージのリダイレクトについて ... 12

下位のメッセージのタグ付けについて ... 12

第 3 章

MTA 統合アーキテクチャ

... 14

統合アーキテクチャについて ... 14

Network Prevent for Email Server のメッセージチェーンについて ... 15

反射モードの統合アーキテクチャ ... 17 2 番目の SMTP リスナーベースのルーティングについて ... 18 SMTP クライアントの IP アドレスベースのルーティングについて ... 19 HELO 識別文字列ベースのルーティングについて ... 21 メッセージヘッダーベースのルーティングについて ... 23 転送モードの統合アーキテクチャについて ... 24 次ホップの MTA の選択について ... 25 TLS 認証について ... 26 TLS のキーと証明書の設定 ... 27

Network Prevent for Email Server キーストアパスワードの変更 ... 29

Network Prevent for Email Server のキーの生成 ... 31

Network Prevent for Email Server の公開キー証明書のエクスポート ... 32

Network Prevent for Email Server キーストアへの公開キー証明書のインポート ... 33

(6)

Network Prevent for Email サーバーを反射モードまたは転送モード用に設定する ... 34 制限付きポートからトラフィックを再ルーティングするための Linux IP テーブルの設定 ... 39

第 4 章

容量と耐障害性

... 41 容量と耐障害性について ... 41 容量管理と耐障害性の実装について ... 41 容量管理について ... 42 MX ベースのクラスタについて ... 42 IP ロードバランサーベースのクラスタについて ... 43 耐障害性の計画について ... 46 MX ベースのバイパスについて ... 46 MTA ベースのキュー管理について ... 46

第 5 章

統合のテスト

... 48

Network Prevent for Email Server 統合テストについて ... 48

機能テストについて ... 48 基本的なフェールオーバーテストについて ... 49

付録 A

電子メールメッセージシステム

... 50 ストアアンドフォワードの電子メールシステムについて ... 50 DNS システムについて ... 51

付録 B

MTA 統合のチェックリスト

... 52 MTA 統合のチェックリストについて ... 52

Network Prevent for Email Server 統合の前提条件を満たす ... 52

統合アーキテクチャの選択 ... 53

メッセージストリームコンポーネントの容量の評価 ... 54

Network Prevent for Email と MTA の統合 ... 54

索引

... 56

6 目次

(7)

概要

この章では以下の項目について説明しています。 ■ Network Prevent for Email Server について

■ Network Prevent for Email の環境の互換性と必要条件 ■ 統合アーキテクチャの選択について

Network Prevent for Email Server について

Network Prevent for Email Server は、電子メールメッセージを分析し、ポリシーに応じてそれらを遮断または修正する検出サーバーです。ネットワーク内の 1 つ以上のメール転送エージェント (MTA) から電子メールメッセージを受信できます。

Network Prevent for Email Server は、SMTP エラーレスポンスのリレー、SMTP コマンド動詞

EHLO、次の SMTP 拡張をサポートします。 ■ 8BITMIME ■ VRFY ■ DSN ■ HELP ■ PIPELINING ■ SIZE ■ ENHANCEDSTATUSCODES ■ STARTTLS

Network Prevent for Email Server はローカルにメッセージを格納しないため、MTA ではありません。Network Prevent for Email Server がメッセージを保持する唯一のメッセージハンドラとなることはありません。インバウンドの SMTP メッセージの各トランザクションが保持されるのは、アウトバウンドのトランザクションが閉じられるまでに限られます。

(8)

Network Prevent for Email Server は TLS 暗号化された電子メールを上位の MTA から受信できます。また、必要に応じてアウトバウンド MTA、ホストされた電子メールサービス、または反射モードの MTA の TLS セッションを開始できます。

p.14 の「統合アーキテクチャについて」を参照してください。 p.26 の「TLS 認証について」を参照してください。

メモ: SMTP のアウトバウンドメッセージストリームにのみ Network Prevent for Email Server を実装する必要があります。

Network Prevent for Email Server の動作モード

次のいずれかのモードで動作するように Network Prevent for Email Server を設定できます。 ■ 反射モード

反射モードでは、Network Prevent for Email Server はメッセージを MTA から受信、分析した後で、同じ MTA にそのメッセージを送信します。

■ 転送モード

転送モードでは、Network Prevent for Email Server は上位の MTA からメッセージを受信し、それらを分析して、下位の MTA に送信します。また、MessageLabs 電子メールコンテンツ制御サービスなど、ホストされた電子メールサービスにメッセージを送信することもできます。

いずれかのモードの設定については、『Symantec Data Loss Prevention 管理者ガイド』の「Network Prevent for Email サーバーの設定」を参照してください。

p.34 の「Network Prevent for Email サーバーを反射モードまたは転送モード用に設定する」を参照してください。

ホスト型の Network Prevent の配備について

Symantec Data Loss Prevention はホストされているサービスプロバイダネットワークでの、または Wide Area Network (WAN) をまたがる通信を必要とするネットワーク上の場所での、1 つ以上の Network Prevent 検出サーバーの配備をサポートします。サービスプロバイダのメールサーバーか Web プロキシを使う場合、ホスト環境に Network Prevent Server を配備する場合があります。このように、Network Prevent Server をリモートプロキシと簡単に統合し、電子メールか HTTP 送信経由の機密データの漏えいを防ぐことができます。

Enforce Server と検出サーバーを Amazon Web Services のインフラに配備できます。詳しくは、 https://support.symantec.com/en_US/article.DOC9520.html を参照してください。

検出サーバーをインストールすることを選択すると、Symantec Data Loss Prevention のインストールプログラムはホスト環境に Network Prevent をインストールするかどうか尋ねます。

ホスト環境に Network Prevent 検出サーバーをインストールすることを選択した場合、内部の (企業) 検出サーバーとホスト型検出サーバーの両方で使うための、ユーザーによって生成される複数の証

8 第 1 章概要 Network Prevent for Email Server について

(9)

明書を sslkeytool ユーティリティを使って作成してください。これはホスト型 Network Prevent

Server や、インストールされる他のすべての検出サーバーへの Enforce Server からの安全な通信を保証します。ホスト型 Network Prevent 検出サーバーを配備する場合、組み込みの Symantec Data Loss Prevention 証明書を使うことはできません。

『Symantec Data Loss Prevention インストールガイド』に、ホスト環境またはホスト以外 (WAN) の環境で Network Prevent Server をインストールし設定する方法が記載されています。

Network Prevent for Email の環境の互換性と必要条

件

Network Prevent for Email Server は、SMTP 準拠の他社製エンタープライズ MTA およびホストされた電子メールサービスと互換性があります。特定のサポートの質問については、MTA ベンダーかホストされた電子メールサービスに問い合わせます。

Network Prevent for Email Server は次の条件を満たす MTA かホストされた電子メールサービスと統合できます。

■ MTA またはホストされた電子メールサービスは厳密に SMTP 準拠であることが必要です。コマンド動詞の HELO (または EHLO)、RCPT TO、MAIL FROM、QUIT、NOOP、DATA のみを使ってメールを送受信できる必要があります。

■ 反映モードで Network Prevent for Email Server を実行している場合、上位の MTA はメッセージごとに 1 回のみ Network Prevent for Email Server にメッセージをルーティングできる必要があります。

内部のメールインフラから Network Prevent for Email Server にアウトバウンドメッセージをルーティングする SMTP 対応 MTA を使うことができます。また、反射モードの互換性のために、MTA は Network Prevent for Email Server から返されるメッセージを本来の受信者にルーティングできる必要があります。

Network Prevent for Email Server は上位の MTA が STARTTLS コマンドを発行するときのみ下位の MTA との TLS 接続を開始するように試みます。下位 MTA またはホストされた電子メールサービスで TLS を使用している場合にのみ TLS で接続できます。Network Prevent for Email Server でこのサーバー自体を認証する必要もあります。認証が成功するには、適切なキーと X509 証明書が、プロキシされるメッセージ連鎖の各メールサーバーで利用可能であることが必要です。 p.26 の「TLS 認証について」を参照してください。

統合アーキテクチャの選択について

このマニュアルでは、Network Prevent for Email Server に対して提案されているいくつかの統合アーキテクチャについて説明します。

p.14 の「統合アーキテクチャについて」を参照してください。

9 第 1 章概要 Network Prevent for Email の環境の互換性と必要条件

(10)

実装するアーキテクチャは、既存のメッセージアーキテクチャ、MTA の機能、組織のメッセージ要件によって異なります。環境にとって最善のソリューションを特定するために、メッセージチームと密接に連携します。環境にとって最善のソリューションには、シマンテック社が提案する以外の統合アーキテクチャが必要な場合もあります。 10 第 1 章概要統合アーキテクチャの選択について

(11)

Network Prevent for Email

Server 応答ルール

この章では以下の項目について説明しています。 ■ Network Prevent for Email 応答ルールについて

■ メッセージの遮断について ■ メッセージのリダイレクトについて ■ 下位のメッセージのタグ付けについて

Network Prevent for Email 応答ルールについて

この章では、Network Prevent for Email Server の動作と機能について説明します。メッセージの遮断とリダイレクト、およびメッセージヘッダーのタグ付けについて説明します。

Network Prevent for Email Server は、アウトバウンドの電子メールトラフィックをインラインで監視して分析し、必要に応じてポリシーで指定されているように電子メールメッセージを遮断、リダイレクト、修正します。Enforce Server 管理コンソールで Network Prevent for Email Server のポリシーを作成します。ポリシー作成者は、ポリシーごとに、防止 (インライン管理) ポリシーまたは監視ポリシーを設定できます。

応答ルールとポリシーの作成について詳しくは『Symantec Data Loss Prevention 管理者ガイド』を参照してください。

メッセージの遮断について

ポリシーに違反するメッセージの配信を遮断するように Network Prevent for Email Server を設定できます。Network Prevent for Email Server はエラーレスポンスコード SMTP 5xx を戻してメッセージを遮断します。

(12)

メッセージが遮断されたときに、カスタマイズされた未配信レポートをメッセージの送信者に送り返すようにも指定できます。未配信レポートを使うには、Enforce Server 管理コンソールで［SMTP メッセージの遮断］応答ルールを作成します。未配信レポート (バウンスされたメッセージ) は応答ルールで指定するテキストを含みます。MTA はメッセージが遮断された時点でレポートを生成します。 MTA で生成された未配信レポートは、別の種類の応答ルールとして設定できる送信者通知とは異なります。Enforce Server は送信者通知を生成します。Network Prevent for Email Server と Enforce Server 間の接続が正常な場合、送信者通知メッセージは数秒で生成されます。ただし、 Network Prevent for Email Server と Enforce Server 間の接続が割り込まれると、接続が復元されるまで送信者通知メッセージは生成されません。

Enforce Server 管理コンソールの［応答ルールの設定］画面で、電子メールメッセージの遮断と Enforce Server によって生成される送信者通知の処理を設定できます。次に、該当するポリシーに応答ルールを含めることができます。

応答ルールとポリシーについて詳しくは『Symantec Data Loss Prevention 管理者ガイド』を参照してください。

メッセージのリダイレクトについて

ポリシーに違反するメッセージは、［SMTP メッセージの遮断］応答ルールで設定するアドレスにリダイレクトできます。このアドレスは、通常、メッセージを確認してから送信するために管理者やマネージャが使うメールボックスまたはリストです。このようなメールボックスは、Symantec Data Loss Prevention システムの外部にあります。この機能が正しく機能するには、Network Prevent と統合された各 MTA またはホストされた電子メールサービスで、すべてのリダイレクトアドレスを送信者の例外として個々に設定する必要があります。

ポリシーのリダイレクトアドレスと、Network Prevent と統合された MTA またはホストされた電子メールサービスで設定する送信者の例外アドレスの同期は維持してください。［SMTP メッセージの遮断］応答ルールでメッセージのリダイレクトを有効にし、設定するには、Enforce Server 管理コンソールの［応答ルールの設定］ページの［メッセージのリダイレクト先アドレス］フィールドにアドレスを入力します。

下位のメッセージのタグ付けについて

ゲートウェイベースのメッセージの暗号化システムは、メッセージの件名のキーワードに基づいて指定した処理が実行されるように設定できます。特定の RFC 5322 メッセージヘッダーは、同じ目的のために使うことができます。通常、「X-」で始まる拡張ヘッダーに基づき処理を指定します。次のいずれか、またはすべての方法でメッセージを修正するようにポリシーを設定できます。 ■ 件名の先頭を置き換えるか、追記、変更します。

■ Network Prevent と統合された MTA またはホストされた電子メールサービスで追加の処理をトリガできる新しいヘッダーを生成します。処理には、メッセージの暗号化、メッセージの隔離、メッセージのアーカイブ、その他の処理が含まれることがあります。

12 第 2 章 Network Prevent for Email Server 応答ルール

(13)

MTA またはホストされた電子メールサービスがヘッダーを解釈してメッセージのルーティングルールを処理できれば、違反が検出されたときに実行する追加の処理を設定できます。Enforce Server の［応答ルールの設定］画面で［SMTP メッセージの修正］の応答ルールを作成します。RFC 5322 のヘッダー行を最大 3 つ追加できます。スキャン判定に応じて、異なる値の -Cfilter ヘッダーを使うことを推奨します。件名のヘッダーを変更または置き換えることもできます。表 2-1 は、これらのヘッダーに共通のアプリケーションの一部を示します。表 2-1 Network Prevent for Email Server で追加されるヘッダーの例

説明ヘッダーの例包括的にメッセージを暗号化するように要求します。 X-CFilter: Encrypt メッセージの隔離を要求します。 X-CFilter: Quarantine メッセージのアーカイブを要求します。 X-CFilter: Archive

メッセージの暗号化システムの設定と、関連する Symantec Data Loss Prevention ポリシーの詳細が同期されているようにしてください。

［応答ルールの設定］画面で［SMTP メッセージの修正］の応答ルールを作成することによって、下位での暗号化のためのメッセージのタグ付けを有効にし、設定することができます。その後、このルールを使って、インシデントの適切な修復ワークフローをポリシーごとに設定することができます。

13 第 2 章 Network Prevent for Email Server 応答ルール

(14)

MTA 統合アーキテクチャ

この章では以下の項目について説明しています。

■ 統合アーキテクチャについて

■ Network Prevent for Email Server のメッセージチェーンについて ■ 反射モードの統合アーキテクチャ

■ 転送モードの統合アーキテクチャについて ■ TLS 認証について

■ Network Prevent for Email サーバーを反射モードまたは転送モード用に設定する

統合アーキテクチャについて

この章では、Network Prevent for Email Server をメッセージ連鎖に統合する方法と、その統合を達成するための複数のアーキテクチャについて説明します。

次のいずれかのモードで動作するように Network Prevent for Email Server を設定できます。 ■ 反射モード

反射モードでは、Network Prevent for Email Server は、RFC 5321 準拠の SMTP プロキシとして機能します。MTA からメッセージを受信して分析し、同じ MTA にそのメッセージを送り返します。Network Prevent for Email Server は、ポリシーが必要とする場合、メッセージを遮断または修正します。

■ 転送モード

転送モードでは、Network Prevent for Email Server は上位の MTA からメッセージを受信する RFC 5321 準拠の SMTP プロキシとして機能します。メッセージを分析し、次に、元の MTA にそれらのメッセージを送信するかわりに、下位の MTA または MessageLabs 電子メールコンテンツ制御サービスのようなホストされた電子メールサービスにそれらのメッセージを送信します。サーバーが SMTP エラーレスポンスのリレーと DNS の SMTP 拡張をサポートするため、メッセージの状態を 2つの MTA 間のプロキシとしてリレーできます。

3

(15)

Network Prevent for Email Server がサーバー設定で指定した特定の IP アドレスまたはホスト名にメッセージをプロキシ処理するよう設定できます。または、設定で指定したホスト名の MX レコードのルックアップを実行するように Network Prevent for Email Server を設定できます。MX レコードのルックアップを実行することで、Network Prevent for Email Server はネクストホップの MTA またはホストされたメールサーバーを選択するときに、DNS の負荷分散とフェールオーバーの機能を使うことができます。

Network Prevent for Email Server のメッセージチェー

ンについて

Network Prevent for Email Server は、組織のメッセージ連鎖に統合されることによって機能します。図 3-1 は、Network Prevent for Email Server がメッセージ連鎖において反射モードで動作する実装例を示します。

図 3-1 反射モードの Network Prevent for Email Server の動作

1 2 3 4 MTA または SMTP サーバー次ホップまたはバイパスの MTA 前ホップの MSA SMTP Prevent 追加のインライン MTA 統合 5 次の図は、検出サーバーがメッセージチェーン内で転送モードで動作する実装を示します。 15 第 3 章 MTA 統合アーキテクチャ Network Prevent for Email Server のメッセージチェーンについて

(16)

図 3-2 転送モードの Network Prevent for Email Server の動作 1 2 ₃ ₄ 上位の MTA または SMTP サーバー次ホップの MTA 前ホップの MSA または MTA Network Prevent Server 下位の MTA または SMTP サーバー 5 追加のインライン MTA (任意) 次のリストでは、図 3-1 と図 3-2 のメッセージ連鎖について説明します。

■ メッセージサブミッションエージェント (MSA) または MTA は、Network Prevent と統合された MTA または上位の MTA に SMTP メッセージを送信します。

■ セットアップによって、次のいずれかが発生します。Network Prevent と統合された MTA は、 Network Prevent for Email Server からのメッセージではないと判断すると、このサーバーにメッセージをルーティングします。または、上位の MTA が Network Prevent for Email Server にメッセージをルーティングします。

Network Prevent for Email Server が SMTP メッセージを受信すると、Symantec Data Loss Prevention ポリシーに照らしてメッセージが分析されます。

Network Prevent for Email Server は、メッセージを転送し転送セッションを終了するまで SMTP セッションを終了しません。

■ Network Prevent for Email Server は、ポリシーと応答ルールに基づいて、表 3-1 に示すいずれかの方法でメッセージを処理します。

■ 必要に応じて、Network Prevent と統合された MTA または下位の MTA は、追加の処理 (暗号化など) のために他のインライン MTA に SMTP メッセージを送信することができます。SMTP メッセージは MTA に戻されます。

Network Prevent for Email Server がメッセージの暗号化をトリガするには、Network Prevent と統合された MTA または下位の MTA は、メッセージ自体を暗号化できるか、暗号化を行うインライン MTA にメッセージをルーティングできる必要があります。Network Prevent と統合された MTA または下位の MTA は、適切な処理の判断にヘッダー情報を使うことができる必要があります。

■ Network Prevent と統合された MTA、下位の MTA またはホストされた電子メールサービスプロバイダは、次ホップの MTA に、または選択した電子メールサーバーにインターネットを介して、 SMTP メッセージを送信します。

表 3-1 は、レスポンスがトリガされる方法と、メッセージが処理される方法のアウトラインを示します。

16 第 3 章 MTA 統合アーキテクチャ Network Prevent for Email Server のメッセージチェーンについて

(17)

表 3-1 メッセージの処理

メッセージの処理設定されているレスポンス

トリガ

Symantec Data Loss Prevention は、Network Prevent と統合された MTA、下位の MTA またはホストされた電子メールサービスに (変更されていない) メッセージを送り返します。

なしメッセージがポリシーに違反しない

このルールは、Network Prevent と統合された MTA または上位の MTA に 550 SMTP メッセージを戻してメッセージを遮断します。エラーの理由または連絡先のアドレスが 550 レスポンステキストに含まれるように設定できます。エンベロープ受信者を置き換えるように Symantec Data Loss Prevention を設定することもできます。 SMTP メッセージの遮断メッセージがポリシーに違反するこのルールによって、メッセージの件名を自動的に修正または置き換えて、メッセージに 3 つの SMTP ヘッダーを追加することができます。修正された件名と追加の SMTP ヘッダーによって、下位の処理がトリガされます。修正されたメッセージの件名によって、メッセージがよりユーザーフレンドリになります。 p.12 の「下位のメッセージのタグ付けについて」を参照してください。 SMTP メッセージの修正メッセージがポリシーに違反するこのルールによって、メッセージの受信者のリストと元の送信者にインシデントの電子メール通知を自動的に送信できます。電子メール通知の送信メッセージがポリシーに違反する

反射モードの統合アーキテクチャ

反射モードで動作する Network Prevent for Email Server に対応する統合アーキテクチャの 4 つオプションは、次のとおりです。 ■ 2 番目の SMTP リスナーベースのルーティング p.18 の「2 番目の SMTP リスナーベースのルーティングについて」を参照してください。 ■ SMTP クライアントの IP アドレスベースのルーティング p.19 の「SMTP クライアントの IP アドレスベースのルーティングについて」を参照してください。 ■ HELO 識別文字列ベースのルーティング p.21 の「HELO 識別文字列ベースのルーティングについて」を参照してください。 ■ メッセージヘッダーベースのルーティング p.23 の「メッセージヘッダーベースのルーティングについて」を参照してください。 17 第 3 章 MTA 統合アーキテクチャ反射モードの統合アーキテクチャ

(18)

このリストでは、安全性が最も高いオプションから順番に示されています。MTA の機能と一致し、リストの上位にある統合アーキテクチャを選択する必要があります。これらの統合アーキテクチャの中にメッセージストリームに適合するものがない場合は、その他の方法を使用できる可能性があります。統合の別の可能性を検討するために社内のメッセージグループと MTA ベンダーに連絡します。メモ: Network Prevent と統合された MTA によって自動的に生成されるアウトバウンドメッセージが Network Prevent for Email Server をバイパスするように設定することを推奨します。

次のセクションでは、統合の各オプションについて詳しく説明します。

2 番目の SMTP リスナーベースのルーティングについて

2 番目の SMTP リスナーベースのルーティングを実装するには、2 つの TCP ポートのうちどちらがメッセージを受信したかに基づいて SMTP メッセージの処理方法とルーティング方法を判断するように、Network Prevent と統合された MTA を設定します。

Network Prevent for Email Server をバイパスするために必要な基準をメッセージが満たさない場合に、Network Prevent と統合された MTA から受信した SMTP メッセージを Network Prevent for Email Server にルーティングするように、1 つの SMTP リスナー (TCP ポート 25) を設定します。 Network Prevent for Email Server からの SMTP セッションのみを待機するように、2 番目の SMTP リスナー (TCP ポート 10026) を設定します。SMTP Prevent のリスナーで受信されたメッセージは、メッセージチェーン内でさらに転送されます。2 番目の SMTP リスナーベースのルーティングは最も安全な統合アーキテクチャです。図 3-3 は、SMTP リスナーポートベースのルーティングを示します。 18 第 3 章 MTA 統合アーキテクチャ反射モードの統合アーキテクチャ

(19)

図 3-3 2 番目の SMTP リスナーポートベースのルーティング MTA 次ホップまたはバイパスの MTA Network Prevent Server TCP ポート 25 の SMTP リスナー SMTP クライアントの処理 SMTP クライアントの処理 Symantec DLP の処理前ホップのMTA 1 2 3 4 TCP ポート 10026 (25 以外) の SMTP リスナー TCP ポート 10025 の SMTP リスナー SMTP リスナーポートベースのルーティングについての詳細は次のとおりです。

■ Network Prevent と統合された MTA の SMTP リスナーは、ポート 25 でメッセージを受信します。

■ Network Prevent と統合された MTA の SMTP 送信者は、TCP ポート 10025 の Network Prevent for Email Server SMTP リスナーに検査のためにメッセージをルーティングします。(TCP ポート 10025 はデフォルトのポート番号です。この値は変更できます。)

■ Network Prevent for Email Server はメッセージを検査します。関連するポリシーに基づいてメッセージを遮断しない場合、サーバーは TCP ポート 10026 の Network Prevent と統合された MTA にメッセージを送信します。(メッセージはデフォルトで TCP ポート 10026 に返信されますが、25 以外の任意のポートでメッセージを受信するように設定できます。)

■ Network Prevent と統合された MTA の SMTP リスナーは、ポート 10026 でメッセージを受信します。また、TCP のポート番号に基づいて、有効な Network Prevent for Email Server からのメッセージであると判断します。メッセージストリームのアーキテクチャと Network Prevent for Email Server が修正するヘッダーは、メッセージ配信の次ホップを決定します。

SMTP クライアントの IP アドレスベースのルーティングについて

SMTP クライアントの IP アドレスベースのルーティングを実装するには、前ホップの IP アドレスに基づいて SMTP メッセージの処理方法とルーティング方法を判断するように、Network Prevent と統合された MTA を設定します。 19 第 3 章 MTA 統合アーキテクチャ反射モードの統合アーキテクチャ

(20)

SMTP クライアントの IP アドレスベースのルーティングは、IP アドレスが信頼性の高いソースから入手される限り安全です。実際の IP アドレスを取得する最も確実な方法は、TCP 接続情報から直接入手することです。偽造される可能性があるヘッダー情報から IP アドレスを抽出する方法は、信頼できません。たとえば、SMTP リスナーがメッセージに配置した受信ヘッダーを読み取るなど、別の方法を使う場合、SMTP クライアントの IP アドレスベースのルーティングの統合アーキテクチャの安全性は、SMTP リスナーが IP アドレスを確かめる能力と同程度です。図 3-4 は、SMTP クライアントの IP ベースのルーティングを示します。図 3-4 SMTP クライアントの IP アドレスベースのルーティング次ホップまたはバイパスの MTA Network Prevent Server TCP ポート 25 の SMTP リスナー SMTP クライアントの処理 SMTP クライアントの処理 TCP ポート 10025 の SMTP リスナー SMTP クライアントの処理 Symantec DLP の処理前ホップのMTA 1 2 3 4 IP アドレスから送信されたか？はいいいえ MTA SMTP クライアントの IP ベースのルーティングについて詳しくは次のとおりです。

■ Network Prevent と統合された MTA は、送信者の IP アドレスを判断するためにメッセージを診断します。送信者の IP アドレスが、Network Prevent と統合された MTA の Network Prevent for Email Server IP アドレスの配信リストにある IP と一致しない場合、Network Prevent と統合された MTA は、TCP ポート 10025 の Network Prevent for Email Server SMTP リスナーに検査のためにメッセージをルーティングします。(TCP ポート 10025 はデフォルトのポート番号です。この値は変更できます。)

20 第 3 章 MTA 統合アーキテクチャ反射モードの統合アーキテクチャ

(21)

■ Network Prevent for Email Server がメッセージを検査し、サーバーが関連するポリシーに基づいてそのメッセージを遮断しない場合は、TCP ポート 25 の Network Prevent と統合された MTA にメッセージが送信されます。

■ Network Prevent と統合された MTA は、有効な Network Prevent for Email Server からのメッセージかどうかを IP アドレスに基づいて判断します。Network Prevent for Email Server SMTP クライアントの IP アドレスを、Network Prevent と統合された MTA の SMTP クライアントの IP アドレスリストと照合します。送信者の IP アドレスが、Network Prevent と統合された MTA の Network Prevent for Email Server IP アドレスリストの IP と一致する場合、Network Prevent と統合された MTA は、該当する次ホップに基づいてメッセージを処理します。メッセージストリームのアーキテクチャと Network Prevent for Email Server が修正するヘッダーは、メッセージ配信の次ホップを決定します。

HELO 識別文字列ベースのルーティングについて

HELO 識別文字列ベースのルーティングの統合アーキテクチャを実装するには、HELO 識別文字列に基づいて SMTP メッセージの処理方法を判断するように、Network Prevent と統合された MTA を設定します。

HELO 識別文字列に基づいて次ホップを判断することは、Network Prevent for Email Server をメッセージストリームに統合する比較的安全な方法です。電子メールクライアントの HELO レスポンスを変更することは困難ですが、IP アドレスの使用を強制する方法は、より安全です。図 3-5 は、HELO 識別文字列ベースのルーティングを示します。 21 第 3 章 MTA 統合アーキテクチャ反射モードの統合アーキテクチャ

(22)

図 3-5 HELO 識別文字列ベースのルーティング次ホップの MTA Network Prevent Server TCP ポート 25 の SMTP リスナー SMTP の処理 SMTP の処理 TCP ポート 10025 の SMTP リスナー SMTP の処理 Symantec DLP の処理前ホップのMTA 1 2 3 4 Prevent の HELO 識別文字列と一致するか？はいいいえ MTA HELO 識別文字列ベースのルーティングについて詳しくは次のとおりです。

■ Network Prevent と統合された MTA の SMTP リスナーはポート 25 でメッセージを受信し、 Network Prevent と統合された MTA は HELO 識別文字列をキャプチャします。

■ Network Prevent と統合された MTA は、送信者の HELO 識別文字列を判断するためにメッセージを診断します。送信者の HELO 識別文字列が、Network Prevent と統合された MTA の Network Prevent for Email Server HELO 識別文字列のリストにある HELO 識別文字列と一致しない場合、Network Prevent と統合された MTA は、TCP ポート 10025 の Network Prevent for Email Server SMTP リスナーに検査のためにメッセージをルーティングします。(TCP ポート 10025 はデフォルトのポート番号です。この値は変更できます。)

■ Network Prevent for Email Server がメッセージを検査し、サーバーが関連するポリシーに基づいてメッセージを遮断しない場合は、TCP ポート 25 の Network Prevent と統合された MTA にメッセージが送信されます。

■ Network Prevent と統合された MTA は、送信者の HELO 識別文字列を判断するためにメッセージを診断します。送信者の HELO 識別文字列が、Network Prevent と統合された MTA の Network Prevent for Email Server HELO 識別文字列のリストの HELO 識別文字列に一致する場合、Network Prevent と統合された MTA は、該当する次ホップに基づいてメッセージを処理します。メッセージストリームのアーキテクチャと Network Prevent for Email Server が修正するヘッダーは、メッセージ配信の次ホップを決定します。

(23)

メッセージヘッダーベースのルーティングについて

メッセージヘッダーベースのルーティングの統合アーキテクチャを実装するには、通知メッセージヘッダーの存在に基づいて SMTP メッセージの処理方法を判断するように、Network Prevent と統合された MTA を設定します。 MTA がメッセージヘッダーを使ってメッセージの次ホップを判断する場合、ユーザーは一般的なメールユーザーエージェント (MUA) を使って簡単に検出を回避できます。この方法は完全に機能する統合を提供しますが、別の統合方法が利用可能な場合は、その方法を選択することを推奨します。図 3-6 に、メッセージヘッダーベースのルーティングを示します。図 3-6 メッセージヘッダーベースのルーティング次ホップの MTA Network Prevent Server TCP ポート 25 の SMTP リスナー SMTP の処理 SMTP の処理 TCP ポート 10025 の SMTP リスナー SMTP の処理 Symantec DLP の処理次ホップの MTA 1 2 3 4 Prevent のメッセージヘッダーが存在するか？はいいいえ MTA メッセージヘッダーベースのルーティングについて詳しくは次のとおりです。

■ Network Prevent と統合された MTA はメッセージヘッダーを診断します。MTA は、Network Prevent for Email Server によって挿入されたヘッダーを見つけなければ、TCP ポート 10025 の Network Prevent for Email Server SMTP リスナーに検査のためにメッセージをルーティングします。(TCP ポート 10025 はデフォルトのポート番号です。この値は変更できます。)

(24)

■ Network Prevent for Email Server がメッセージを検査し、サーバーが関連するポリシーに基づいてメッセージを遮断しない場合は、ヘッダーを挿入し、TCP ポート 25 の Network Prevent と統合された MTA にメッセージが送信されます。

■ Network Prevent と統合された MTA は、Network Prevent for Email Server のヘッダーが存在するかどうかを判断するためにメッセージを診断します。ヘッダーが存在する場合、Network Prevent と統合された MTA は、該当する次ホップに基づいてメッセージを処理します。Network Prevent for Email Server がメッセージにヘッダーを追加した場合、Network Prevent と統合された MTA は、異なるルーティングを使用することがあります。メッセージストリームのアーキテクチャと Network Prevent for Email Server が修正するヘッダーは、メッセージ配信の次のホップを決定します。

転送モードの統合アーキテクチャについて

転送モードでは、Network Prevent for Email Server は、上位の MTA と下位の MTA またはホストされた電子メールサービスプロバイダとの間の SMTP プロキシとして動作します。Network Prevent for Email Server は、下位のホストから上位の MTA にレスポンスをリレーします。Network Prevent for Email Server が転送モードで動作するように設定するには、Network Prevent for Email Server の［サーバーの設定］ページの［インライン SMTP］セクションで［転送］オプションを選択し、次の MTA フィールドを設定する必要があります。

p.34 の「Network Prevent for Email サーバーを反射モードまたは転送モード用に設定する」を参照してください。

図 3-7 に、転送モードの Network Prevent for Email Server を示します。

24 第 3 章 MTA 統合アーキテクチャ転送モードの統合アーキテクチャについて

(25)

図 3-7 転送モードで動作する Network Prevent for Email Server のアーキテクチャ前のホップ次のホップ上位の MTA SMTP リスナー SMTP クライアント処理下位の MTA SMTP リスナー（ポート 25） SMTP クライアント処理

Network Prevent （Email）サーバー SMTP リスナー（ポート 25） SMTP クライアント処理 Symantec DLP Processing 1 2 3 4

転送モードで動作する Network Prevent for Email Server について詳しくは次のとおりです。 ■ 上位の MTA の SMTP リスナーはメッセージを受信します。

■ 上位の MTA は TCP ポート 25 の Network Prevent for Email Server SMTP リスナーにメッセージをルーティングします。(デフォルトでは、設定された TCP ポート番号は 10025 ですが、このポートを 25 に変更することをお勧めします。)

■ Network Prevent for Email Server はメッセージを検査します。設定されたポリシーに基づいてメッセージを遮断しない場合、サーバーは下位の MTA またはホストされた電子メールサーバーにメッセージをプロキシ処理します。メッセージチェーン内のこのネクストホップのIP アドレスは、 Network Prevent for Email Server の設定で指定することができます。また、設定されたドメイン名の MX レコードのルックアップを介して取得することもできます。 ■ 下位の MTA またはホストされた電子メールサーバーは、ネクストホップの MTA によってホストされたメールサーバーに SMTP メッセージを送信します。ホストされた電子メールサービスで、受信 MTA にプロキシ処理する前に、メッセージのウイルス検出やメッセージ内容の暗号化などの追加のタスクが実行されることがあります。

次ホップの MTA の選択について

Network Prevent for Email Server は、検出の実行後にメッセージをプロキシ処理するときに、次ホップのサーバーを決定するためにメールサーバーアドレスの設定済みリストを使います。Network Prevent for Email Server は、設定されているメールサーバーアドレス (DNS 名または IP アドレス) を使うか、設定済みドメインに対して MX レコードのルックアップを実行できます。

25 第 3 章 MTA 統合アーキテクチャ転送モードの統合アーキテクチャについて

(26)

MX レコードのルックアップが無効な場合には Network Prevent for Email Server はリストで最初に設定されているメールサーバーアドレスにメッセージの転送を試みます。そのメールサーバーへの接続を確立できなければ、リストにある順序で以降のサーバーアドレスを試みます。

MX レコードのルックアップを有効にすると、Network Prevent for Email Server は設定されたドメインのメール交換 (MX) レコードを入手するために DNS クエリーを実行します。Network Prevent for Email Server は、返された MX レコードを使って、プロキシの連鎖内の次ホップのメールサーバーを選択します。

MX レコードは特定のドメインのメールサーバーアドレスと MX 優先度番号を指定します。MX 優先度は同じドメインに返す複数の MX レコードに優先順位を割り当てます。Network Prevent for Email Server とすべての SMTP クライアントは MX 優先度と関連付けられた次のルールに従います。 ■ 番号の小さい MX 優先度があるメールサーバーは、番号の大きい MX 優先度があるサーバー

の前に使われます。

たとえば MX ルックアップを実行するように Network Prevent for Email Server を設定し、次ホップの MTA のリストに単一のアドレス emailcompanyname.com を入力したとします。Network Prevent

for Email Server は DNS ルックアップを実行し、次の MX レコードを受信します。

emailcompanyname.com 10 smtp1.emailcompanyname.com emailcompanyname.com 10 smtp2.emailcompanyname.com emailcompanyname.com 10 smtp3.emailcompanyname.com emailcompanyname.com 40 smtp4.emailcompanyname.com

この場合には Network Prevent for Email Server は次ホップの MTA として MX 優先度が 10 に割り当てられた 3 台のサーバー (smtp1、smtp2、smtp3) から最初のサーバーを選択します。DNS の rrset-order は、設定済みの負荷分散アルゴリズムに基づいて MX レコードの順序を決定します。通常、このアルゴリズムは循環的 (ラウンドロビン) です。最後のサーバー smtp4 は MX 優先度が 10 のサーバーを利用できない場合にのみ選択されます。次ホップのメールサーバーアドレスの有効なリストを設定するには、Enforce のコンソールを使います。

TLS 認証について

Network Prevent for Email Server は次の場合のみ下位の MTA で TLS を使います。 ■ 上位の MTA は STARTTLS コマンドを使って TLS 接続を要求します。

■ 下位の MTA またはホストされた電子メールサービスは TLS をサポートし、自身を認証できます。これらの状況は Network Prevent for Email が反射モードで動作する場合にも当てはまります。反射モードでは、単一の MTA が上位の MTA としても下位の MTA としても機能します。

TLS が要求されると、エンドツーエンドの TLS 接続を確立するために、電子メールチェーン内の連続する各プロキシは前のサーバーに対して自身を認証する必要があります。認証が成功するには、各メールサーバーがトラストストアに次ホップのメールサーバーの有効な証明書を格納している必要 26 第 3 章 MTA 統合アーキテクチャ TLS 認証について

(27)

があります。たとえば、Network Prevent for Email Server は送信 MTA に対して自身を認証し、下位の MTA またはホストされた電子メールサービスは Network Prevent for Email Server に対して自身を認証する必要があります。

メモ: 各 MTA が自身の認証セットアップを実行するため、電子メールチェーン内の MTA で証明書の検証を無視するように選択される可能性があります。この方法は実働の電子メール設定には推奨されません。

Network Prevent for Email Server が利用不能なときにこのサーバーをバイパスするように上位の MTA を設定する場合、上位の MTA は下位のメールサーバーの証明書と Network Prevent for Email Server の証明書を格納する必要があります。

TLS のキーと証明書の設定

転送モードの典型的な MTA の統合では、TLS をサポートするために、次のキーと証明書が必要になります。

■ 上位の MTA のキーストアは Network Prevent for Email Server の公開キー証明書を含む必要があります。このキーは、TLS セッションの一部として Network Prevent for Email を認証するように上位の MTA で判断した場合に必要になります。

■ Network Prevent for Email Server のキーストアには、自身の秘密キーと、下位の MTA またはホストされた電子メールサーバーの公開キー証明書が格納されている必要があります。 ■ Network Prevent for Email Server が利用不能なときにこのサーバーをバイパスするように上位

の MTA が設定されている場合、上位の MTA のトラストストアには、下位の MTA またはホストされた電子メールサービスの有効な証明書も格納されている必要があります。

反射モードの MTA の統合では、単一の MTA は上位の MTA としても下位の MTA としても機能します。反射モードの MTA は Network Prevent for Email Server の公開キー証明書を含む必要があります。Network Prevent for Email Server のキーストアには、自身の秘密キーと、統合された反射モードの MTA の公開キー証明書が格納されている必要があります。Network Prevent for Email Server が利用不能なときにこのサーバーをバイパスするように反射モードの MTA が設定されている場合、MTA のトラストストアには、下位の MTA またはホストされた電子メールサービスの有効な証明書も格納されている必要があります。

ホストされたメールサーバーは通常、ルート認証局 (CA) によってデジタル署名された公開キー証明書を使います。ホストされた電子メールサービスプロバイダから CA によって署名された公開キー証明書を入手し、転送モードの設定用に Network Prevent for Email Server のキーストアに追加する必要があります。反射モードの設定では、反射モードの MTA のキーストアにキーを追加します。 Network Prevent for Email のキーストアに追加するどの証明書も、証明書ファイル内で ---BEGIN CERTIFICATE--- と ---END CERTIFICATE--- 文字列で囲まれた、Private Enhanced

Mail (.pem) の Base64 でエンコードされた DER (Distinguished Encoding Rules) 証明書形式の

X.509 証明書である必要があります。

27 第 3 章 MTA 統合アーキテクチャ

(28)

表 3-2 に、必要なキーと証明書を設定するプロセスのアウトラインを示します。

表 3-2 TLS のキーと証明書の設定

説明処理

ステップ

Network Prevent for Email Server のデフォルトのキーストアパスワードを安全なパスワードに変更するために Java の keytool ユーティリティを使います。次に、Enforce Server 管理コンソールを使って、更新済みのパスワードを使うように Network Prevent for Email Server を設定します。

p.29 の「Network Prevent for Email Server キーストアパスワードの変更」を参照してください。 Network Prevent for Email Server

のデフォルトのキーストアパスワードを変更します。

ステップ 1

Java の keytool ユーティリティを使って、Network Prevent for Email Server の公開キーと秘密キーのペアを生成します。

p.31 の「Network Prevent for Email Server のキーの生成」を参照してください。

Network Prevent for Email Server のキーペアを生成します。ステップ 2 keytool ユーティリティを使って、ステップ 2 で生成した公開キーの自己署名の証明書をエクスポートします。

p.32 の「Network Prevent for Email Server の公開キー証明書のエクスポート」を参照してください。 Network Prevent for Email Server

のキーストアから公開キー証明書をエクスポートします。ステップ 3 keytool を使って、ステップ 3 でエクスポートした公開キー証明書ファイルを上位の MTA のキーストアにインポートします。これにより MTA は TLS 通信で Network Prevent for Email Server を認証できます。公開キー証明書をインポートする方法の手順については、MTA のマニュアルを参照してください。上位の MTA のキーストアか反射

モードの MTA のキーストアに Network Prevent for Email Server の公開キー証明書をインポートします。ステップ 4 28 第 3 章 MTA 統合アーキテクチャ TLS 認証について

(29)

説明処理ステップネットワークで管理する次ホップの MTA の公開キー証明書ファイルを入手します。証明書をエクスポートする方法の手順については、MTA のマニュアルを参照してください。 TLS プロキシチェーン内のネクストホップとして外部のホストされたメールサーバーにアクセスする場合は、プロバイダから公開キー証明書を入手します。手順については、電子メールホスティングサービスプロバイダのマニュアルを参照してください。次ホップの MTA またはホストされた電子メールサービスの公開キー証明書を入手します。ステップ 5 Java の keytool ユーティリティを使って、下位の MTA またはホストされたメールサーバーの公開キー証明書を Network Prevent for Email Server のキーストアにインポートします。

p.33 の「Network Prevent for Email Server キーストアへの公開

キー証明書のインポート」を参照し

てください。転送モードの統合の場合、Network

Prevent for Email Server のキーストアに次ホップの公開キー証明書を追加します。ステップ 6 公開キー証明書をインポートする方法の手順については、MTA のマニュアルを参照してください。反射モードの統合の場合、反射モードの MTA のキーストアに次ホップの公開キー証明書を追加します。ステップ 7

Network Prevent for Email Server キーストアパスワードの変更

Network Prevent for Email Server のインストール時に、空のキーストアファイルが

installdirc:¥Program Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥Protect¥keystore¥prevent.k に作成されます。このキーストアファイルには初期パスワード dummypassword があります。キーストアパスワードを変更するには、次の手順を使います。 29 第 3 章 MTA 統合アーキテクチャ TLS 認証について

(30)

Network Prevent for Email Server キーストアパスワードの変更

1

Network Prevent for Email Server コンピュータの c:¥Program

Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥Protect¥jre¥bin ディレクトリに移動します。

2

-storepasswd オプションとともにkeytool ユーティリティを実行して、デフォルトパスワードを

変更します。次の例は 1 つのコマンドです。3 つの別々のコマンドではありません。コマンドが 1 行に収まらないため、改行されている場合があります。

keytool -storepasswd -new prevent_keystore_password -keystore c:¥Program Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥ Protect¥keystore¥prevent.ks -storepass dummypassword

prevent_keystore_password を、キーストア用の安全なパスワードで置き換えます。Linux シス

テムでは、デフォルトのキーストアの場所は

/opt/Symantec/DataLossPrevention/DetectionServer/Protect/keystore/prevent.ks

です。

メモ: Network Prevent for Email Server のキーストアパスワードとキーパスワードの値は一致する必要があります。Network Prevent for Email Server のキーを生成するときは同じ

prevent_keystore_password を使ってください。

p.31 の「Network Prevent for Email Server のキーの生成」を参照してください。

3

Network Prevent for Email Server を管理する Enforce コンソールにログオンします。

4

メインメニューバーで［システム］ > ［サーバー］ > ［概要］の順に選択します。

5

設定する Network Prevent for Email Server の名前をクリックします。

6

［設定］をクリックします。

7

［セキュリティの設定］セクションで、フィールドに次のように入力します。説明フィールドキーストアファイルの正しいパスワードを入力します。 ステップ 2 で指定した new_password を使います。 キーストアパスワードキーストアファイルパスワードを再入力します。キーストアパスワードの確認

8

［保存］をクリックします。 30 第 3 章 MTA 統合アーキテクチャ TLS 認証について

(31)

Network Prevent for Email Server のキーの生成

管理する各メールサーバーは、TLS 通信を認証するために必要なキーと X.509 証明書を格納したキーストアを備えている必要があります。次の手順を使って、キーストアファイルに新しい公開キーと秘密キーのペアを作成します。

Network Prevent for Email Server の公開キーと秘密キーのペアの作成

1

Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥Protect¥jre¥bin ディ

レクトリに移動します。

2

-genkeypair と -keystore オプションとともに keytool ユーティリティを実行して、新しい公開キーと秘密キーをキーストアに追加します。

keytool -genkeypair -dname "dname_string" -alias smtp_prevent -keypass key_password -keystore c:¥Program Files¥Symantec¥

DataLossPrevention¥DetectionServer¥15.5¥Protect¥keystore¥prevent.ks -storepass store_password -validity expiration_days

表 3-3 では、コマンドで使われるトークンについて説明します。

たとえば、次のコマンドは 90 日で期限切れになる新しいキーペアを生成します。

keytool -genkeypair -dname "CN=John Doe, OU=DLP_Development,

O=Symantec, L=SanFrancisco, S=California, C=USA" -alias smtp_prevent -keypass prevent_keystore_password

-keystore c:¥Program Files¥Symantec¥DataLossPrevention¥DetectionServer¥ 15.5¥Protect¥keystore¥prevent.ks

-storepass prevent_keystore_password -validity 90

3

作成した公開キー証明書をエクスポートします。TLS セッションで Network Prevent for Email Server を認証する必要があるすべての上位の MTA に証明書をインポートする必要があります。

p.32 の「Network Prevent for Email Server の公開キー証明書のエクスポート」を参照してください。

(32)

表 3-3 Keytool のトークンの説明説明

トークン

公開キーでバインドする X.500 識別名。通常、識別名にはキーに関連付けられた個人の共通名、組織と組織単位、場所の一連のコードが含まれます。次に例を示します。 -dname "CN=John Doe, OU=DLP_Development,

O=Symantec, L=SanFrancisco, S=California, C=USA"

識別名の文字列の形式について詳しくは keytool のヘルプ、または Sun の keytool のマニュアルを参照してください。

dname_string

新しいキーのエイリアス。

smtp_prevent

作成する新しいキーのパスワード。

メモ: key_password と store_password の値は Network Prevent for Email Server で

は同一である必要があります。

p.29 の「Network Prevent for Email Server キーストアパスワードの変更」を参照してください。

key_password

キーストアファイルを修正するためのパスワード。

メモ: key_password と store_password の値は Network Prevent for Email Server で

は同一である必要があります。

p.29 の「Network Prevent for Email Server キーストアパスワードの変更」を参照してください。

store_password

新しいキーペアが無効になるまでの日数。

expiration_days

Network Prevent for Email Server の公開キー証明書のエクスポート

Network Prevent for Email Server を認証するには、上位の MTA (または反射モードの MTA) のローカルキーストアに Network Prevent for Email Server の公開キー証明書を格納する必要があります。次の手順では、Network Prevent for Email Server の公開キー証明書をファイルにエクスポートする方法を示します。その後、このファイルから上位の MTA のキーストアに証明書をインポートできます。

(33)

公開キー証明書のエクスポート

1

Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥Protect¥jre¥bin ディレクトリに移動します。

2

公開キー証明書を新しいファイルにエクスポートするために -exportcert オプションとともに keytool ユーティリティを実行します。

keytool -exportcert -alias smtp_prevent -file smtp_prevent.cer

-keystore c:¥Program Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥ Protect¥keystore¥prevent.ks -storepass prevent_key_password

このコマンドの smtp_prevent.cer は公開キー証明書を格納するファイルの名前、

prevent_key_password はキーストアと Network Prevent for Email Server のキーのパスワー

ドです。

3

Network Prevent for Email Server を認証する必要がある上位の各 MTA のキーストアに、または反射モードの MTA に、公開キー証明書をインポートします。手順については MTA のマニュアルを参照してください。

Network Prevent for Email Server キーストアへの公開キー証明書の

インポート

TLS プロキシ連鎖の各メールサーバーは次ホップのメールサーバーを認証する必要があります。認証では、上位のメールサーバーのトラストストアに次ホップのメールサーバーの証明書を追加する必要があります。次の手順では、Network Prevent for Email Server のキーストアに次ホップの MTA サーバーまたはホストされた電子メールサーバーの公開キー証明書をインポートする方法を示します。

メモ: Network Prevent for Email のキーストアに追加するどの証明書も、証明書ファイル内で

---BEGIN CERTIFICATE--- と ---END CERTIFICATE--- 文字列で囲まれた、Private

Enhanced Mail (.pem) の Base64 でエンコードされた DER (Distinguished Encoding Rules) 証明書形式の X.509 証明書である必要があります。

(34)

公開キー証明書のインポート

1

Network Prevent for Email Server コンピュータにインポートする証明書ファイルをコピーすることから始めます。

次ホップの MTA をネットワーク内で管理している場合、公開キー証明書のエクスポートについては MTA のマニュアルを参照してください。

ホストされた電子メールサービスを次ホップのサーバーとして使う場合、証明書の入手についてはサービスプロバイダに問い合わせます。

2

Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥Protect¥jre¥bin ディ

レクトリに移動します。

3

次のコマンドを使用して Network Prevent for Email Server キーストアに公開キーの証明書をインポートするために -importcert オプションとともにkeytool ユーティリティを実行します。ここでは、コマンドが 1 行に収まらない場合は 2 行に渡って表示されることがありますが、コマンドラインには 1 つのコマンドとして入力する必要があります。

keytool -importcert -alias new_mta_alias -file certificate_file

-keystore c:¥Program Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥ Protect¥keystore¥prevent.ks -storepass prevent_key_password

このコマンドの certificate_file はインポートする公開キー証明書ファイルの絶対パス、

store_password はキーストアのパスワードです。new_mta_alias はインポートした証明書に

割り当てる新しいエイリアスです。

ルート CA 証明書を含む公開キーチェーンをインポートする場合は、チェーン全体を検証するために次のように -trustcacerts オプションを指定します。

keytool -importcert -alias prevent_alias -file .¥smtp_prevent.cer

-keystore c:¥Program Files¥Symantec¥DataLossPrevention¥DetectionServer¥15.5¥ Protect¥keystore¥prevent.ks -trustcacerts