BEA Logo BEA Tuxedo Release 8.0

  BEA ホーム  |  イベント  |  ソリューション  |  パートナ  |  製品  |  サービス  |  ダウンロード  |  ディベロッパ・センタ  |  WebSUPPORT

 

   Tuxedo ホーム   |   BEA Tuxedo のセキュリティ機能   |   先頭へ   |   前へ   |   次へ   |   目次

 


公開鍵セキュリティの管理

分散型の ATMI アプリケーションの安全性を確保する最も効果的な方法は、リンク・レベルの暗号化と公開鍵による暗号化を組み合わせることです。公開鍵による暗号化は、公開鍵セキュリティの基盤となるフレームワークです。

公開鍵セキュリティにより、メッセージ・ベースのデジタル署名とメッセージ・ベースの暗号化を ATMI アプリケーションに統合することができます。これらの機能を組み合わせると、データの完全性と機密性が保たれます。これは、ATMI アプリケーションが外部の ATMI アプリケーションまたはワークステーション・クライアントと相互運用する場合に特に重要です。

公開鍵セキュリティで推奨されている事項について

公開鍵と秘密鍵の組み合わせの割り当て

アプリケーションの管理者と開発者は、公開鍵と秘密鍵の組み合わせ、および関連するデジタル証明書を認証するための認証局を選択する必要があります。次に、鍵の組み合わせを ATMI アプリケーションに割り当てる方法を決定する必要があります。鍵の組み合わせを割り当てる方法はたくさんあります。管理者は、次のうち、1 つまたは複数の方法で鍵の組み合わせを割り当てることができます。

アプリケーションの管理者と開発者は、鍵の組み合わせを割り当てる方法を選択し、実際に割り当てる責任があります。ただし、鍵の組み合わせを割り当てた後の管理作業を行う必要はありません。鍵の配布と管理は、公開鍵セキュリティのプラグインによって行われます。

デジタル署名方針の設定

管理者は、次のコンフィギュレーション・パラメータを使用して、ATMI アプリケーションのデジタル署名に関する方針を設定します。

パラメータ名

説明

設定

UBBCONFIGSIGNATURE_AHEAD (TM_MIBTA_SIGNATURE_AHEAD)

デジタル署名付きのメッセージ・バッファに記録されたタイムスタンプ値と、そのメッセージ・バッファが受信された時刻の最大時間差。デジタル署名のタイムスタンプ値が遠い将来の時刻を示す場合、受信側のプロセスではメッセージ・バッファを拒否します。

1 〜 2147483647 秒。デフォルト値は 3600 秒 (1 時間) です。

UBBCONFIGSIGNATURE_BEHIND (TM_MIBTA_SIGNATURE_BEHIND)

デジタル署名付きのメッセージ・バッファが受信された時刻と、そのメッセージ・バッファに添付されたタイムスタンプ値との最大時間差。デジタル署名のタイムスタンプ値が遠い過去の時刻を示す場合、受信側のプロセスではメッセージ・バッファを拒否します。

1 〜 2147483647 秒。デフォルト値は 604800 秒 (1 週間) です。

UBBCONFIGSIGNATURE_REQUIRED (TM_MIBTA_SIGNATURE_REQUIRED)

受信側のプロセスで受け付けるメッセージ・バッファを、デジタル署名付きのものだけに制限するかどうかを決定します。

Y (デジタル署名が必要) または N (デジタル署名は不要) を指定します。デフォルト値は N です。

デジタル署名のタイムスタンプに設定された将来の日付を制限する

SIGNATURE_AHEAD は、コンフィギュレーション階層のうち、ドメイン・レベルで指定されるため、このパラメータに割り当てた値は、ATMI アプリケーションで実行されるすべてのプロセスに適用されます。ドメイン全体にわたるパラメータは、UBBCONFIG ファイルの RESOURCES セクションおよび TM_MIBT_DOMAIN クラスで設定されます。

SIGNATURE_AHEAD パラメータは、受信したメッセージ・バッファに添付されたタイムスタンプと、検証システムのローカル・クロックに表示される現在時刻との最大時間差を設定します。最小値は 1 秒です。最大値は 2147483647 秒です。デフォルトは 3600 秒 (1 時間) です。

デジタル署名のタイムスタンプが遠い将来の時刻を示す場合、その署名は無効と見なされます。このパラメータを設定すると、将来の日付が指定された署名を拒否できます。ただし、ローカル・クロックの時刻との間に多少ずれが生じていても、その分は無視されます。

