第 8 章セキュリティの管理

この章では、セキュリティに関連するタスクを実行する方法を説明します。具体的には、認証、承認、および暗号化について取り上げます。

ユーザーの認証管理者は、ユーザー、ユーザーグループ、およびパスワードのリストをユーザーリポジトリに保持しておく責任があります。ブローカインスタンスごとに異なるユーザーリポジトリを使用できます。この章の最初の節では、ユーザーリポジトリの作成、設定、および管理の方法を説明します。Message Queue セキュリティについては、「セキュリティマネージャ」を参照してください。

ユーザーの承認 : アクセス制御プロパティファイル管理者は、アクセス制御プロパティファイルを編集する責任があります。プロパティファイルはブローカ操作へのユーザーのアクセスをユーザー名またはグループメンバーシップにマッピングします。ブローカインスタンスごとに異なるアクセス制御プロパティファイルを使用できます。この章の 2 番目の節では、このプロパティファイルのカスタマイズ方法を説明します。

暗号化 : SSL ベースのサービスとの連動 (Enterprise Edition) SSL (Secure Socket Layer) 標準に基づくコネクションサービスを使用すると、クライアントとブローカ間で送信されるメッセージを暗号化できます。Message Queue による暗号化の処理方法については、「暗号化 (Enterprise Edition)」を参照してください。この章の最後の節では、SSL ベースのコネクションサービスを設定する方法を説明し、SSL 使用に関する追加情報を記載します。

ブローカが SSL キーストア、LDAP ユーザーリポジトリ、または JDBC 準拠の持続ストアへ安全にアクセスするのにパスワードが必要となる状況では、次の 3 つの手段でパスワードを提供します。

ブローカの起動時に、システムがユーザーに要求する

ブローカの起動時に、コマンド行オプションとしてパスワードを渡す (「ブローカの起動」および表 5-2 を参照)

ブローカの起動時にシステムがアクセスする passfile にパスワードを格納する (「passfile の使用」を参照)

ユーザーの認証

ユーザーがブローカへの接続を試みると、ブローカは提供された名前とパスワードを調べて、それぞれ参照するように設定されているブローカ固有のユーザーリポジトリの名前およびパスワードと一致した場合に、コネクションを許可します。このリポジトリには、次の 2 つのタイプがあります。

Message Queue に付属している単層型ファイルリポジトリ

このタイプのユーザーリポジトリはかなり簡単に使用できますが、セキュリティ攻撃に対して脆弱なため、評価および開発を目的とする場合にだけ使用してください。ユーザーマネージャユーティリティ (imqusermgr) を使用してリポジトリを設定および管理します。認証を有効にするには、ユーザーリポジトリにユーザー名、パスワード、およびユーザーグループの名前を設定します。

単層型ファイルユーザーリポジトリを使用する

Message Queue には、単層型ファイルユーザーリポジトリ、コマンド行ツール、および単層型ファイルユーザーリポジトリの設定と管理ができる Message Queue ユーザーマネージャ (imqusermgr) が用意されています。次の節では、単層型ファイルユーザーリポジトリと、そのリポジトリを設定し管理する Message Queue ユーザーマネージャユーティリティ (imqusermgr) の使用方法について説明します。

ユーザーリポジトリの作成

単層型ファイルユーザーリポジトリは、インスタンス固有です。起動するブローカインスタンスごとに、passwd という名前のデフォルトのユーザーリポジトリが作成されます。このユーザーリポジトリは、そのリポジトリが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに書き込まれます (付録 A 「Message Queue データの場所」を参照)。

表 8-1 に示すように、リポジトリは 2 つのエントリ (行) 構成されます。

これらの初期エントリにより、管理者が介入しなくても、インストール後直ちに Message Queue ブローカを使用できます。言い換えれば、Message Queue ブローカを使用する上で、ユーザーやパスワードの初期設定は必要ありません。

表 8-1 ユーザーリポジトリでの初期エントリ
ユーザー名	パスワード	グループ	状態
admin	admin	admin	アクティブ
guest	guest	anonymous	アクティブ

たとえばテストの目的で、初期設定された guest ユーザーエントリを使って、クライアントはデフォルトのユーザー名とパスワード guest でブローカに接続できます。

初期設定された admin ユーザーエントリでは、デフォルトのユーザー名とパスワード admin で、imqcmd コマンドを使用してブローカを管理できます。この初期設定されたエントリを更新して、パスワードを変更することをお勧めします (「デフォルトの管理者パスワードの変更」を参照)。

次の節では、単層型ユーザーリポジトリの設定、および管理方法について説明します。

ユーザーマネージャユーティリティ (imqusermgr)

ユーザーマネージャユーティリティ (imqusermgr) を使って、単層型ファイルユーザーリポジトリを編集したり設定したりできます。

