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

管理者は、ユーザーの認証に使用するユーザーリポジトリの設定、アクセス制御の定義、クライアントブローカ間の通信を暗号化する SSL (Secure Socket Layer) 接続サービスの設定、ブローカ起動時に使用するパスファイルの設定を行います。

ユーザーの認証

管理者は、ユーザー、ユーザーグループ、およびパスワードのリストをユーザーリポジトリに保持しておく責任があります。ブローカインスタンスごとに異なるユーザーリポジトリを使用できます。この節では、リポジトリの作成、設定、および管理の方法を説明します。

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

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

このタイプのユーザーリポジトリは、非常に簡単に扱えます。ユーザーマネージャユーティリティ (imqusermgr) を使用してリポジトリを設定および管理します。認証を有効にするには、ユーザーリポジトリにユーザー名、パスワード、およびユーザーグループの名前を設定します。

このリポジトリは、LDAP v2 または v3 プロトコルを使用する既存または新規の LDAP ディレクトリサーバーです。単層型ファイルリポジトリほど使用方法は簡単ではありませんが、よりスケーラブルなため、本稼動環境に適しています。

LDAP ユーザーリポジトリを使用している場合、LDAP ベンダーから提供されているツールを使用して、ユーザーリポジトリを設定、管理します。詳細は、「ユーザーリポジトリに LDAP サーバーを使用する」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

ユーザーマネージャユーティリティ (imqusermgr) を使って、単層型ファイルユーザーリポジトリを編集したり設定できます。この節では、ユーザーマネージャユーティリティについて説明します。後続の節では、imqusermgr サブコマンドを使用して、特定のタスクを実行する方法について説明します。

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

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

リポジトリへの書き込みに関する適切なアクセス権を持つ必要があります。たとえば、Solaris と Linux の場合、root ユーザーまたはブローカインスタンスを最初に作成したユーザーになる必要があります。



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

サブコマンド

imqusermgr コマンドには、add、delete、list、update といったサブコマンドがあります。

add サブコマンド add サブコマンドは、ユーザーとそのパスワードを指定した、またはデフォルトのブローカインスタンスリポジトリに追加し、オプションでユーザーグループを指定します。このサブコマンドの構文は次のようになります。

delete サブコマンド delete サブコマンドは、指定したユーザーを、指定した、またはデフォルトのブローカインスタンスリポジトリから削除します。このサブコマンドの構文は次のようになります。

list サブコマンド list サブコマンドは、指定した、またはデフォルトのブローカインスタンスリポジトリの指定したユーザーまたはすべてのユーザーに関する情報を表示します。このサブコマンドの構文は次のようになります。

update サブコマンド update サブコマンドは、指定した、またはデフォルトのブローカインスタンスリポジトリの指定ユーザーのパスワードまたは状態、もしくは両方を更新します。このサブコマンドの構文は次のようになります。

コマンドオプション

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

表 7-2 imqusermgr オプション
オプション	説明
-a active_state	ユーザーの状態をアクティブにするかどうかを指定します (true/false)。値が true の場合、状態はアクティブです。デフォルト値は true です。
-f	ユーザーの確認なしで、アクションを実行します。
-h	使用方法に関するヘルプを表示します。コマンド行ではそれ以外のことは実行されません。
-i 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 が非アクティブになります。

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

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

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

ユーザー名にアスタリスク (*)、コンマ (,)、コロン (;)、改行やキャリッジリターンを使用することはできません。

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

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

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

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

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

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

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

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

imqusermgr list -u isa

% imqusermgr list -u isa

User repository for broker instance: imqbroker

----------------------------------

User Name Group Active State

----------------------------------

isa admin true

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

imqusermgr list

% imqusermgr list

User repository for broker instance: imqbroker

--------------------------------------

User Name Group Active State

--------------------------------------

admin admin true

guest anonymous true

isa admin true

testuser1 user true

testuser2 user true

testuser3 user true

testuser4 user false

testuser5 user false

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

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

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

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

新しいパスワード (grandpoobah) は入力可能であり、古いパスワードでは失敗します。

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

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

ユーザーリポジトリに LDAP サーバーを使用する場合、次の作業を実行します。

