前へ
目次
索引
次へ
|
| Sun ONE Message Queue 管理者ガイド |
第 8 章 セキュリティ管理
この章では、認証、承認、暗号化といったセキュリティ関連のタスクを実行する方法を説明します。
ユーザの認証 管理者は、ユーザ、ユーザグループ、およびパスワードのリストをユーザリポジトリに保持しておく責任があります。この章の最初の節では、ユーザリポジトリの作成、設定、および管理の方法を説明します。MQ セキュリティについては、「セキュリティマネージャ」を参照してください。
ユーザの承認 管理者は、プロパティファイルを編集する責任があります。プロパティファイルはブローカ操作へのユーザのアクセスをユーザ名またはユーザグループにマッピングします。この章の 2 番目の節では、このプロパティファイルのカスタマイズ方法を説明します。
暗号化 - SSL サービスの設定 SSL (Secure Socket Layer) 標準に基づくコネクションサービスを使用すると、クライアントとブローカ間で送信されるメッセージを暗号化できます。MQ による暗号化の処理方法については、「暗号化」を参照してください。この章の最後の節では、SSL ベースのコネクションサービスを設定する方法を説明し、SSL 使用に関する追加情報を記載します。
ブローカが SSL キーストア、LDAP ユーザリポジトリ、または JDBC 準拠の持続ストアへ安全にアクセスするのにパスワードが必要となる状況では、次の 3 つの手段でパスワードが要求されます。
ブローカの起動時に、システムがユーザに要求する
ブローカの起動時に、コマンド行オプションとしてパスワードを渡す (「ブローカの起動」および表 5-2 を参照)
ブローカの起動時にシステムがアクセスする passfile にパスワードを格納する (「passfile の使用」を参照)
ユーザの認証
ユーザがブローカへの接続を試みると、ブローカは提供された名前とパスワードを調べて、参照するように設定されているユーザリポジトリの名前とパスワードと一致した場合に、コネクションを許可します。このリポジトリには、次の 2 つのタイプがあります。
MQ に付属している単層型ファイルリポジトリ
LDAP サーバ
- このタイプのユーザリポジトリの使用は簡単です。ユーザマネージャユーティリティ (imqusermgr) を使用してリポジトリを設定および管理します。認証を有効にするには、ユーザリポジトリにユーザ名、パスワード、およびユーザグループの名前を設定します。
- ユーザリポジトリの設定と管理についての詳細は、「単層型ファイルユーザリポジトリを使用する」を参照してください。
- このリポジトリは、既存または新規の LDAP ディレクトリサーバで、ユーザリポジトリに LDAP v2 または v3 プロトコルを使用します。単層型ファイルリポジトリほど使用方法は簡単ではありませんが、より安全であるため、運用環境に適しています。
- LDAP ユーザリポジトリを使用している場合、LDAP ベンダーから提供されているツールを使用して、ユーザリポジトリを設定、管理する必要があります。詳細は、「ユーザリポジトリに LDAP サーバを使用する」を参照してください。
単層型ファイルユーザリポジトリを使用する
MQ には、単層型ファイルユーザリポジトリ、コマンド行ツール、および単層型ファイルユーザリポジトリの設定と管理ができる MQ ユーザマネージャ (imqusermgr) が用意されています。次に、単層型ファイルユーザリポジトリ、その初期エントリ、およびリポジトリの設定や管理方法を説明します。デフォルトの単層型ファイルリポジトリは、次の場所にあります。
表 8-1 に示すように、リポジトリには定義済みの 2 つのエントリ (行) が付属しています。
- IMQ_HOME/etc/passwd (Solaris では /etc/imq/passwd)
ユーザ名
パスワード
グループ
状態
admin
admin
admin
アクティブ
guest
guest
anonymous
アクティブ
これらの初期エントリにより、管理者が介入しなくても、インストール後直ちに MQ ブローカを使用できます。言い換えれば、MQ ブローカを使用する上で、ユーザやパスワードの初期設定は必要ありません。
たとえばテストの目的で、初期の guest ユーザエントリを使って、JMS クライアントはデフォルトの guest ユーザ名とパスワードでブローカに接続できます。
初期の admin ユーザエントリでは、デフォルトの admin ユーザ名とパスワードで、 imqcmd コマンドを使用してブローカを管理できます。この初期エントリを更新して、パスワードを変更することをお勧めします。
Solaris の場合：インストール後、スーパーユーザ権限を持ったユーザだけがユーザリポジトリファイルに書き込むことができます。スーパーユーザ権限は、ファイルのアクセス権属性を使用するファイルへのアクセスを制御するオペレーティングシステムのポリシーと一貫性があります。
ブローカをインストールしたあと、ユーザマネージャユーティリティを使用してユーザリポジトリを設定できます。この設定が完了するまで、ブローカを設定または起動する必要はありません。ユーザマネージャユーティリティを使用する上での唯一の要件は、ブローカがインストールされたホスト上で実行するということです。ブローカが使用するリポジトリの設定、および管理方法については後で説明します。Windows の場合：インストール後、オペレーティングシステムがユーザ名ベースのアクセス権属性を使用するファイルへのアクセスを制御しないため、あらゆるユーザがユーザリポジトリファイルに書き込むことができます。
MQ User Manager サブコマンドとオプション
表 8-2 に imqusermgr サブコマンドを一覧表示します。
サブコマンド
説明
add -u name -p passwd [-g group] [-s]
delete -u name [-s] [-f]
list [-u name]
update -u name -p passwd [-a state] [-s] [-f]
update -u name -a state [-p passwd] [-s] [-f]
表 8-3 に imqusermgr コマンドのオプションを一覧表示します。
オプション
説明
-a true | false
ユーザの状態をアクティブにするかどうかを指定する。値が true の場合、状態はアクティブである。デフォルト値 は true
-f
-h
-p passwd
-g admin | user | anonymous
-s
-u name
-v
グループ
ユーザエントリをリポジトリに追加するとき、管理者はあらかじめ定義された admin、user、または anonymous のうち、どれかのグループをユーザに指定できます。グループが指定されない場合、デフォルトの user が割り当てられます。
admin グループは、ブローカの管理者です。このグループに割り当てられたユーザは、デフォルトでブローカを設定および管理できるようになっています。管理者は、複数のユーザを admin グループに割り当てることができます。
ユーザグループを変更するには、管理者はユーザエントリを削除し、それからユーザの別のエントリを追加して新しいグループを指定します。user グループは、管理者ではない通常の JMS クライアントアプリケーションのためのグループです。ほとんどの MQ クライアントアプリケーションは、ユーザグループで認証されたブローカにアクセスします。このように、クライアントアプリケーションでは、デフォルトで、あらゆるトピックやキューに対するメッセージのプロデュース、あらゆるトピックやキューからのメッセージのコンシューム、あるいは任意のキューのメッセージの検索が実行できます。
anonymous グループは、ブローカが認識している名前を使用しない JMS クライアントアプリケーションのためのグループです。それには、アプリケーションが実際に使用するユーザ名を認識していないなどの理由があります。このグループは、多くの FTP サーバにある匿名アカウントに似ています。管理者が一度に anonymous グループに割り当てられるのは、1 人のユーザだけです。管理者は、ユーザグループと比べてこのグループのアクセス権限をアクセス制御を使用して制限したり、あるいは配置時にユーザを削除することが考えられます。
そのグループのメンバーがどの操作を実行するかを定義するアクセス規則を指定できます。詳細は、「ユーザの承認: アクセス制御プロパティファイル」を参照してください。
状態
管理者がユーザをリポジトリに追加したとき、デフォルトのユーザの状態はアクティブです。ユーザを非アクティブに変更するには、管理者は更新コマンドを使用する必要があります。たとえば、次のコマンドでは、ユーザの JoeD が非アクティブになります。
非アクティブになったユーザのエントリは、リポジトリに保持されますが、非アクティブのユーザは、新規コネクションを開くことはできません。ユーザが非アクティブのとき、管理者が同じ名前を持つ別のユーザを追加すると、操作に障害が発生します。管理者は非アクティブなユーザのエントリを削除するか、ユーザの名前を変更するか、あるいは新しいユーザに別の名前を使用する必要があります。これは、管理者が重複する名前やパスワードを追加しないようにするためです。
- imqusermgr update -u JoeD -a false
ユーザ名とパスワードの形式
ユーザ名とパスワードは、次の規則に従う必要があります。
ユーザ名とパスワードには、表 8-4 に一覧表示されている文字を使用できない
ユーザ名とパスワードには、改行やキャリッジリターンを文字として使用できない
ユーザリポジトリの設定と管理
add サブコマンドを使用して、ユーザをリポジトリに追加します。たとえば、次のコマンドでは、sesame というパスワードを持つ Katharine というユーザが追加されます。
delete サブコマンドを使用して、ユーザをリポジトリから削除します。たとえば、次のコマンドでは Bob というユーザが削除されます。
- imqusermgr add -u Katharine -p sesame -g user
update サブコマンドを使用して、ユーザのパスワードまたは状態を変更します。たとえば、次のコマンドでは、Katharine のパスワードが alladin に変更されます。
- imqusermgr delete -u Bob
1 人またはそれ以上のユーザに関する情報を一覧表示するには、list コマンドを使用します。次のコマンドでは、isa という名前のユーザに関する情報が表示されます。
- imqusermgr update -u Katharine -p alladin
次のコマンドでは、すべてのユーザに関する情報が表示されます。
デフォルトの管理者パスワードの変更
セキュリティのために、admin のデフォルトパスワードを自分だけが認識できるパスワードに変更する必要があります。この変更を行うには、imqusermgr ツールを使用します。次のコマンドでは、デフォルトのパスワードが grandpoobah に変更されます。
ブローカの実行中に任意のコマンド行ツールを実行すれば、この変更が反映されていることをすぐに確認できます。たとえば、次のコマンドを実行します。
- imqusermgr update -u admin -p grandpoobah
ここでは変更前のパスワードは使用できません。
- imqcmd list svc -u admin -p grandpoobah
パスワードを変更したあとは、管理コンソールなどのあらゆる管理ツールを使用するときに、新しいパスワードを使用してください。
ユーザリポジトリに LDAP サーバを使用する
ユーザリポジトリに LDAP サーバを使用する場合は、インスタンス設定ファイルで特定のブローカプロパティを設定する必要があります。このプロパティでは、ユーザがブローカへ接続しようとしたり、特定の操作を実行したりすると、ブローカがユーザとグループに関する情報について LDAP にクエリを実行できるようになります。インスタンス設定ファイルは、次の場所にあります。
- IMQ_VARHOME/instances/brokerName/props/config.properties
(Solaris では、/var/imq/instances/brokerName/props/config.properties)
次のプロパティを設定して、LDAP ユーザリポジトリの使用を指定します。
imq.authentication.type プロパティを設定して、クライアントからブローカへのパスワードの受け渡しに、base64 暗号化方式 (basic) を使用するか、MD5 ダイジェスト (digest) を使用するかを決定します。LDAP ディレクトリサーバをユーザリポジトリに使用する場合、認証タイプにbasic を設定する必要があります。たとえば、次のように指定します。
- imq.authentication.basic.user_repository=ldap
LDAP へのアクセスを制御するブローカプロパティを設定する必要もあります。これらのプロパティは、ブローカのインスタンス設定ファイルにあります。表 8-5 の説明を参照してください。MQ は、JNDI API を使用して、LDAP ディレクトリサーバと通信します。構文と、これらのプロパティが参照する用語についての詳細は、JNDI のマニュアルを確認してください。MQ 3.0 では、Sun JNDI LDAP プロバイダと、単一の認証が使用されます。
- imq.authentication.type=basic
プロパティ
説明
imq.user_repository.
ldap.server
LDAP サーバのホスト、およびポート。ホストでは、ディレクトリサーバを実行中の、完全修飾 DNS 名が指定される。ポートでは、ディレクトリサーバが通信に利用しているポート番号が指定される
imq.user_repository.
ldap.principal
検索時にブローカがディレクトリサーバにバインドするために使用する識別名。ディレクトリサーバで匿名検索が可能な場合、このプロパティに値を設定する必要はない
imq.user_repository.
ldap.password
ブローカが使用する識別名と関連付けられたパスワード。このパスワードは passfile 内だけで指定可能 (「passfile の使用」を参照)。さらにセキュリティを強化するには、ブローカがパスワードを求めるように設定するか、あるいは imqbrokerd -ldappassword というコマンド行オプションを使用してパスワードを指定する
imq.user_repository.
ldap.base
imq.user_repository.
ldap.uidattr
imq.user_repository.
ldap.usrfilter
JNDI 検索フィルタ (論理式で表現される検索クエリ)。ユーザに検索フィルタを指定すると、ブローカが検索範囲を絞り込めるので検索効率が上がる。詳細は、次の場所にある JNDI チュートリアルを参照 http://java.sun.com/products/jndi/tutorial
imq.user_repository.
ldap.grpsearch
グループ検索を有効にするかどうかを指定するブール値。ユーザをグループに関連付けるかどうかを決定するには、LDAP プロバイダから提供されているマニュアルを参照
imq.user_repository.
ldap.grpbase
imq.user_repository.
ldap.gidattr
imq.user_repository.
ldap.memattr
imq.user_repository.
ldap.grpfiltler
JNDI 検索フィルタ (論理式で表現される検索クエリ)。グループに検索フィルタを指定すると、ブローカが検索範囲を絞り込めるため検索効率が上がる。詳細は、次の場所にある JNDI チュートリアルを参照
imq.user_repository.
ldap.timeout
imq.user_repository.
ldap.ssl.enabled
LDAP サーバとの通信時にブローカが SSL プロトコルを使用するかどうかを指定するブール値。デフォルトでは false に設定されている
必要に応じて、アクセス制御プロパティファイルにあるユーザまたはグループ、および規則を編集する必要があります。アクセス制御プロパティファイルの使用に関する詳細は、「ユーザの承認: アクセス制御プロパティファイル」を参照してください。
- サンプル (デフォルト) の LDAP ユーザリポジトリ関連プロパティ設定については、ブローカの default.properties ファイルを参照してください。
コネクションの認証やグループ検索の間、ブローカに SSL を使用して LDAP ディレクトリとの通信を行わせる場合、LDAP サーバの SSL をアクティブにし、ブローカ設定ファイルで次のプロパティを設定します。
LDAP ユーザリポジトリプロパティに安全なポートを指定します。たとえば次のように指定します。
ブローカのプロパティ imq.user_repository.ldap.ssl.enabled を true に設定します。
- imq.user_repository.ldap.server=myhost:7878
ユーザの承認: アクセス制御プロパティファイル
ブローカを接続したあと、ユーザがメッセージをプロデュースしたり、送信先でメッセージをコンシュームしたり、あるいはキュー送信先でメッセージを検索したりする場合があります。ユーザがこういった操作を試行すると、ブローカはアクセス制御プロパティファイル (ACL ファイル) をチェックし、ユーザが操作を実行する承認を受けていることを確認します。ACL ファイルには、特定のユーザ (またはユーザのグループ) がどの操作の実行を承認されているかを指定する規則が含まれています。デフォルトでは、すべての承認されたユーザは、任意の送信先でメッセージをプロデュースおよびコンシュームできます。アクセス制御プロパティファイルを編集して、特定のユーザやグループによるこれらの操作を制限できます。ユーザ情報が単層型ファイルリポジトリにあっても、LDAP リポジトリにあっても、ACL ファイルが使用されます。デフォルトの ACL プロパティファイルは、ブローカとともにインストールされます。ACL プロパティファイルの名前は、accesscontrol.properties で、インストーラにより次の場所に配置されます。
ACL ファイルは、Java プロパティファイルのようにフォーマットされています。ACL ファイルは、ファイルのバージョンを指定すると起動し、次の 3 つのセクションのアクセス制御規則を指定します。
- IMQ_HOME/etc (Solaris では /etc/imq)
version プロパティでは、ACL プロパティファイルのバージョンが定義されるので、このエントリを変更しないでください。
アクセス制御を指定する ACL ファイルの 3 つのセクションについては、アクセス規則の基本構文およびアクセス権の計算方法に続いて、説明します。
- version=JMQFileAccessControlModel/100
アクセス規則の構文
ACL プロパティファイルでは、アクセス制御は、特定のユーザやグループが送信先やコネクションサービスといった保護されたリソースに対してどのアクセスを持っているのかを定義します。アクセス制御は、それぞれ Java プロパティとして提示されている規則、または規則のセットで表現されます。
表 8-6 に構文規則の各要素を示します。
- resourceType.resourceVariant.operation.access.principalType = principals
要素
説明
resourceType
resourceVariant
resourceType で指定されたタイプのインスタンス。たとえば、myQueue。ワイルドカードの文字 (*) を、すべてのコネクションサービス、またはすべての送信先を表すのに使用できる
operation
access
principalType
user または group のどちらか。詳細は、「グループ」を参照
principals
規則の左側で指定されるアクセス権を保持するユーザを示す。ここでは、principalType が user の場合は個々のユーザまたはカンマで区切られたユーザのリストとなり、principalType が group の場合は 1 つのグループまたはカンマで区切られたグループのリストとなる。ワイルドカードの文字 (*) を、すべてのユーザまたはすべてのグループを表すのに使用できる
次の規則では、あらゆるユーザがメッセージを ql という名前のキューに送信する
次の規則では、あらゆるユーザがあらゆるキューにメッセージを送信する
- queue.q1.produce.allow.user=*
アクセス権の計算
次の原理は、一連の規則が示すアクセス権を計算するときに適用されます。
特定のアクセス規則は、一般的なアクセス規則をオーバーライドする。次の 2 つの規則が適用されると、ユーザはだれでもすべてのキューに送信できるが、Bob は tq1 に送信できない
明示的な principal に指定されたアクセスは、* principal に指定されたアクセスをオーバーライドする。次の規則では、Bob は tq1 にメッセージをプロデュースできないが、その他のユーザは tq1 にメッセージをプロデュースできる
- queue.*.produce.allow.user=*
- queue.tq1.produce.deny.user=Bob
ユーザの * principal 規則は、グループの対応する * principal 規則をオーバーライドする。たとえば、次の 2 つの規則では、すべての認証済みユーザがメッセージを tq1 に送信できる
- queue.tq1.produce.allow.user=*
- queue.tq1.produce.deny.user=Bob
ユーザに許可されたアクセスは、ユーザのグループに許可されたアクセスをオーバーライドする。次の例では、Bob が User のメンバーである場合、tq1 にメッセージをプロデュースできないが、User のほかのメンバーは tq1 にメッセージをプロデュースできる
- queue.tq1.produce.allow.user=*
- queue.tq1.produce.deny.group=*
アクセスを介して明示的に指定されていないアクセス権は、暗黙的に拒否される。たとえば、ACL ファイルにアクセス規則がない場合、すべてのユーザはすべての操作を実行できない
- queue.tq1.produce.allow.group=User
- queue.tq1.produce.deny.user=Bob
同じユーザまたはグループにアクセス権の拒否と許可を行うと、すべてが取り消される。たとえば、次の 2 つの規則では、結果として Bob が t1 を検索できなくなる
同じ左側の規則が複数ある場合、最後のエントリが有効になる
- queue.q1.browse.allow.user=Bob
- queue.q1.browse.deny.user=Bob
- 次の 2 つの規則では、User というグループが q5 にあるメッセージをコンシュームできなくなる
- queue.q5.consume.allow.group=User
- queue.q5.consume.deny.group=User
コネクションアクセス制御
ACL プロパティファイルのコネクションアクセス制御のセクションには、ブローカのコネクションサービスのアクセス制御規則が含まれます。コネクションアクセス制御規則の構文は次のとおりです。
NORMAL と ADMIN の 2 つの値が、resourceVariant に定義されます。デフォルトでは、すべてのユーザが NORMAL タイプにアクセスできますが、admin グループのユーザは、ADMIN タイプのコネクションサービスにアクセスできます。
- connection.resourceVariant.access.principalType = principals
コネクションアクセス制御規則を編集して、ユーザのコネクションアクセス権限を制限できます。たとえば、次の規則では Bob が NORMAL にアクセスすることは拒否されますが、ほかのユーザはすべてアクセスが許可されます。
アスタリスク (*) 文字を使用して、すべての認証済みユーザまたはグループを指定できます。
- connection.NORMAL.deny.user=Bob
- connection.NORMAL.allow.user=*
自分自身のサービスタイプを作成することは許可されていません。NORMAL と ADMIN の定数で指定された定義済みのタイプに対して自分自身を制限する必要があります。
送信先アクセス制御
アクセス制御プロパティファイルの送信先アクセス制御セクションには、送信先ベースのアクセス制御規則が含まれます。これらの規則では、誰 (ユーザまたはグループ) が何 (操作) をどこ (送信先) に行うかが決定されます。これらの規則で統制されるアクセスのタイプには、キューへのメッセージの送信、トピックへのメッセージの発行、キューからのメッセージの受信、トピックへのサブスクライブ、キューでのメッセージの検索が含まれます。デフォルトでは、あらゆるユーザまたはグループが、任意の送信先に対してあらゆるタイプのアクセス権を保持できます。さらに詳細な送信先アクセス規則を追加したり、デフォルトの規則を編集したりできます。この節の残りの部分では、自分自身の規則を記述するために理解しておく必要のある送信先アクセス規則の構文について説明します。
resourceType.resourceVariant.operation.access.principalType = principals
表 8-7 にこれらの要素の説明を示します。
コンポーネント
説明
resourceType
resourceVariant
operation
access
principalType
アクセスは、1 人以上のユーザまたは 1 つ以上のグループ、あるいはその両方に対して指定できます。
次の例では、さまざまな種類の送信先アクセス制御規則を示します。
すべてのユーザが、あらゆるキュー送信先に対してメッセージを送信できる
user グループのメンバーがトピック Admissions にサブスクライブするのを拒否する
- queue.*.produce.allow.user=*
- topic.Admissions.consume.deny.group=user
送信先自動作成アクセス制御
ACL プロパティファイルの最後のセクションには、どのユーザおよびグループに対してブローカが送信先を自動作成するのかを指定するアクセス規則が含まれます。ユーザがまだ存在していない送信先でプロデューサまたはコンシューマを作成すると、ブローカの自動作成プロパティが有効になっていて、物理的送信先がまだ存在していない場合、ブローカは送信先を作成します。
デフォルトでは、任意のユーザやグループは、ブローカに送信先を自動作成させる権限を持っています。この権限は、次の規則で指定されます。
ACL ファイルを編集して、このタイプのアクセスを制限できます。
- queue.create.allow.user=*
- topic.create.allow.user=*
送信先自動作成アクセス規則の一般的な構文は、次のとおりです。
resourceType の部分には、queue か topic が表示されます。
- resourceType.create.access.principalType = principals
たとえば次の規則により、ブローカは Snoopy 以外の全員に対してトピック送信先を自動作成できます。
送信先自動作成規則の結果は、送信先アクセス規則の影響と一致している必要があります。たとえば、1) 送信先アクセス規則を変更して、どのユーザも送信先にメッセージを送信できないようにしてから、2) 送信先の自動作成を有効にすると、ブローカは送信先が存在しない場合、送信先を作成しますが、メッセージの配信は行いません。
- topic.create.allow.user=*
- topic.create.deny.user=Snoopy
暗号化 : SSL サービスの操作
MQ Enterprise Edition (「製品エディション」を参照) は、TCP/IP (ssljms および ssladmin) や HTTP (httpsjms) を介した SSL (Secure Socket Layer) 標準に基づくコネクションサービスがサポートしています。これらの SSL ベースのコネクションサービスで、クライアントとブローカ間で送信されるメッセージを暗号化できます。現在の MQ リリースでは、自己署名型サーバ証明書に基づく SSL 暗号化をサポートしています。SSL ベースのコネクションサービスを利用するには、キーツールユーティリティ (imqkeytool) を使用して、非公開キーと公開キーの組み合わせを生成する必要があります。このユーティリティは、ブローカへのコネクションを要求しているクライアントに渡される自己署名の証明書に公開キーを埋め込み、クライアントはこの証明書を使用して、コネクションを暗号化します。
MQ の SSL ベースのコネクションサービスはこれと同様の概念ですが、設定の方法に若干の違いがあります。したがって、TCP/IP および HTTP を介した安全なコネクションについては、次に別々に説明します。
TCP/IP を介した SSL サービスの設定
TCP/IP を使用してダイレクトで安全なコネクションを提供する SSL ベースのコネクションサービスには、2 種類あります。
ssljms このコネクションサービスは、クライアントとブローカ間の安全で暗号化されたコネクションを経由した JMS メッセージの配信に使用されます。
ssladmin このコネクションサービスは、コマンド行管理ツールであるコネクションユーティリティ (imqcmd) とブローカ間の、安全で暗号化されたコネクションの確立に使用されます。安全なコネクションは、管理コンソール (imqadmin) に対してサポートされていません。
ssljms および ssladmin コネクションサービスを設定する手順は、手順 4 のクライアントの設定と実行以外は同じです。
手順 1. 自己署名型証明書の生成
MQ 3.0 の SSL Support は、クライアントが既知の信頼されたサーバと通信することを前提に、ネットワーク上のデータを保護することを目的としています。したがって MQ 3.0 では、自己署名型証明書だけを使用して SSL が実装されます。imqkeytool コマンドを実行し、ブローカの自己署名型証明書を生成します。ssljms と ssladmin の両方のコネクションサービスには、同じ証明書が使用されます。コマンドプロンプトで次のとおり入力します。
ユーティリティが、必要な情報を要求します。Unix システムでは、キーストアを作成するアクセス権を取得するためにスーパーユーザ (root) として imqkeytool を実行する必要があります。
- imqkeytool -broker
imqkeytool は、まず、キーストアに対するパスワードの入力を要求します。次に一部の組織情報の入力、続いて確認を要求します。確認が取れると、キーの組み合わせを生成している間、このコマンドは停止します。その後、特定のキーの組み合わせをロックするためのパスワード (キーパスワード) の入力を要求してくるので、Return キーを押します。これで、キーパスワードに、キーストアと同じパスワードが設定されます。
注 設定したパスワードを忘れないでください。あとでブローカを起動したときにキーストアを開くため、そのパスワードを入力する必要があります。また、キーストアパスワードを passfile (「passfile の使用」を参照) に格納できます。
imqkeytool を実行すると、JDK keytool ユーティリティが実行されて、自己署名型証明書が生成されます。生成された証明書は、次の場所にある MQ のキーストアに配置されます。
キーストアは、JDK1.2 keytool ユーティリティでサポートされているのと同じフォーマットになっています。
- IMQ_HOME/etc/keystore (Solaris では /etc/imq/keystore)
MQ キーストアの設定可能なプロパティを表 8-8 に示します。各プロパティの説明については、第 5 章「ブローカの起動と設定」を参照してください。
プロパティ名
説明
imq.keystore.file.
dirpath
SSL ベースのサービスの場合、キーストアファイルを含むディレクトリへのパスを指定する
デフォルトは、IMQ_HOME/etc (Solaris では /etc/imq)imq.keystore.file.name
imq.keystore.password
SSL ベースのサービスの場合、キーストアパスワードを指定する。このパスワードは passfile 内だけで指定可能 (「passfile の使用」を参照)。さらにセキュリティを強化するには、ブローカがパスワードを求めるように設定するか、あるいは imqbrokerd -passwordというコマンド行オプションを使用してパスワードを指定する
たとえば次のような問題を解決するには、キーの組み合わせを生成し直す必要があります。
パスワードを忘れてしまった
ブローカを起動して、次のような例外を受け取ったときに、SSL サービスに障害が発生して初期化されてしまったjava.security.UnrecoverableKeyException: Cannot recover key
- この例外は、自己署名型証明書を 「手順 1. 自己署名型証明書の生成」で生成するときに、キーストアのパスワードと違ったものをキーのパスワードに設定したことが原因で発生する場合があります。
ブローカのキーストアを、次の場所から削除します。
imqkeytool をもう 1 度実行し、「手順 1. 自己署名型証明書の生成」の説明に従って、キーの組み合わせを生成します。
- IMQ_HOME/etc/keystore (Solaris では /etc/imq/keystore)
手順 2. ブローカでの SSL ベースのサービスを有効にする
ブローカでの SSL サービスを有効にするには、ssljms (ssladmin) を imq.service.activelist プロパティに追加する必要があります。
ブローカのインスタンス設定ファイルを開きます。ブローカのインスタンス設定ファイルは、次の場所にあります。
ssljms か ssladmin、またはその両方 (希望するサービスによる) を、imq.service.activelist プロパティに追加します。
- IMQ_VARHOME/instances/brokerName/props/config.properties
- brokerName には、ブローカインスタンスの名前が表示されます。
- imq.service.activelist=jms,admin,httpjms,ssljms,ssladmin
手順 3. ブローカを起動する
キーストアパスワードを入力して、ブローカを起動します。パスワードの入力は、次のいずれかの方法で行います。
ブローカの起動時にパスワードを要求するように許可する
passfile 関連ブローカプロパティの一覧については、表 2-6 を参照してください。
imqbrokerd コマンドに -password オプションを使用する
- imqbrokerd
Please enter Keystore password: mypassword
ブローカの起動時にアクセスする passfile ファイル (「passfile の使用」を参照) にパスワードを入力する。最初に、ブローカ設定プロパティ (「インスタンス設定ファイルの編集」を参照) を次のように設定しておく必要がある
- imqbrokerd -password mypassword
- imq.passfile.enabled=true
- このプロパティが設定されると、次のどちらかの方法で passfile にアクセスできる
imqbrokerd コマンドに passfile の場所を渡す
-passfile オプションを使用せず、次の 2 つのブローカ設定ファイルを使用する passfile の場所を指定して、ブローカを起動する
- imqbrokerd -passfile /tmp/mypassfile
- imq.passfile.dirpath=/tmp
- imq.passfile.name=mypassfile
SSL を使用してブローカまたはクライアントを起動するとき、多くの CPU サイクルが数秒間消費されます。これは、MQ が JSSE (Java Secure Socket Extension) を使用して SSL を実装するためです。JSSE は java.security.SecureRandom() を使用して、ランダムな数を生成します。このメソッドで初期ランダム番号シードを作成するにはかなりの時間がかかり、そのために CPU の使用率が増加します。シードが作成されたあと、CPU レベルは通常に戻ります。
手順 4. SSL ベースのクライアントを設定および実行する
最後にクライアントを設定して、安全なコネクションサービスを使用するようにする必要があります。使用しているコネクションサービスによって、次の 2 つのタイプのクライアントがあります。ssljms を使用する JMS クライアントと、ssladmin を使用する MQ 管理 Command ユーティリティ (imqcmd) です。後続の節では、これらについて次で別個に説明します。
JMS クライアント
クライアントが必要な Secure Socket Extension (JSSE) jar ファイルをクラスパスに保持していることを確認し、このファイルに ssljms コネクションサービスを使用するよう指示する必要があります。
クライアントが JSSE と JNDI のサポートを組み込んだ J2SDK1.4 を使用していない場合、クライアントのクラスパスに次の jar ファイルがあることを確認します。
クライアントのクラスパスに次の MQ jar ファイルがあることを確認します。
- jsse.jar、jnet.jar、jcert.jar、jndi.jar
クライアントを起動し、ブローカの ssljms サービスに接続します。これを行う 1 つの方法として、次のようなコマンドを入力します。
- imq.jar、jms.jar
- java -DimqConnectionType=TLS clientAppName
- imqConnectionType を設定すると、コネクションに SSL を使用するよう指示が出されます。
- クライアントアプリケーションでの ssljms コネクションサービスの使用についての詳細は、『MQ 開発者ガイド』の管理対象オブジェクトの使用に関する章を参照してください。
コマンドユーティリティ (imqcmd)
imqcmd を使用するときに -secure オプションを含めると、安全な管理コネクションを確立できます (表 6-2 を参照)。たとえば、次のように指定します。
adminName と adminPassword には、MQ ユーザリポジトリにある有効なエントリが表示されます (単層型ファイルリポジトリを使用している場合は、「デフォルトの管理者パスワードの変更」を参照)。
- imqcmd list svc -b hostName:port -u adminName -p adminPassword -secure
例のように、コネクションサービスを一覧表示すると、次の出力のように、 ssladmin サービスが実行中で、安全な管理コネクションが問題なく確立されたことがを示されます。
HTTP を介した SSL サービスの設定
SSL ベースのコネクションサービス (httpsjms) では、クライアントとブローカは、HTTPS トンネルサーブレット経由で安全なコネクションを確立します。HTTPS サポートのアーキテクチャと実装は、page 215付録 B 「HTTP/HTTPS サポート」で説明されています。
passfile の使用
ブローカに必要なパスワードを要求させずに起動する場合や、imqbrokerd コマンドのオプションとしてこれらのパスワードの入力を要求させずに起動する場合、必要なパスワードを passfile に置くことができます。passfile は、パスワードを含む簡単なテキストファイルです。ファイルは暗号化されないため、手動でパスワードを入力するより安全性は低くなります。ただし、このファイルにアクセス権を設定して、ファイルにアクセスして表示できるユーザを制限できます。passfile のアクセス権では、ブローカを起動したユーザに読み込みのアクセス権を与える必要があります。
passfile には、表 8-9 に示すパスワードを含めることができます。
パスワード
説明
imq.keystore.password
imq.user_repository.ldap.
password
設定された LDAP ユーザリポジトリにバインドするためにブローカに割り当てられた、識別名に関連するパスワードを指定する
imq.persist.jdbc.password
- IMQ_HOME/etc/passfile.sample (Solaris では、/etc/imq/passfile.sample)
前へ 目次 索引 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
最終更新日 2002 年 6 月 19 日