将来の日付を制限する UBBCONFIG のエントリ例

*RESOURCES
SIGNATURE_AHEAD 2400

デジタル署名のタイムスタンプに設定された過去の日付を制限する

SIGNATURE_BEHIND は、コンフィギュレーション階層のうち、ドメイン・レベルで指定されるため、このパラメータに割り当てた値は、ATMI アプリケーションで実行されるすべてのプロセスに適用されます。ドメイン全体にわたるパラメータは、UBBCONFIG ファイルの RESOURCES セクションおよび TM_MIBT_DOMAIN クラスで設定されます。

SIGNATURE_BEHIND パラメータは、検証システムのローカル・クロックに表示される現在時刻と、受信したメッセージ・バッファに添付されたタイムスタンプとの最大時間差を設定します。最小値は 1 秒です。最大値は 2147483647 秒です。デフォルト値は 604800 秒 (1 週間) です。

デジタル署名のタイムスタンプ値が遠い過去の時刻を示す場合、その署名は無効と見なされます。このパラメータを設定すると、リプレイ攻撃、つまり、署名付きの有効なバッファが再びシステムに送信されるのを阻止することができます。ただし、非同期通信を行うシステム、たとえばディスク・ベースのキューを使用するシステムでは、かなり古い署名が添付されたバッファが有効と見なされる場合があります。したがって、非同期通信を行うシステムでは、SIGNATURE_BEHIND の設定を増やしてください。

過去の日付を制限する UBBCONFIG のエントリ例

*RESOURCES
SIGNATURE_BEHIND 300000

受信メッセージに対する署名方針の適用

SIGNATURE_REQUIRED は、コンフィギュレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。

特定のレベルで SIGNATURE_REQUIREDY (はい) を設定すると、下位レベルで動作するすべてのプロセスに署名が必要となります。たとえば、mach1 というマシンで SIGNATURE_REQUIREDY を設定すると、mach1 上で動作するすべてのプロセスは、デジタル署名が添付されたメッセージだけを受け付けます。

ドメイン全体にわたるレベル、マシン・レベル、グループ・レベル、またはサービス・レベルでは、SIGNATURE_REQUIRED=Y および ENCRYPTION_REQUIRED=Y を同時に指定することができます。ENCRYPTION_REQUIRED の詳細については、「受信メッセージに対する暗号化方針の適用」を参照してください。

制限

SIGNATURE_REQUIRED を指定するかどうかの方針は、アプリケーション・サービス、アプリケーション・イベント、およびアプリケーション・エンキュー要求に対してのみ適用されます。システム生成されたサービス呼び出しや、システム・イベントのポストには適用されません。

mach1 というマシンに SIGNATURE_REQUIRED を設定するには、次の手順に従います。

  1. ATMI アプリケーションの MASTER マシンで作業しており、ATMI アプリケーショ ンが非アクティブであることを確認します。

  2. テキスト・エディタで UBBCONFIG を開き、MACHINES セクションに次の行を追加 します。
    *MACHINES
    mach1 LMID="machine_logical_name"
    TUXCONFIG="absolute_path_name_to_tuxconfig_file"
    TUXDIR="absolute_path_name_to_BEA_Tuxedo_directory"
    APPDIR="absolute_path_name_to_application_directory"
    SIGNATURE_REQUIRED=Y

  3. tmloadcf(1) を実行してコンフィギュレーションをロードします。tmloadcf コ マンドを実行すると、UBBCONFIG が解析され、TUXCONFIG 変数が指す場所にバイ ナリ形式の TUXCONFIG ファイルがロードされます。

上の例では、tmboot(1) を実行すると、ATMI アプリケーションが起動し、SIGNATURE_REQUIRED=Y パラメータが mach1 というマシンに渡されます。この時点で、mach1 によって宣言されたすべてのアプリケーション・サービスは、ゲートウェイ・プロセスによって宣言されたアプリケーション・サービスも含め、有効なデジタル署名が添付されたメッセージだけを受け付けることができます。mach1 によって制御されるプロセスが、有効なデジタル署名が添付されていないメッセージを受信すると、システム側では次のアクションが実行されます。

注記 NULL バッファ (空のバッファ) にデジタル署名を添付することはできません。したがって、デジタル署名を必要とするプロセスで受信された NULL バッファは、上記のいずれかの方法で、システム側で拒否されます。

イベント・ブローカの署名方針の適用

