BEA TOP END システムと BEA Tuxedo システム間のセキュリティ

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

• BEA TOP END セキュリティの概要

• BEA Tuxedo セキュリティの概要

• TEDG のセキュリティ処理

• TEDG と NI 間の安全な接続の確立

• BEA Tuxedo から BEA TOP END へのセキュリティのしくみ

• BEA TOP END から BEA Tuxedo へのセキュリティのしくみ

関連項目

• BEA TOP END システムと BEA Tuxedo システム間のセキュリティの設定

 

---

BEA TOP END セキュリティの概要

BEA TOP END のセキュリティを有効にするとは、BEA TOP END システムがユーザ認証、ユーザ認可、およびノード認証を、起動時とメッセージの送受信時に実行することを意味します。これらの機能を個々に有効にすることはできません。BEA TOP END アプリケーションのセキュリティ範囲は、BEA TOP END システムです。システム内のすべてのノードで同じセキュリティのコンフィギュレーションが必要です。2 つのノードが接続しようとすると、両方のノードでセキュリティのコンフィギュレーションがチェックされます。セキュリティのコンフィギュレーションが同じでない場合は接続が拒絶されます。セキュリティ機能が有効のときは、BEA TOP END ノード・マネージャ (NM) は接続プロセスの一部としてお互いを認証します。

TEDG に対しては、BEA TOP END セキュリティ機能は DMCONFIG ファイルの DM_LOCAL_DOMAINS セクションの SECURITY パラメータ、および BEA TOP END ノード上の nm_config ファイルによって有効になります。

認証と認可

BEA TOP END のセキュリティ機能が有効の場合、すべてのクライアントは tp_client_signon(3T) によって認証され、以降のサービス要求はすべて認可される前にチェックされます。認証と認可は一緒に機能し、これらを分けることはできません。認可はプロダクトおよび関数ベースで実行されます。

メッセージ保護と暗号化

BEA TOP END のセキュリティ機能が有効な場合、NI 間のメッセージは次のいずれかの方法で送信されます。

• 平文 (CLEAR)

• チェックサムによる保護 (SAFE)

• 暗号化 (PRIVATE)

ノード間メッセージは Kerberos 4 を使用して保護されます。BEA TOP END システム内のすべての接続に対して、同じメッセージ保護レベルが要求されます。ただし、接続プロセスの一部として、接続ごとに別々のキーが作成されます。この機能は BEA TOP END システムが提供するものであり、顧客が代わって指定することはできません。

 

---

BEA Tuxedo セキュリティの概要

BEA Tuxedo ドメインには複数レベルのセキュリティを設定できます。BEA Tuxedo アプリケーション・トランザクション・モニタ・インターフェイス (ATMI) アプリケーションで利用できるセキュリティ・レベルについては、『BEA Tuxedo のファイル形式とデータ記述方法』の UBBCONFIG(5) を参照してください。

認証と認可

クライアントの認証では、次のいずれかの方法を使用します。

• アプリケーション全体のパスワードを定義する (APP_PW)。

• 個々のクライアント認証を定義する (USER_AUTH)。

BEA Tuxedo システムでは、固有の認証および認可サービスが提供されています。認証は各ユーザのユーザ ID とパスワードを使って行われます。認可は、特定のリソース (サービス、キュー、およびイベント) へのアクセスを許可されたユーザを指定するアクセス制御リスト (ACL) に基づいて行われます。ユーザがリソースの使用を要求すると、そのリソースの ACL が検索されます。ACL が見つかると、ACL をチェックしてユーザがそのリソースを使用することを認可するかどうかが決定されます。最高レベルのセキュリティでは、任意のサービス、キュー、またはイベントへのアクセスで明示的な認可 (MANDATORY_ACL) が要求されます。

オプションの暗号化

ノード間でデータを保護するために、オプションの暗号化を設定することができます。BEA TOP END の暗号化と異なり、BEA Tuxedo の暗号化はユーザ認証および認可なしで有効にできます。

公開鍵による暗号化

BEA Tuxedo ATMI アプリケーションでは、メッセージ・ベースの暗号化とメッセージ・ベースのデジタル署名の 2 種類の公開鍵暗号化が使用されます。どちらも、公開鍵と秘密鍵の暗号化アルゴリズムの技術および鍵管理を基に構築されています。

