メッセージングユーザー認証の計画
ユーザー認証を行うことで、ユーザーはメールクライアントへのログインとメールメッセージの取得が可能になります。ユーザー認証の方法には次のものがあります。
プレーンテキストと暗号化されたパスワードによるログイン
ユーザー ID とパスワードは、LDAP ディレクトリに保存されます。最低限必要な長さなど、パスワードのセキュリティー基準は、ディレクトリポリシー要件によって決定されます。パスワードのセキュリティー基準は、Messaging Server 管理の一部ではありません。ディレクトリサーバーのパスワードポリシーについては、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』を参照してください。
管理者は、メッセージング設定パラメータを設定して、プレーンテキストのパスワードを許可するかどうか、パスワードの暗号化を必須とするかどうかを決めることができます。詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の service.xxx.plaintextminciper パラメータ (xxx は http、pop、imap のいずれか) を参照してください。
プレーンテキストによるログインと暗号化されたパスワードによるログインは、どちらも POP、IMAP、および Messenger Express ユーザーアクセスプロトコルで使用できます。
Simple Authentication and Security Layer (SASL) による認証
SASL (RFC 2222) は、POP、IMAP、および SMTP ユーザーアクセスプロトコルの追加認証メカニズムとして機能します。Messaging Server は、表 13–3 に一覧表示されているユーザーアクセスプロトコルの SASL をサポートしています。
表 13–3 SASL 認証のユーザーアクセスプロトコルのサポートマトリックス|
|
プレーン |
ログイン |
CRAM-MD5 |
Digest-MD5 |
証明書 |
APOP |
|---|---|---|---|---|---|---|
|
SMTP AUTH |
Yes |
Yes |
Yes |
Yes |
- |
- |
|
POP |
Yes |
- |
Yes |
Yes |
- |
Yes |
|
IMAP |
Yes |
- |
Yes |
Yes |
- |
- |
|
HTTP (Messenger Express) |
Yes |
- |
- |
- |
Yes |
- |
注 –
-
CRAM-MD5 を使用する場合は、パスワードをプレーンテキスト形式で LDAP ディレクトリサーバーに保存する必要があります。
-
POP を使用する場合は、パスワードをプレーンテキストで LDAP ディレクトリサーバーに保存する必要があります。
SASL を使用する場合、セッションで SSL を使用しないと、ユーザー名とパスワードは暗号化されません。SSL の詳細については、「SSL による暗号化」を参照してください。SASL メカニズム、PLAIN および LOGIN は、認証情報を復号化しますが、情報が捕捉された場合には容易に解読されてしまいます。このような限界があるにもかかわらず、SASL は SMTP AUTH (「認証された SMTP を有効にする」を参照) と組み合わせて、システムで認証されたユーザーにだけシステムを経由したメールのリレーを許可できるため、便利です。たとえば、正当なユーザーが SMTP サーバーへの認証を受けると、SMTP サーバーで別のチャネルへの切り替えを設定できます。このようにすると、認証されたセッションからのメッセージは、認証されていないユーザーとは別の TCP チャネルから送られてくるメッセージとなります。内部ネットワークのユーザーからのメッセージも、着信接続の IP アドレスに基づいて、その他の発信元からのメッセージとは別のチャネルに切り替えできます。
SASL の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。
認証された SMTP を有効にする
デフォルトでは、ユーザーは、メッセージ送信時に Messaging Server の SMTP サービスに接続する際に、パスワードを送信する必要はありません。ただし、SMTP へのパスワードログインを有効にすれば、認証された SMTP を使用できるようになります。
認証された SMTP (SMTP AUTH とも呼ばれる) は、SMTP プロトコルを拡張したものです。認証された SMTP を使用すると、サーバーへのクライアント認証が可能になります。認証は、メッセージの送受信時に実行されます。認証された SMTP の主な用途は、悪用される可能性のあるオープンリレーを作成することなく、オフィス外のローカルユーザーがメールを送信するのを可能にすることです。クライアントは、AUTH コマンドを使用してサーバーに対する認証を行います。
認証された SMTP は、SMTP プロトコルによるメッセージの送信をセキュリティーで保護します。認証された SMTP を使用する場合に、証明書に基づいたインフラストラクチャーを用意する必要はありません。証明書による認証については、「Secure Sockets Layer (SSL) による証明書ベースの認証」を参照してください。
認証された SMTP を使用すると、クライアントは認証メカニズムをサーバーに提示し、認証プロトコルの交換を行うことができます。さらに任意で、後続のプロトコル相互対話で使用するセキュリティー層とネゴシエーションを行うこともできます。
メールの送信に SMTP AUTH の使用を要求している場合は、適切なログを記録してメールが悪用されたケースを追跡できます。
認証された SMTP の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の MTA に関する章を参照してください。
Secure Sockets Layer (SSL) による証明書ベースの認証
Messaging Server は、SSL プロトコルを使用して、暗号化通信とクライアントおよびサーバーの証明書ベースの認証を行います。この節では、証明書ベースの SSL 認証について説明します。SSL 暗号化の詳細については、「SSL による暗号化」を参照してください。
SSL は公開鍵暗号法の概念に基づいています。TLS (Transport Layer Security) は SSL のスーパーセットとして機能しますが、名前が混同されて使われています。
SSL をサポートしているサーバーには、証明書、公開鍵、非公開鍵、証明書、鍵、およびセキュリティーデータベースが高レベルで必要となります。これにより、メッセージの認証、機密、完全性が確保されます。
表 13–4 で、各クライアントアクセスプロトコルによる SSL 認証のサポートについて説明します。
表 13–4 SSL 認証のサポートマトリックス|
|
MMP による SSL |
代替ポートでの MMP による SSL |
SSL |
代替ポートでの SSL |
|---|---|---|---|---|
|
SMTP |
Yes |
Yes |
Yes |
Yes |
|
- |
Yes |
- |
Yes |
|
|
Yes |
Yes |
- |
Yes |
|
|
Yes (Messenger Express マルチプレクサによる) |
Yes (Messenger Express マルチプレクサによる) |
- |
Yes |
SMTP、POP、および IMAP プロトコルは、クライアントとサーバーが SSL なしで通信を開始したあと、"start TLS" と同等のコマンドを使用して SSL 通信に切り替える方法を提供します。"start TLS" を実装していないクライアントの場合は、SMTP、POP、および IMAP サーバーが SSL を代替ポートで使用するように設定することもできます。
SSL による認証を行うには、メールクライアントはサーバーとの SSL セッションを確立し、ユーザーの証明書をサーバーに提出します。サーバーは、提出された証明書が本物であるかどうかを評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。
SSL を認証用途で使う場合、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、クライアントやほかのサーバーに対して、そのユーザーのサーバーを特定します。サーバーは、クライアントの認証に使用する、信頼できる認証局 (CA) の証明書をいくつでも持つことができます。
SSL の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。
- © 2010, Oracle Corporation and/or its affiliates