test

Sun Java System Message Queue 3.7 UR1 管理ガイド

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

ユーザーの認証、アクセス制御の定義、クライアントブローカ間の通信を暗号化する SSL (Secure Socket Layer) 接続サービスの設定、ブローカ起動時に使用するパスワードファイルの設定のためのユーザーリポジトリの設定によって、セキュリティーを管理します。

この章では、次の節について説明します。

ユーザー認証

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

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

リポジトリは次のいずれかのタイプになります。

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

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

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

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

   …/instances/instanceName/etc/passwd

リポジトリは 2 つのエントリから構成されます。表 7–1 の各行にエントリを示します。

表 7–1 ユーザーリポジトリでの初期エントリ

ユーザー名 

パスワード 

グループ 

状態 

admin

admin

admin

アクティブ

guest

guest

anonymous

アクティブ

これらの初期エントリにより、管理者が介入しなくても、インストール後直ちに Message Queue ブローカを使用できます。

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

ユーザーマネージャーユーティリティー

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

imqusermgr コマンドの詳細は、第 13 章「コマンド行のリファレンス」を参照してください。

ユーザーマネージャーの使用に先立ち、次の点に留意してください。

注 –

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

サブコマンド

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

コマンドオプション

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

表 7–2 imqusermgr オプション

オプション 

説明 

-a activeState