アプリケーション・メッセージに対するメッセージ・ベースの暗号化とメッセージ・ベースのデジタル署名は、BEA Tuxedo アプリケーションと TEDG 間ではサポートされていますが、TEDG と BEA TOP END システム間のメッセージに対してはサポートされていません。

システムの相互運用性

BEA Tuxedo システムでは、ドメイン・ゲートウェイを介して複数のドメインを相互運用できます。ドメインは個別に設定されるので、2 つのドメインが同じセキュリティ・コンフィギュレーションである必要はありません。ゲートウェイで提供されるコンフィギュレーション・オプションにより、管理者は任意の 2 つのドメイン間で相互運用性レベルを制御できます。

ドメイン間セキュリティ

ドメイン・ゲートウェイでは次のように 4 つのレベルのセキュリティが提供されています。これは DMCONFIG ファイルで定義されます。

• リモート・ドメインで利用できるローカル・サービスを制限するようにゲートウェイを設定できます。

• 特定のサービスへのアクセスを制限して、リモート・ドメインを選択することができます。

• リモート・ドメインに接続しようとすると認証が要求されるようにゲートウェイを設定できます。

• ドメイン間のリンクを暗号化できます。

関連項目

• 『BEA Tuxedo CORBA アプリケーションのセキュリティ機能』の 1-1 ページの「ATMI のセキュリティについて」

 

---

TEDG のセキュリティ処理

TEDG は BEA Tuxedo TDomain と同様の方法でセキュリティを実行します。

• ローカル BEA Tuxedo ドメインまたは BEA TOP END システムがローカル・クライアントに対してアクセスを制御します。クライアントは個々のシステムにログインした後、ローカルの方針に従って認証および認可されます。

• TEDG では、管理者が BEA Tuxedo クライアントによる BEA TOP END サービスへのアクセスを制御することができます。同様に、管理者は BEA TOP END システムからの BEA Tuxedo サービスへのアクセスを制御できます。

• ゲートウェイを通して渡される要求はゲートウェイのクリデンシャルを使用して実行されます。これによって、BEA Tuxedo システムと BEA TOP END システムで重複するセキュリティ・データベースを保持する必要がなくなります。

• BEA TOP END ノードと TEDG ノードの相互認証およびノード間メッセージの暗号化はオプションです。BEA TOP END セキュリティ・アルゴリズムに基づくこれらの機能は、BEA TOP END セキュリティ・パッケージを使用します。

次の図は、BEA Tuxedo システムと BEA TOP END システム間のセキュリティを示しています。詳細については、以下の節を参照してください。

• BEA Tuxedo から BEA TOP END へのセキュリティのしくみ

• BEA TOP END から BEA Tuxedo へのセキュリティのしくみ

  図 3-1 TEDG と BEA TOP END 間のセキュリティ

  
   

 

---

BEA Tuxedo から BEA TOP END へのセキュリティのしくみ

クライアントは、UBBCONFIG(5) ファイル内のローカル・ドメインのコンフィギュレーションに基づいて、BEA Tuxedo システムによって認証および認可されます。BEA TOP END のセキュリティ機能が有効の場合、追加のセキュリティ・チェックを BEA TOP END ノードで行うことができます。

BEA Tuxedo 側のセキュリティ

クライアントは、ほかの BEA Tuxedo クライアント同様に、ユーザ ID およびパスワードを使って BEA Tuxedo システムにより認証されます。クライアントは標準的な BEA Tuxedo の認可方式を通して認可されます。その特性は次のとおりです。

• TEDG は、DMCONFIG ファイルの DM_REMOTE_SERVICES セクションでリストされる SERVICE および QSPACE エントリを、サービスとしてローカル BEA Tuxedo ドメインに宣言します。DMCONFIG ファイルにない BEA TOP END サービスは、BEA Tuxedo クライアントからアクセスできません。

• TEDG によって宣言されるサービスへのアクセスは、ローカル BEA Tuxedo ドメインのコンフィギュレーションで制御されます。認可制御のレベルは、ドメインに対する UBBCONFIG ファイルの SECURITY パラメータの値で決定されます。値が ACL または MANDATORY_ACL の場合、BEA Tuxedo システムでアクセス制御チェックが必要であることを示します。BEA Tuxedo 管理者はインポートされる BEA TOP END サービスに対して ACL を作成できます。

BEA Tuxedo 側のセキュリティが正常に終了すると、TEDG はメッセージを BEA TOP END システムに送信する準備をします。この時点で、BEA TOP END セキュリティ機能に引き継がれます。

