|
|
以下の節では、Oracle Tuxedo の ATMI アプリケーション用のさまざまなセキュリティ機能について説明します。
| 注意 : | Oracle Tuxedo には、ATMI (アプリケーション トランザクション モニタ インタフェース) アプリケーションと CORBA アプリケーションを作成するための 2 種類の環境が用意されています。この章では、ATMI アプリケーションに対するセキュリティ機能の実装方法を説明します。CORBA アプリケーションに対するセキュリティ機能の実装方法については、『Tuxedo CORBA アプリケーションのセキュリティ機能』を参照してください。 |
セキュリティとは、コンピュータ内のデータまたはコンピュータ間で送受信されるデータが損なわれないことを保証する技術のことです。ほとんどのセキュリティ機能では、パスワードおよびデータの暗号化を使用してセキュリティを実現します。パスワードとは、秘密の文字列であり、ユーザは、これを入力することにより特定のプログラムやシステムにアクセスできます。データの暗号化とは、データを理解できない形式に変換することであり、変換されたデータは復号化のメカニズムがないと解読できません。
電子商取引などで使用される分散アプリケーションには、悪質なユーザがデータを傍受したり、操作を中断したり、不正な情報を入力できるアクセス ポイントが多数あります。ビジネスがより広い範囲に分散されるほど、こうした悪質なユーザによる攻撃を受けやすくなります。したがって、このようなアプリケーションの基盤となる分散型のコンピューティング ソフトウェア、つまりミドルウェアは、セキュリティ機能を備えている必要があります。
Oracle Tuxedo 製品には、ATMI アプリケーション用のセキュリティ機能がいくつか用意されており、その大部分は、特定のニーズに合わせてカスタマイズできます。
次の図に示すように、Oracle Tuxedo システムで利用できるセキュリティ機能は、プラグイン インタフェースによって実装されています (ただし、例外が 1 つあります)。プラグイン インタフェースにより、Oracle Tuxedo のユーザは、独自のセキュリティ プラグインを定義し、動的に追加することができます。セキュリティ プラグインは、特定のセキュリティ機能を実装するコード モジュールです。
セキュリティ プラグインのインタフェースの仕様は一般には公開されていませんが、サード パーティのセキュリティ ベンダには公開されています。サード パーティのセキュリティ ベンダは、Oracle 社と専用契約を結ぶことで Oracle Tuxedo のセキュリティ プラグインを開発することができます。セキュリティ機能をカスタマイズする場合は、これらのセキュリティ ベンダにお問い合わせください。たとえば、公開鍵によるセキュリティ機能をカスタマイズする場合は、適切なセキュリティ プラグインを提供するサード パーティのセキュリティ ベンダに問い合わせる必要があります。セキュリティ プラグインの詳細 (インストール手順およびコンフィグレーション手順を含む) については、Oracle 社の営業担当者にお問い合わせください。
Oracle Tuxedo システムでは、さまざまな方法でセキュリティを実現できます。たとえば、ホスト オペレーティング システムのセキュリティ機能を使用して、ファイル、ディレクトリ、およびシステム リソースへのアクセスを制御することができます。次の表では、Oracle Tuxedo システムの ATMI 環境で利用できるセキュリティ機能を説明します。
ファイルに対するパーミッション設定などのセキュリティ機能を備えた、ホスト側のオペレーティング システムでは、オペレーティング システム レベルのセキュリティが、第一レベルのセキュリティ機能になります。アプリケーション管理者は、ファイルに対してパーミッションを設定することにより、特定のユーザまたはユーザ グループに対して、アクセス特権を付与したり、拒否することができます。
ほとんどの場合、ATMI アプリケーションは、アプリケーション管理者によって管理されます。アプリケーション管理者は、アプリケーションをコンフィグレーションし、起動し、実行中のアプリケーションを動的にモニタし、必要に応じて変更します。ATMI アプリケーションは、管理者が起動し、実行するため、サーバ プログラムは、管理者のパーミッションで実行されます。これで、サーバ プログラムは安全であり、「信頼性がある」と見なされます。この方法は、基盤となるオペレーティング システムのログイン メカニズムとパーミッション設定 (ファイル、ディレクトリ、およびシステム リソースに対する読み取り権と書き込み権の設定) に基づいています。
クライアント プログラムは、自分のパーミッションを持つユーザによって直接実行されます。さらに、ネイティブ クライアント (サーバ プログラムと同じマシンで実行中のクライアント) を実行するユーザは、UBBCONFIG コンフィグレーション ファイルにアクセスしたり、掲示板 (ATMI アプリケーションを制御するパラメータおよびアプリケーションの統計情報を格納するために確保されている共有メモリの一部) などのプロセス間通信 (IPC) のメカニズムにアクセスできます。
より高度なセキュリティ機能を備えたプラットフォーム上の ATMI アプリケーションでは、ファイルおよび IPC メカニズムに対するアクセスをアプリケーション管理者だけに限定し、管理者のパーミッション (UNIX ホスト マシンの setuid コマンドまたは別のプラットフォームでの同等のコマンド) を使用して「信頼性のある」クライアント プログラムを実行すると、より安全です。最も高いレベルのオペレーティング システムのセキュリティを実現するには、ワークステーション クライアントだけがアプリケーションにアクセスできるようにし、アプリケーション サーバおよび管理プログラムを実行するマシンではクライアント プログラムを実行できないようにします。
認証機能とは、通信するプロセスどうしがお互いの ID を証明し合うことです。Oracle Tuxedo システムの ATMI 環境の認証プラグイン インタフェースは、共有シークレット パスワード、ワンタイム パスワード、CHALLENGE 応答、Kerberos などの認証技術を使用して、セキュリティ プロバイダによるさまざまな認証プラグインに対応できます。インタフェースは、必要に応じて GSSAPI (Generic Security Service Application Programming Interface) の仕様に厳密に従います。GSSAPI は、公開されている IETF (Internet Engineering Task Force) の標準です。認証プラグイン インタフェースは、サード パーティ ベンダのセキュリティ製品をできるだけ簡単に Oracle Tuxedo システムに統合できるように設計されています。ただし、セキュリティ製品は GSSAPI を使用して記述しておく必要があります。
認証機能を使用するためのプラグイン インタフェースは、1 つのプラグインとして実装され、デフォルトの認証プラグインを使用することも、カスタマイズした認証プラグインを使用することもできます。
Oracle Tuxedo システムなどの分散型のエンタープライズ ミドルウェア環境で、エンド ツー エンドの相互認証を直接行う場合、特に、長時間の接続用に最適化されたセキュリティ メカニズムでは、大幅にコストがかかります。クライアントから各サーバ プロセスに対して直接ネットワーク接続を確立したり、サービス要求の処理時に複数の認証メッセージを交換および検証するのは、非効率的です。代わりに、ATMI アプリケーションは、次の図のような、高信頼性委託型認証モデルを使用します。
ワークステーション クライアントは、起動時に、信頼性のあるシステム ゲートウェイ プロセスであるワークステーション ハンドラ (WSH: Workstation Handler) に対して認証を行います。ネイティブ クライアントの場合は、自身に対して認証を行います (後で説明)。認証が成功すると、認証ソフトウェアは、クライアントにセキュリティ トークンを割り当てます。トークンとは、プロセス間の転送に適したオペークなデータ構造体です。WSH は、認証済みのワークステーション クライアントのトークンを安全に格納します。ネイティブ クライアントの場合は、認証済みのネイティブ クライアント自身のトークンを安全に格納します。
信頼性のあるゲートウェイは、通過するクライアント要求にセキュリティ トークンを添付します。添付されたセキュリティ トークンは、クライアント要求のメッセージと共に送信され、送信先のサーバ プロセスでの認可と監査で使用されます。
このモデルのゲートウェイでは、認証ソフトウェアがクライアントの ID を検証し、適切なトークンを生成することが期待されています。一方、サーバサイドでは、ゲートウェイ プロセスで適切なセキュリティ トークンが添付され、そのセキュリティ トークンが、クライアント要求を処理するその他のサーバに安全に格納されることが期待されています。
次の図は、ワークステーション クライアントと WSH との間でセッションが確立されているときの、Oracle Tuxedo システムの ATMI 環境内の制御フローを示しています。ここでは、ワークステーション クライアントと WSH が、メッセージを交換して相互に認証し合い、長期間にわたる接続を確立する様子を示しています。
まず、開始プロセス (ミドルウェアのクライアント プロセスなど) が、Oracle Tuxedo の「セキュリティ コンテキストの開始」関数を呼び出して、戻りコードとして成功または失敗が返されるまで繰り返し、セッション コンテキストを作成します。セッション コンテキストは、認証されたユーザと ID 情報を関連付けます。
ワークステーション クライアントが、ATMI アプリケーションに参加するために C の tpinit(3c) または COBOL の TPINITIALIZE(3cbl) を呼び出すと、Oracle Tuxedo システムは、まず内部の「資格取得」関数を呼び出して、セッション資格ハンドルを取得し、応答を返します。次に、内部の「セキュリティ コンテキストの開始」関数を呼び出して、セッション コンテキストを取得します。「セキュリティ コンテキストの開始」関数は、呼び出し時に入力セッション トークンを取り (セッション トークンがある場合)、出力セッション トークンを返します。セッション トークンでは、ユーザの ID を確認するためのプロトコルを使用します。開始プロセスが出力セッション トークンをセッションの対象プロセス (WSH) に渡すと、出力セッション トークンは、別の入力トークンと交換されます。トークンの交換は、双方のプロセスが相互認証を完了するまで繰り返されます。
セキュリティ プロバイダの認証プラグインでは、セキュリティ実装用のセッション トークンおよびセッション コンテキストの内容が定義されています。したがって、Oracle Tuxedo の認証セキュリティでは、セッション トークンとセッション コンテキストをオペークなオブジェクトとして扱う必要があります。交換されるトークンの数は定義されておらず、認証システムのアーキテクチャに応じて異なります。
ネイティブ クライアントでセッションを開始する場合、開始プロセスと対象プロセスは同じです。このプロセスは、ミドルウェア クライアント プロセスと見なすことができます。ミドルウェア クライアント プロセスは、セキュリティ プロバイダの認証プラグインを呼び出してネイティブ クライアントを認証します。
認証に成功すると、信頼性のあるゲートウェイは、Oracle Tuxedo の内部関数を 2 つ呼び出し、クライアント用の認可トークンおよび監査トークンを取得します。これらのトークンは、ゲートウェイによって格納されます。これらのトークンの組み合わせは、セキュリティ コンテキストのユーザ ID を表します。セキュリティ トークンという用語は、集合的に認可トークンと監査トークンを表します。
デフォルトの認証の認可トークンには、次の 2 つの情報が設定されています。
また、デフォルトの認証を使用する場合、監査トークンにも、プリンシパル名とアプリケーション キーが設定されます。
セッション トークンと同様に、認可トークンと監査トークンもオペークであり、内容は、セキュリティ プロバイダごとに異なります。認可トークンを使用すると、認可 (パーミッション) をチェックすることができます。監査トークンを使用すると、監査情報を記録することができます。ATMI アプリケーションによっては、認可用と監査用のユーザ ID を別々に設定すると便利です。
クライアントのサービス要求がサーバサイドで転送されるとき、サーバの ID が付く場合があります。次の図はその様子を示しています。サーバは、サービス要求に添付されたクライアント トークンを自らのトークンに置き換えてから、そのサービス要求を適切なサービスに転送します。
| 注意 : | サーバが自らの認可トークンと監査トークンを取得する方法、およびこれらのトークンを必要とする理由については、「プリンシパル名の指定」を参照してください。 |
上の図に示す機能を、サーバ パーミッションのアップグレードと呼びます。この機能では、ドット付きのサービス (.TMIB のように名前の先頭にピリオドが付いた、システムに組み込まれているサービス) をサーバが呼び出すたびに、サービス要求にサーバの ID が付き、サーバに対するアクセス権が取得されます。サーバのアクセス権とは、アプリケーション管理者 (システム管理者) のアクセス権のことです。つまり、クライアントからドット付きのサービスを直接呼び出すことはできなくても、まずサーバに要求を送信し、そのサーバからドット付きのサービスに要求を転送することはできます。ドット付きサービスの詳細については、『Oracle Tuxedo のファイル形式とデータ記述方法』の「MIB(5)」のリファレンス ページにある .TMIB サービスの説明を参照してください。
ATMI アプリケーションで認証機能を実行するには、デフォルトのプラグインまたはカスタマイズしたプラグインを使用します。どちらのプラグインを使用するかは、Oracle Tuxedo のレジストリをコンフィグレーションして決めます。これは、すべてのセキュリティ プラグインを制御するツールです。
デフォルトの認証プラグインを使用する場合、レジストリをコンフィグレーションする必要はありません。ただし、カスタマイズされた認証プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合わせてレジストリをコンフィグレーションする必要があります。レジストリの詳細については、「Oracle Tuxedo レジストリの設定」を参照してください。
認可の機能により、管理者は ATMI アプリケーションへのアクセスを制御できます。つまり、管理者は、認可の機能を使用して、ATMI アプリケーションのリソースまたは機能に対するアクセス権をプリンシパル (認証されたユーザ) に許可するかどうかを決定します。
ファンアウトとは、さまざまなプラグインの実装が接続された、アンブレラ (傘) 型のプラグインです。次の図に示すように、認可プラグインのインタフェースは、ファンアウトの構成で実装されます。
デフォルトの認可プラグインの実装は、ファンアウト プラグインとデフォルトの認可プラグインで構成されます。カスタマイズされたプラグインの実装は、ファンアウト プラグイン、デフォルトの認可プラグイン、および 1 つ以上のカスタム認可プラグインで構成されます。
ファンアウト プラグイン モデルでは、まず、呼び出し側がファンアウト プラグインに要求を送信します。受信された要求は、下位のプラグインに渡され、各プラグインから応答が返されます。最後に、ファンアウト プラグインは、受け取った複数の応答を 1 つの応答にまとめ (コンポジット応答)、呼び出し側に送信します。
認可要求の目的は、クライアント操作を許可するか、または操作の結果をそのまま残すかを決めることです。各認可プラグインは、permit、deny、または abstain のいずれかの応答を返します。abstain 応答が返されると、認可プラグインの作成者は、元のプラグインでは対応できないこと、たとえば、プラグインのインストール後にシステムに追加された操作名などに対処できます。
次の表は、認可のファンアウト プラグインで作成されるコンポジット応答を示しています。デフォルトの認可の場合、コンポジット応答は、デフォルトの認可プラグインによってのみ決まります。
カスタマイズした認可として、銀行アプリケーションを例に取ります。この例では、ユーザを Customer グループのメンバーとし、以下の条件が適用されるとします。
Customer グループのユーザは、月曜日の午前 10 時に 500 ドルを引き出すことはできます。ただし、同じユーザが、土曜日の午前中に同じ操作を行おうとしてもできません。
このほかにも、さまざまな状況が考えられます。色々な状況を想定し、ビジネス上のニーズに合った最適な状況を定義してください。
認可に関する一部の決定は、認可トークンに格納されているユーザ ID に基づいて行われます。認可トークンは、認証プラグインによって生成されるため、認証プラグインと認可プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。
Oracle Tuxedo システムのプロセスまたはサーバ (/Q サーバの TMQUEUE(5) またはイベント ブローカ サーバの TMUSREVT(5) など) は、クライアントからの要求を受け取ると認可プラグインを呼び出します。これに対し、認可プラグインは、操作前のチェックを行い、操作を許可するかどうかを示す応答を返します。
クライアント操作が許可されると、Oracle Tuxedo システムのプロセスまたはサーバは、クライアント操作が完了した後で認可プラグインを呼び出すことができます。これに対し、認可プラグインは、操作後のチェックを行い、操作の結果を許可するかどうかを示す応答を返します。
これらの呼び出しは、アプリケーション レベルの呼び出しではなく、システム レベルの呼び出しです。ATMI アプリケーションは、認可プラグインを呼び出せません。
Oracle Tuxedo システムに組み込まれているデフォルトの認可プラグインを使用する場合と、カスタマイズした認可プラグインを 1 つ以上使用する場合では、認可のプロセスが多少異なります。デフォルトのプラグインでは、操作後のチェックをサポートしていません。したがって、デフォルトの認可プラグインが、操作後のチェックを行う要求を受け取っても、要求は直ちに返され、何も実行されません。
カスタマイズしたプラグインでは、操作前と操作後の両方のチェックをサポートしています。
クライアントから操作前のチェックの実行が要求され、それに対して Oracle Tuxedo のプロセスによってデフォルトの認可が呼び出されると、認可プラグインは、次のタスクを実行します。
認可トークンは、認証プラグインによって作成されるため、認可プラグインにはトークンの内容が記録されていません。ただし、認可プロセスではこの情報が必要です。
認可プラグインは、クライアントの認可トークン、アクセス制御リスト (ACL: Access Control List)、および ATMI アプリケーションのセキュリティ レベル (ACL のコンフィグレーション (オプションまたは必須)) を調べて、操作を許可するかどうかを決めます。
認可のファンアウト プラグインは、デフォルトの認可プラグインの決定 (permit または deny) を受け取ると、その決定に従って動作します。
カスタマイズした 1 つ以上の認可プラグインを使用するユーザは、Oracle Tuxedo 製品の ATMI 環境で提供される別の機能を利用できます。つまり、操作の実行後にさらにチェックを行うことができます。
クライアントから操作前のチェックの実行が要求され、それに対して Oracle Tuxedo のプロセスによってカスタマイズした認可が呼び出されると、認可プラグインは、次のタスクを実行します。
認可プラグインは、操作、クライアントの認可トークン、および関連するデータを調べて、操作を許可するかどうかを決めます。関連するデータには、ユーザ データおよび ATMI アプリケーションのセキュリティ レベルが含まれます。
認可プラグインは、認可の要件に合うよう、必要に応じてユーザ データを変更してから操作を実行します。
認可のファンアウト プラグインは、下位にある個々のプラグインの応答 (permit、deny、または abstain) をチェックして、最終的な決定を行います。
クライアント操作が許可されると、Oracle Tuxedo システムのプロセスは、クライアント操作が完了した後でカスタマイズした認可を呼び出すことができます。その場合、認可プラグインは次のタスクを実行します。
操作後のチェック機能は、ラベル付けされた文書を扱うセキュリティ モデルで便利です。たとえば、機密文書へのアクセスを許可されたユーザが、最高機密文書を取り出す操作を実行したとします (通常、文書を識別するラベルの内容は、その文書が取り出されるまでわかりません)。この場合、操作後のチェックにより、操作の拒否または出力データの変更 (機密情報の削除) を効率的に行うことができます。
ATMI アプリケーションで認可機能を実行するには、デフォルトのプラグインを使用するか、または 1 つ以上のプラグインをカスタマイズします。プラグインを選択するには、すべてのセキュリティ プラグインを制御するツールである、Oracle Tuxedo レジストリをコンフィグレーションします。
デフォルトの認可プラグインを使用する場合、レジストリをコンフィグレーションする必要はありません。ただし、カスタマイズした認可プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合わせてレジストリをコンフィグレーションする必要があります。レジストリの詳細については、「Oracle Tuxedo レジストリの設定」を参照してください。
監査とは、操作要求とその結果に関する情報を収集、格納、および配布する方法です。監査証跡の記録からは、ATMI アプリケーションのセキュリティ レベルに違反するアクションを実行したプリンシパルや、そのようなアクションを実行しようとしたプリンシパルを判別できます。また、これらの記録から、試行された操作、失敗した操作、および成功した操作を判別することもできます。
監査方法 (情報の収集、処理、保護、および配布の方法) は、監査プラグインによって異なります。
ファンアウトとは、さまざまなプラグインの実装が接続された、アンブレラ (傘) 型のプラグインです。次の図は、ファンアウト型で実装された、監査プラグインのインタフェースを示しています。
デフォルトの監査プラグインの実装は、ファンアウト プラグインとデフォルトの監査プラグインで構成されます。カスタマイズされたプラグインの実装は、ファンアウト プラグイン、デフォルトの監査プラグイン、および 1 つ以上のカスタム監査プラグインで構成されます。
ファンアウト プラグイン モデルでは、まず、呼び出し側がファンアウト プラグインに要求を送信します。受信された要求は、下位のプラグインに渡され、各プラグインから応答が返されます。最後に、ファンアウト プラグインは、受け取った複数の応答を 1 つの応答にまとめ (コンポジット応答)、呼び出し側に送信します。
監査要求の目的は、イベントを記録することです。success (監査は成功し、イベントが記録される) または failure (監査は失敗し、イベントは記録されない) のどちらかの応答を返します。監査のファンアウト プラグインでは、下位のすべてのプラグインから応答として success が返されると、コンポジット応答は success になります。それ以外の場合、コンポジット応答は failure になります。
デフォルトの監査の場合、コンポジット応答は、デフォルトの監査プラグインによってのみ決まります。カスタマイズした監査の場合、コンポジット応答は、ファンアウト プラグインの下位プラグインの応答によって決まります。ファンアウト プラグインの動作については、「認可プラグインのアーキテクチャ」を参照してください。
監査に関する一部の決定は、監査トークンに格納されているユーザ ID に基づいて行われます。監査トークンは、認証プラグインによって生成されるため、認証プラグインと監査プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。
Oracle Tuxedo システムのプロセスまたはサーバ (/Q サーバの TMQUEUE(5) またはイベント ブローカ サーバの TMUSREVT(5) など) は、クライアントからの要求を受け取ると監査プラグインを呼び出します。監査プラグインは、操作が開始する前に呼び出されるため、操作の実行そのものを記録したり、データを格納することができます。データは、操作後の監査で使用できます。これに対し、監査プラグインは、操作前の監査を実行して、監査が成功したかどうかを返します。
Oracle Tuxedo システムのプロセスまたはサーバは、クライアント操作が実行された後で監査プラグインを呼び出すことができます。これに対し、監査プラグインは、操作後の監査を実行して、監査が成功したかどうかを示す応答を返します。
さらに、Oracle Tuxedo システムのプロセスまたはサーバは、セキュリティ違反につながる現象を検出すると、監査プラグインを呼び出す場合があります。たとえば、操作前または操作後の認可のチェックが失敗したり、セキュリティに対する攻撃が検出された場合などです。これに対し、監査プラグインは、操作後の監査を実行して、監査が成功したかどうかを示す応答を返します。
これらの呼び出しは、アプリケーション レベルの呼び出しではなく、システム レベルの呼び出しです。ATMI アプリケーションは、監査プラグインを呼び出せません。
Oracle Tuxedo システムに組み込まれているデフォルトの監査プラグインを使用する場合と、カスタマイズした監査プラグインを 1 つ以上使用する場合では、監査のプロセスが多少異なります。デフォルトのプラグインでは、操作前の監査をサポートしていません。したがって、デフォルトの監査プラグインが、操作前の監査を行う要求を受け取っても、要求は直ちに返され、何も実行されません。
カスタマイズしたプラグインでは、操作前と操作後の両方の監査をサポートしています。
デフォルトの監査の実装は、Oracle Tuxedo イベント ブローカとユーザ ログ (ULOG) で構成されます。これらのユーティリティは、セキュリティ違反だけをレポートします。試行された操作、失敗した操作、および成功した操作についてはレポートしません。
セキュリティ違反の疑いに対して操作後の監査を実行するため、Oracle Tuxedo プロセスによってデフォルトの監査が呼び出されると、監査プラグインは、次のタスクを実行します。
カスタマイズした 1 つ以上の監査プラグインを使用するユーザは、Oracle Tuxedo 製品の ATMI 環境で提供されるの別の機能を利用できます。つまり、操作の実行前に監査を行うことができます。
クライアントから操作前の監査の実行が要求され、それに対して Oracle Tuxedo のプロセスによってカスタマイズした監査が呼び出されると、監査プラグインは、次のタスクを実行します。
クライアント操作が実行されると、Oracle Tuxedo プロセスは、カスタマイズした監査を呼び出して操作後の監査を実行できます。その場合、監査プラグインは次のタスクを実行します。
操作前と操作後の監査を両方通過し、操作自体が成功した場合、その操作は成功したものと見なされます。操作前と操作後の両方の監査データを収集および格納する企業もありますが、これらのデータは大量のディスク領域を消費する可能性があります。
ATMI アプリケーションで監査機能を実行するには、デフォルトのプラグインを使用するか、または 1 つ以上のプラグインをカスタマイズします。プラグインを選択するには、すべてのセキュリティ プラグインを制御するツールである、Oracle Tuxedo レジストリをコンフィグレーションします。
デフォルトの監査プラグインを使用する場合、レジストリをコンフィグレーションする必要はありません。ただし、カスタマイズした認可プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合わせてレジストリをコンフィグレーションする必要があります。レジストリの詳細については、「Oracle Tuxedo レジストリの設定」を参照してください。
リンク レベルの暗号化 (LLE: Link-Level Encryption) は、ATMI アプリケーション内のマシン間をつなぐネットワーク リンク上で送受信されるメッセージの秘密性を保護します。また、対称鍵による暗号化技術である RC4 を使用します。RC4 では、暗号化と復号化の際に同じ鍵を使用します。
LLE を使用する場合、Oracle Tuxedo システムは、データを暗号化してからネットワーク リンク上に送信し、データがネットワーク リンクを離れると復号化します。システムは、データが通過するすべてのリンクで、この暗号化/復号化プロセスを繰り返します。したがって、LLE はポイント ツー ポイント機能と呼ばれます。
LLE は、ATMI アプリケーションの次の種類のリンクで使用できます。
LLE セキュリティには、0 ビット (暗号化なし)、56 ビット (国際版)、および 128 ビット (米国およびカナダ版) の 3 つのレベルがあります。国際版の LLE では、0 ビットと 56 ビットの暗号化が可能です。米国およびカナダ版の LLE では、0 ビット、56 ビット、および 128 ビットの暗号化が可能です。
LLE の制御パラメータおよび基本となる通信プロトコルは、リンクの種類によって異なります。ただし、以下の点では基本的に同じです。
以降の説明では、上記の 2 つのパラメータを (min, max) の形式で表記します。たとえば、あるプロセスの値が (56, 128) の場合は、56 ビットから 128 ビットまでの暗号化がサポートされることを示します。
ネットワーク リンクの両端にある 2 つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の 2 段階の手順で確認されます。
2 つのプロセスのうち、どちらかが起動すると、Oracle Tuxedo のローカル ソフトウェアは、(1) lic.txt ファイルの LLE 情報を参照して、インストール済みの LLE のバージョンのビット暗号化機能をチェックし、(2) 両方のプロセスのコンフィグレーション ファイルで指定されている、特定の種類のリンクでの LLE の min-max 値をチェックします。続いて、ローカル ソフトウェアは、次の処理を実行します。
min-max 値が、インストール済みの LLE のバージョンと対応する場合、ローカル ソフトウェアは、この値をプロセスの min-max 値として割り当てます。min-max 値が、インストール済みの LLE のバージョンと対応しない場合、ローカル ソフトウェアからは実行時エラーが返されます。たとえば、国際版の LLE がインストールされているときに、min-max 値が (128, 128) である場合です。この時点では、リンク レベルの暗号化は不可能です。min-max 値が指定されていない場合、ローカル ソフトウェアは、最小値として 0 を割り当て、最大値としてインストール済みの LLE のバージョンに対して可能な最高ビットの暗号化レートを割り当てます。つまり、ライセンス ファイルに STRENGTH=128 が指定されている場合は、LLE に (0, 128) を割り当てます。
2 つのプロセスの min-max 値が決まると、キー サイズの調整が開始します。この調整プロセスを暗号化したり、見えないようにする必要はありません。調整されたキー サイズは、ネットワーク接続が確立されている間は有効です。
次の表は、2 つのプロセス間で可能な min-max 値のすべての組み合わせを調整した結果のキー サイズを示しています。上段のヘッダ行は、2 つのプロセスのうち、片方のプロセスの min-max 値を示しています。左側のカラムは、もう一方のプロセスの min-max 値を示しています。
Oracle Tuxedo システムの ATMI 環境は、LLE の旧バージョンと互換性があります。
次の表は、ATMI アプリケーションの 2 つのプロセスのうち、片方がリリース 6.5 で動作しており、もう一方がリリース 7.1 以上で動作しているときの、調整結果のキー サイズを示しています。上段のヘッダ行は、リリース 7.1 以上で動作するプロセスの min-max 値を示しています。左側のカラムは、リリース 6.5 で動作するプロセスの min-max 値を示しています。
現在インストールされている Oracle Tuxedo が (0, 56)、(0, 128)、(56,56)、または (56, 128) にコンフィグレーションされているときに、LLE の最大レベルが 40 ビットにコンフィグレーションされている ATMI アプリケーションのリリース 6.5 と相互運用させようとすると、調整結果のキー サイズは、常に 56 に自動アップグレードされます。
この調整結果は、2 つのサイトで共にリリース 6.5 が動作しており、LLE のレベルが 40 ビットにコンフィグレーションされている場合の結果と同じです。どちらの場合も、調整を行うと、56 に自動的にアップグレードされます。
次の表は、ATMI アプリケーションの 2 つのプロセスのうち、片方がリリース 6.5 より前のバージョンで動作しており、もう一方がリリース 7.1 以上で動作しているときの、調整結果のキー サイズを示しています。上段のヘッダ行は、リリース 7.1 以上で動作するプロセスの min-max 値を示しています。左側のカラムは、リリース 6.5 より前のバージョンで動作するプロセスの min-max 値を示しています。
現在インストールされている Oracle Tuxedo が (0, 56) または (0, 128) にコンフィグレーションされているときに、LLE の最大レベルが 40 ビットにコンフィグレーションされている、リリース 6.5 より前のバージョンの ATMI アプリケーションと相互運用させようとすると、調整結果のキー サイズは、常に 40 になります。
現在インストールされている Oracle Tuxedo が (56, 56)、(56, 128)、または (128, 128) にコンフィグレーションされていると、LLE の最大レベルが 40 にコンフィグレーションされている、ATMI アプリケーションのリリース 6.5 より前のバージョンとは相互運用できません。共通のキー サイズを調整しようとしてもできません。
ワークステーション クライアントが初期化に費やせる時間は制限されています。デフォルトでは、LLE を使用しない ATMI アプリケーションでは 30 秒、LLE を使用する ATMI アプリケーションでは 60 秒に制限されています。この 60 秒には、暗号化されたリンクを調整する時間も含まれます。ただし、LLE がコンフィグレーションされている場合は、UBBCONFIG ファイルの MAXINITTIME パラメータでワークステーション リスナ (WSL) のサーバの値を変更するか、または WS_MIB(5) にある T_WSL クラスの TA_MAXINITTIME 属性の値を変更することによって、制限を変更できます。
LLE ソフトウェアは、Oracle Tuxedo システムの一部として、Oracle Tuxedo CD-ROM に収められています。米国およびカナダで LLE を使用するための Oracle Tuxedo リリース 7.1 のライセンスが供与されている場合、56 ビットまたは 128 ビットの暗号化が可能です。米国およびカナダ以外で LLE を使用するためのライセンスが供与されている場合、56 ビットの暗号化が可能です。
Oracle Tuxedo のライセンスは、UNIX ホスト マシンの場合は $TUXDIR/udataobj/lic.txt ファイル、Windows ホスト マシンの場合は %TUXDIR%\udataobj\lic.txt ファイルにすべて格納されています。
次のリストは、米国およびカナダで LLE を実行するためのライセンス ファイルのサンプルからの抜粋です。
[Oracle Tuxedo]
VERSION=9.1
LICENSEE=ACME CORPORATION
SERIAL=155566678
ORDERID=
USERS=1000
EXPIRATION=2006-01-31
SIGNATURE=TXmtx+AhQdJgr3sjjznBqRB7SP9Jgr3UzAKctjz+e6RmsFSAhUAhStj
znBQdL9n=
[LINK ENCRYPTION]
VERSION=9.1
LICENSEE=ACME CORPORATION
SERIAL=155566678
ORDERID=
USERS=1000
STRENGTH=128
EXPIRATION=2006-01-31
SIGNATURE=TXUAhSPnx2C9kMC0CFG+e6Rgr3UzmsFKRBPdJASAhU7KctjznBqFQsj
jznBdh0h=
.
.
.
Oracle Tuxedo 製品では、業界標準の SSL プロトコルを使用して、クライアント アプリケーションとサーバ アプリケーション間で安全な通信を確立します。SSL プロトコルを使用する場合、プリンシパルはデジタル証明書を使用して、自身の ID をピアに対して証明します。
| 注意 : | 実際に使用されているネットワーク プロトコルは、SSL プロトコルの後継にあたる TLS 1.0 です。しかしながらこのドキュメントでは、一般的な用法に従い、このプロトコルを SSL 暗号化と呼んでいます。 |
LLE と同じく、SSL プロトコルをパスワードによる認証で使用すると、クライアント アプリケーションと Oracle Tuxedo ドメイン間の通信の機密性と整合性を保護できます。SSL プロトコルをパスワードによる認証で使用する場合、tmloadcf コマンドを入力したときに SEC_PRINCIPAL_NAME パラメータで定義した IIOP リスナ/ハンドラ (IIOP、ワークステーション、または JOLT) のパスワードの入力を求められます。
SSL は、ATMI アプリケーションの次の種類のリンクで使用できます。
SSL セキュリティには、0 ビット (暗号化なし)、56 ビット、128 ビット、および 256 ビットの 4 つのレベルがあります。Tuxedo ライセンス ファイルの SSL セクションで STRENGTH=56 と指定した場合は、0 ビットおよび 56 ビットの SSL 暗号のみを使用できます。Tuxedo ライセンス ファイルの SSL セクションに STRENGTH=128 と指定されている場合は、0 ビット、56 ビット、128 ビット、および 256 ビットの SSL 暗号を使用できます。
図 1-7 に、SSL プロトコルのしくみを示します。
ATMI アプリケーションで SSL プロトコルを使用するには、SSL プロトコルおよび PKI を有効にするライセンスをインストールする必要があります。セキュリティ機能のライセンスのインストール方法については、『Oracle Tuxedo システムのインストール』を参照してください。
| 注意 : | 256 ビット SSL は、ライセンス ファイルに STRENGTH=128 と指定されている場合でも使用できます。 |
SSL プロトコルの実装は柔軟性が高いので、ほとんどの PKI に対応します。Oracle Tuxedo 製品で使用できるプラグインのデフォルト実装では、デジタル証明書を LDAP 対応のディレクトリに格納する必要があります。LDAP 対応であれば、どのディレクトリ サービスでもかまいません。また、Tuxedo アプリケーションで使用するデジタル証明書およびプライベート キーの取得先の認証局を選択する必要があります。LDAP 対応のディレクトリ サービスおよび認証局を準備してからでないと、SSL プロトコルを Tuxedo アプリケーションで使用できません。
ネットワーク リンクの両端にある 2 つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の 2 段階の手順で確認されます。
2 つのプロセスのうち、どちらかが起動すると、Oracle Tuxedo のローカル ソフトウェアは、(1) lic.txt ファイルの SSL 情報を参照して、インストール済みの SSL のバージョンのビット暗号化機能をチェックし、(2) 両方のプロセスのコンフィグレーション ファイルで指定されている、特定の種類のリンクでの SSL の min-max 値をチェックします。続いて、ローカル ソフトウェアは、次の処理を実行します。
min-max 値が、インストール済みの SSL のバージョンと対応する場合、ローカル ソフトウェアは、この値をプロセスの min-max 値として割り当てます。min-max 値が、インストール済みの SSL のバージョンと対応しない場合、ローカル ソフトウェアからは実行時エラーが返されます。たとえば、国際版の SSL がインストールされているときに、min-max 値が (128, 256) である場合です。この時点では、接続をネゴシエートすることはできません。min-max 値が指定されていない場合、ローカル ソフトウェアは、最小値として 0 を割り当て、最大値としてインストール済みの SSL のバージョンに対して可能な最高ビットの暗号化レートを割り当てます。つまり、強力な SSL 暗号化がライセンス供与された Tuxedo の場合は (0, 256) を割り当てます。
2 つのプロセスの min-max 値が決まると、キー サイズの調整が開始します。この調整プロセスを暗号化したり、見えないようにする必要はありません。調整されたキー サイズは、ネットワーク接続が確立されている間は有効です。
次の表は、2 つのプロセス間で可能な min-max 値のすべての組み合わせを調整した結果のキー サイズを示しています。上段のヘッダ行は、2 つのプロセスのうち、片方のプロセスの min-max 値を示しています。左側のカラムは、もう一方のプロセスの min-max 値を示しています。
2 つの Tuxedo プロセスの間で SSL を使用するには、両方のプロセスで Tuxedo 10.0 以降を実行している必要があります (ただし、『Tuxedo CORBA アプリケーションのセキュリティ機能』で説明されている CORBA SSL 機能を使用する場合を除きます)。WSL プロセスと JSL プロセスに非 SSL ポートと SSL ポートの両方を指定し、*DM_TDOMAIN 内の個別のエントリに SSL 接続または LLE 接続を指定できます。この方法により、個別のワークステーション クライアントおよび Tuxedo ドメインを Tuxedo 10 にアップグレードするのに合わせ、ワークステーションやドメイン アプリケーションを徐々に SSL に移行できます。
| 注意 : | MP モード アプリケーションでは、Tuxedo ドメイン内のすべてのマシンを Tuxedo 10.0 にアップグレードするまでは、BRIDGE プロセスと tlisten プロセスの間で SSL を使用することはできません。 |
ワークステーション クライアントが初期化に費やせる時間は制限されています。デフォルトの間隔は 60 秒で、これには暗号化されたリンクを調整する時間も含まれます。ただし、WSL がコンフィグレーションされている場合は、UBBCONFIG ファイルの MAXINITTIME パラメータでワークステーション リスナ (WSL) のサーバの値を変更するか、または WS_MIB(5) にある T_WSL クラスの TA_MAXINITTIME 属性の値を変更することによって、制限を変更できます。
暗号スイートとは、通信の整合性を保護するための鍵暗号アルゴリズム、対称暗号アルゴリズム、および Secure Hash Algorithm からなる SSL 暗号化方式のことです。たとえば、暗号スイート RSA_WITH_RC4_128_MD5 では、鍵暗号用に RSA、バルク暗号化用に 128 ビット鍵の RC4、メッセージ ダイジェスト用に MD5 を使用します。
ATMI セキュリティ環境では、表 1-8 の暗号化スイートがサポートされています。
SSL ソフトウェアは、Oracle Tuxedo システムの一部として、Oracle Tuxedo CD-ROM に収められています。SSL を使用するための Oracle Tuxedo リリース 7.1 のライセンスが供与されている場合は、256 ビットの暗号化が可能です。
Oracle Tuxedo のライセンスは、UNIX ホスト マシンの場合は $TUXDIR/udataobj/lic.txt ファイル、Windows ホスト マシンの場合は %TUXDIR%\udataobj\lic.txt ファイルにすべて格納されています。
次のリストは、SSL を実行するためのライセンス ファイルのサンプルからの抜粋です。
[Oracle Tuxedo]
VERSION=10.0
LICENSEE=ACME CORPORATION
SERIAL=155566678
ORDERID=
USERS=1000
EXPIRATION=2006-01-31
SIGNATURE=TXmtx+AhQdJgr3sjjznBqRB7SP9Jgr3UzAKctjz+e6RmsFSAhUAhStj
znBQdL9n=
[SSL ENCRYPTION]
VERSION=10.0
LICENSEE=ACME CORPORATION
SERIAL=155566678
ORDERID=
USERS=1000
STRENGTH=128
EXPIRATION=2006-01-31
SIGNATURE=TXUAhSPnx2C9kMC0CFG+e6Rgr3UzmsFKRBPdJASAhU7KctjznBqFQsj
jznBdh0h=
.
.
.
公開鍵によるセキュリティは、エンド ツー エンドのデジタル署名およびデータの暗号化を実現する、次の 2 つの機能を提供します。
メッセージ ベースのデジタル署名により、メッセージの受信者は、送信元と送信メッセージの両方を識別し、認証できます。デジタル署名では、送信元と送信メッセージの内容が確実に証明されます。送信メッセージには、送信者の署名が添付されているため、送信者はメッセージを送信した事実を否認することはできません。たとえば、ある人が自分の銀行口座から引き出しを行った後で、その処理が別の人によって行われたと主張することはできません。
さらに、メッセージ ベースの暗号化では、指定した受信者だけがメッセージを復号化できるため、メッセージの機密性が保たれます。
RSA Laboratories を中心とする主要な通信会社のグループによって規定された、非公式でありながら業界では認知されている公開鍵ソフトウェアの標準があります。これを PKCS (Public-Key Cryptography Standards) と言います。Oracle Tuxedo の ATMI 環境の公開鍵ソフトウェアは、PKCS-7 標準に準拠しています。
PKCS-7 は、ハイブリッド型の暗号化システムのアーキテクチャです。つまり、メッセージを暗号化するときは、ランダムなセッション キーを用いた対称鍵のアルゴリズムを使用し、ランダムなセッション キーを暗号化するときは、公開鍵のアルゴリズムを使用します。乱数ジェネレータにより、通信のたびに新しいセッション キーが作成されます。これで、以前の通信を利用した攻撃を防ぐことができます。
公開鍵の基底のアルゴリズムは、いずれもよく知られており、一般に市販されています。ATMI アプリケーションに最も適したアルゴリズムを選択するには、処理速度、セキュリティのレベル、およびライセンスに関する制約を考慮してください。たとえば、米国政府は、外国に輸出できるアルゴリズムを制限しています。
Oracle Tuxedo の ATMI 環境の公開鍵によるセキュリティでは、RSA、ElGamal、Rabin など、基盤となるプラグインでサポートされるすべての公開鍵のアルゴリズムがサポートされます (RSA は、RSA アルゴリズムの発明者の頭文字 (Rivest、Shamir、Adelman) を取ったものです)。これらのアルゴリズムはすべて、デジタル署名と暗号化に使用できます。
RSA など、公開鍵 (または非対称鍵) のアルゴリズムは、次の 2 つの鍵の組み合わせによって実装されます。これらの鍵は異なりますが、数学的には関連性があります。
Oracle Tuxedo の ATMI 環境のデジタル署名によるセキュリティでは、RSA、ElGamal、Rabin、Digital Signature Algorithm (DSA) など、基盤となるプラグインでサポートされるすべてのデジタル署名アルゴリズムがサポートされます。DSA 以外のすべてのアルゴリズムは、デジタル署名と暗号化に使用できます。DSA は、デジタル署名には使用できますが、暗号化には使用できません。
デジタル署名のアルゴリズムは、単にデジタル署名を実現するための公開鍵アルゴリズムです。DSA も公開鍵アルゴリズム、つまり、公開鍵とプライベート キーの組み合わせによって実装するアルゴリズムですが、デジタル署名用です。暗号化には適用できません。
公開鍵セキュリティでは、以下の 3 つの対称鍵アルゴリズムをサポートしています。
DES-CBC は、CBC (Cipher Block Chaining) モードで実行する 64 ビットのブロック暗号です。56 ビット (64 ビットの暗号化キーから 8 パリティ ビットを引いたもの) のキーを使用し、米国以外の国でも使用できます。
2 つの鍵による Triple DES は、EDE (Encrypt-Decrypt-Encrypt) モードで実行する 128 ビットのブロック暗号です。2 つの鍵による Triple DES では、56 ビット (実際には 112 ビット) のキーを使用します。米国から輸出することは禁止されています。
最近では、Triple-DES を使用して、DES の暗号鍵を保護し、転送するのが一般的になりました。つまり、入力データ (この場合は単一の DES キー) は、暗号化、復号化、暗号化、の順に繰り返し処理されます (暗号化/復号化/暗号化のプロセス)。このうち、2 回行われる暗号化では、両方とも同じ暗号鍵が使用されます。
RC2 は、40 ～ 128 ビットの範囲で、暗号鍵のサイズを変更できるブロック暗号です。DES より高速であり、40 ビットの暗号鍵は輸出できます。米国籍の企業の海外子会社および海外支店であれば、56 ビットの暗号鍵を使用することができます。Oracle Tuxedo の公開鍵セキュリティ機能では暗号鍵の長さを 128 ビットに制限していますが、米国では実質的に、RC2 にはどんな長さの鍵を使用することもできます。
Oracle Tuxedo をお使いのお客様は、このアルゴリズムのリストを拡張したり変更することはできません。
対称鍵アルゴリズムでは、同じ鍵を使用して、メッセージの暗号化と復号化を行います。公開鍵による暗号化システムでは、通信し合う 2 つのエンティティ間で送信されるメッセージの暗号化に対称鍵暗号化を使用します。対称鍵暗号は、公開鍵暗号より、少なくとも 1000 倍速く実行されます。
ブロック暗号は、対称鍵アルゴリズムの一種であり、固定長の平文 (暗号化されていないテキスト) のブロックを、同じ長さの暗号文 (暗号化されたテキスト) のブロックに変換します。この変換は、ランダムに生成されたセッション キーの値に基づいて行われます。固定長は、ブロック サイズと呼ばれます。
公開鍵によるセキュリティでは、MD5、SHA-1 (Secure Hash Algorithm 1) など、基盤となるプラグインでサポートされるすべてのメッセージ ダイジェスト アルゴリズムがサポートされます。MD5 と SHA-1 は、どちらも有名な一方向のハッシュ アルゴリズムです。一方向のハッシュ アルゴリズムでは、メッセージが「メッセージ ダイジェスト」または「ハッシュ値」と呼ばれる固定長の数値文字列に変換されます。
MD5 は、128 ビットのハッシュ値を生成する、高速のアルゴリズムです。32 ビットのマシンでの使用に適しています。SHA-1 は、160 ビットのハッシュ値を生成する、セキュリティ レベルの高いアルゴリズムですが、処理速度は MD5 よりやや遅くなります。
メッセージ ベースのデジタル署名およびメッセージ ベースの暗号化のソフトウェアは、Oracle Tuxedo システムの一部として、Oracle Tuxedo CD-ROM に収められていますが、これを使用するには別個のライセンスが必要です。Oracle Tuxedo のライセンスは、UNIX ホスト マシンの場合は $TUXDIR/udataobj/lic.txt ファイル、Windows 2003 ホスト マシンの場合は %TUXDIR%\udataobj\lic.txt ファイルにすべて格納されています。
次のリストは、メッセージ ベースのデジタル署名およびメッセージ ベースの暗号化用のライセンス ファイルのサンプルからの抜粋です。
[Oracle Tuxedo]
VERSION=9.1
LICENSEE=ACME CORPORATION
SERIAL=155566678
ORDERID=
USERS=1000
EXPIRATION=2006-01-31
SIGNATURE=TXmtx+AhQdJgr3sjjznBqRB7SP9Jgr3UzAKctjz+e6RmsFSAhUAhStj
znBQdL9n=
.
.
.
[PK ENCRYPTION]
VERSION=9.1
LICENSEE=ACME CORPORATION
SERIAL=155566678
ORDERID=
USERS=1000
STRENGTH=128
EXPIRATION=2006-01-31
SIGNATURE=TX0CFHkaBpKpAlXGEtQqi+/jJvMo1VB9AhUAUAkizwsgYefRwQJDNTF
0205b1ik=
[PK SIGNATURE]
VERSION=9.1
LICENSEE=ACME CORPORATION
SERIAL=155566678
ORDERID=
USERS=1000
STRENGTH=128
EXPIRATION=2006-01-31
SIGNATURE=TX0CiqA5FCAXJFXUEGvAki+gL+i09eRep9hYdshS/8a70MIJQChUAk9
zIAhUIH4=
メッセージ ベースのデジタル署名は、メッセージの送信者の ID を証明し、その内容を特定のメッセージ バッファとバインドすることにより、Oracle Tuxedo のセキュリティ機能を強化します。企業間または企業と一般ユーザの間で、インターネットを介してデータを送受信する多くのアプリケーションでは、送信側と受信側の両方で認証を行い、送信妨害のない通信を実現することが重要です。これらの条件は、セキュリティ保護されていない社内ネットワークを使用して ATMI アプリケーションを導入する場合にも特に重要です。
メッセージ ベースのデジタル署名では、エンド ツー エンドで内容がセキュリティ保護されます。つまり、メッセージ バッファは、送信プロセスで発信され、受信プロセスで受け取られるまで保護されます。送信中には、一時的なメッセージ キュー、ディスク ベース キュー、システム プロセスなどの中継ポイントでも保護され、サーバ間のネットワーク リンクで転送される間も保護されます。
次の図は、エンド ツー エンド型のメッセージ ベースのデジタル署名のしくみを示しています。
メッセージ ベースのデジタル署名では、メッセージのメッセージ ダイジェストを計算し、次に送信者のプライベート キーでメッセージ ダイジェストを暗号化して、デジタル署名を生成します。受信者は、暗号化されたメッセージ ダイジェストを署名者の公開鍵を使って復号化し、復号化したメッセージ ダイジェストと、別途計算したメッセージ ダイジェストを比較することによって、署名を検証します。署名者の公開鍵は、署名者の情報に含まれているデジタル証明書から参照するか、または、公開鍵の証明をユニークに識別する、発行者識別名および発行者固有のシリアル番号を参照して取得します。
デジタル証明書は、インターネットなどのネットワーク経由で、個人およびリソースを識別するために使用される電子ファイルです。デジタル証明書は、信頼性のある第三者機関である「認証局」によって認定された個人またはリソースの ID を特定の公開鍵に安全な方法でバインドします。公開鍵は重複しないため、公開鍵からオーナーを特定できます。
デジタル証明書は、特定の公開鍵が特定のサブスクライバ (所有者) に属することを検証します。証明書の受信者は、証明書に記載されている公開鍵を使用して、その公開鍵に対応するプライベート キーでデジタル署名が作成されたことを検証します。検証が成功すると、証明書で指定されたサブスクライバが、対応するプライベート キーの所有者であること、および、そのサブスクライバによってデジタル署名が作成されたことを、一連の処理で確認できたことになります。
最も広く知られている証明書の形式は、ITU-T X.509 国際規格によって定義された形式です。したがって、X.509 準拠の ATMI アプリケーションであれば、証明書の読み書きを行えます。Oracle Tuxedo の ATMI 環境の公開鍵によるセキュリティ機能では、X.509 バージョン 3 (X.509v3) 準拠の証明書が認識されます。
証明書は、認証局 (CA: Certification Authority) によって発行されます。証明書と公開鍵の発行対象に対して ID を保証できる、信頼性のある第三者機関または企業は、CA となることができます。CA は、証明書の作成時にプライベート キーを使用して証明書に署名し、デジタル署名を取得します。次に、CA は署名付きの証明書をサブスクライバに返します。証明書と CA の署名の組み合わせにより、有効な証明書が作成されます。
サブスクライバおよびその他の人が、CA のデジタル署名を検証するには、CA の公開鍵を使用します。CA は、そのキーを公開するか、または上位レベルの CA の証明書 (下位レベルの CA の公開鍵の有効性を証明) を発行して、公開鍵を利用可能にします。2 つ目の方法を用いると、CA が階層化されます。
暗号化メッセージの受信者が、信頼する上位 CA によって署名された証明書を持ち、この証明書に CA の公開鍵が含まれている場合は、CA のプライベート キーの信頼性を再帰的に高めることができます。この意味で、証明書は、デジタル署名の信頼性を確認する足がかりとなります。つまり、最終的には、いくつかの上位 CA の公開鍵の信頼性を確認するだけで済みます。一連の証明書を確認することにより、多数のユーザ署名の信頼性を証明できます。
つまり、デジタル署名は通信エンティティの ID を証明しますが、署名の信頼度は、署名を検証するための公開鍵を信頼できる、というレベルと同じです。
Oracle が CA となる予定はありません。Oracle の公開鍵のプラグイン インタフェースにより、Oracle Tuxedo のユーザは、CA を自由に選択できます。
特定のサブスクライバ用の公開鍵およびその ID を利用可能にし、検証に使用できるようにするため、デジタル証明書をリポジトリに公開したり、その他の方法で公開できます。リポジトリは、証明書およびその他の情報で構成されるデータベースであり、リポジトリ内の情報は、取得したり、デジタル署名を検証するために使用できます。情報を取得するには、検証プログラムを実行し、直接リポジトリ内の証明書を要求することにより、自動的に行います。
PKI (Public-Key Infrastructure) は、公開鍵暗号のアプリケーションをサポートするプロトコル、サービス、および標準で構成されます。PKI は比較的新しい技術であるため、定義はあいまいです。たとえば、単に、公開鍵証明書に基づいた、信頼性を示す階層構造を指す場合があります。また、別のコンテキストでは、エンド ユーザ用アプリケーションのデジタル署名および暗号化サービスを意味する場合もあります。
PKI を規定する単一の標準はありませんが、標準の策定を進める動きはあります。現時点では、標準が策定されるかどうか、またはさまざまな相互運用レベルの PKI が複数誕生するかどうかは不明です。この意味で、PKI 技術の現状は、インターネットによる広範囲の接続が可能になるまでの、1980 年代の LAN および WAN 技術に似ていると言えます。
Oracle が PKI ベンダとなる予定はありません。Oracle の公開鍵のプラグイン インタフェースにより、Oracle Tuxedo のユーザは、PKI ソフトウェアのベンダを自由に選択し、PKI のセキュリティ ソリューションを使用できます。
メッセージ ベースの暗号化では、データが秘密に扱われます。これは、企業間または企業と一般ユーザの間で、インターネットを介してデータを送受信する ATMI アプリケーションでは重要です。データの秘密性は、セキュリティ保護されていない社内ネットワークを使用して ATMI アプリケーションを導入する場合にも特に重要です。
メッセージ ベースの暗号化では、メッセージが意味のわからない状態に変換され、内容を変更しようとしてもできないため、メッセージの整合性が保たれます。
メッセージ ベースの暗号化では、エンド ツー エンドで内容がセキュリティ保護されます。つまり、メッセージ バッファは、送信プロセスで発信され、受信プロセスで受け取られるまで保護されます。送信中には、一時的なメッセージ キュー、ディスク ベース キュー、システム プロセスなどの中継ポイントでも保護され、サーバ間のネットワーク リンクで転送される間も保護されます。
次の図は、エンド ツー エンド型のメッセージ ベースの暗号化のしくみを示しています。
メッセージは、対称鍵アルゴリズムとセッション キーによって暗号化されます。次に、セッション キーが受信者の公開鍵によって暗号化されます。さらに、受信者は、受信者のプライベート キーを使用して、暗号化されたセッション キーを復号化します。最後に、受信者は、セッション キーを使用して暗号化されたメッセージを復号化し、メッセージ内容を取得します。
| 注意 : | この図では、(1) メッセージを暗号化する直前にデータを圧縮する、および (2) メッセージを復号化した直後にデータを解凍する、という 2 つの手順が説明されていません。 |
暗号化は、ATMI のメッセージ バッファ単位で行われます。したがって、メッセージ ベースの暗号化は、既存の ATMI のプログラミング インタフェースおよび通信パラダイムと互換性があります。暗号化のプロセスは、単一のマシン内にある 2 つのプロセス間で送受信されるメッセージに対して行われる場合も、2 つのマシン間でネットワークを介して送受信されるメッセージに対して行われる場合も同じです。
公開鍵セキュリティのベースとなるプラグイン インタフェースは、6 つのコンポーネント インタフェースから成り、それぞれのコンポーネントは、1 つ以上のプラグインを必要とします。これらのインタフェースを好みのプラグインでインスタンス化すれば、メッセージ ベースのカスタム デジタル署名とメッセージ ベースの暗号化を ATMI アプリケーションに持ち込むことができます。
公開鍵の初期化インタフェースによって、公開鍵ソフトウェアは、公開鍵とプライベート キーを開くことができます。たとえば、ゲートウェイ プロセスでは、メッセージを復号化してから転送するために、特定のプライベート キーへのアクセスが必要なこともあります。このインタフェースは、ファンアウトとして実装されます。
鍵管理インタフェースによって、公開鍵ソフトウェアは、公開鍵とプライベート キーを管理および使用することができます。なお、メッセージ ダイジェストとセッション キーは、このインタフェースを使用して暗号化および復号化されますが、公開鍵暗号を使用するバルク データの暗号化は行われません。バルク データの暗号化は、対称鍵暗号を使用して行われます。
証明ルックアップ インタフェースによって、公開鍵ソフトウェアは、所定のプリンシパルに対する X.509v3 証明を取得できます。プリンシパルは認証されたユーザです。証明データベースは、Lightweight Directory Access Protocol (LDAP)、Microsoft Active Directory、Netware Directory Service (NDS)、またはローカル ファイルなど、適切なツールを使用して格納することができます。
証明解析インタフェースによって、公開鍵ソフトウェアは、簡単なプリンシパル名と X.509v3 証明を関連付けることができます。パーサは、証明を解析して、証明に関連付けるプリンシパル名を生成します。
証明検査インタフェースによって、公開鍵ソフトウェアは、特定のビジネス ロジックに基づいて X.509v3 証明を検証することができます。このインタフェースはファンアウトとして実装されているため、Oracle Tuxedo のユーザは、自分自身のビジネス ルールを使用して証明の有効性を判定できます。
証明資料のマッピング インタフェースによって、公開鍵ソフトウェアは、鍵を開くために必要な証明資料へのアクセス、認可トークンの提供、および監査トークンの提供を行うことができます。
ATMI アプリケーションに公開鍵セキュリティを提供するには、カスタム プラグインを使用します。プラグインを選択するには、すべてのセキュリティ プラグインを制御するツールである、Oracle Tuxedo レジストリをコンフィグレーションします。
カスタム公開鍵プラグインを使用する場合は、公開鍵プラグイン用のレジストリをコンフィグレーションしてから、それらのプラグインをインストールする必要があります。レジストリの詳細については、「Oracle Tuxedo レジストリの設定」を参照してください。
デフォルト公開鍵の実装では、以下のアルゴリズムをサポートしています。
Oracle Tuxedo システムの ATMI 環境に用意されている、デフォルトの認証および認可のプラグインは、Oracle Tuxedo で最初に実現された、従来の Oracle Tuxedo の認証および認可の実装と同じように機能します。
アプリケーション管理者は、デフォルトの認証および認可のプラグインを使用して、5 つのうち、1 つのセキュリティ レベルを ATMI アプリケーションにコンフィグレーションできます。5 つのセキュリティ レベルは、以下のとおりです。
最も低いセキュリティ レベルでは、認証は行われません。最も高いセキュリティ レベルでは、アクセス制御リストの機能により、サービスを実行し、イベントをポストし、アプリケーション キューのメッセージをキューに登録 (または登録解除) するユーザが決定されます。次の表は、セキュリティ レベルを簡単にまとめたものです。
| 注意 : | 「クライアント」という用語は「クライアント プロセス」と同義であり、実行中のクライアント プログラムの特定のインスタンスを意味します。ATMI のクライアント プログラムは、任意の数の個別インスタンスのアクティブ メモリ内に存在することができます。 |
アプリケーション管理者は、UBBCONFIG コンフィグレーション ファイルの SECURITY パラメータに適切な値を設定することにより、セキュリティ レベルを指定できます。
デフォルト値は NONE です。SECURITY に USER_AUTH、ACL、または MANDATORY_ACL を設定した場合、アプリケーション管理者は、システム側で提供される AUTHSVR という名前の認証サーバをコンフィグレーションしなければなりません。AUTHSVR は、ユーザ単位で認証を行います。
アプリケーション開発者は、AUTHSVR を、ATMI アプリケーションに固有のロジックを持つ認証サーバに置き換えることができます。たとえば、広く使用されている Kerberos のメカニズムを使用して認証を行うため、認証サーバをカスタマイズすることもできます。
クライアント プロセスは、ATMI アプリケーションに参加すると、ユーザ クライアント名 (ユーザとクライアントを組み合わせた名前) およびアプリケーション キー (ユニークなクライアント識別子) を持ちます。
2 つのクライアント名 tpsysadm および tpsysop が、特殊なセマンティクス用に用意されています。tpsysadm はアプリケーション管理者として扱われ、tpsysop はアプリケーション オペレータとして扱われます。
認証されたクライアントは、ATMI アプリケーションに参加すると、ユーザ名とクライアント名を TPINIT バッファの tpinit(3c) に渡すか (アプリケーションが C で記述されている場合)、または、TPINFDEF-REC レコードの TPINITIALIZE(3cbl) に渡します (アプリケーションが COBOL で記述されている場合)。次の表では、ユーザ名とクライアント名、および、TPINIT バッファまたは TPINFDEF-REC レコード内のその他のセキュリティ関連フィールドを説明します。
認証されたセキュリティ レベル (USER_AUTH、ACL、または MANDATORY_ACL) では、ユーザ名、クライアント名、およびユーザ固有のデータは、Oracle Tuxedo システムで変換されることなく AUTHSVR に転送されます。これらの情報が変換されるとすれば、ワークステーション クライアントからネットワーク経由で送信されるときに暗号化が行われる場合のみです。
クライアントが ATMI アプリケーションに参加するたびに、Oracle Tuxedo システムはクライアントに 32 ビットのアプリケーション キーを割り当てます。クライアントは、アプリケーションとの関連付けを解除し、別のユーザとして ATMI アプリケーションに参加しない限り、このアプリケーション キーをリセットできません。
割り当てられたアプリケーション キーは、クライアントのセキュリティ資格です。クライアントは、TPSVCINFO 構造体の一部として、すべてのサービス呼び出しに appkey フィールドを指定します。TPSVCINFO の詳細については、『Oracle Tuxedo C リファレンス』の tpservice(3c) を参照してください。
次の表は、さまざまなセキュリティ レベルとクライアントに割当てられるアプリケーション キーを示します。アプリケーション キーの割り当ては、最後の項目を除き、すべてハードコーディングされます。
さらに、C プログラムの tpsvrinit(3c) または tpsvrdone(3c) (COBOL では TPSVRINIT(3cbl) または TPSVRDONE(3cbl)) から発信されるメッセージには、管理者のアプリケーション キーである 0x80000000 が割り当てられます。クライアントのアプリケーション キーは、クライアントからサーバに送信されるメッセージに割り当てられます。この規則の例外については、「クライアント トークンとサーバ トークンの交換」を参照してください。
ユーザ識別子 (UID) は、特定のユーザを示すため、アプリケーション側で使用される識別子であり、0 ～ 128K の整数で表されます。グループ識別子 (GID) は、アプリケーション グループを示すため、アプリケーション側で使用される識別子であり、0 ～ 16K の整数で表されます。
アクセス制御機能を使用するため、アプリケーション管理者は、(1) ユーザ、(2) グループ、および (3) グループとアプリケーション エンティティ (サービス、イベント、およびアプリケーション キューなど) のマッピング リストを管理する必要があります。3 つ目のアプリケーション エンティティへのグループのマッピング リストは、アクセス制御リスト (ACL) と呼ばれます。
クライアントがサービスなどのアプリケーション リソースに対してアクセスを試みると、システム側では、クライアントのアプリケーション キーをチェックし、ユーザが属するグループを識別します。次に、システムは、ACL にある対象リソースをチェックし、そのリソースに対するアクセス権がクライアントのグループに付与されているかどうかを判別します。アプリケーション管理者、アプリケーション オペレータ、およびアプリケーション管理者またはオペレータの特権で実行中のプロセスやサービス要求は、ACL によるパーミッションのチェックの対象にはなりません。
ユーザ、グループ、および ACL のファイルは、application_root ディレクトリに置かれています。application _root は、APPDIR 変数に定義された最初のパス名です。次の図は、これらのファイルと、各リストを制御するための管理コマンドを示しています。
| 注意 : | Compaq VMS オペレーティング システムで動作する ATMI アプリケーションでは、ユーザ、グループ、および ACL ファイルの名前に .dat 拡張子が付きます (tpusr.dat、tpgrp.dat、および tpacl.dat)。 |
これらのファイルは、コロンで区切られたフラットなテキスト ファイルであり、アプリケーション管理者 (TUXCONFIG 変数が参照する TUXCONFIG ファイルのオーナー) だけが読み書きできます。これらのファイルは一連の専用コマンドで完全に管理されるため、ファイルの形式は無関係です。これらのコマンドを使用できるのは、アプリケーション管理者だけです。
アプリケーション管理者は、tpaclcvt(1) コマンドを使用して、セキュリティに関するデータ ファイルを ACL チェック用の形式に変換できます。たとえば、UNIX ホスト マシンで tpaclcvt を実行して /etc/password ファイルを変換し、変換後のファイルを tpusr ファイルに保存できます。この管理者は、tpaclcvt を実行して /etc/group ファイルを変換し、変換後のファイルを tpgrp ファイルに保存することもできます。
AUTHSVR サーバは、tpusr ファイル内のユーザ情報を使用して、ATMI アプリケーションに参加しようとするユーザを認証します。
ACL および MANDATORY_ACL のセキュリティ レベルは、Oracle Tuxedo システムの ATMI 環境でのデフォルトの認可実装です。
セキュリティ レベルが ACL の場合、対象アプリケーションのエンティティに関連するエントリが tpacl ファイルになくても、クライアントはそのエンティティにアクセスできます。管理者は、このセキュリティ レベルを使用して、セキュリティを強化したいリソースに対してのみアクセス権をコンフィグレーションできます。つまり、すべてのユーザにアクセスを許可するサービス、イベント、およびアプリケーション キューについて、tpacl ファイルにエントリを追加する必要はありません。
一方、セキュリティ レベルが MANDATORY_ACL の場合、対象アプリケーションのエンティティに関連するエントリが tpacl ファイルにないと、クライアントはそのエンティティにアクセスできません。したがって、このレベルは「必須」と呼ばれます。クライアントがアクセスを必要とするアプリケーション エンティティごとに、tpacl ファイル内にエントリが必要です。
ACL および MANDATORY_ACL のセキュリティ レベルで、クライアントが、tpacl ファイルにエントリがあるエンティティに対してアクセスしようとする場合、クライアントに関連するユーザは、そのエンティティへのアクセスを許可されたグループのメンバーでなければなりません。そうでない場合、アクセスは拒否されます。
ATMI アプリケーションによっては、システム レベルとアプリケーション レベルの両方の認可を使用することが必要な場合もあります。tpacl ファイルのエントリを使用すると、サービスに対するアクセスを許可するユーザを制限できます。また、アプリケーションのロジックを使用して、データ依存型のアクセスを制御することもできます。たとえば、100 万ドル以上のトランザクションを処理するユーザを指定することができます。
先頭にピリオド (.) が付く管理サービス、イベント、およびアプリケーション キューは、ACL によるパーミッションのチェック対象にはなりません。たとえば、.SysMachineBroadcast、.SysNetworkConfig、および .SysServerCleaning などの管理イベントには、どのクライアントもサブスクライブできます。さらに、アプリケーション管理者、アプリケーション オペレータ、およびアプリケーション管理者またはオペレータの特権で実行中のプロセスやサービス要求は、ACL によるパーミッションのチェックの対象にはなりません。
ATMI アプリケーションを Oracle Tuxedo リリース 7.1 より前 (6.5 以前) の Oracle Tuxedo ソフトウェアと相互運用させる場合、アプリケーションの開発者および管理者は、いくつかのセキュリティに関する問題を認識しておく必要があります。
この節で説明する「相互運用性」とは、最新版の Oracle Tuxedo ソフトウェアが、以前のリリースの Oracle Tuxedo ソフトウェアとネットワーク経由で通信する機能のことです。具体的には、「ドメイン間の相互運用性」と「ドメイン内の相互運用性」があり、それぞれ次のことを意味します。
Oracle Tuxedo リリース 7.1 以上を実行する ATMI アプリケーションが、Oracle Tuxedo リリース 7.1 より前のバージョンのソフトウェアを実行する別の ATMI アプリケーションと相互運用することです。「ドメイン間の相互運用性」を参照してください。
Oracle Tuxedo のアプリケーションが複数のマシンで構成されているときに、そのアプリケーション内で、Oracle Tuxedo リリース 7.1 以上を実行するマシンと Oracle Tuxedo リリース 7.1 より前のバージョンを実行する別のマシンが相互運用することです。「ドメイン内の相互運用性」を参照してください。
Oracle Tuxedo リリース 7.1 より前のバージョンのソフトウェアと相互運用するかどうかは、認証のセキュリティ レベルによって決まります。Oracle Tuxedo リリース 7.1 以上のソフトウェアで実装される認証機能では、通信プロセスにより相互の ID が証明されます。
デフォルトでは、リリース 7.1 より前の Oracle Tuxedo ソフトウェアを実行しているマシンとの相互運用は許可されません。このデフォルト設定を変更するには、アプリケーション管理者が CLOPT -t オプションを使用して、リリース 7.1 以上の ATMI アプリケーション内のワークステーション ハンドラ (WSH)、ドメイン ゲートウェイ (GWTDOMAINs)、およびサーバを、リリース 7.1 より前の Oracle Tuxedo ソフトウェアと相互運用できるようにします。CLOPT -t オプションの使い方、および CLOPT -t を使用するときの認証と認可に関するセキュリティ問題については、「相互運用性のポリシーの指定」を参照してください。
Oracle Tuxedo ソフトウェアを実行するマシン間でネットワーク リンクが確立されると、リンク レベルの暗号化を使用してデータを暗号化してからネットワーク リンク経由で送信し、データがネットワーク リンクを離れると復号化することができます。ただし、リンク レベルの暗号化は、送信側と受信側の両方のマシンの両方に LLE がインストールされている場合にのみ使用できます。
LLE と Oracle Tuxedo リリース 7.1 より前のソフトウェアとの相互運用性については、「LLE の旧バージョンとの互換性」を参照してください。
Oracle Tuxedo ソフトウェアを実行しているマシン間のネットワーク リンクで SSL 暗号化を使用できるのは、両方のマシンで Tuxedo 10.0 以降を実行している場合のみです。LLE 暗号化は、それ以前のバージョンの Tuxedo を実行しているマシン間のネットワーク リンクでも使用できます。
| 注意 : | SSL 暗号化の相互運用性規則には 1 つだけ例外があります。『Tuxedo CORBA アプリケーションのセキュリティ機能』で説明されている CORBA 関連の SSL 機能は、Tuxedo 8.0 との相互運用および以前の WLE 製品との相互運用に使用できます。 |
公開鍵によるセキュリティに関する以下の相互運用性の規則は、Oracle Tuxedo7.1 以上を実行するマシンと、Oracle Tuxedo 7.1 より前のバージョンを実行するマシンが相互運用する場合に適用されます。規則の内容を明確にするため、各規則では、Oracle Tuxedo 7.1 より前のバージョンを実行するワークステーション クライアントの例を示しています。
ドメイン間の相互運用性の場合、リリース 7.1 以上のドメイン ゲートウェイ (GWTDOMAIN) プロセスには、公開鍵によるセキュリティの相互運用性の規則が適用されます。
ドメイン内の相互運用性の場合、リリース 7.1 以上のネイティブ クライアント、ワークステーション ハンドラ (WSH)、またはローカル ブリッジ プロセスと通信するサーバ プロセスには、次の図のような、公開鍵によるセキュリティの相互運用性の規則が適用されます。ブリッジ プロセスは、パイプ役を果たすだけであり、メッセージ バッファの内容の復号化やデジタル署名の検証は行いません。
| 注意 : | 一般に、リリース 7.1 以上の WSH はデジタル署名を検証しません。しかし、リリース 7.1 より前の Oracle Tuxedo ソフトウェアを実行しているプロセスにデジタル署名付きのメッセージ バッファを転送すると、WSH は、デジタル署名を検証してから削除します。 |
Oracle Tuxedo リリース 7.1 以上のソフトウェアを実行する ATMI アプリケーションでは、デフォルトまたはカスタマイズした認証、認可、監査、および公開鍵セキュリティを自由に組み合わせることができます。さらに、これらの 4 つのセキュリティ機能の任意の組み合わせは、リンク レベルの暗号化とも互換性があります。
認可セキュリティ トークンに少なくとも (1) 認証されたユーザ名またはプリンシパル名、および (2) アプリケーション キーの値 (「アプリケーション キー」で定義) が必要であることがアプリケーション開発者側で認識されていれば、デフォルトの認証とカスタマイズした認可、またはカスタマイズした認証とデフォルトの認可を組み合わせて使用できます。
認可に関する一部の決定は、認可トークンに格納されているユーザ ID に基づいて行われます。認可トークンは、認証プラグインによって生成されるため、認証プラグインと認可プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。詳細については、「認証」および「認可」を参照してください。
監査セキュリティ トークンに少なくとも (1) 認証されたユーザ名またはプリンシパル名、および (2) アプリケーション キーの値 (「アプリケーション キー」で定義) が必要であることがアプリケーション開発者側で認識されていれば、デフォルトの認証とカスタマイズした監査、またはカスタマイズした認証とデフォルトの監査を組み合わせて使用できます。
監査に関する一部の決定は、監査トークンに格納されているユーザ ID に基づいて行われます。監査トークンは、認証プラグインによって生成されるため、認証プラグインと監査プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。詳細については、「認証」および「監査」を参照してください。
公開鍵によるセキュリティは、Oracle Tuxedo リリース 7.1 以上のソフトウェアでサポートされる、圧縮機能以外のすべての機能やプロセスと互換性があります。暗号化されたメッセージ バッファは、圧縮機能を使用しても圧縮できません。ただし、公開鍵によるソフトウェアでは、メッセージ バッファを暗号化する前に内容が圧縮されるため、ある程度サイズを節約できます。
この節では、公開鍵によるセキュリティと、次の機能またはプロセスとの互換性および相互運用性について説明します。
GWTDOMAIN)
データ依存型ルーティング機能の中心となるのは、プロセスが、受信したメッセージ バッファの内容を調べることです。受信したメッセージ バッファが暗号化されている場合、データ依存型ルーティング用にコンフィグレーションされたプロセスでは、受信者のプライベート キーを開き、公開鍵ソフトウェアがそのキーを使用してメッセージ バッファを復号化できるようにしておく必要があります。データ依存型ルーティングでは、公開鍵ソフトウェアは、デジタル署名を検証しません。
復号化キーを使用できない場合、ルーティング操作は失敗します。システムから userlog(3c) エラー メッセージが返され、操作が失敗したことがレポートされます。
復号化キーを使用できる場合、プロセスは、暗号化されたメッセージ バッファを復号化したコピーに基づいて、ルーティングに関する決定を行います。次の手順で実行されます。
その後、システムは、ルーティングに関する決定に基づいて、元の暗号化されたメッセージ バッファを送信します。
公開鍵とプライベート キーは、ハンドルを介して表現および操作されます。ハンドルには、それに関連付けられたデータがあります。公開鍵のアプリケーション プログラミング インタフェース (API: Application Programming Interface) では、ハンドルのデータを使用することにより、ハンドルで指定される項目の検索やアクセスを行います。プロセスは、デジタル署名の生成、メッセージの暗号化、およびメッセージの復号化のために、キー ハンドルを開きます。
キー ハンドルはプロセスのリソースです。特定のスレッドやコンテキストにバインドされることはありません。キーを開くために必要な Oracle Tuxedo の通信は、スレッドで現在アクティブなコンテキストの内部で実行されます。その後は、コンテキストが同じ ATMI アプリケーションに関連付けられているかどうかとは無関係に、プロセス内のどのコンテキストでもそのキーを使用できます。
キーの内部データ構造はスレッド セーフです。つまり、複数のスレッドが 1 つのキーに同時にアクセスできます。
一般に、TMUSREVT(5) システム サーバは、暗号化されたメッセージ バッファを復号化しないで処理します。つまり、メッセージが Oracle Tuxedo のイベント ブローカ コンポーネントを通過しても、デジタル署名と暗号化エンベロープは何の影響も受けません。ただし、以下の場合、イベント ブローカ コンポーネントは、ポストされたメッセージ バッファを復号化する必要があります。
イベント ブローカが適切な復号化キーにアクセスできない場合、そのサブスクリプションのフィルタ式は false と見なされ、サブスクリプションは不一致と見なされます。
イベント ブローカが適切な復号化キーにアクセスできない場合、そのサブスクリプションの通知アクションは失敗し、システムからは userlog(3c) エラー メッセージが返されて、処理が失敗したことがレポートされます。
イベント ブローカが適切な復号化キーにアクセスできない場合、そのサブスクリプションの通知アクションは失敗し、システムからは userlog() エラー メッセージが返されて、処理が失敗したことがレポートされます。
トランザクション型のサブスクリプションの場合、トランザクションは「ロールバックのみ」とマーキングされます。
イベント ブローカが適切な復号化キーにアクセスできない場合、tppost(3c) 操作は失敗し、システムからは userlog() エラー メッセージが返されて、処理が失敗したことがレポートされます。
イベント ブローカが適切な復号化キーにアクセスできない場合、tppost(3c) 操作は失敗し、システムからは userlog() エラー メッセージが返されて、処理が失敗したことがレポートされます。
一般に、TMQUEUE(5) または TMQFORWARD(5) のシステム サーバは、暗号化されたメッセージ バッファを復号化しないで処理します。つまり、メッセージが Oracle Tuxedo の /Q コンポーネントを通過しても、署名と暗号化エンベロープは何の影響も受けません。ただし、以下の場合、/Q コンポーネントは、キューに登録されたメッセージ バッファを復号化する必要があります。
TMQFORWARD を実行する場合
TMQFORWARD が適切な復号化キーにアクセスできない場合、転送操作は失敗します。システムからはメッセージがキューに返され、userlog(3c) エラー メッセージを生成して失敗をレポートします。
再試行を周期的に何度か繰り返すと、TMQFORWARD により、読み込み不可能なメッセージがエラー キューに格納される場合があります。
/Q コンポーネントが適切な復号化キーにアクセスできない場合、tpenqueue(3c) 操作は失敗し、システムからは userlog() エラー メッセージが返されて、処理が失敗したことがレポートされます。
/Q コンポーネントが適切な復号化キーにアクセスできない場合、tpenqueue(3c) 操作は失敗し、システムからは userlog() エラー メッセージが返されて、処理が失敗したことがレポートされます。
呼び出し側プロセスに有効な復号化キーがないと、非トランザクション型の tpdequeue(3c) 操作により、キューに登録された暗号化済みメッセージが破壊されます。
無効な署名が添付されたメッセージがキューに登録された場合 (またはそのメッセージがキュー内で破壊または改ざんされた場合) にそのメッセージをキューから取り出そうとすると失敗します。非トランザクション型の tpdequeue() 操作は、このようなメッセージを破壊します。トランザクション型の tpdequeue() 操作を行うと、トランザクションのロールバックが発生し、以降、キューからメッセージを取り出そうとしても失敗します。
公開鍵によるセキュリティ操作 (キーの開閉、デジタル署名の要求、暗号化の要求) はトランザクション型ではないため、トランザクションのロールバックによって元に戻すことはできません。ただし、トランザクションは、公開鍵の操作時に発生する以下の障害によってロールバックされる場合があります。
Oracle Tuxedo リリース 7.1 以上のソフトウェアを実行する 2 つの ATMI アプリケーションを接続するドメイン ゲートウェイ (GWTDOMAIN) プロセスには、デジタル署名および暗号化エンベロープがあります。さらに、これらのドメイン ゲートウェイ プロセスは、デジタル署名を検証し、デジタル署名と暗号化に関する管理システムポリシーを適用します。
次の図は、ドメイン ゲートウェイ プロセスが、ローカルおよびリモートの ATMI アプリケーションと対話する様子を示しています。この図に続く表では、デジタル署名が添付された暗号化メッセージ バッファが、リリース 7.1 以上のドメイン ゲートウェイ プロセスでどのように扱われるかを示しています。
|
|
||
|
|
||
|
|
||
Oracle Tuxedo リリース 7.1 以上の ATMI アプリケーションと、別のベンダのゲートウェイ プロセスを接続するドメイン ゲートウェイ (GWTDOMAIN) のプロセスは、アウトバウンド メッセージ バッファに対して次のように動作します。
さらに、ドメイン ゲートウェイ プロセスは、ATMI アプリケーションの暗号化とデジタル署名に関する管理システムのポリシーを適用します。たとえば、ATMI アプリケーションのドメイン レベルで、暗号化またはデジタル署名、あるいはその両方が必要な場合、ローカル ドメイン ゲートウェイのプロセスは、ほかのベンダのゲートウェイ プロセスから受信するすべてのメッセージを拒否します。
分散型のマルチ ドメイン Tuxedo アプリケーションがパブリック ネットワークや安全性の低い環境に拡張された場合、Tuxedo ドメイン ゲートウェイを潜在的脅威から確実に防御する必要があります。これらの環境には、安全性に問題のあるネットワークや、サービス拒否 (DoS) 攻撃 (図 1-16 を参照) などの悪意のある攻撃を開始または拡大させる信頼されていない参加者が含まれます。
Tuxedo TDomain ゲートウェイ (GWTDOMAIN) では、DoS 攻撃に対する防御に以下の機能が使用されます。
デーモン サーバである GWTDOMAIN は、既知の TCP ポートで待機して受信時接続要求を受け付けます。この場合、接続フラッド攻撃 (攻撃者がポート スキャン プログラムなど何らかのツールを使用して GWTDOMAIN と多数の接続を連続して確立しようとする DoS 攻撃の一種) の危険にさらされます。この攻撃により、ドメイン ゲートウェイは、接続要求を受け付けて各接続にリソースを割り当てることにコンピューティング パワー (時間やメモリなど) を浪費してしまいます。
この問題は、GWTDOMAIN で接続数を制限することによって回避できます。GWTDOMAIN の詳細については、「GWTDOMAIN(5)」を参照してください。
接続数の制限機能を使用するには、UBBCONFIG ファイルの *SERVERS セクションを変更する必要があります。
GWTDOMAIN のパラメータの指定に使用される CLOPT の構文は、-x limit[:{[duration][:period]}] です (「-x」が指定される)。各オプションはコロン (:) で区切ります。
| 注意 : | コロン (:) は、2 つのオプション間でのみ使用します。たとえば、「:duration」や「limit::」などのコンフィグレーションは無効です。 |
| 注意 : | オプション duration と period は、値が指定されなければデフォルト値が使用されます。 |
| 注意 : | パフォーマンス上の理由からタイミングは正確ではありません。1 秒の誤差が生じる可能性があります。 |
現在のアクティブな接続数と指定した前の期間 (period) で閉じられた接続数の合計が limit より大きい場合、GWTDOMAIN は秒単位で指定した時間 (duration) だけ一時停止します。
| 注意 : | 現在のアクティブな接続数には、アクティブな受信時接続とアクティブな送信時接続の両方が含まれます。前の「period」で閉じられた接続数には、閉じられた受信時接続と閉じられた送信時接続の両方が含まれます。しかし、GWTDOMAIN が一時停止した場合、閉じられた接続はカウントされません。 |
limit、duration、period の定義は次のとおりです。
接続の最大数。最小値は 0、最大値は 2,147,483,647 です。
limit に達している (あるいは超えている) ときに受信時接続要求があった場合、GWTDOMAIN は指定した時間 (duration) だけ一時停止します。同時に、一時停止をトリガする現在の受信時接続要求は受け付けられません。ポーリングは、duration の経過後に再開されます。
limit を 0 に設定すると、ドメイン ゲートウェイは受信時接続要求を受け付けません。つまり、「OUTGOING_ONLY」接続ポリシーになります。
制限 (limit) に達したときに受信時接続でポーリングを一時停止する時間 (秒)。デフォルト値は (SCANUNIT * SANITYSCAN) 秒です。最小値は 5、最大値は 65,535 です。
前に閉じられた接続をカウントするための GWTDOMAIN チェック ポイントからの時間間隔 (秒)。値を指定しない場合、duration と同じデフォルト値が指定されます。最小値は 0、最大値は 65,535 です。
period に 0 を指定した場合、前の期間 (period) で閉じられた接続数は常に 0 になるため、limit ではアクティブな接続のみがカウントされます。
コード リスト 1-1 に、GWTDOMAIN 制限 (limit) が 512 同時ソケット接続数に設定されている例を示します。制限 (limit) が 512 に達しているときに受信時接続があった場合、GWTDOMAIN は 300 秒 (5 分) 間だけポーリングと新たな受信時接続要求の受け付けを停止します。期間 (period) は 0 に指定しているので、アクティブな接続数のみがカウントされます。
# UBBCONFIG
...
*SERVERS
GWTDOMAIN SRVGRP=GWGRP1 SRVID=2 CLOPT= “-A -- -x 512:300:0”
コード リスト 1-2 に、GWTDOMAIN 制限 (limit) が 200 同時ソケット接続数に設定されている例を示します。制限 (limit) が 200 に達しているとき、以下のような状況であるとします。
duration 値が指定されていないので、GWTDOMAIN は duration のデフォルト値 (SCANUNIT * SANITYSCAN 秒) だけポーリングと新たな受信時接続要求の受け付けを停止します。
| 注意 : | 一時停止をトリガした現在の受信時接続も受け付けらず、一時停止時間の終了時に閉じられます。 |
# UBBCONFIG
...
*SERVERS
GWTDOMAIN SRVGRP=GWGRP1 SRVID=2 CLOPT= “-A -- -x 200::60”
以下のような場合、USERLOG にメッセージが出力されます。
<LIBGW_CAT 5359> "WARN: <ldom-name> に対する接続数は制限 <%d> を超えています。<%d> 秒間の中断を開始します。"
<LIBGW_CAT 5360> "INFO: 接続要求の受け付けを再開します。"
| 注意 : | 上記の 2 つのメッセージは、USERLOG がいっぱいになるのを回避するために「メッセージ調整」メカニズムを使用して制御できます。 |
<LIBGW_CAT 5361> "INFO: <ldom-name> に対する接続制限が 0 に設定されています。受信した接続要求は受け付けられません。"
メッセージの正常性チェックは、この機能を使用して強化され、GWTDOMAIN が攻撃を受けてクラッシュしないように保護します。この機能はインストール後に自動的にデプロイされるため、コンフィグレーション作業は必要ありません。
メッセージ認証コード (MAC) をメッセージと関連付けると、Tuxedo ドメイン ゲートウェイでメッセージを検証および認証することができます。MAC を使用すると、ドメイン ゲートウェイは、各種 DoS 攻撃 (メッセージの改ざん、メッセージの偽造、メッセージのリプレイ攻撃など) に対して防御することができます。
この機能は、LLE またはドメイン SECURITY がコンフィグレーションされている場合にのみ有効です。MAC は接続が確立した後に機能します。リモート ドメイン ゲートウェイからの MAC メッセージが検証および認証に失敗すると、対応する接続が切断されます。保留メッセージもすべて破棄され、現行のすべてのサービス要求が失敗します。
セッションで MAC を有効にするかどうかは、セッション調整フェーズ時に GWTDOMAIN によって決定されます。MAC を有効にできるのは、セッションで LLE または SECURITY がサポートされていて、アクティブになっている場合のみです。
| 注意 : | SSL では、MAC は使用できません。 |
MAC を有効にするために SECURITY 機能をサポートする必要はありませんが、SECURITY は「介在者」の攻撃に対する防御に使用できるのでお勧めします。
MAC が有効な場合、ドメイン間の要求に対するスループットと応答時間が低下する可能性があります。
MAC 機能をコンフィグレーションする場合、2 つの方法が利用できます。DMCONFIG ファイル コンフィグレーションと MIB コンフィグレーションです。
この機能は、2 つの新しいキーワード (MAC と MACLEVEL) を使用して、DMCONFIG ファイルの DM_TDOMAIN セクションでコンフィグレーションできます。MAC はセッションで MAC の機能を切り替えるために使用され、MACLEVEL は MAC レベルを指定するために使用されます。
| 注意 : | MACLEVEL の数値が大きいければ、暗号化という点ではより強力なアルゴリズムになりますが、同時にパフォーマンスは低下します。 |
コード リスト 1-3 に、DMCONFIG コンフィグレーションの例を示します。
# DMCONFIG
...
*DM_TDOMAIN
“RDOM” NWADDR=”//RHOST:RPORT”
MAC=”ON”
MACLEVEL=1
MIB を使用して MAC を動的に設定する場合、既存のドメイン セッションは影響を受けません。この設定は、新しい接続でのみ有効です。
MIB インタフェースをサポートするための 2 つの新しい属性 (TA_DMMAC と TA_DMMACLEVEL) が T_DM_TDOMAIN クラス定義の属性表に追加されます。
TA_DMMAC="{OFF|ON|MANDATORY}"
TA_DMMACLEVEL="{0|1|2|3}"
コード リスト 1-4 とコード リスト 1-5 に、ud32 を使用して MAC 属性を取得および更新する例をそれぞれ示します。
SRVCNM .TMIB
TA_OPERATION GET
TA_CLASS T_DM_TDOMAIN
TA_DMACCESSPOINT RDOM
TA_DMNWADDR //host:port
SRVCNM .TMIB
TA_OPERATION SET
TA_CLASS T_DM_TDOMAIN
TA_DMACCESSPOINT RDOM
TA_DMNWADDR //host:port
TA_DMLACCESSPOINT LDOM
TA_DMMAC MANDATORY
TA_DMMACLEVEL 2
表 1-17 に、2 つのドメイン (DOM1 と DOM2) を示します。DOM1 (開始側) が DOM2 (受信側) とのセッションを確立している場合、MAC 調整結果は (1) MAC = ON、(2) MACLEVEL = 2 になります。
表 1-18 と表 1-19 に、MAC と MACLEVEL の詳細をそれぞれ示します。
各表の最初のカラムには、DOM1 DMCONFIG ファイルの DM_TDOMAIN セクション内の DOM2 に対するコンフィグレーション パラメータが記入されています。ヘッダ行には、DOM2 DMCONFIG ファイルの DM_TDOMAIN セクション内の DOM1 に対するコンフィグレーション パラメータが記入されています。
表 1-18 の "ERROR" 結果は、接続が確立できないことを示します。MAC 調整結果が ON の場合、メッセージ全体の MACLEVEL が決定されます (表 1-19 を参照)。
MAC が有効な場合、使用される MACLEVEL は安全上の理由からより高い数値 (max (m1,m2)) に設定されます。これは、両方のエンドポイントでサポートされる必要があります (min (Max1,Max2) 以下)。つまり、調整された MACLEVEL は次の関係を満たす必要があります。
max(m1, m2)<=negotiated MACLEVEL<=min(Max1, Max2)。この関係が満たされていない場合は、接続が閉じられて対応するエラー メッセージが USERLOG に記録されます。
以下の INFO メッセージは、MAC に関する合意がなされて 1 つのセッションで MAC 機能が設定された後に出力されます。
以下のエラー メッセージは、セッション調整および MAC 検証フェーズ時に表示されます。これらのメッセージが出力されると、接続は切断されます。
<LIBGWT 1681> "ERROR: MAC が必要ですが、リモート ドメイン <rdom-name> はこの機能をサポートしていません"
<LIBGWT 1682> "ERROR: MAC が必要ですが、LLE も SECURITY も (<ldom-name>、<rdom-name>) の接続でサポートされていません"
<LIBGWT 1683> "ERROR: リモート ドメイン <rdom-name> で MAC が必要ですが、ローカル ドメイン <ldom-name> でサポートされていません"
<LIBGWT 1684> "ERROR: MAC は MACLEVEL に関する合意 (<ldom_name> は <%d>..<%d>、<rdom-name> は <%d>..<%d>) に失敗しました"
| 注意 : | このメッセージの "%d" プレースホルダに対応するパラメータは、m1、Max1、m2、Max2 です。 |
パスワード ペア保護機能はインストール後に自動的にデプロイされるため、コンフィグレーション作業は必要ありません。この機能により、GWTDOMAIN セキュリティ メカニズムが強化され、また、同じリモート パスワードによるデュアル パスワード ペアが使用できなかった以前のセキュリティの制限もなくなります。
パスワード ペア保護は、ローカル ドメインとリモート ドメインの両方でサポートされている場合にのみ機能します。ローカル ドメインとリモート ドメインの両方でサポートされてない場合は、既存の動作が変更されることはありません。
  
|