ポスト済みのメッセージ・バッファにデジタル署名が添付されると、これらの署名は保存され、メッセージ・バッファと共に、適切なイベントのサブスクライバに転送されます。

TMUSREVT(5) システム・サーバが、デジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、このサーバは、コンポジット署名ステータスが TPSIGN_OK に設定されていないイベントを拒否します。詳細については、「コンポジット署名ステータスについて」 を参照してください。

TMUSREVT サーバは、サービスの呼び出しやキューへのメッセージの登録などの、サブスクリプションに関する通知アクションを実行できます。有効なデジタル署名を必要とするサービスやキューに対して、有効なデジタル署名が添付されていないメッセージをポストすると、サブスクリプションの通知アクションは失敗します。

システム・イベント (システム側でポストされ、TMSYSEVT サーバで処理されるイベント) には、デジタル署名を添付することができます。デジタル署名に関する管理方針は、TMSYSEVT(5) サーバには適用されません。

/Q の署名方針の適用

キューに登録されたバッファにデジタル署名が添付されると、署名はキュー内に保存され、キューから取り出すプロセスの実行時に転送されます。また、メッセージが TMQFORWARD(5) によって処理され、サービスが呼び出されると、署名は保存されます。

TMQUEUE(5) システム・サーバが、デジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、このサーバは、コンポジット署名ステータスが TPSIGN_OK に設定されていないエンキュー要求を拒否します。詳細については、「コンポジット署名ステータスについて」 を参照してください。さらに、キュー空間に関連するサービス名に対してこのような方針が有効な場合、TMQUEUE サーバはデジタル署名を必要とします。

リモート・クライアントの署名方針の適用

ワークステーション・ハンドラ (WSH) が、デジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、WSH は、コンポジット署名ステータスが TPSIGN_OK に設定されていない、アプリケーション・データを含むメッセージ・バッファを拒否します。詳細については、「コンポジット署名ステータスについて」 を参照してください。

暗号化方針の設定

管理者は、次のコンフィギュレーション・パラメータを使用して、ATMI アプリケーションの暗号化方針を設定します。

パラメータ名

説明

設定

UBBCONFIGENCRYPTION_REQUIRED (TM_MIBTA_ENCRYPTION_REQUIRED)

受信側のプロセスで受け付けるメッセージ・バッファを、暗号化されたものだけに制限するかどうかを決定します。

Y (暗号化が必要) または N (暗号化は不要) を指定します。デフォルト値は N です。

受信メッセージに対する暗号化方針の適用

ENCRYPTION_REQUIRED は、コンフィギュレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。

特定のレベルで ENCRYPTION_REQUIREDY (はい) を設定すると、下位レベルで動作するすべてのプロセスに暗号化が必要となります。たとえば、mach1 というマシンで ENCRYPTION_REQUIREDY を設定すると、mach1 上で動作するすべてのプロセスは、暗号化されたメッセージだけを受け付けます。

ドメイン全体にわたるレベル、マシン・レベル、グループ・レベル、またはサービス・レベルでは、ENCRYPTION_REQUIRED=Y および SIGNATURE_REQUIRED=Y を同時に指定することができます。SIGNATURE_REQUIRED の詳細については、「受信メッセージに対する署名方針の適用」を参照してください。

制限

ENCRYPTION_REQUIRED を指定するかどうかの方針は、アプリケーション・サービス、アプリケーション・イベント、およびアプリケーション・エンキュー要求に対してのみ適用されます。システム生成されたサービス呼び出しや、システム・イベントのポストには適用されません。

STDGRP というサーバ・グループに ENCRYPTION_REQUIRED を設定するには、次の手順に従います。

  1. ATMI アプリケーションの MASTER マシンで作業しており、ATMI アプリケーショ ンが非アクティブであることを確認します。

  2. テキスト・エディタで UBBCONFIG を開き、GROUPS セクションに次の行を追加し ます。
    *GROUPS
    STDGRP LMID="machine_logical_name"
    GRPNO="server_group_number"
    ENCRYPTION_REQUIRED=Y

  3. tmloadcf(1) を実行してコンフィギュレーションをロードします。tmloadcf コ マンドを実行すると、UBBCONFIG が解析され、TUXCONFIG 変数が指す場所にバイ ナリ形式の TUXCONFIG ファイルがロードされます。