インスタンス設定ファイルの編集

管理者のアクセス制御の設定

インスタンス設定ファイルの編集

ブローカでディレクトリサーバーを使用する場合、ブローカインスタンス設定ファイル config.properties で特定のプロパティの値を設定します。これらのプロパティを使用すると、ブローカインスタンスが LDAP サーバーに対してユーザーおよびグループに関する情報をクエリーできるようになります。ブローカは LDAP サーバーに対して、ユーザーがブローカインスタンスへの接続を試みているか、特定のメッセージング操作を実行しようとしているかクエリーします。

インスタンス設定ファイルは、ブローカインスタンスディレクトリのディレクトリ内にあります。パスは次のような形式です。

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

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

imq.authentication.basic.user_repository=ldap

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

imq.authentication.type=basic

LDAP へのアクセスを制御するブローカプロパティを設定する必要もあります。このプロパティは、ブローカインスタンス設定ファイル内にあります。プロパティについては、この節の後半でまとめて説明しています。

Message Queue は JNDI API を使用して、LDAP ディレクトリサーバーと対話します。このプロパティで使用されている構文と用語の詳細については JNDI のドキュメントを参照してください。Message Queue は、Sun JNDI LDAP プロバイダと簡単な認証を使用しています。

Message Queue は LDAP 認証のフェイルオーバーをサポートします。認証が試みられる LDAP ディレクトリサーバーのリストを指定できます (imq.user.repos.ldap.server プロパティの詳細を参照)。

LDAP ユーザーリポジトリに関連したプロパティの設定方法の例については、ブローカの config.properties ファイルを参照してください。

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

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

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

imq.user_repository.ldap.server=myhost:7878

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

imq.user_repository.ldap.server。LDAP サーバーの host:port です。

imq.user_repository.ldap.principal。検索時にブローカがディレクトリサーバーにバインドするために使用する識別名です。

imq.user_repository.ldap.password。ブローカが使用する識別名と関連付けられたパスワードです。

imq.user_repository.ldap.base。ユーザーエントリのためのディレクトリベースです。

imq.user_repository.ldap.uidattr。プロバイダ固有の属性識別子。その値はユーザーを一意に識別します。たとえば、次のように指定します。
uid, cn

imq.user_repository.ldap.usrfilter。ユーザーとともに使用する JNDI 検索フィルタです。

imq.user_repository.ldap.grpsearch。グループ検索を有効にするかどうかを指定するブール値です。

imq.user_repository.ldap.grpbase。グループエントリのためのディレクトリベースです。

imq.user_repository.ldap.gidattr。プロバイダ固有の属性識別子。その値はグループ名です。

imq.user_repository.ldap.memattr。グループエントリにある属性識別子。その値はグループメンバーの識別名です。

imq.user_repository.ldap.grpfiltler。グループとともに使用する JNDI 検索フィルタです。

imq.user_repository.ldap.timeout。検索の時間制限を秒単位で指定する整数です。

imq.user_repository.ldap.ssl.enabled。LDAP サーバーとの通信時にブローカが SSL プロトコルを使用するかどうかを指定するブール値です。

管理者のアクセス制御の設定

管理ユーザーを作成するには、アクセス制御プロパティファイルで、ADMIN コネクションを作成できるユーザーとグループを指定します。これらのユーザーとグループは、LDAP ディレクトリで事前に定義されている必要があります。

ADMIN コネクションを作成できるユーザーまたはグループは、管理コマンドを発行できます。

管理ユーザーを設定する

アクセス制御ファイルの使用を有効にするには、ブローカプロパティ imq.accesscontrol.enabled を、デフォルト値である true に設定します。

imq.accesscontrol.enabled プロパティにより、アクセス制御ファイルの使用が有効になります。

アクセス制御ファイル accesscontrol.properties を開きます。このファイルの場所については、付録 A 「オペレーティングシステムごとの Message Queue データの場所」の一覧を参照してください。

このファイルには、次のようなエントリが収められています。

サービスコネクションアクセス制御
##################################
connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admin