BEA TOP END 側のセキュリティ

BEA TOP END のセキュリティ機能が有効の場合、TEDG は BEA TOP END システムに渡すメッセージすべてにユーザ ID を挿入します。要求をキューに登録するためには、ユーザ ID とパスワードの両方を各メッセージに与えます。パスワードは RTQ で使用される現在の BEA TOP END アルゴリズムによって保護されます。

TEDG では、BEA TOP END システムに渡すすべてのメッセージに対して 1 セットのクリデンシャルを使います。クリデンシャルは次のものから構成されています。

• TEDG TOP END ユーザ ID (DMCONFIG ファイルの DM_LOCAL_DOMAINS セクションの DOMAINID)

• dmadmin(1) ユーティリティの topendpasswd コマンドを通して確立されたパスワード

暗号化されたパスワードは BDMCONFIG ファイルに格納されます。管理者は、BEA TOP END の tpsecure(1T) ユーティリティを使用して、一致するユーザ ID およびパスワードを BEA TOP END セキュリティ・データベースで定義します。

BEA TOP END のセキュリティ機能が有効の場合、BEA TOP END のメッセージ受け渡しでは、メッセージがクライアントのユーザ ID を保持していなければなりません。ユーザ ID は BEA TOP END システムでは再認証されないので、パスワードは不要です。ユーザ ID は参考のために提供されます。キュー処理では、ユーザ ID とパスワードの両方をサービス要求とともに渡すことが要求されます。BEA TOP END システムはこれらのクリデンシャルを使ってクライアントを認証し、キューに入れられたサービス要求を処理します。

BEA TOP END システムでは、要求を渡すメッセージに対して追加のアクセス制御チェックは行われません。ただし、キューに入れられた要求は、RTQ によって取り出される時点で BEA TOP END システムによって認可され、サービス要求が処理されます。TEDG からのメッセージはすべて、ローカル・ドメイン DOMAINID と等しい TEDG TOP END ユーザ ID を使ってサブミットされるので、要求されているサービスを実行するにはこの TEDG ユーザ ID が認可されることが必要です。管理者は TOP END tpsecure(1T) ユーティリティを使用して、TEDG ユーザ ID に対する ACL を作成しなければなりません。

関連項目

• BEA TOP END システムと BEA Tuxedo システム間のセキュリティの設定

 

---

BEA TOP END から BEA Tuxedo へのセキュリティのしくみ

クライアントは、BEA TOP END システムのコンフィギュレーションに基づいて、BEA TOP END によって認証および認可されます。BEA Tuxedo のセキュリティ機能が有効の場合、追加のセキュリティ・チェックを BEA Tuxedo ノードで行うことができます。

BEA TOP END 側のセキュリティ

BEA TOP END のセキュリティ機能が有効の場合、クライアントはサインオン時に認証されます。TEDG は着信要求に関してクライアント認証を実行しません。

BEA TOP END システムは、メッセージが送られる前にクライアント・ノードで認証チェックを行います。BEA TOP END のセキュリティ機能が有効の場合、認可されなければ、クライアントは要求されている BEA Tuxedo サービスまたはキューにアクセスできません。管理者は BEA TOP END tpsecure(1T) ユーティリティを使用して、BEA Tuxedo リソースにアクセスする BEA TOP END ユーザそれぞれに ACL を作成しなければなりません。BEA TOP END プロダクトおよび関数は、BEA TOP END リソースを BEA Tuxedo システムにマッピングする際に使用される DMCONFIG ファイルの DM_LOCAL_SERVICES セクションのエントリと一致しなければなりません。

BEA Tuxedo 側のセキュリティ

TEDG には、BEA TOP END システムからの着信要求に対して、次のようなアクセス制御レベルが用意されています。

• 第 1 レベルのアクセス制御では、BEA TOP END システムに宣言される BEA Tuxedo SERVICE エントリと QSPACE エントリが、DMCONFIG ファイルの DM_LOCAL_SERVICES セクションにリストされます。

• 第 2 レベルでは、ドメイン・ゲートウェイのアクセス制御機能を使って、特定の BEA TOP END ノード (または NI 接続) から特定のサービスへのアクセスが制限されます。

  管理者は特定の SERVICE または QSPACE エントリに対して、DM_LOCAL_SERVICES エントリの一部として ACL パラメータを指定することができます。ACL は、DMCONFIG ファイルの DM_ACCESS_CONTROL セクションで定義します。各 ACL レコードには、サービスへのアクセスを許可されるリモート・ドメイン名が含まれます。リモート・ドメインはコンフィギュレーション・ファイルの DM_REMOTE_DOMAINS セクションの BEA TOP END NI インスタンスにマッピングされます。ACL エントリを使うと、宣言されたサービスへのアクセスを特定の BEA TOP END ノードに制限する場合に便利です。