上の例では、tmboot(1) を実行すると、ATMI アプリケーションが起動し、ENCRYPTION_REQUIRED=Y パラメータが STDGRP というサーバ・グループに渡されます。この時点で、STDGRP によって宣言されたすべてのアプリケーション・サービスは、ゲートウェイ・プロセスによって宣言されたアプリケーション・サービスも含め、暗号化のエンベロープで保護されたメッセージだけを受け付けることができます。STDGRP によって制御されるプロセスが、暗号化されていないメッセージを受信すると、システム側では次のアクションが実行されます。

注記 NULL バッファ (空のバッファ) は暗号化できません。したがって、暗号化を必要とするプロセスで受信された NULL バッファは、上記のいずれかの方法で、システム側で拒否されます。

イベント・ブローカの暗号化方針の適用

ポスト済みのメッセージ・バッファが暗号化されると、これらの署名は保存され、暗号化されたメッセージの内容と共に、適切なイベントのサブスクライバに転送されます。

TMUSREVT(5) システム・サーバが、暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、このサーバは、暗号化されていないメッセージを拒否します。

TMUSREVT サーバは、サービスの呼び出しやキューへのメッセージの登録などの、サブスクリプションに関する通知アクションを実行できます。入力する情報の暗号化を必要とするサービスやキューに対して、暗号化されていないメッセージをポストすると、サブスクリプションの通知アクションは失敗します。また、サブスクライバが適切な復号化キーを保持していない場合も、イベント通知アクションは失敗します。

システム・イベント (システム側でポストされ、TMSYSEVT サーバで処理されるイベント) は、暗号化できます。暗号化に関する管理方針は、TMSYSEVT(5) サーバには適用されません。

/Q の暗号化方針の適用

キューに登録されたバッファが暗号化されると、このステータスはキュー内に保存され、バッファは、キューから取り出すプロセスの実行時に暗号化された形式で転送されます。また、メッセージが TMQFORWARD(5) によって処理され、サービスが呼び出されると、暗号化のステータスは保存されます。

TMQUEUE(5) システム・サーバが、暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、このサーバは、暗号化されていないエンキュー要求を拒否します。さらに、キュー空間に関連するサービス名に対してこのような方針が有効な場合、TMQUEUE サーバは、暗号化を必要とします。

リモート・クライアントの暗号化方針の適用

ワークステーション・ハンドラ (WSH) が、暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合、WSH は、暗号化されていないアプリケーション・データ・バッファを含むメッセージ・バッファを拒否します。

プラグインによる復号化キーの初期化

管理者は、次のコンフィギュレーション・パラメータを使用して、アプリケーション内で動作するシステム・プロセスのプリンシパル名と復号化キーを指定します。

パラメータ名

説明

設定

UBBCONFIGSEC_PRINCIPAL_NAME (TM_MIBTA_SEC_PRINCIPAL_NAME)

ターゲットのプリンシパル名。これが 1 つまたは複数のシステム・プロセスの ID になります。

1 〜 511 文字。

UBBCONFIGSEC_PRINCIPAL_LOCATION (TM_MIBTA_SEC_PRINCIPAL_LOCATION)

ターゲットのプリンシパルの復号化 (秘密) キーが格納されているファイルまたはデバイスの位置。

1 〜 511 文字。指定しない場合、NULL 文字列 (長さゼロ) がデフォルト値になります。

UBBCONFIGSEC_PRINCIPAL_PASSVAR (TM_MIBSEC_PRINCIPAL_PASSVAR)

ターゲットのプリンシパルのパスワードが格納されている変数。

1 〜 511 文字。指定しない場合、NULL 文字列 (長さゼロ) がデフォルト値になります。

上記の 3 つのパラメータは、コンフィギュレーションの階層のうち、次の 4 つのレベルのどこでも指定できます。

特定のコンフィギュレーション・レベルでのプリンシパル名および復号化キーは、下位レベルで上書きできます。たとえば、mach1 というマシンにプリンシパル名と復号化キーを設定し、mach1 上で動作する serv1 というサーバにプリンシパル名と復号化キーを設定したとします。この場合、mach1 のプロセスは次のように動作します。

ATMI アプリケーションが起動すると、設定された復号化キーは自動的にオープンします。次の図は、このプロセスのしくみを示しています。

復号化キーの初期化例


 