上記のエントリは一例です。admin グループはファイルベースのユーザーリポジトリに存在しますが、デフォルトでは LDAP ディレクトリに存在しないことに注意してください。LDAP ディレクトリで定義される、Message Queue 管理者権限を付与するグループの名前は変更する必要があります。

Message Queue 管理者権限をユーザーに付与するには、ユーザー名を次のように入力します。

connection.ADMIN.allow.user=userName[,userName2,..]

Message Queue 管理者権限をグループに付与するには、グループ名を次のように入力します。

connection.ADMIN.allow.group=groupName[,groupName2,..]

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

アクセス制御プロパティファイル (ACL ファイル) には、ユーザーおよびユーザーグループがどの操作を実行できるかを指定する規則が収められています。ACL ファイルを編集して、操作を特定のユーザーやグループに制限します。ブローカインスタンスごとに異なる ACL ファイルを使用できます。

ブローカは、クライアントアプリケーションが次の操作のいずれかを実行するときに ACL ファイルをチェックします。

コネクションの作成

プロデューサの作成

コンシューマの作成

キューの検索

ブローカは ACL ファイルをチェックして、要求を生成したユーザーまたはユーザーが所属するグループに対して、操作の実行を許可するかどうかを決定します。

ACL ファイルを編集する場合、次にブローカがファイルをチェックして認証を検証するまで、新しい設定は有効になりません。ファイルの編集後、ブローカを再起動する必要はありません。

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

ACL ファイルはインスタンス固有です。ブローカインスタンスを起動する場合は常に、インスタンスディレクトリでデフォルトファイル accesscontrol.properties が作成されます。ファイルのパスは次のような形式です (付録 A 「オペレーティングシステムごとの Message Queue データの場所」を参照)。

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

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

物理的送信先のアクセス制御

物理的送信先の自動作成アクセス制御

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

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

アクセス規則の構文

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

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

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

queue.q1.produce.allow.user=*

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

queue.*.produce.allow.user=*



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

権限の計算方法

ファイル内に複数のアクセス規則が存在する場合、権限を次のように計算します。

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

queue.*.produce.allow.user=*

queue.tq1.produce.deny.user=Bob

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

queue.tq1.produce.allow.user=*

queue.tq1.produce.deny.user=Bob

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

queue.tq1.produce.allow.user=*

queue.tq1.produce.deny.group=*

ユーザーに許可されたアクセスは、ユーザーのグループに許可されたアクセスをオーバーライドする。次の例では、Bob が User のメンバーである場合でも、tq1 へのメッセージは生成できません。User のその他のメンバーはすべて、メッセージを生成できます。

queue.tq1.produce.allow.group=User

queue.tq1.produce.deny.user=Bob

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

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

queue.q1.browse.allow.user=Bob

queue.q1.browse.deny.user=Bob

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

コネクションサービスのアクセス制御

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

resourceVariant には、 NORMAL と ADMIN の 2 つの値が定義されています。これらの定義済みの値は、アクセス権を付与できる唯一のタイプのコネクションサービスです。

デフォルトの ACL プロパティファイルは、すべてのユーザーに NORMAL コネクションサービスへのアクセス権を付与し、グループ admin のユーザーに ADMIN コネクションサービスへのアクセス権を付与します。

ファイルベースのユーザーリポジトリを使用している場合、imqusermgr によりデフォルトのグループ admin が作成されます。LDAP ユーザーリポジトリを使用している場合、次のいずれかを実行して、デフォルトの ACL プロパティファイルを使用します。

LDAP ディレクトリでグループ admin を定義する。

ACL プロパティファイルの名前 admin を、LDAP ディレクトリで定義される 1 つ以上のグループの名前と置換する。

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

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

ACL プロパティファイルを使用して ADMIN コネクションへのアクセスを付与する方法は、次のように、ファイルベースのユーザーリポジトリと LDAP ユーザーリポジトリでは異なります。

ファイルベースのユーザーリポジトリ

アクセス制御が無効に設定されている場合、グループ admin には ADMIN コネクション権限が割り当てられます。

アクセス制御が有効な場合、ACL ファイルを編集します。ユーザーまたはグループに、ADMIN コネクションサービスへのアクセス権を明示的に付与します。