この節では、imqusermgr コマンドの基本構文、サブコマンドのリスト、imqusermgr コマンドのオプションの概要について説明します。後続の節では、imqusermgr サブコマンドを使用して、特定のタスクを実行する方法について説明します。

ブローカ固有のユーザーリポジトリが存在していない場合は、それを作成するために該当するブローカインスタンスを起動する必要がある

imqusermgr コマンドは、ブローカがインストールされているホスト上で実行する必要がある

管理者はリポジトリに書き込むための適切なアクセス権を持っている必要がある。すなわち、Solaris と Linux では、root ユーザーまたは最初にブローカインスタンスを作成したユーザーでなければならない。

imqusermgr コマンドの構文

-v、または -h オプションを指定する場合、そのコマンド行で指定するサブコマンドは実行できません。たとえば、次のコマンドを入力すると、バージョン情報が表示されますが、list サブコマンドは実行されません。

imqusermgr サブコマンド

imqusermgr コマンドのオプションの概要

表 8-2 imqusermgr サブコマンド
サブコマンド	説明
add [-i instanceName] -u userName -p passwd [-g group] [-s]	ユーザーとそのパスワードを指定した、またはデフォルトのブローカインスタンスリポジトリに追加し、オプションでユーザーグループを指定する
delete [-i instanceName] -u userName [-s] [-f]	指定したユーザーを、指定した、またはデフォルトのブローカインスタンスリポジトリから削除する
list [-i instanceName] [-u userName]	指定した、またはデフォルトのブローカインスタンスリポジトリの指定したユーザーまたはすべてのユーザーに関する情報を表示する
update [-i instanceName] -u userName -p passwd [-a state] [-s] [-f] update [-i instanceName] -u userName -a state [-p passwd] [-s] [-f]	指定した、またはデフォルトのブローカインスタンスリポジトリの指定ユーザーのパスワードまたは状態、もしくは両方を更新する


注	次の節の例は、デフォルトのブローカインスタンスを前提としています。

表 8-3 に imqusermgr コマンドのオプションを一覧表示します。

表 8-3 imqusermgr オプション
オプション	説明
-a active_state	ユーザーの状態をアクティブにするかどうかを指定する (true/false)。値が true の場合、状態はアクティブであるデフォルト値は true
-f	ユーザーの確認なしで、アクションを実行する
-h	使用方法に関するヘルプを表示する。コマンド行ではそれ以外のことは実行されない
-i instanceName	コマンドを適用するブローカインスタンスユーザーリポジトリを指定する。指定しない場合は、デフォルトの instanceName、imqbroker が使用される
-p passwd	ユーザーのパスワードを指定する
-g group	ユーザーグループを指定する。指定できる値は、admin、user、anonymous
-s	サイレントモードに設定する
-u userName	ユーザー名を指定する
-v	バージョン情報を表示する。コマンド行ではそれ以外のことは実行されない

グループ

ブローカインスタンスのユーザーリポジトリにユーザーエントリを追加する場合は、オプションでユーザーに定義済みの 3 つのグループ、つまり、admin、user、anonymous のどれかを指定できます。グループが指定されない場合、デフォルトの user が割り当てられます。

admin グループ: ブローカの管理者用。このグループに割り当てられたユーザーは、デフォルトでブローカを設定および管理できるようになっています。管理者は、複数のユーザーを admin グループに割り当てることができます。

user グループ: 管理ユーザーでない Message Queue 通常のクライアントユーザー用。ほとんどのクライアントユーザーは、user グループで認証されたブローカにアクセスします。デフォルトでは、このグループのアプリケーションクライアントユーザーは、あらゆるトピックやキューに対するメッセージのプロデュース、あらゆるトピックやキューからのメッセージのコンシューム、あるいは任意のキューのメッセージの検索を実行できます。

anonymous グループ: ブローカが認識しているユーザー名を使用しない Message Queue クライアント用。クライアントアプリケーションが実際に使用するユーザー名を認識していないなどの理由がある場合に使います。このグループは、多くの FTP サーバにある匿名アカウントに似ています。一度に anonymous グループに割り当てられるのは、1 人のユーザーだけです。user グループと比較してアクセス権を制限するか、配置時にこのグループからユーザーを削除すること推奨します。

ユーザーが属するグループを変更するには、そのユーザーのエントリを削除してから、そのユーザーの別のエントリを追加し、新しいグループを指定します。

状態

ユーザーをリポジトリに追加した場合、デフォルトのユーザーの状態はアクティブです。ユーザーを非アクティブに変更するには、更新コマンドを使用する必要があります。たとえば、次のコマンドでは、ユーザーの JoeD が非アクティブになります。

