Sun Java Communications Suite 5 配備計画ガイド

配備における Instant Messaging の保護

この節では、Instant Messaging 配備でコンポーネントを保護する方法について説明します。

Instant Messaging セキュリティーの概要

Instant Messaging では、次のレベルのセキュリティーをサポートしています。

セキュリティーなし。クライアントからマルチプレクサを介したサーバーまでの通信は、すべてプレーンテキストです。
レガシー SLL。クライアントとマルチプレクサの間はセキュリティーで保護された通信、マルチプレクサとサーバーの間はプレーンテキストです (マルチプレクサを使用している場合のみ該当)。
startTLS。クライアントとサーバーの間は、終端間でセキュリティー保護された通信です。マルチプレクサを有効にすると、マルチプレクサはデータを処理しませんが、サーバーに渡します。

startTLS オブションでは終端間の暗号化が有効になり、クライアントとマルチプレクサとサーバーの間の通信は、すべて暗号化されます。一方、レガシー SSL では Instant Messenger クライアントからマルチプレクサまでの暗号化が有効になります。したがって、マルチプレクサとサーバーの間の通信はプレーンテキストです (ただし、専用のプロトコルが使用される)。より高いレベルのセキュリティーが必要な場合は、startTLS を使用してください。startTLS を使用する場合、マルチプレクサからサーバーへの通信をセキュリティーで保護するために代替手段は必要ありません。この通信はセキュリティーで保護されます。

Instant Messaging サーバーとマルチプレクサの保護

Instant Messaging では、セキュリティーで保護された通信のために、TLS (Transport Layer Security) およびレガシー SSL (Secure Sockets Layer) をサポートしています。Instant Messaging では、クライアントとサーバーの間およびサーバー間の暗号化通信、およびサーバー間の証明書ベースの認証で、Transport Layer Security (TLS) 1.0 プロトコルの startTLS 拡張機能を使用します。また Instant Messaging では、Instant Messenger クライアントとマルチプレクサの間の暗号化通信で、SSL プロトコル (バージョン 3.0) のレガシー実装もサポートしています。

Instant Messaging 用に SSL を計画するときは、次の点に注意してください。

Instant Messaging 配備をセキュリティーで保護するには、Web コンテナポート (Web Server または Application Server) で SSL を有効にし、XMPP/HTTP ゲートウェイ (httpbind) を使用して Instant Messaging 機能にアクセスします。マルチプレクサで SSL を有効にすることもでき、その場合、Instant Messaging クライアントは、マルチプレクサを介して直接 Instant Messaging 機能にアクセスできます。
マルチプレクサでレガシー SSL が有効になっている場合、Instant Messenger クライアントはレガシー SSL だけを使用します。この場合、Instant Messenger クライアントはサーバーで startTLS を使用します。
Instant Messaging ではレガシー SSL を使用した終端間の暗号化をサポートしません。そのため、Instant Messaging サーバーとマルチプレクサが複数のノードに配備されていて、かつマルチプレクサで SSL が有効な場合、Instant Messaging サーバーとマルチプレクサの間の通信は、クリアテキスト形式です。終端間の暗号化を利用するには、startTLS を使用する必要があります。
適切なファイルとディレクトリの権限を Instant Messaging 設定ファイル(/etc/opt/SUNWiim/default/config ディレクトリの iim.conf および httpbind.conf) に設定します。 [Instant Messaging は、iim.conf ファイルで指定されたユーザーとして実行します。このユーザーには、このファイルの読み取りアクセス権が必要です。httpbind を使用する場合、Web コンテナを実行するユーザーは、Instant Messaging のディレクトリパスおよび設定ファイルにアクセスできるようにしてください。一般に、Instant Messaging の配備に Access Manager または Portal Server が含まれる場合、デフォルトのユーザーは root です。] 追加の Instant Messaging サーバーまたはマルチプレクサのインスタンスを手動で作成するときは、ファイルとディレクトリの権限が正しいことも確認する必要があります。デフォルトのインストールで、ファイルやディレクトリの権限が設定されます。デフォルトのインスタンスディレクトリ (/var/opt/SUNWiim/default) には、次の権限があります。
drwx------ 5 root other 512 Oct 16 14:24 default
Instant Messaging 監視を有効にするときは注意してください。有効にするとサーバー統計が公開されますが、セキュリティー上の問題になる可能性があります。デフォルトの設定では、監視機能が有効ではありません。このプロパティーは、iim.conf ファイルを使用して有効にします。
デバッグのロギングは必要なときだけ有効にします。有効にすると、システムのパフォーマンス全体に影響があります。パスワードはログに記録されませんが、ユーザー間のプロトコル通信は記録されるため、セキュリティー上の問題になる可能性があります。
startTLS を使用可能にする場合は、クライアントとサーバーの間とサーバー間の両方の通信で、1 つのサーバー証明書を使用します。
Identity Integration が有効な場合は、Instant Messaging サーバーが Access Manager に接続できるようにしてください。同様に、Portal Server を使用して配備する場合は、Instant Messaging サーバーが Portal Server 検索にアクセスできる必要があります。また、LDAP を利用する Instant Messaging 配備では、アクセスするために適切な認証が必要です。各コンポーネントをセキュリティーで保護する方法については、各製品の個々のマニュアルを参照してください。