LDAP ユーザーリポジトリ。LDAP ユーザーリポジトリを使用している場合、次のいずれかを実行します。

アクセス制御を有効にします。

ACL ファイルを編集して、ADMIN コネクションを作成できるユーザーまたはグループの名前を指定します。LDAP ディレクトリサーバーで定義されるユーザーまたはグループを指定します。

物理的な送信先のアクセス制御

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

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

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

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

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

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

queue.*.produce.allow.user=*

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

topic.Admissions.consume.deny.group=user

自動作成された物理的送信先のアクセス制御

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

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

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

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

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

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

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

SSL ベースのサービスの操作

SSL (Secure Socket Layer) 標準に基づくコネクションサービスは、クライアントとブローカ間で暗号化されるメッセージを送信します。この節では、SSL ベースのコネクションサービスの設定方法を説明します。

Message Queue は、SSL (Secure Socket Layer) 規格に基づく次のコネクションサービスをサポートしています。

ssljms, ssladminと cluster は、TCP/IP で使用される。

httpsjms は HTTP で使用される。

これらのコネクションサービスにより、クライアントとブローカ間で送信されるメッセージが暗号化されます。Message Queue は、自己署名型サーバー証明書または自己署名型証明書に基づく SSL 暗号化をサポートしています。

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

Message Queue の SSL ベースのコネクションサービスはこれと同様の概念ですが、設定の方法に若干の違いがあります。

この節の後半では、TCP/IP で安全なコネクションを設定する方法について説明します。

HTTP を使用するユーザー向けの SSL ベースのコネクションサービス httpsjms では、クライアントとブローカが HTTPS トンネルサーブレットを使用して安全なコネクションを確立できます。HTTP を使用した安全なコネクションの確立の詳細は、付録 C 「HTTP/HTTPS のサポート」を参照してください。

TCP/IP を介した安全なコネクションサービス

次の SSL ベースのコネクションサービスは、TCP/IP を介した直接的で安全なコネクションを提供します。

ssljms サービスは、クライアントとブローカ間で安全な暗号化コネクションを介してメッセージを配信します。

ssladmin サービスは、Message Queue コマンドユーティリティ (imqcmd) とブローカ間に安全な暗号化コネクションを作成します。安全なコネクションは、管理コンソール (imqadmin) に対してサポートされていません。

cluster サービスは、メッセージを配信し、クラスタ内のブローカ間に安全な暗号化コネクションを介したブローカ間通信を確立します (「ブローカ間の安全なコネクション」を参照)。

自己署名型証明書の使用の設定

この節では、自己署名型証明書を使用した SSL ベースのサービスの設定方法を説明します。

認証を強力なものにするために、認証局が検証する署名付き証明書を使用できます。まずこの節の手順に従い、次に「署名付き証明書の使用の設定」に進んで、追加手順を実行します。

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

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

ブローカで ssljms、ssladmin、cluster のいずれかのコネクションサービスを有効にする。

ブローカを起動する。

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

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

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

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

imqkeytool コマンドを実行し、ブローカの自己署名型証明書を生成します。UNIX® システムでは、キーストアを作成するアクセス権を取得するためにスーパーユーザー (root) として imqkeytool を実行する必要があります。

ssljms、ssladmin、cluster のコネクションサービスに対して、同じ証明書を使用できます。

ユーティリティがキーストアのパスワードの入力を要求します。

次に、ユーティリティは証明書の所有者である、ブローカを識別する情報の入力を要求します。指定する情報は、X.500 識別名になります。次の表にプロンプトの一覧とその説明、および各プロンプトの例を示します。値は大文字と小文字を区別し、空白を使用できます。

表 7-5 自己署名型証明書に必要な識別名情報
プロンプト	説明	例
氏名	X.500 commonName (CN)。ブローカを実行しているサーバーの完全修飾名を入力します。	myhost.sun.com
組織名	X.500 organizationUnit (OU)。部署または部門の名前を入力します。	purchasing
組織名	X.500 organizationName (ON)。企業または政府機関などの大規模組織の名前です。	My Company, Inc.
市町村名	X.500 localityName (L)。	San Francisco
州名または県名	X.500 stateName (ST)。頭語ではなく、州または県の完全名を入力します。	California
組織の 2 文字国コード	X.500 country (C)。	US