非アクティブになったユーザーのエントリは、リポジトリに保持されますが、非アクティブのユーザーは、新規コネクションを開くことはできません。ユーザーが非アクティブのときに、同じ名前を持つ別のユーザーを追加すると、操作に障害が発生します。非アクティブなユーザーのエントリを削除するか、新しいユーザーのユーザー名を変更するか、あるいは新しいユーザーに別のユーザー名を使用する必要があります。このようにして、重複するユーザー名が追加されるのを防ぎます。

ユーザー名とパスワードの形式

ユーザー名とパスワードは、次の規則に従う必要があります。

ユーザー名には、表 8-4 に一覧表示されている文字を使用できない

表 8-4 ユーザー名とパスワードに無効な文字
文字	説明
*	アスタリスク
,	カンマ
:	コロン

ユーザー名とパスワードには、改行やキャリッジリターンを文字として使用できない

ユーザー名やパスワードに空白を入れる場合は、ユーザー名やパスワード全体を引用符で囲む

ユーザー名やパスワードは、1 文字以上であることが必要

コマンド行で入力可能な最大文字数で、コマンドシェルにより強制されない限り、パスワードやユーザー名の長さに制限はない

ユーザーリポジトリの設定と管理

add サブコマンドを使用して、ユーザーをリポジトリに追加します。たとえば、次のコマンドでは、sesame というパスワードを持つ Katharine というユーザーがデフォルトのブローカインスタンスユーザーリポジトリに追加されます。

delete サブコマンドを使用して、ユーザーをリポジトリから削除します。たとえば、次のコマンドでは Bob というユーザーが削除されます。

update サブコマンドを使用して、ユーザーのパスワードまたは状態を変更します。たとえば、次のコマンドでは、Katharine のパスワードが alladin に変更されます。

1 人またはすべてのユーザーに関する情報を一覧表示するには、list コマンドを使用します。次のコマンドでは、isa という名前のユーザーに関する情報が表示されます。

次のコマンドでは、すべてのユーザーに関する情報が表示されます。

デフォルトの管理者パスワードの変更

セキュリティのために、admin のデフォルトパスワードを自分だけが知っているパスワードに変更する必要があります。この変更を行うには、imqusermgr ツールを使用します。

次のコマンドは、mybroker ブローカインスタンスのデフォルトのパスワードを grandpoobah に変更します。

ブローカインスタンスの実行中に任意のコマンド行ツールを実行すれば、この変更が反映されていることをすぐに確認できます。たとえば、次のコマンドを実行します。

パスワードを変更したあとは、管理コンソールなどのあらゆる Message Queue 管理ツールを使用するときに、新しいパスワードを使用してください。

ユーザーリポジトリに LDAP サーバを使用する

ユーザーリポジトリに LDAP サーバを使用する場合は、インスタンス設定ファイルで特定のブローカプロパティを設定する必要があります。このプロパティでは、ユーザーがブローカインスタンスへ接続しようとしたり、特定のメッセージング操作を実行したりすると、ブローカインスタンスがユーザーとグループに関する情報について LDAP にクエリーを実行できるようになります。インスタンス設定ファイル (config.properties) は、設定ファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに書き込まれます (付録 A 「Message Queue データの場所」を参照)。

設定ファイルを編集して、LDAP サーバを使用するには

次のプロパティを設定して、LDAP ユーザーリポジトリの使用を指定します。

imq.authentication.basic.user_repository=ldap

imq.authentication.type プロパティを設定して、クライアントからブローカへのパスワードの受け渡しに、base64 暗号化方式 (basic) を使用するか、MD5 ダイジェスト (digest) を使用するかを決定します。LDAP ディレクトリサーバをユーザーリポジトリに使用する場合、認証タイプに basic を設定する必要があります。たとえば、次のように指定します。

imq.authentication.type=basic

LDAP へのアクセスを制御するブローカプロパティを設定する必要もあります。これらのプロパティは、ブローカのインスタンス設定ファイルにあります。表 8-5 の説明を参照してください。Message Queue は、JNDI API を使用して、LDAP ディレクトリサーバと通信します。このプロパティで使用されている構文と用語の詳細については JNDI のドキュメントを参照してください。Message Queue は、Sun JNDI LDAP プロバイダと簡単な認証を使用しています。

Message Queue は、LDAP 認証フェイルオーバーをサポートしているため、認証の対象とする LDAP ディレクトリサーバのリストを指定できます (表 8-5 の imq.user.repos.ldap.server プロパティを参照)。