ユーザーの状態をアクティブにするかどうかを指定します (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 が割り当てられます。グループが次のように割り当てられるはずです。

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

このようなシステムで生成されたグループの名前の変更や削除、および新しいグループの作成は行えません。ただし、そのグループのメンバーがどの操作を実行するかを定義するアクセス規則を指定できます。詳細は、「ユーザー承認: アクセス制御プロパティーファイル」を参照してください。

ユーザーの状態

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

imqusermgr update -u JoeD -a false

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

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

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

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

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

imqusermgr add -u Katharine -p sesame -g user

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

imqusermgr delete -u Bob

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

imqusermgr update -u Katharine -p aladdin

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 のデフォルトパスワードを自分だけが知っているパスワードに変更する必要があります。次のコマンドは、mybroker ブローカインスタンスのデフォルトの管理者パスワードを admin から grandpoobah に変更します。

imqusermgr update mybroker -u admin -p grandpoobah

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

imqcmd list svc mybroker -u admin

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

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

ユーザーリポジトリでの LDAP サーバーの使用

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

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

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

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

…/instances/instanceName

/props/config.properties

オペレーティングシステム別のインスタンスディレクトリの場所については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照してください。

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

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


    imq.authentication.basic.user_repository=ldap

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


    imq.authentication.type=basic

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

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

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

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

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

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

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


      imq.user_repository.ldap.server=myhost:7878

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

      複数の LDAP ディレクトリサーバーを使用している場合は、ldap:// を使用して、追加の各ディレクトリサーバーを指定します。たとえば、次のように指定します。

      imq.user_repository.ldap.server = myHost:7878 ldap:// otherHost:7878 …

      追加の各ディレクトリサーバーはスペースで区切ります。リスト内のすべてのディレクトリサーバーは、LDAP 関連プロパティーに同じ値を使用する必要があります。

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

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

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

Procedure管理ユーザーを設定する

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

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

  2. アクセス制御ファイル accesscontrol.properties を開きます。このファイルの場所については、付録 A 「プラットフォームごとの Message QueueTM データの場所」の一覧を参照してください。

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

    サービス接続アクセス制御##################################connection.NORMAL.allow.user=*connection.ADMIN.allow.group=admin

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

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

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

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

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

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

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

ユーザー情報が単層型ファイルのユーザーリポジトリにある場合でも LDAP ユーザーリポジトリにある場合でも、ACL ファイルが使用されます。ブローカは、クライアントアプリケーションが次の操作のいずれかを実行するときに ACL ファイルをチェックします。

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

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

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

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

…/instances/brokerInstanceName/etc/accesscontrol.properties

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

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

version=JMQFileAccessControlModel/100

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

アクセス規則の構文

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

これらの規則の基本的な構文は次のとおりです。

resourceType.resourceVariant

.operation.access.
principalType=principals

表 7–3 に構文規則の各要素を示します。

表 7–3 アクセス規則の構文要素

要素 

説明 

resourceType

次のうちのいずれか: connection、queue、topic。

resourceVariant

resourceType で指定されたタイプのインスタンス。たとえば、myQueue。ワイルドカードの文字 (*) を、すべての接続サービスの種類、またはすべての物理的な送信先を表すのに使用できます。

operation

公式化されているアクセス規則の種類に依存する値です。 

access

次のうちのいずれか: allow か deny。

principalType

次のうちのいずれか: user か group。詳細は、「グループ」を参照してください。

principals

規則の左側で指定されるアクセス権を保持するユーザーを示します。ここでは、principalType が user の場合は個々のユーザーまたはコンマで区切られたユーザーのリストとなり、principalType が group の場合は 1 つのグループまたはコンマで区切られたグループのリストとなります。ワイルドカードの文字 (*) を、すべてのユーザーまたはすべてのグループを表すのに使用できます。

ここで、アクセス規則の例をいくつか紹介します。

注 –

ASCII でないユーザー、グループ、または送信先の名前を指定するには、Unicode エスケープ (\\uXXXX) の表記法を使用します。ASCII コードではない名前を含む ACL ファイルを編集して保存した場合、Java native2ascii ツールを使用して、ファイルを ASCII に変換できます。詳細は、次を参照してください。

http://java.sun.com/j2se/1.4/docs/guide/intl/faq.html

権限の計算方法

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

接続サービスのアクセス制御

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

connection.resourceVariant.
access.principalType=
principals

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

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

connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admin

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

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

connection.NORMAL.deny.user=Bob
connection.NORMAL.allow.user=*

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

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

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

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

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

送信先規則の構文は次のとおりです。

resourceType.resourceVariant.operation.access.principalType=principals

表 7–4 にこれらの要素の説明を示します。

表 7–4 送信先アクセス制御規則の要素

コンポーネント 

説明 

resourceType

queue か topic のいずれかです。

resourceVariant

物理的送信先名、またはすべてのキューやすべてのトピックを表す、すべての物理的送信先 (*) です。 

operation

produce、consume または browse のいずれかです。

access

allow か deny のいずれかです。

principalType

user か group のいずれかです。

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

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

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

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

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

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

queue.create.allow.user=*
topic.create.allow.user=*

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

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

resourceType.create.access.principalType=principals

resourceType の部分には、queue か topic が表示されます。

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

topic.create.allow.user=*
topic.create.deny.user=Snoopy

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

メッセージの暗号化

この節では、SSL (Secure Socket Layer) 規格に基づいた接続サービスの設定方法を説明します。これにより、クライアントとブローカ間で、暗号化されたメッセージが送信されます。Message Queue は、次の SSL ベースの接続サービスをサポートしています。

この節の後半では、ssljms、ssladmin、および cluster 接続サービスを使用して、TCP/IP 経由で安全な接続を確立する方法について説明します。httpsjms サービスを使用した、HTTP 経由の安全な接続の確立の詳細は、付録 C 「HTTP/HTTPS のサポート」を参照してください。

自己署名付き証明書の使用

TCP/IP を介して SSL ベースの接続サービスを使用するには、キーツールユーティリティー (imqkeytool) を使用して、公開鍵と非公開鍵のペアを生成します。このユーティリティーは、ブローカへの接続を要求しているクライアントに渡される自己署名付き証明書に公開鍵を埋め込み、クライアントはこの証明書を使用して、接続を暗号化します。この節では、このような自己署名付き証明書を使用した SSL ベースのサービスの設定方法を説明します。

認証を強力なものにするために、認証局が検証する署名付き証明書を使用できます。署名付き証明書を使用するには、自己署名付き証明書に必要な手順のほかに、いくつかの追加手順を実行する必要があります。まず、この節で説明されている手順を実行し、次に、「署名付き証明書の使用」の追加手順に従う必要があります。

Message Queue の自己署名付き証明書による SSL のサポートは、クライアントが既知の信頼されたサーバーと通信することを前提に、ネットワーク上のデータを保護することを目的としています。以降に、SSL ベースの接続サービスを設定して、自己署名付き証明書を使用するために必要な手順を示します。手順に続く項では、これらの各手順についてより詳しく説明しています。

Procedure自己署名付き証明書を使用して SSL ベースの接続サービスを設定する

  1. 自己署名付き証明書を生成します。

  2. ブローカで ssljms、ssladmin、cluster のいずれかの接続サービスを有効にします。

  3. ブローカを起動します。

  4. クライアントを設定し実行します。

    この手順は、ssljms 接続サービスにのみ適用されます。ssladmin または cluster には適用されません。

自己署名付き証明書の生成

キーツールユーティリティー (imqkeytool) を実行し、ブローカの自己署名付き証明書を生成します。UNIX® システムでは、キーストアを作成するアクセス権を取得するために、スーパーユーザー (root) としてユーティリティーを実行する必要があります。ssljms、ssladmin、cluster の接続サービスに対して、同じ証明書を使用できます。

コマンドプロンプトで次のとおり入力します。 

imqkeytool -broker

キーツールユーティリティーによりキーストアのパスワードの入力が要求されます。

   Generating keystore for the broker ...
   Enter keystore password:

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

表 7–5 自己署名付き証明書に必要な識別名情報

プロンプト 

X.500 属性 

説明 

例 

姓名を入力してください。

commonName (CN)

ブローカを実行しているサーバーの完全修飾名 

mqserver.sun.com

組織単位名を入力してください。

organizationalUnit (OU)

部署または部門の名前 

purchasing

組織名を入力してください。

organizationName (ON)

企業または政府機関などの大規模組織の名前 

My Company, Inc.

都市名または地域名を入力してください。

localityName (L)

市町村の名前 

San Francisco

州名または地方名を入力してください。

stateName (ST)

(頭語ではない) 州または県の完全名  

California

この単位に該当する 2 文字の国番号を入力してください。

country (C)

標準的な 2 文字国コード 

US

情報を入力し終えたら、キーツールユーティリティーにより確認の画面が表示されます。たとえば、次のように指定します。

   Is CN=mqserver.sun.com, OU=purchasing, ON=My Company, Inc.,
   L=San Francisco, ST=California, C=US correct?

現在の値でよければ、先に進み、yes を入力します。値を再入力する場合は、デフォルトを使用するか no を入力します。確認後、ユーティリティーが鍵ペアを生成する間、このユーティリティーは停止します。

次に、ユーティリティーから鍵ペアをロックするためのパスワードの入力が要求されます (キーパスワード)。このプロンプトに対して Return キーを押し、キーパスワードおよびキーストアパスワードと同じパスワードを使用します。

注 –

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

キーツールユーティリティーは、自己署名付き証明書を生成し、Message Queue のキーストアに配置します。キーストアは、付録 A 「プラットフォームごとの Message QueueTM データの場所」に記載されているとおり、オペレーティングシステムに応じたディレクトリにあります。

次に示すのは、SSL ベースの接続サービスの場合の、Message Queue キーストアの設定可能なプロパティーです。

状況によっては、特定の問題を解決するために、鍵ペアを生成し直す必要があります。たとえば、キーストアのパスワードを忘れてしまった場合や、ブローカの起動時に次の例外が発生し、SSL ベースのサービスの初期化に失敗した場合などです。

java.security.UnrecoverableKeyException:Cannot recover key

この例外は、自己署名付き証明書を生成したときに、キーストアのパスワードと違ったものをキーのパスワードに設定した場合に発生する可能性があります。

Procedure鍵ペアを生成し直す

  1. 付録 A 「プラットフォームごとの Message QueueTM データの場所」に示すとおり、ブローカのキーストアを削除します。

  2. 上記の説明に従って、imqkeytool をもう一度実行し、新しい鍵ペアを生成します。

SSL ベースの接続サービスを有効にする

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

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

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

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

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

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

    デフォルトでは、プロパティーには jms 接続サービスと admin 接続サービスが含まれます。SSL ベースのサービス、またはアクティブ化するサービス (ssljms か ssladmin、またはその両方) を追加します。

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

    SSL ベースの cluster 接続サービスは、imq.service.activelist プロパティーではなく imq.cluster.transport プロパティーを使用して有効化されます。「ブローカの接続」を参照してください。

  3. インスタンス設定ファイルを保存して閉じます。

ブローカを起動する

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

注 –

SSL を使用してブローカまたはクライアントを起動するときに、CPU の使用率が、数秒間急上昇します。これは、Message Queue が乱数を生成するために使用する JSSE (Java Secure Socket Extension) メソッド java.security.SecureRandom が、最初の乱数シードを作成するのにかなりの時間がかかるためです。シードが作成されると、CPU の使用率は通常に戻ります。

SSL ベースのクライアントを設定して実行する

SSL ベースの接続サービスを使用するようにクライアントを設定する手順は、クライアントが、アプリケーションクライアント (ssljms 接続サービスを使用) であるか、imqcmd などの Message Queue 管理クライアント (ssladmin 接続サービスを使用) であるかによって異なります。

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

アプリケーションクライアントの場合、クライアントが、次の .jar ファイルを CLASSPATH 変数に指定していることを確認する必要があります。

J2SDK (Java 2 Software Development Kit) の 1.4 よりも古いバージョンを使用している場合は、次の JSSE (Java Secure Socket Extension) および JNDI (Java Naming and Directory Interface) の .jar ファイルも含める必要があります。

JSSE と JNDI のサポートが組み込まれている J2SDK 1.4 以降を使用している場合は、これらのファイルを含める必要はありません。

CLASSPATH ファイルを適切に指定したら、クライアントを起動し、ブローカの ssljms 接続サービスに接続する方法の 1 つとして、次のようなコマンドを入力します。

java -DimqConnectionType=TLS clientAppName

これにより、接続に SSL ベースの接続サービスを使用するよう指示が出されます。

管理クライアント

管理クライアントの場合、imqcmd コマンドを呼び出すときに、-secure オプションを指定すると、安全な接続を確立できます。たとえば、次のように指定します。

imqcmd list svc -b hostName:portNumber -u adminName -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.

署名付き証明書の使用

署名付き証明書は、自己署名付き証明書よりも強力なサーバー認証をもたらします。署名付き証明書はクライアントとブローカ間でのみ実装可能で、クラスタ内の複数のブローカ間に実装できません。署名付き証明書を実装するには、前に説明した自己署名付き証明書の設定の手順に加えて、次の追加の手順を実行する必要があります。これらの手順については、以降の節でより詳しく説明します。

Procedure署名付き証明書を使用する

  1. 証明書をキーストアにインストールします。

  2. ブローカへの SSL ベースの接続を確立するときに、署名付き証明書を要求するように Message Queue クライアントを設定します。

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

次の手順は、署名付き証明書を取得して、インストールする方法について説明しています。

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

  1. J2SE keytool コマンドを使用して、前節で作成した自己署名付き証明書の CSR (certificate signing request) を生成します。

    keytool コマンドについての情報は、次のサイトを参照してください。

    http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html

    次に例を示します。


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

    これにより、指定したファイル (この例では certreq.csr) に証明書を含む CSR が生成されます。

  2. CSR を使用して、署名付き証明書を生成または要求します。

    次のいずれかの方法で、これを行うことができます。

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

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

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

  3. 署名付き証明書をファイルに保存します。

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

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

  1. J2SE が、使用中の認証局をデフォルトでサポートしているかどうかを確認します。

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

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

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

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

    次に例を示します。

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

    ca.cer は、CA から取得したルート証明書を含むファイルです。

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

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

    次に例を示します。

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

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

    Message Queue キーストアに、SSL 接続に使用できる署名付き証明書が格納されました。

署名付き証明書を要求する Message Queue クライアントランタイムの設定

次に、署名付き証明書を要求するように Message Queue クライアントランタイムを設定し、証明書に署名した認証局を信頼していることを確認する必要があります。

Procedure署名付き証明書を要求するようにクライアントランタイムを設定する

  1. 接続ファクトリの imqSSLIsHostTrusted 属性を false に設定します。

    デフォルトでは、クライアントがブローカ接続の確立に使用する接続ファクトリオブジェクトの imqSSLIsHostTrusted 属性は true に設定されています。これは、クライアントランタイムが、提示されたすべての証明書を受け入れることを意味しています。この値を false に変更して、クライアントランタイムが、提示されたすべての証明書の検証を試みるようにする必要があります。証明書の署名者がクライアントのトラストストアに含まれていない場合、検証は失敗します。

  2. 署名機関がクライアントのトラストストアに登録されているかどうかを確認します。

    クライアントが、使用している認証局によって署名された証明書を受け入れるかどうかをテストするには、「SSL ベースのクライアントを設定して実行する」の説明に従って、SSL 接続の確立を試みます。CA が、クライアントのトラストストアに含まれている場合は、接続は成功します。この場合、次の手順は省略してもかまいません。接続が証明書の有効性検証エラーにより失敗した場合、次の手順を実行します。

  3. クライアントのトラストストアに、署名 CA のルート証明書をインストールします。

    クライアントは、デフォルトで、キーストアファイル cacerts と jssecacerts を検索するため、これらのいずれかに証明書をインストールする場合は、これ以降の設定は不要です。次の例では、testrootca.cer というファイルから、デフォルトのシステムの証明書ファイル cacerts に、Verisign 認証局からの test root 証明書をインストールしています。この例は、J2SE がディレクトリ $JAVA_HOME/usr/j2se にインストールされていることを前提としています。

    keytool -import -keystore /usr/j2se/jre/lib/security/cacerts
        -alias VerisignTestCA -file testrootca.cer -noprompt
        -trustcacerts -storepass myStorePassword

    もう 1 つの選択肢 (推奨) として、ルート証明書を、別のシステムの証明書ファイル jssecacerts にインストールする方法があります。

    keytool -import -keystore /usr/j2se/jre/lib/security/jssecacerts
        -alias VerisignTestCA -file testrootca.cer -noprompt
        -trustcacerts -storepass myStorePassword

    3 つ目は、ルート証明書をその他のキーストアファイルにインストールして、それをトラストストアとして使用するようにクライアントを設定する方法です。次の例では、ファイル /home/smith/.keystore にインストールしています。

    keytool -import -keystore /home/smith/.keystore
        -alias VerisignTestCA -file testrootca.cer -noprompt
        -trustcacerts -storepass myStorePassword

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

    javax.net.ssl.trustStore=/home/smith/.keystore

パスワードファイル

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

表 7–6 パスワードを使用するコマンド

コマンド 

目的 

パスワードの目的 

imqbrokerd

ブローカを起動する 

JDBC ベースの持続データストア、SSL 証明書キーストア、または LDAP ユーザーリポジトリにアクセスします 

imqcmd

ブローカを管理する 

コマンドの使用が許可された管理ユーザーを認証します 

imqdbmgr

JDBC ベースのデータストアを管理する 

データストアにアクセスします 

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

imqbrokerd -passfile myPassfile
注 –

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

セキュリティー上の問題

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

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

パスワードファイルの内容

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

パスワードファイルには、表 7–7 に示すパスワードを含めることができます。

表 7–7 パスワードファイル内のパスワード

パスワード 

影響を受けるコマンド 

説明 

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 製品に組み込まれています。サンプルファイルの場所については、付録 A 「プラットフォームごとの Message QueueTM データの場所」を参照してください。

ファイアウォールを介した接続

クライアントアプリケーションが、ファイアウォールによってブローカから隔てられている場合は、接続を確立するために特別な手段が必要です。1 つの手段として、ファイアウォールを「トンネリング」できる httpjms または httpsjms 接続サービスを使用する方法があります。詳細については、付録 C 「HTTP/HTTPS のサポート」を参照してください。ただし、HTTP 接続は、ほかの接続サービスよりも低速です。より高速な別の手段として、Message Queue ポートマッパーをバイパスし、目的の接続サービスに静的ポートアドレスを明示的に割り当ててから、ファイアウォールでその特定のポートを開く方法があります。この方法を使用することで、jms または ssljms 接続サービス (例外的な場合は admin もしくは ssladmin) を使用して、ファイアウォールを介して接続できます。

表 7–8 静的ポートアドレスのブローカ設定プロパティー

接続サービス 

設定プロパティー 

jms

imq.jms.tcp.port

ssljms

imq.ssljms.tls.port

admin

imq.admin.tcp.port

ssladmin

imq.ssladmin.tls.port

Procedureファイアウォールを介したブローカの接続を有効にする

  1. 使用する接続サービスに、静的ポートアドレスを割り当てます。

    ポートマッパーをバイパスし、接続サービスに静的ポート番号を直接割り当てるには、ブローカ設定プロパティー imq.serviceName. protocolType.port を設定します。serviceName は接続サービスの名前で、protocolType はそのプロトコルタイプです (表 7–8 を参照)。すべてのブローカ設定プロパティーと同様に、このプロパティーは、ブローカのインスタンス設定ファイルで指定するか、またはブローカの起動時にコマンド行から指定することができます。たとえば、jms 接続サービスにポート番号 10234 を割り当てるには、次の行を設定ファイルに含めるか、

       imq.jms.tcp.port=10234

    または、次のコマンドを使用してブローカを起動します。

       
imqbrokerd  -name myBroker  -Dimq.jms.tcp.port=10234

  2. 接続サービスに割り当てたポート番号への接続を許可するように、ファイアウォールを設定します。

    Message Queue のポートマッパーのポートへの、ファイアウォールを介した接続も許可する必要があります。このポートは、ポートマッパーをその他のポートに再割り当てしていない限り、通常は 7676 です。たとえば、上記の例では、ポート 10234 および 7676 のファイアウォールを開く必要があります。

監査ロギング

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

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