情報を入力し終えたら、imqkeytool により確認の画面が表示されます。たとえば、次のように指定します。

値を再入力する場合は、デフォルトを使用するか no を入力します。現在の値でよければ、先に進み、yes を入力します。確認後、imqkeytool がキーの組み合わせを生成する間、このツールは停止します。

次に、imqkeytool から特定のキーの組み合わせをロックするためのパスワードの入力が要求されます (キーパスワード)。このプロンプトに対して Return キーを押し、キーパスワードおよびキーストアパスワードと同じパスワードを使用します。


注	指定したパスワードは覚えておいてください。ブローカの起動時にこのパスワードを指定し、ブローカがキーストアを開けるようにする必要があります。また、キーストアパスワードを passfile (「passfile の使用」を参照) に格納できます。

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

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

次に示すのは Message Queue キーストアの設定可能なプロパティです。

imq.keystore.file.dirpath。SSL ベースのサービスの場合は、キーストアファイルが配置されているディレクトリへのパスを指定します。デフォルト値については、付録 A 「オペレーティングシステムごとの Message Queue データの場所」を参照してください。

imq.keystore.file.name。SSL ベースのサービスの場合は、キーストアファイル名を指定します。

imq.keystore.password。SSL ベースのサービスの場合は、キーストアのパスワードを指定します。

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

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

ブローカの起動時に例外 java.security.UnrecoverableKeyException: Cannot recover key が発生し、SSL ベースのサービスの初期化に失敗した。

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

付録 A 「オペレーティングシステムごとの Message Queue データの場所」に示すとおり、ブローカのキーストアを削除します。

imqkeytool をもう一度実行し、「手順 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
Please enter Keystore password:mypassword

「passfile の使用」の説明に従って、パスワードをパスファイルに格納する。パスワードをパスファイルに格納し、プロパティ imq.passfile.enabled=true を設定した後で次のいずれかを実行します。

imqbrokerd コマンドに passfile の場所を渡す。

imqbrokerd -passfile /tmp/mypassfile

-passfile オプションを使用せず、次の 2 つのブローカ設定プロパティを使用する passfile の場所を指定して、ブローカを起動する。

imq.passfile.dirpath=/tmp

imq.passfile.name=mypassfile

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

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

最後に安全なコネクションサービスを使用するように、クライアントを設定します。TCP/IP を使用した安全なコネクションには、2 つのシナリオが考えられます。

ssljms を使用するアプリケーションクライアント

ssladmin を使用する Message Queue 管理クライアント (imqcmd など)

ssljms を使用するアプリケーションクライアント

クライアントが必要な JSSE (Java Secure Socket Extension) 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 Developer's Guide for Java Clients』の管理対象オブジェクトの使用に関する章を参照してください。

ssladmin を使用する管理クライアント (imqcmd)

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

adminName には Message Queue ユーザーリポジトリの有効なエントリが入り、コマンドからパスワードの入力が要求されます (単層型ファイルリポジトリを使用している場合は、「デフォルトの管理者パスワードの変更」を参照)。

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

Listing all the services on the broker specified by:

Host Primary Port

localhost 7676

Service Name Port Number Service State

admin 33984 (dynamic) RUNNING

httpjms - UNKNOWN

httpsjms - UNKNOWN

jms 33983 (dynamic) RUNNING

ssladmin 35988 (dynamic) RUNNING

ssljms dynamic UNKNOWN

Successfully listed services.

署名付き証明書の使用の設定

署名付き証明書は、自己署名型証明書よりも強力なサーバー認証をもたらします。署名付き証明書を実装するには、キーストアに署名付き証明書をインストールし、Message Queue クライアントが imqbrokerd との SSL コネクションを確立するときに、署名付き証明書を要求するように設定します。

署名付き証明書はクライアントとブローカ間でのみ実装可能で、クラスタ内の複数のブローカ間に実装できません。

次の手順では、「自己署名型証明書の使用の設定」に文書化した手順を実行しているものと仮定しています。手順に従う際に、J2SE キーツール証明書と X.509 証明書に関する情報を http://java.sun.com で確認しておくと役に立つ場合があります。