表 8-5 LDAP 関連プロパティ
プロパティ	説明
imq.user_repository. ldap.server	LDAP サーバの場合、host:port の host にはディレクトリサーバを実行しているホストの完全指定 DNS 名を指定し、port にはディレクトリサーバが通信に使用しているポート番号を指定する。フェイルオーバーサーバのリストを指定するには、次の構文を使用する。 host1:port1 ldap://host2:port2 ldap://host3:port3... リスト内のエントリはスペースで区切る。2 番目以降の各フェイルオーバーサーバアドレスは ldap で始まることに注意する
imq.user_repository. ldap.principal	検索時にブローカがディレクトリサーバにバインドするために使用する識別名。ディレクトリサーバで匿名検索が可能な場合、このプロパティに値を設定する必要はない
imq.user_repository. ldap.password	ブローカが使用する識別名と関連付けられたパスワード。このプロパティは passfile 内だけで指定可能 (「passfile の使用」を参照) さまざまな方法でパスワードを指定できる。もっとも安全な方法は、ブローカプロンプトでパスワードを入力することである。安全性は低くなるが、パスファイルを使用してパスファイルを読み取り保護することもできる。安全性はもっとも低くなるが、次のコマンド行オプションを使用してパスワードを指定することもできる。imqbrokerd -ldappassword ディレクトリサーバで匿名の検索が許可されている場合、パスワードは不要
imq.user_repository. ldap.base	ユーザーエントリのためのディレクトリベース
imq.user_repository. ldap.uidattr	プロバイダ固有の属性識別子で、その値はユーザーを一意に識別する。たとえば、 uid、cn、など
imq.user_repository. ldap.usrfilter	JNDI 検索フィルタ (論理式で表現される検索クエリー)。ユーザーに検索フィルタを指定すると、ブローカが検索範囲を絞り込めるので検索効率が上がる。詳細は、次の場所にある JNDI チュートリアルを参照 http://java.sun.com/products/jndi/tutorial このプロパティの設定は任意
imq.user_repository. ldap.grpsearch	グループ検索を有効にするかどうかを指定するブール値。ユーザーをグループに関連付けるかどうかを決定するには、LDAP プロバイダから提供されているマニュアルを参照ネストされたグループは、Message Queue ではサポートされていないので注意するデフォルト値 : false
imq.user_repository. ldap.grpbase	グループエントリのためのディレクトリベース
imq.user_repository. ldap.gidattr	プロバイダ固有の属性識別子で、その値はグループ名
imq.user_repository. ldap.memattr	グループエントリにある属性識別子で、その値はグループメンバーの識別名
imq.user_repository. ldap.grpfiltler	JNDI 検索フィルタ (論理式で表現される検索クエリー)。グループに検索フィルタを指定すると、ブローカが検索範囲を絞り込めるため検索効率が上がる。詳細は、次の場所にある JNDI チュートリアルを参照 http://java.sun.com/products/jndi/tutorial このプロパティの設定は任意
imq.user_repository. ldap.timeout	検索の時間制限を秒単位で指定する整数。デフォルトでは 180 に設定されている
imq.user_repository. ldap.ssl.enabled	LDAP サーバとの通信時にブローカが SSL プロトコルを使用するかどうかを指定するブール値。デフォルトでは false に設定されている

サンプル (デフォルト) の LDAP ユーザーリポジトリ関連プロパティ設定については、ブローカの default.properties ファイルを参照してください。

必要に応じて、アクセス制御プロパティファイルにあるユーザーまたはグループ、および規則を編集する必要があります。アクセス制御プロパティファイルの使用に関する詳細は、「ユーザーの承認 : アクセス制御プロパティファイル」を参照してください。

コネクションの認証やグループ検索の間、ブローカに SSL を使用して LDAP ディレクトリとの通信を行わせる場合、LDAP サーバの SSL をアクティブにし、ブローカ設定ファイルで次のプロパティを設定します。

LDAP サーバが SSL 通信に使用するポートを指定する。たとえば、次のように指定する

imq.user_repository.ldap.server=myhost:7878

ブローカプロパティの imq.user_repository.ldap.ssl.enabled
を true に設定する

ユーザーの承認 : アクセス制御プロパティファイル

ブローカインスタンスを接続したあと、ユーザーがメッセージをプロデュースしたり、送信先でメッセージをコンシュームしたり、あるいはキュー送信先でメッセージを検索したりする場合があります。ユーザーがこういった操作を試行すると、ブローカはブローカ固有のアクセス制御プロパティファイル (ACL ファイル) をチェックし、ユーザーが操作を実行する承認を受けているか確認します。ACL ファイルには、特定のユーザー (またはユーザーのグループ) がどの操作の実行を承認されているかを指定する規則が含まれています。デフォルトでは、すべての承認されたユーザーは、任意の送信先でメッセージをプロデュースおよびコンシュームできます。ACL ファイルを編集して、特定のユーザーやグループによるこれらの操作を制限できます。

アクセス制御プロパティファイルの作成

ACL ファイルはインスタンス固有です。起動するブローカインスタンスごとに、accesscontrol.properties という名前のデフォルトファイルが作成されます。この ACL プロパティは、その ACL ファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに書き込まれます (付録 A 「Message Queue データの場所」を参照)。

