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 のセキュリティー保護」を参照してください。