手順 1: 署名付き証明書の取得とインストール

署名付き証明書を取得する

J2SE キーツールを使用して、前節で作成した自己署名型証明書の CSR (Certificate Signing Request) を生成します。

次に例を示します。

keytool -certreq -keyalg RSA -alias imq -file certreq.csr
-keystore /etc/imq/keystore -storepass myStorePassword

CSR は次にファイル certreq.csr に証明書をカプセル化します。

次のいずれかの方法で、署名付き証明書を作成するか要求します。

Thawte や Verisign などの非常に著名な認証局 (CA) から、証明書に署名してもらいます。このプロセスの詳細は、CA のマニュアルを参照してください。

SSL 署名ソフトウェアパッケージを使用して、証明書に自己署名を行います。

最終的な署名付き証明書は、ASCII 文字列が連続したものになります。CA から署名付き証明書を受け取る場合、電子メールの添付またはテキスト形式のメッセージとして到着します。

署名付き証明書を取得した場合、ファイルに保存します。

次の手順では、ブローカの証明書に broker.cer という名前が使用されています。

署名付き証明書をインストールする

$JAVA_HOME/lib/security/cacerts で、次のコマンドを使用して、J2SE がデフォルトで使用中の CA をサポートしているかどうかを確認します。

keytool -v -list -keystore $JAVA_HOME/lib/security/cacerts

このコマンドは、システムキーストアの root CA を一覧表示します。

使用中の CA がリスト内に見つかったら、次の手順は省略してください。

使用中の CA が J2SE でサポートされていない場合、認証局の root 証明書を imqbrokerd キーストアにインポートします。

次に例を示します。

keytool -import -alias ca -file ca.cer -noprompt -trustcacerts
-keystore /etc/imq/keystore -storepass myStorePassword

値 ca.cer は、CA から入手した CA root 証明書です。

CA テスト証明書を使用している場合、Test CA Root 証明書をインポートする必要があるかもしれません。CA には、Test CA Root のコピーの入手方法に関する手順が示されているはずです。

署名付き証明書をキーストアにインポートし、オリジナルの自己署名型証明書と置き換えます。

たとえば、次のように指定します。

keytool -import -alias imq -file broker.cer -noprompt -trustcacerts
-keystore /etc/imq/keystore -storepass myStorePassword

値 broker.cer は、CA から受け取った署名付き証明書を含むファイルです。

imqbrokerd キーストアに、SSL コネクションに使用できる署名付き証明書が格納されました。

手順 2: 署名付き証明書を要求するクライアントランタイムの設定

Java クライアントランタイムを設定する

デフォルトでは、Message Queue クライアントランタイムは imqbrokerd を信頼し、提示されるすべての証明書を受け付けます。次に署名付き証明書を要求するクライアントランタイムを設定し、クライアントが証明書に署名した CA を確実に信頼する必要があります。

imqbrokerd から有効な署名付き証明書を要求するようにクライアントを設定するには、クライアントの ConnectionFactory オブジェクトに対して imqSSLIsHostTrusted 属性を false に設定します。

「手順 4: SSL ベースのクライアントを設定および実行する」の説明に従って、imqbrokrd との SSL コネクションの確立を試みます。

broker の証明書に著名な CA が署名している場合、コネクションは成功すると見られ、次の手順は省略してもかまいません。コネクションが証明書の有効性検証エラーにより失敗した場合、次の手順を実行します。

次の節の説明に従って、クライアントの truststore に署名 CA の root 証明書をインストールします。

root CA をデフォルトシステム cacerts ファイルにインストールする。

root CA を代替システム jssecacerts ファイルにインストールする。これは推奨オプションです。

root CA を任意のキーストアファイルにインストールし、これを truststore として使用するようにクライアントを設定する。

次の節では、上記のオプションを使用した Verisign Test Root CA のインストール方法の例を説明します。root CA はファイル testrootca.cer 内にあります。この例では、J2SE が /usr/j2se にインストールされていると仮定しています。

デフォルトシステム cacerts ファイルへのインストール