ACL ファイルは、Java プロパティファイルのようにフォーマットされています。ACL ファイルは、ファイルのバージョンを指定すると起動し、次の 3 つのセクションのアクセス制御規則を指定します。

コネクションアクセス制御

送信先アクセス制御

送信先自動作成アクセス制御

version プロパティでは、ACL プロパティファイルのバージョンが定義されるので、このエントリを変更しないでください。

アクセス制御を指定する ACL ファイルの 3 つのセクションについては、アクセス規則の基本構文およびアクセス権の計算方法に続いて、説明します。

アクセス規則の構文

ACL プロパティファイルでは、アクセス制御は、特定のユーザーやグループが送信先やコネクションサービスといった保護されたリソースに対してどのアクセスを持っているのかを定義します。アクセス制御は、それぞれ Java プロパティとして提示されている規則、または規則のセットで表現されます。

表 8-6 アクセス規則の構文要素
要素	説明
resourceType	connection、queue、topic のどれか
resourceVariant	resourceType で指定されたタイプのインスタンス。たとえば、myQueue。ワイルドカードの文字 (*) を、すべてのコネクションサービス、またはすべての送信先を表すのに使用できる
operation	公式化されているアクセス規則の種類に依存する値
access	allow か deny のどちらか
principalType	user か group のどちらか。詳細は、「グループ」を参照
principals	規則の左側で指定されるアクセス権を保持するユーザーを示す。ここでは、principalType が user の場合は個々のユーザーまたはカンマで区切られたユーザーのリストとなり、principalType が group の場合は 1 つのグループまたはカンマで区切られたグループのリストとなる。ワイルドカードの文字 (*) を、すべてのユーザーまたはすべてのグループを表すのに使用できる

次の規則では、あらゆるユーザーがメッセージを ql という名前のキューに送信する

次の規則では、あらゆるユーザーがあらゆるキューにメッセージを送信する

アクセス権の計算

次の原理は、一連の規則が示すアクセス権を計算するときに適用されます。


注	ASCII でないユーザー、グループ、または送信先の名前を指定するには、Unicode エスケープ (¥uXXXX) の表記法を使用する必要があります。ASCII コードではない名前を含む ACL ファイルを編集して、保存した場合、Java native2ascii ツールを使用して、ファイルを ASCII に変換できます。詳細は、http://java.sun.com/j2se/1.4/docs/guide/intl/faq.html を参照してください。

特定のアクセス規則は、一般的なアクセス規則をオーバーライドする。次の 2 つの規則が適用されると、ユーザーはだれでもすべてのキューに送信できるが、Bob は tq1 に送信できない

明示的な principal に指定されたアクセスは、* principal に指定されたアクセスをオーバーライドする。次の規則では、Bob はメッセージをプロデュースできないが、その他のユーザーは tq1 にメッセージをプロデュースできる

ユーザーの * principal 規則は、グループの対応する * principal 規則をオーバーライドする。たとえば、次の 2 つの規則では、すべての認証済みユーザーがメッセージを tq1 に送信できる

ユーザーに許可されたアクセスは、ユーザーのグループに許可されたアクセスをオーバーライドする。次の例では、Bob が User のメンバーである場合、tq1 にメッセージをプロデュースできないが、ほかの User のメンバーはメッセージをプロデュースできる

アクセスを介して明示的に指定されていないアクセス権は、暗黙的に拒否される。たとえば、ACL ファイルにアクセス規則がない場合、すべてのユーザーはすべての操作を実行できない

同じユーザーまたはグループにアクセス権の拒否と許可を行うと、すべてが取り消される。たとえば、次の 2 つの規則では、結果として Bob が q1 を検索できなくなる

同じ左側の規則が複数ある場合、最後のエントリが有効になる

コネクションアクセス制御

ACL プロパティファイルのコネクションアクセス制御のセクションには、ブローカのコネクションサービスのアクセス制御規則が含まれます。コネクションアクセス制御規則の構文は次のとおりです。

resourceVariant には、 NORMAL と ADMIN の 2 つの値が定義されています。デフォルトでは、すべてのユーザーが NORMAL タイプにアクセスできますが、admin グループのユーザーは、ADMIN タイプのコネクションサービスにアクセスできます。

コネクションアクセス制御規則を編集して、ユーザーのコネクションアクセス権限を制限できます。たとえば、次の規則では Bob が NORMAL にアクセスすることは拒否されますが、ほかのユーザーはすべてアクセスが許可されます。

アスタリスク (*) 文字を使用して、すべての認証済みユーザーまたはグループを指定できます。

自分自身のサービスタイプを作成することは許可されていません。NORMAL と ADMIN の定数で指定された定義済みのタイプに対して自分自身を制限する必要があります。

送信先アクセス制御

