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

第 22 章 Instant Messaging のセキュリティーの計画

この章では、Instant Messaging 配備のさまざまなコンポーネントに対する計画を立案し、それらのコンポーネントを保護する方法について説明します。

この章の内容は次のとおりです。

配備における 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 アーカイブの管理」を参照してください。

Instant Messaging ユーザー認証の計画

ユーザー認証を使用すると、ユーザーは各自の Instant Messaging クライアントからログインして、チャットしたり、Instant Messaging のそのほかの機能にアクセスしたりすることができます。

Instant Messaging とパスワード

ユーザー ID とパスワードは、LDAP ディレクトリに保存されます。最低限必要な長さなど、パスワードのセキュリティー基準は、ディレクトリポリシー要件によって決定されます。パスワードのセキュリティー基準は、Instant Messaging 管理の一部ではありません。ディレクトリサーバーのパスワードポリシーについては、Directory Server のマニュアルを参照してください。

http://docs.sun.com/coll/1660.1

Instant Messaging と LDAP

Instant Messaging のすべての配備で、ディレクトリサーバーが必要です。Access Manager を実装しない配備では、Instant Messaging サーバーはディレクトリサーバーを使用してエンドユーザー認証を実行したり、エンドユーザーを検索したりします。ディレクトリをセキュリティーで保護する各種の方法については、Directory Server のマニュアルを参照してください。

Portal Server を実装する配備では、Instant Messaging サーバーは Portal Server で使用されるディレクトリを使用します。Access Manager 配備環境にインストールすると、Instant Messaging サーバーは Access Manager で使用されるディレクトリを使用してエンドユーザーを検索しますが、エンドユーザー認証には使用しません。Access Manager 配備では、Access Manager によって認証が実行されます。

LDAP ディレクトリを使ってユーザーの名前空間を管理する場合、デフォルトの設定では、このディレクトリで使用するスキーマに関して、次のような仮定がなされます。

エンドユーザーエントリは、inetOrgPerson オブジェクトクラスによって識別される。
グループエントリは、groupOfUniqueNames または groupofURLs オブジェクトクラスによって識別される。
エンドユーザーの Instant Messenger ユーザー ID 属性は、inetOrgPerson オブジェクトクラスの uid 属性によって提供される。
エンドユーザーの電子メールアドレスは、mail 属性によって提供される。
エンドユーザーまたはグループの表示名は、cn 属性によって提供される。
グループのメンバーリストは、groupOfUniqueNames オブジェクトクラスの uniqueMember 属性によって提供される。

注 –

一部のユーザー属性には、機密情報が含まれる可能性があります。権限を持たないユーザーによる不正アクセスを防ぐようにディレクトリアクセス制御が設定されていることを確認してください。

Instant Messaging とディレクトリの匿名検索

Instant Messaging が正しく機能するには、ディレクトリを検索できる必要があります。匿名ユーザーが検索可能であるようにディレクトリが設定されていることを確認する必要があります。ディレクトリが匿名ユーザーによる読み取り可能または検索可能ではない場合は、追加の設定を行なう必要があります。

詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』の第 11 章「Instant Messaging の LDAP アクセス設定の管理」を参照してください。

インスタントメッセージのプライバシ、セキュリティー、およびサイトポリシーの計画

Instant Messaging には、Instant Messaging 機能へのアクセスを制御する機能や、エンドユーザーのプライバシを保護する機能が用意されています。

Instant Messaging サイトポリシー

サイトポリシーでは、Instant Messaging の特定機能に対するエンドユーザーアクセスを指定します。Instant Messaging 用のサイトポリシーを開発するときは、次の点に注意してください。

ユーザーは、ほかのエンドユーザーの Presence ステータスにアクセスできるか。
ユーザーは、ほかのエンドユーザーにアラートを送信できるか。
ユーザーにプロパティーをサーバー上に保存させるか。
会議室の作成および管理を実行できるユーザーを誰にするか。
ニュースチャネルの作成および管理を実行できるユーザーを誰にするか。

詳細については、『Sun Java System Instant Messaging 7.2 管理ガイド』の第 17 章「Instant Messaging ポリシーおよび Presence ポリシーの管理」を参照してください。

Instant Messaging エンドユーザーおよび管理者の権限を制御する方法

エンドユーザーの Instant Messaging サービスへのアクセスを可能にするか、またはアクセスの種類を制限するかについては、Instant Messaging サーバーを使用するサイトごとに異なる要件があります。エンドユーザーと管理者の、Instant Messaging サーバー機能と権限情報へのアクセスを制御する処理は、ポリシー管理と呼ばれます。ポリシー管理には、2 つの方法があります。アクセス制御ファイルを使用する方法と、Sun Java System Access Manager を使用する方法です。

アクセス制御ファイルによるポリシー管理。ポリシー管理にアクセス制御ファイルを使用する方法では、次の分野でエンドユーザー権限を調整できます。ニュースチャネルの管理、会議室の管理、ユーザー設定ダイアログでの設定変更、アラートの送信。また、特定のエンドユーザーをシステム管理者として割り当てることもできます。
Sun Java System Access Manager によるポリシー管理。この方法では、アクセス制御ファイルを使う方法と同じ権限を制御できますが、さらに、アラートの受信、調査の送受信など、機能の制御をよりきめ細かく行えます。さらに、Sun Java System Access Manager を使用してポリシーを制御すると、権限をより詳細に調整できます。

配備に Access Manager が含まれない場合は、アクセス制御ファイルによる方法でポリシーを管理する必要があります。Access Manager を Instant Messaging とともに使用し、かつ Instant Messaging と Presence サービスコンポーネントをインストールしている場合は、どちらのポリシー管理方法も使用できます。ただし、Access Manager によるポリシー管理のほうが、より包括的な方法です。この方法の利点の 1 つは、すべてのエンドユーザー情報をディレクトリ内に格納できる点です。