• 第 3 レベルでは、通常の BEA Tuxedo 認可が実行されます。

  要求が TEDG で認可されると、通常の BEA Tuxedo 認可が実行されます。UBBCONFIG(5) ファイルで ACL または MANDATORY_ACL が指定されると、要求を行っているリモート・ドメインの DOMAINID が BEA Tuxedo ユーザ名として使われます。UBBCONFIG で SECURITY=ACL であり、このサービスに対する ACL データベースにエントリがある場合、エントリには RDOM の DOMAINID が含まれていなければなりません。含まれていないと、サービス要求またはキュー要求は異常終了します。UBBCONFIG で SECURITY=MANDATORY_ACL の場合、このサービスに対する ACL データベースにエントリがあり、エントリには RDOM の DOMAINID が含まれていなければなりません。含まれていないと、サービス要求またはキュー要求は異常終了します。

関連項目

• BEA TOP END システムと BEA Tuxedo システム間のセキュリティ

 

---

TEDG と NI 間の安全な接続の確立

BEA TOP END システム内のすべてのノードは、同じレベルのメッセージ保護に設定されることが必要です。DMCONFIG ファイルの DM_LOCAL_DOMAINS セクションの SECURITY パラメータで、TEDG の保護レベルが決定されます。保護レベルには、CLEAR、SAFE、および PRIVATE の 3 つがあります。

• 最低レベルの CLEAR では、メッセージは保護せずに送られます。

• 次のレベルの SAFE では、各メッセージに対し Kerberos 4 ライブラリによって checksum が生成され、メッセージに追加されます。

• 最高レベルの PRIVATE では、Kerberos ライブラリが DES アルゴリズムを使用して各メッセージを暗号化します。TEDG と NI が接続すると自動的に暗号化キーが確立されます。

これらの SECURITY パラメータ値は、『BEA TOP END Programmer’s Reference Manual』の nm_config(4T) で説明する BEA TOP END ノード・マネージャ (NM) コンフィギュレーション・パラメータ [security] および [internode security] と対応しています。

TEDG が起動すると、コンフィギュレーションをチェックして、セキュリティ機能が有効かどうか判断します。つまり、CLEAR、SAFE、または PRIVATE が SECURITY パラメータに設定されているかどうかチェックします。セキュリティ機能が有効であれば、BEA TOP END NM が起動時に要求するように、TEDG は Kerberos チケット・グランティング・チケット (TGT: Ticket Granting Ticket) を要求します。TGT を取得するには、BEA TOP END システムで使用される Kerberos データベースに、TEDG が実行しているマシンに対するエントリ (プリンシパル) が含まれていなければなりません。TGT を取得できない場合、TEDG はエラーを記録して終了します。

TEDG と NI 間の接続プロセスは BEA TOP END サインオン・プロトコルに従います。このプロトコルの一部として、TEDG と NI はセキュリティ・コンフィギュレーションを交換し、2 つのコンフィギュレーションが正確に一致することを確認します。コンフィギュレーションが一致しない場合、TEDG はエラーを記録して (『BEA Tuxedo C リファレンス』 の userlog(3c) を参照)、接続を拒絶します。コンフィギュレーションが一致すれば、TEDG とリモート BEA TOP END システムは、BEA TOP END ノード・マネージャ用のプロトルを使って相互認証を実行します。DMCONFIG ファイルの SECURITY に SAFE または PRIVATE のいずれかが設定されている場合、TEDG は認証プロセスの一部として暗号化キーを取得します。

BEA TOP END システムと BEA Tuxedo システム間のメッセージ暗号化は、NI 間の BEA TOP END ノード間メッセージ・セキュリティに基づいて行われます。さらに、ノード間メッセージ・セキュリティは、Kerberos 4.9 アプリケーション・ライブラリに基づいています。

注記 BEA TOP END ノード間セキュリティを使用するには、TEDG と同じマシン上に BEA TOP END セキュリティ・サービス・プロダクトがインストールされていなければなりません。

関連項目

• BEA TOP END システムと BEA Tuxedo システム間のセキュリティの設定