アクセス制御プロパティファイルの送信先アクセス制御セクションには、送信先ベースのアクセス制御規則が含まれます。これらの規則では、誰 (ユーザーまたはグループ) が何 (操作) をどこ (送信先) に行うかが決定されます。これらの規則で統制されるアクセスのタイプには、キューへのメッセージの送信、トピックへのメッセージの発行、キューからのメッセージの受信、トピックへのサブスクライブ、キューでのメッセージの検索が含まれます。

デフォルトでは、あらゆるユーザーまたはグループが、任意の送信先に対してあらゆるタイプのアクセス権を保持できます。さらに詳細な送信先アクセス規則を追加したり、デフォルトの規則を編集したりできます。この節の残りの部分では、自分自身の規則を記述するために理解しておく必要のある送信先アクセス規則の構文について説明します。

アクセス権は、1 人以上のユーザーまたは 1 つ以上のグループ、あるいはその両方に対して指定できます。

次の例では、さまざまな種類の送信先アクセス制御規則を示します。

表 8-7 送信先アクセス制御規則の要素
コンポーネント	説明
resourceType	queue または topic のどちらか
resourceVariant	送信先名、またはすべてのキューやすべてのトピックを表す全送信先 (*)
operation	produce、consume、または browse のどれか
access	allow または deny のどちらか
principalType	user または group のどちらか

すべてのユーザーが、あらゆるキュー送信先に対してメッセージを送信できる

user グループのメンバーがトピック Admissions にサブスクライブするのを拒否する

送信先自動作成アクセス制御

ACL プロパティファイルの最後のセクションには、どのユーザーおよびグループに対してブローカが送信先を自動作成するのかを指定するアクセス規則が含まれます。

ユーザーがまだ存在していない送信先でプロデューサまたはコンシューマを作成すると、ブローカの自動作成プロパティが有効になっていて、物理的送信先がまだ存在していない場合、ブローカは送信先を作成します。

デフォルトでは、任意のユーザーやグループは、ブローカに送信先を自動作成させる権限を持っています。この権限は、次の規則で指定されます。

ACL ファイルを編集して、このタイプのアクセスを制限できます。

送信先自動作成アクセス規則の一般的な構文は、次のとおりです。

たとえば次の規則により、ブローカは Snoopy 以外の全員に対してトピック送信先を自動作成できます。

送信先自動作成規則の結果は、送信先アクセス規則の影響と一致している必要があります。たとえば、1) 送信先アクセス規則を変更して、どのユーザーも送信先にメッセージを送信できないようにしてから、2) 送信先の自動作成を有効にすると、ブローカは送信先が存在しない場合、送信先を作成しますが、メッセージの配信は行いません。

暗号化 : SSL ベースのサービスとの連動 (Enterprise Edition)

Message Queue Enterprise Edition は、Secure Socket Layer (SSL) 規格に基づいてコネクションサービスをサポートしています。SSL では、TCP/IP (ssljms および ssladmin) と HTTP (httpsjms) を使用できます。これらの SSL ベースのコネクションサービスで、クライアントとブローカ間で送信されるメッセージを暗号化できます。現在の Message Queue リリースでは、自己署名型サーバ証明書に基づく SSL 暗号化をサポートしています。

SSL ベースのコネクションサービスを利用するには、キーツールユーティリティ (imqkeytool) を使用して、非公開キーと公開キーの組み合わせを生成する必要があります。このユーティリティは、ブローカへのコネクションを要求しているクライアントに渡される自己署名の証明書に公開キーを埋め込み、クライアントはこの証明書を使用して、コネクションを暗号化します。

Message Queue の SSL ベースのコネクションサービスはこれと同様の概念ですが、設定の方法に若干の違いがあります。したがって、TCP/IP および HTTP を介した安全なコネクションについては、次に別々に説明します。

TCP/IP を介した SSL ベースのサービスの設定

TCP/IP を使用して直接的で安全なコネクションを提供する SSL ベースのコネクションサービスには、3 種類あります。

ssljms このコネクションサービスは、クライアントとブローカ間の安全で暗号化されたコネクションを経由したメッセージの配信に使用されます。

ssladmin このコネクションサービスは、コマンド行管理ツールである Message Queueコマンドユーティリティ (imqcmd) とブローカ間の、安全で暗号化されたコネクションの確立に使用されます。安全なコネクションは、管理コンソール (imqadmin) に対してサポートされていません。

クラスタ (cluster) このコネクションサービスは、クラスタ内のブローカ間の安全で暗号化されたコネクションを経由したメッセージの配信に使用されます (「ブローカ間の安全なコネクション」を参照)。

SSL ベースのコネクションサービスを設定するには

自己署名型証明書を生成します。

ssljms コネクションサービス、ssladmin コネクションサービス、またはブローカ内のクラスタコネクションサービスを有効にします。

ブローカを起動します。

