サービス統合セキュリティーの計画
メッセージング・システムのセキュリティーを計画している場合、使用可能なオプションの範囲についての解説を、一連のよくある質問から得ることができます。
- バスをどのように保護すればいいか?
- 誰がバスにアクセスする権限を持つか?
- 誰がバス宛先にアクセスする権限を持つか?
- 保護が必要なのはどの接続か?
- バスと任意の外部バスとの間でやり取りされるメッセージにどのユーザー ID を格納するか?
- 必要なデータ・ストア・セキュリティーのレベルは?
サービス統合を Web サービスと共に使用する場合は、バス対応 Web サービスの保護を参照してください。
- バスをどのように保護すればいいか?
- WebSphere® Application Server グローバル・セキュリティー
が有効にされていて、ユーザー・レジストリーが構成されている場合、新しく作成される
サービス統合バスはデフォルトで保護されます。バス定義にある「バス・セキュリティー
を有効にする (Enable bus security)」フラグがデフォルトで
チェックされます。これが意味するのは、メッセージング・エンジンが、接続するすべてのクライアント・アプリケーション
を認証し、バス・リソースにアクセスしようとするすべてのクライアント・アプリケーションに対して
許可チェックを実行するということです。バス・セキュリティーを有効にすることに
ついて詳しくは、メッセージング・セキュリティーを参照してください。
新しいバスを作成するか、 または、既存のバスを保護したい場合、「バス・セキュリティー」ウィザードから、 セキュリティー・ドメインを指定するようプロンプトが出されます。セキュリティー・ドメインは、 バスのセキュリティー設定を含みます。バス・メンバーのバージョンに基づいて、デフォルトのグローバル・ドメインを指定するか、 代替ドメインを指定できます。
- グローバル・ドメイン
- これはデフォルトのセキュリティー・ドメインです。バージョンが混在しているバスには、 グローバル・ドメインを指定しなければなりません。
- セル・レベル・ドメインおよびカスタム・ドメイン
- バスに含まれているのが WebSphere Application Server バージョン 7.0 以降 バス・メンバーのみ である場合、セルのデフォルトのセキュリティー・ドメインまたは カスタムのセキュリティー・ドメインを使用するようにバスを構成できます。通常、カスタムのセキュリティー・ドメインは、 ある特定のバスに特有のセキュリティー設定を含みます。例えば UserRepository など、ユーザー・アプリケーション用に 別個のセキュリティー・ドメインを追加で構成することが できます。バス用に複数のセキュリティー・ドメインを使用する ことについて詳しくは、メッセージング・セキュリティーおよび複数のセキュリティー・ドメインを参照してください。
- 誰がバスにアクセスする権限を持つか?
- メッセージング・エンジンは、バスに接続しようとするクライアント・アプリケーションがあると、 そのクライアント・アプリケーションのクレデンシャル (ID とパスワード) を ユーザー・レジストリーと照らし合わせて認証します。クライアントの認証が 成功すると、メッセージング・エンジンは、クライアントがバスに接続する 権限があることをチェックします。ユーザー・レジストリーに有効なユーザー ID とパスワードが入っているクライアント・アプリケーションの 認証はすべて成功しますが、バスに接続できる権限がすべてのクライアント・アプリケーションにあるのは 望ましくない場合もあります。バスへのアクセスを制御するには、 バスのバス・コネクター・ロールで特定のクライアント・アプリケーションだけに 権限を付与する必要があります。ユーザー・レジストリー内にグループを作成し、 対象のクライアント・アプリケーションの ID をそのグループに追加し、 次に、バスのバス・コネクター・ロールにそのグループを追加します。詳しくは、バス・コネクター・ロールの管理を参照してください。
- 誰がバス宛先にアクセスする権限を持つか?
- 宛先ごとに、どのクライアントがバス宛先での操作を実行する権限を必要とするのかと、それらのクライアントがどの操作 (またはロール) を実行する必要があるのかを判断する必要があります。権限は、グループおよびグループ・メンバーを
ロールに追加することで付与されます。例えば、
MyGroup という名前のクライアント・アプリケーションのグループが、
MyQueue という名前のキュー宛先にメッセージを送信するようにしたい場合、MyGroup を
MyQueue の sender ロールに追加します。詳しくは、宛先ロールの管理を参照してください。
1 つのバス内 のすべての宛先に適用される、デフォルトの許可セットを定義することができます。例えば、 MyMediations という名前のグループのすべてのメンバーに、 選択した 1 つのバスのすべての宛先にメッセージを送信できる権限を与えるには、MyMediations をデフォルト sender ロール に追加します。デフォルトでは、すべてのローカル宛先はデフォルト・リソース からロールを継承します。選択した宛先について、デフォルトの継承を オーバーライドすることを選択できます。デフォルトのロールについて 詳しくは、デフォルト・ロールの管理を 参照してください。デフォルトの ロールの継承をオーバーライドすることについて詳しくは、デフォルト・リソースからの継承の無効化を参照してください。
クライアント・アプリケーションの グループがトピックに対してパブリッシュやサブスクライブを行う場合、 それらのトピックはトピック・スペース内に存在します。トピックへのパブリッシュを行うすべてのクライアントの ID は、 そのトピック・スペースの sender ロールを持っているグループに 属していなければなりません。トピックへのサブスクライブを行うすべてのクライアント・アプリケーションは、 そのトピック・スペースの receiver ロールを持っているグループに 属していなければなりません。詳しくは、トピック・スペース・ルート・ロールの管理を参照してください。デフォルトで、トピック・レベルでの認証許可のチェックも実行されます。トピック・レベルでのチェックを 無効にすることも、選択したトピックへのアクセス権限をどのクライアント・アプリケーションのグループに付与するのかを決定することもできます。
- 保護が必要なのはどの接続か?
- 以下のうちのどの接続を SSL を使用して保護するのかを決定します。
- クライアントとサーバー (メッセージング・エンジン) 間の接続。
- 1 つのバス内のメッセージング・エンジン同士の間の接続。
- バスとバスの間の接続。
詳しくは、メッセージング・バス間のメッセージの保護を参照してください。
- バスと任意の外部バスとの間でやり取りされるメッセージにどのユーザー ID を格納するか?
- メッセージが送信されるとき、メッセージには送信者のユーザー ID が格納され、
そのメッセージに対する以降のアクセス制御チェックに使用
されます。バスとバスの間にリンクがある場合、そのリンクにインバウンド ID と
アウトバウンド ID を構成することで、ローカル・バスと外部バスの間を流れる
メッセージにどのユーザー ID が格納されるのかを制御できます。インバウンド ID は、 リンクを経由してバスに流れ込む各メッセージ内のユーザー ID を 置き換えます。インバウンド ID は、バス内のメッセージへのアクセスを 制御するのに使用されます。インバウンド ID を構成する理由として、 以下のことが考えられます。
- ローカル・バスと外部バスが別のセキュリティー・ドメイン内に存在している。
- 外部バスが保護されていない。
- 各メッセージに同じユーザー ID が入っていれば、より簡単に アクセス制御を管理できる。
アウトバウンド ID は、バスから出てリンクを経由して流れる各メッセージ内の ユーザー ID を置き換えます。元のユーザー ID がメッセージに入ったまま外部バスに運ばれるのを防ぎたい場合などに アウトバウンド ID を構成できます。
詳しくは、メッセージング・エンジン間のリンクの保護を参照してください。
- 必要なデータ・ストア・セキュリティーのレベルは?
- メッセージング・システムは、データ・ストア (データベース) を使用して、 ディスクにメッセージを保管できます。データ・ストア内のメッセージは、 ユーザー名とパスワードで保護することができます。これがデータ・ストアのセキュリティーとして十分なのかどうかを 検討する必要があります。使用するデータベースに、例えばデータ暗号化といった追加のセキュリティー・オプションが 備わっていることもあります。詳しくは、データベース・アクセスの保護を参照してください。