次に、この図に示した操作の実行方法を詳しく説明します。

  1. 管理者は、ATMI アプリケーションの UBBCONFIG ファイルの特定のレベルで、 SEC_PRINCIPAL_NAMESEC_PRINCIPAL_LOCATION、および SEC_PRINCIPAL_PASSVAR を定義します。

  2. 管理者は、tmloadcf(1) を実行してコンフィギュレーションをロードします。 tmloadcf コマンドを実行すると、UBBCONFIG が解析され、TUXCONFIG 変数が指す 場所にバイナリ形式の TUXCONFIG ファイルがロードされます。

  3. 管理者は、プロンプトに従い、ターゲットのプリンシパルのパスワードを入力 し、さらにもう一度入力します。

  4. 管理者は、tmboot(1) コマンドを実行して ATMI アプリケーションを起動しま す。

  5. 起動時に、map_proof プラグインにより、SEC_PRINCIPAL_NAMESEC_PRINCIPAL_LOCATION、および SEC_PRINCIPAL_PASSVAR が読み込まれ、各 パラメータの値が解析されます。次に、呼び出しプロセスで、要求された復号化 キーに対するアクセス権が証明されたかどうかが判別されます。復号化キー、つ まり秘密鍵にアクセスできるということは、プリンシパルの ID を所有すること と同じです。

  6. SEC_PRINCIPAL_PASSVAR に関連するパスワードが、SEC_PRINCIPAL_NAME で 指定されたプリンシパルに割り当てられたパスワードと一致する場合、 map_proof プラグインは、プリンシパルの名前、位置、およびパスワードを PKi_init プラグインに渡します。

  7. PKi_init プラグインは、プリンシパルの名前、位置、およびパスワードを引数 に指定し、tpkey_open(3c) を呼び出します。プリンシパルの復号化キー・ハン ドルが返されます。

tmloadcf を呼び出してコンフィギュレーションをロードするたびに、SEC_PRINCIPAL_PASSVAR に設定した各復号化キーに対するパスワードの入力を求められます。各パスワードを手動で入力しないで済むようにするには、パスワードを自動的に入力するスクリプトを記述します。このスクリプトには、各パスワードの変数定義を組み込み、次の行で終了する必要があります。

tmloadcf -y ubbconfig_name < /dev/null

ATMI アプリケーションの起動時にオープンされた復号化キーをクローズするパーミッションは、アプリケーション・プロセスにはありません。復号化キーは、tmshutdown(1) コマンドを実行して ATMI アプリケーションをシャットダウンするまで、オープンしたままの状態になります。

プリンシパル名および復号化キーを指定する UBBCONFIG のエントリ例

*RESOURCES
SEC_PRINCIPAL_NAME "Tommy"
SEC_PRINCIPAL_LOCATION "/home/jhn/secsapp/cert/tommy.pvk"
SEC_PRINCIPAL_PASSVAR "TOMMY_VAR"
.
.
.
*SERVERS
"TMQUEUE" SRVGRP="QUEGROUP" SRVID=1
CLOPT="-s secsdb:TMQUEUE"
SEC_PRINCIPAL_NAME= "TOUPPER"
SEC_PRINCIPAL_LOCATION="/home/jhn/secsapp/cert/TOUPPER.pvk"
SEC_PRINCIPAL_PASSVAR= "TOUPPER_VAR"

障害のレポートと監査

この節では、デジタル署名とメッセージの暗号化で検出されたエラーがシステム側でどのように処理されるかを説明します。

デジタル署名のエラー処理

メッセージの改ざんが検出された場合、つまり、コンポジット署名ステータスが PSIGN_TAMPERED_MESSAGE または TPSIGN_TAMPERED_CERT の場合 (「コンポジット署名ステータスについて」 を参照)、システム側では次のアクションが実行されます。

有効期限が切れた証明書、取り消された証明書、有効期限が切れた署名、または古い日付の署名が検出された場合、システム側では次のアクションが実行されます。

SIGNATURE_REQUIRED=Y の設定に基づいて有効なデジタル署名を必要とするプロセスが、コンポジット署名ステータス TPSIGN_UNKNOWN が添付されたメッセージを受信した場合、システム側では次のアクションが実行されます。

暗号化のエラー処理

プロセスが、メッセージの暗号化エンベロープのいずれかと一致するオープンした復号化キーを持たない状態で、暗号化されたメッセージを受信した場合、システムは次のアクションを実行します。

ENCRYPTION_REQUIRED=Y の設定に基づいて暗号化された入力を必要とするプロセスが、暗号化されていないメッセージを受信した場合、システムは次のアクションを実行します。

関連項目

 

先頭へ戻る 前のトピックへ 次のトピックへ