クライアントを設定し実行します (ssljms コネクションサービスだけに適用)。

ssljms および ssladmin コネクションサービスを設定する手順は、手順 4 のクライアントの設定と実行以外は同じです。

手順 1: 自己署名型証明書の生成

Message Queue の SSL Support は、クライアントが既知の信頼されたサーバと通信することを前提に、ネットワーク上のデータを保護することを目的としています。したがって、自己署名型証明書だけを使用して SSL が実装されます。

imqkeytool コマンドを実行し、ブローカの自己署名型証明書を生成します。ssljms コネクションサービス、ssladmin コネクションサービス、またはクラスタコネクションサービスに対して同じ証明書を使用できます。コマンドプロンプトで次のとおり入力します。

ユーティリティが、必要な情報を要求します。UNIX�システムでは、キーストアを作成するアクセス権を取得するためにスーパーユーザー (root) として imqkeytool を実行する必要があります。

imqkeytoolは、まず、キーストアに対するパスワードの入力を要求します。次に一部の組織情報の入力、続いて確認を要求します。確認が取れると、キーの組み合わせを生成している間、このコマンドは停止します。その後、特定のキーの組み合わせをロックするためのパスワード (キーパスワード) の入力を要求してくるので、Return キーを押します。これで、キーパスワードに、キーストアと同じパスワードが設定されます。


注	設定したパスワードを忘れないでください。あとでブローカを起動したときにキーストアを開くため、そのパスワードを入力する必要があります。また、キーストアパスワードを passfile (「passfile の使用」を参照) に格納できます。

imqkeytool を実行すると、JDK keytool ユーティリティが実行されて、自己署名型証明書が生成されます。生成された証明書は、付録 A 「Message Queue データの場所」に記載されているとおり、オペレーティングシステムに応じたディレクトリにある Message Queue のキーストアに配置されます。

キーストアは、JDK1.2 keytool ユーティリティでサポートされているのと同じフォーマットになっています。

Message Queue キーストアの設定可能なプロパティを表 8-8 に示します。各プロパティの設定に関する説明は、第 5 章「ブローカの起動と設定」を参照してください。

たとえば次のような問題を解決するには、キーの組み合わせを生成し直す必要があります。

表 8-8 キーストアのプロパティ
プロパティ名	説明
imq.keystore.file. dirpath	SSL ベースのサービスの場合は、キーストアファイルが配置されているディレクトリへのパスを指定する。デフォルト値 : 付録 A 「Message Queue データの場所」を参照
imq.keystore.file.name	SSL ベースのサービスの場合は、キーストアファイル名を指定するデフォルト値 : keystore
imq.keystore.password	SSL ベースのサービスの場合は、キーストアのパスワードを指定する。このプロパティは passfile 内だけで指定可能 (「passfile の使用」を参照) さまざまな方法でパスワードを指定できる。もっとも安全な方法は、ブローカプロンプトでパスワードを入力することである。安全性は低くなるが、パスファイルを使用してパスファイルを読み取り保護することもできる。安全性はもっとも低くなるが、次のコマンド行オプションを使用してパスワードを指定することもできる。imqbrokerd -ldappassword

パスワードを忘れてしまった

ブローカの起動時に、SSL ベースのサービスが初期化に失敗し、次の例外を受け取った
java.security.UnrecoverableKeyException:Cannot recover key.

キーの組み合わせを生成し直すには

付録 A 「Message Queue データの場所」に示すとおり、ブローカのキーストアを削除します。

imqkeytool をもう 1 度実行し、「手順 1: 自己署名型証明書の生成」の説明に従って、キーの組み合わせを生成します。

手順 2: ブローカでの SSL ベースのサービスを有効にする

ブローカでの SSL ベースのサービスを有効にするには、ssljms (または、ssladmin) を imq.service.activelist プロパティに追加する必要があります。

ブローカで SSL ベースのサービスを有効にするには


注	imq.service.activelist プロパティではなく、imq.cluster.transport プロパティを使用して、SSL ベースの cluster コネクションサービスを有効にします。「ブローカ間の安全なコネクション」を参照

ブローカのインスタンス設定ファイルを開きます。

インスタンス設定ファイルは、その設定ファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに書き込まれます (付録 A 「Message Queue データの場所」を参照)。

.../instances/instanceName/props/config.properties

存在していない場合は、imq.service.activelist プロパティのエントリを追加し、SSL ベースのサービスをリストに含めます。

デフォルトでは、プロパティには jms コネクションサービスと admin コネクションサービスが含まれます。アクティブ化するサービスに応じて、ssljms コネクションサービスか ssladmin コネクションサービス、またはその両方を追加する必要があります。

imq.service.activelist=jms,admin,ssljms,ssladmin

手順 3: ブローカを起動する