この例では root CA をファイル $JAVA_HOME/usr/jre/lib/security/cacerts にインストールしています。

クライアントはデフォルトでこのキーストアを検索するため、その他のクライアント設定は不要です。

jssecacerts へのインストール

この例では root CA をファイル $JAVA_HOME/usr/jre/lib/security/jssecacerts にインストールしています。

クライアントはデフォルトでこのキーストアを検索するため、その他のクライアント設定は不要です。

その他のファイルへのインストール

この例では、root CA をファイル /home/smith/.keystore にインストールしています。

クライアントはデフォルトでこのキーストアを検索しないため、truststore の場所をクライアントに知らせる必要があります。この場合、クライアントの実行後に Java システムプロパティ javax.net.ssl.trustStore を設定します。たとえば、次のように指定します。

passfile の使用

コマンドにはパスワードを必要とするものがいくつかあります。表 7-6 では、最初の列にパスワードを必要とするコマンド、2 番目の列にパスワードが必要な理由を一覧表示しています。

表 7-6 パスワードを使用するコマンド
コマンド	目的	パスワードの目的
imqbrokerd	ブローカを起動	プラグイン持続データストア、SSL 証明書キーストア、または LDAP ユーザーリポジトリにアクセスします
imqcmd	ブローカを管理	コマンドの使用が許可された管理ユーザーを認証します
imqdbmgr	プラグインデータストアを管理	データストアにアクセスします

パスワードファイル (passfile) でこれらのパスワードを指定し、-passfile オプションを使用してファイル名を指定します。次に示すのは、-passfile オプションの形式です。

imqbrokerd -passfile myPassfile



注	以前のリリースでは、-p、-password、-dbpassword、-ldappassword のオプションを使用してコマンド行でパスワードを指定できました。これらのオプションには異論が多く、今後のリリースでは削除される予定です。今回のリリースでは、これらのオプションのいずれかのコマンド行の値は、パスワードファイルの対応する値よりも優先されます。

セキュリティ上の問題

プロンプトに応じて、パスワードをインタラクティブに指定するのは、ほかのユーザーにモニタリングが表示されていなければ、もっとも安全なパスワード指定の方法です。またコマンド行でパスファイルも指定できます。ただし、コマンドをインタラクティブではない方法で使用する場合、パスファイルを使用する必要があります。

パスファイルは暗号化されず、このため不正なアクセスから保護するためにパスファイルにアクセス権を設定する必要があります。ファイルを表示できるユーザーを制限するが、ブローカを起動するユーザーに読み取りアクセスを許可するようにアクセス権を設定します。

パスファイルの内容

パスファイルは、一連のプロパティと値を収めた簡単なテキストファイルです。それぞれの値はコマンドで使用されるパスワードです。

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

表 7-7 passfile のパスワード
パスワード	影響を受けるコマンド	説明
imq.imqcmd.password	imqcmd	imqcmd コマンド行の管理者パスワードを指定します。パスワードはコマンドごとに認証されます。
imq.keystore.password	imqbrokerd	SSL ベースのサービスにキーストアパスワードを指定します。
imq.persist.jdbc.password	imqbrokerd imdbmgr	必要に応じて、データベースコネクションを開くときに使用するパスワードを指定します。
imq.user_repository.ldap. password	imqbrokerd	設定された LDAP ユーザーリポジトリにバインドするためにブローカに割り当てられた、識別名に関連するパスワードを指定します。

監査ログの作成

Message Queue は Enterprise Edition でのみ監査ロギングをサポートします。監査ロギングを有効にすると、Message Queue は次のタイプのイベントにレコードを生成します。

ブローカインスタンスの起動、シャットダウン、再起動、削除

ユーザーの認証と承認

持続ストアのリセット

物理的送信先の作成、パージ、破棄

永続的サブスクライバの管理上の破棄

Message Queue ブローカログファイルにレコードの監査ロギングを作成するには、imq.audit.enabled ブローカプロパティを true に設定します。ログ内のすべての監査レコードには、キーワード AUDIT が含まれています。

前へ目次索引次へ
Sun Java System Message Queue 3 2005Q1 管理ガイド