Instant Messaging のデフォルトのインストールでは、SASL Plain だけをサポートします。より高いレベルのセキュリティーが必要な場合は、Instant Messaging の公開サービスプロバイダインタフェースを使用してください。SASL Plain と jabber:iq:auth は、プレーンテキスト認証の 2 つの形態です。つまりどちらの場合も、パスワードはクリアテキスト形式 (エンコードされる場合もあるが、依然としてクリアテキスト形式) で送信されるため、どちらも認証はセキュリティーで保護されません。それでも、これが問題になるのは、終端間の暗号化 (直接のソケット接続の場合は startTLS 経由、httpbind の場合は HTTPS 経由) が有効でない場合のみです。終端間の暗号化が有効な場合、ネットワークでパスワードはクリアテキスト形式で見えません。

一方、暗号化されたストリーム上であってもパスワードをクリアテキスト形式で伝送したくない場合は、SASLRealm を使用してサーバー側で認証メカニズムをプラグインするための Instant Messaging SPI を使用してください。カスタム SASL メカニズムを実装することはできますが、このカスタムメカニズムをサポートする Instant Messaging クライアントが必要です。Sun Java System Instant Messaging クライアントでは、SASL Plain、jabber:iq:auth だけがサポートされます (両方ともセキュリティー保護されていない)。

詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』の第 12 章「TLS と従来の SSL による Instant Messaging のセキュリティー保護」を参照してください。

ファイアウォールを介した Instant Messaging クライアントアクセスの提供

XMPP/HTTP ゲートウェイ (httpbind) では、HTML ベースのクライアントや、HTTP トラフィックは許可するが XMPP トラフィックは許可しないファイアウォールの背後にあるクライアントなど、XMPP ベースのクライアントに対する Instant Messaging アクセスを提供します。ゲートウェイは、XMPP サーバーへの Instant Messaging トラフィックを HTTP クライアントの代わりにプロキシ化します。

XMPP/HTTP ゲートウェイの使用を計画するときは、次の点に注意してください。

ゲートウェイがマルチプレクサを介してサーバーと通信する場合は、ゲートウェイでポート 5222 を使用してください。マルチプレクサが関わらない場合は、サーバーのポート 5269 を使用してください。httpbind.conf ファイルでポート 5222 または 5269 を指定できます。
XMPP/HTTP ゲートウェイでは、startTLS とレガシー SSL の両方をサポートします。レガシー SSL のサポートが必要な場合は、Web Server ポートで SSL を使用可能にしてください。ただし、XMPP/HTTP ゲートウェイ設定で、サーバーではなくマルチプレクサを指す場合は、マルチプレクサでレガシー SSL を無効にしてください。startTLS のサポートが必要な場合は、サーバーで startTLS を使用可能にすると、すべての通信が暗号化されます。
Instant Messaging サーバーをダイレクトアクセスに公開しないでください。一般的な配備シナリオでは、マルチプレクサを DMZ に配置し、2 番目のファイアウォールでマルチプレクサからサーバーへの通信ポート (通常は 45222) を開きます。

Instant Messaging アーカイブの保護

Instant Messaging には、あとで取得および検索するためにインスタントメッセージをアーカイブする機能があります。電子メールのアーカイブを有効にする場合は、アーカイブされたインスタントメッセージを含む電子メールを受信する管理者を決定する必要があります。調査、ニュース、会議室、アラート、チャットセッションを受信する管理者のリストを別に設定できます。また、拡張 RFC 822 ヘッダーを使用するように Instant Messaging を設定することもできます。そのようにすると、メールクライアントはヘッダーの内容に基づいてメッセージをフィルタ処理できます。Portal アーカイブを有効にする場合は、Portal アーカイブデータベースにアクセスできる管理者を決定できます。

詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』の第 18 章「Instant Messaging アーカイブの管理」を参照してください。