キーストアパスワードを入力して、ブローカを起動します。パスワードの入力は、次のいずれかの方法で行います。

ブローカの起動時にパスワードを要求するように許可する

imqbrokerd コマンドに -password オプションを使用する

ブローカの起動時にアクセスする passfile ファイル (「passfile の使用」を参照) にパスワードを入力する。最初に、ブローカ設定プロパティ (「インスタンス設定ファイルの編集」を参照) を次のように設定しておく必要がある

passfile 関連ブローカプロパティの一覧については、表 2-6 を参照してください。

SSL を使用してブローカまたはクライアントを起動するとき、多くの CPU サイクルが数秒間消費されます。これは、Message Queue が JSSE (Java Secure Socket Extension) を使用して SSL を実装するためです。JSSE は java.security.SecureRandom() を使用して、ランダムな数を生成します。このメソッドで初期ランダム番号シードを作成するにはかなりの時間がかかり、そのために CPU の使用率が増加します。シードが作成されたあと、CPU レベルは通常に戻ります。

手順 4: SSL ベースのクライアントを設定および実行する

最後にクライアントを設定して、安全なコネクションサービスを使用するようにする必要があります。使用しているコネクションサービスによって、次の 2 つのタイプのクライアントがあります。ssljms を使用するアプリケーションクライアントと、ssladmin を使用する imqcmd などの Message Queue 管理クライアントです。後続の節では、これらについて次で別個に説明します。

アプリケーションクライアント

クライアントが必要な Secure Socket Extension (JSSE) jar ファイルをクラスパスに保持していることを確認し、このファイルに ssljms コネクションサービスを使用するよう指示する必要があります。

クライアントが JSSE と JNDI のサポートを組み込んだ J2SDK1.4 を使用していない場合、クライアントのクラスパスに次の jar ファイルがあることを確認します。

jsse.jar、jnet.jar、jcert.jar、jndi.jar

クライアントのクラスパスに次の Message Queue jar ファイルがあることを確認します。

imq.jar、jms.jar

クライアントを起動し、ブローカの ssljms サービスに接続します。これを行う 1 つの方法として、次のようなコマンドを入力します。

java -DimqConnectionType=TLS clientAppName

imqConnectionType を設定すると、コネクションに SSL を使用するよう指示が出されます。

クライアントアプリケーションでの ssljms コネクションサービスの使用についての詳細は、『Message Queue Java Client Developer's Guide』の管理対象オブジェクトの使用に関する章を参照してください。

管理クライアント (imqcmd)

imqcmd を使用するときに -secure オプションを含めると、安全な管理コネクションを確立できます (表 6-2 を参照)。たとえば、次のように指定します。

adminName と adminPassword には、Message Queue ユーザーリポジトリ内の有効なエントリを指定します。単層型ファイルリポジトリを使用している場合は、「デフォルトの管理者パスワードの変更」を参照してください。

コネクションサービスを一覧表示すると、次の出力のように、ssladmin サービスが実行中で、安全な管理コネクションが問題なく確立されたことが示されます。

HTTP を介した SSL サービスの設定

SSL ベースのコネクションサービス (httpsjms) では、クライアントとブローカは、HTTPS トンネルサーブレット経由で安全なコネクションを確立します。HTTPS サポートのアーキテクチャと実装は、付録 C 「HTTP/HTTPS サポート (Enterprise Edition)」で説明されています。

passfile の使用

ブローカに必要なパスワードを要求させずに起動する場合や、imqbrokerd コマンドのオプションとしてこれらのパスワードの入力を要求させずに起動する場合、必要なパスワードを passfile に置くことができます。その後、ブローカの起動時に -passfile オプションを使用して、この passfile を指定できます。

passfile は、パスワードを含む簡単なテキストファイルです。ファイルは暗号化されないため、手動でパスワードを入力するより安全性は低くなります。ただし、このファイルにアクセス権を設定して、ファイルにアクセスして表示できるユーザーを制限できます。ブローカを起動したユーザーに対して読み取りアクセスを許可するように、passfile にアクセス権を設定する必要があります。

passfile には、表 8-9 に示すパスワードを含めることができます。

表 8-9 passfile のパスワード
パスワード	説明
imq.keystore.password	SSL ベースのサービスにキーストアパスワードを指定する (表 8-8 を参照)
imq.user_repository.ldap. password	設定された LDAP ユーザーリポジトリにバインドするためにブローカに割り当てられた、識別名に関連するパスワードを指定する (表 8-5 を参照)
imq.persist.jdbc.password	必要に応じて、データベースコネクションを開くためのパスワードを指定する (表 B-1 を参照)

passfile のサンプルは、付録 A 「Message Queue データの場所」に示すとおり、オペレーティングシステムに応じて該当する場所に格納されています。

前へ目次索引次へ
Sun Java System Message Queue 3.5 SP1 管理ガイド