|
|
次の項では、Oracle TuxedoのATMIアプリケーション用の様々なセキュリティ機能について説明します。
| 注: | Oracle Tuxedoには、ATMI (アプリケーション・トランザクション・モニター・インタフェース)アプリケーションとCORBAアプリケーションを作成するための2種類の環境が用意されています。この章では、ATMIアプリケーションに対するセキュリティ機能の実装方法を説明します。CORBAアプリケーションに対するセキュリティ機能の実装方法については、『CORBAアプリケーションにおけるセキュリティの使用』を参照してください。 |
セキュリティとは、コンピュータに保存されているデータまたはコンピュータ間でやりとりされるデータが危険にさらされないことを保証する技術です。ほとんどのセキュリティ機能では、パスワードおよびデータの暗号化を使用してセキュリティを実現します。パスワードとは、秘密の文字列であり、ユーザーは、これを入力することにより特定のプログラムやシステムにアクセスできます。データの暗号化とは、データを理解できない形式に変換することであり、変換されたデータは復号化のメカニズムがないと解読できません。
電子商取引などで使用される分散アプリケーションには、悪質なユーザーがデータを傍受したり、操作を中断したり、不正な情報を入力できるアクセス・ポイントが多数あります。ビジネスがより広い範囲に分散されるほど、こうした悪質なユーザーによる攻撃を受けやすくなります。したがって、このようなアプリケーションの基盤となる分散型のコンピューティング・ソフトウェア、つまりミドルウェアは、セキュリティ機能を備えている必要があります。
Oracle Tuxedo製品には、ATMIアプリケーション用のセキュリティ機能がいくつか用意されており、その大部分は、特定のニーズに合せてカスタマイズできます。
図1-1に示すように、Oracle Tuxedo製品のATMI環境で利用できるセキュリティ機能は、1つを除いてすべてプラグイン・インタフェースによって実装されています。プラグイン・インタフェースにより、Oracle Tuxedoのユーザーは、独自のセキュリティ・プラグインを定義し、動的に追加することができます。セキュリティ・プラグインは、特定のセキュリティ機能を実装するコード・モジュールです。
セキュリティ・プラグインのインタフェースの仕様は一般には公開されていませんが、サード・パーティのセキュリティ・ベンダーには公開されています。サード・パーティのセキュリティ・ベンダーは、オラクル社と専用契約を結ぶことでOracle Tuxedoのセキュリティ・プラグインを開発することができます。セキュリティ機能をカスタマイズする場合は、これらのセキュリティ・ベンダーにお問い合せください。たとえば、公開鍵によるセキュリティ機能をカスタマイズする場合は、適切なセキュリティ・プラグインを提供するサード・パーティのセキュリティ・ベンダーに問い合せる必要があります。セキュリティ・プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。
Oracle Tuxedoシステムでは、様々な方法でセキュリティを実現できます。たとえば、ホスト・オペレーティング・システムのセキュリティ機能を使用して、ファイル、ディレクトリ、およびシステム・リソースへのアクセスを制御することができます。表1-1では、Oracle TuxedoシステムのATMI環境で利用できるセキュリティ機能を説明します。
デフォルトの認証プラグインには、認証なし、アプリケーション・パスワード、ユーザー・レベルの認証という3つのレベルのセキュリティが用意されています。このデフォルトのプラグインは、Oracle Tuxedoシステムで最初に実現された、Oracle Tuxedoの従来の認証の実装と同じように機能します。
|
|||
デフォルトの認可プラグインには、オプションのアクセス制御リストと必須のアクセス制御リストという2つのレベルのセキュリティが用意されています。このデフォルトのプラグインは、Oracle Tuxedoシステムで最初に実現された、Oracle Tuxedoの従来の認可の実装と同じように機能します。
|
|||
対称鍵による暗号化を使用して、ATMIアプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージの秘密性を保護します。
|
|||
公開鍵(非対称鍵)による暗号化を使用して、ATMIアプリケーションのクライアントとサーバー間でエンド・ツー・エンドのデジタル署名とデータの秘密性を実現します。この機能は、PKCS-7標準に準拠しています。
|
6つのインタフェースとして実装されます。
|
ファイルに対するパーミッション設定などのセキュリティ機能を備えた、ホスト側のオペレーティング・システムでは、オペレーティング・システム・レベルのセキュリティが、第一レベルのセキュリティ機能になります。アプリケーション管理者は、ファイルに対してパーミッションを設定することにより、特定のユーザーまたはユーザー・グループに対して、アクセス権限を付与したり、拒否することができます。
ほとんどの場合、ATMIアプリケーションは、アプリケーション管理者によって管理されます。アプリケーション管理者は、アプリケーションを構成し、起動し、実行中のアプリケーションを動的にモニターし、必要に応じて変更します。ATMIアプリケーションは、管理者が起動し、実行するため、サーバー・プログラムは、管理者のパーミッションで実行されます。これで、サーバー・プログラムは安全であり、「信頼性がある」と見なされます。この方法は、基盤となるオペレーティング・システムのログイン・メカニズムとパーミッション設定(ファイル、ディレクトリ、およびシステム・リソースに対する読取り権と書込み権の設定)に基づいています。
クライアント・プログラムは、自分のパーミッションを持つユーザーによって直接実行されます。さらに、ネイティブ・クライアント(サーバー・プログラムと同じマシンで実行中のクライアント)を実行するユーザーは、UBBCONFIG構成ファイルにアクセスしたり、掲示板(ATMIアプリケーションを制御するパラメータおよびアプリケーションの統計情報を格納するために確保されている共有メモリーの一部)などのプロセス間通信(IPC)のメカニズムにアクセスできます。
より高度なセキュリティ機能を備えたプラットフォーム上のATMIアプリケーションでは、ファイルおよびIPCメカニズムに対するアクセスをアプリケーション管理者だけに限定し、管理者のパーミッション(UNIXホスト・マシンのsetuidコマンドまたは別のプラットフォームでの同等のコマンド)を使用して「信頼性のある」クライアント・プログラムを実行すると、より安全です。最も高いレベルのオペレーティング・システムのセキュリティを実現するには、ワークステーション・クライアントだけがアプリケーションにアクセスできるようにし、アプリケーション・サーバーおよび管理プログラムを実行するマシンではクライアント・プログラムを実行できないようにします。
認証機能とは、通信するプロセスどうしがお互いのIDを証明し合うことです。Oracle TuxedoシステムのATMI環境の認証プラグイン・インタフェースは、共有シークレット・パスワード、ワンタイム・パスワード、CHALLENGEレスポンス、Kerberosなどの認証技術を使用して、セキュリティ・プロバイダによる様々な認証プラグインに対応できます。インタフェースは、Generic Security Service (GSS) Application Programming Interface (API)の仕様に可能なかぎり厳密に従います。GSSAPIは、Internet Engineering Task Forceの公開されている標準です。認証プラグイン・インタフェースは、サード・パーティ・ベンダーのセキュリティ製品をできるだけ簡単にOracle Tuxedoシステムに統合できるように設計されています。ただし、セキュリティ製品はGSSAPIを使用して記述しておく必要があります。
認証セキュリティの基礎となるプラグイン・インタフェースは、1つのプラグインとして実装されます。このプラグインは、デフォルトの認証プラグインでもカスタマイズした認証プラグインでもかまいません。
Oracle Tuxedoシステムなどの分散型のエンタープライズ・ミドルウェア環境で、エンド・ツー・エンドの相互認証を直接行う場合、特に、長時間の接続用に最適化されたセキュリティ・メカニズムでは、大幅にコストがかかります。クライアントから各サーバー・プロセスに対して直接ネットワーク接続を確立したり、サービス・リクエストの処理時に複数の認証メッセージを交換および検証するのは、非効率的です。かわりに、ATMIアプリケーションは、図1-2のような、高信頼性委任型認証モデルを使用します。
ワークステーション・クライアントは、起動時に、信頼性のあるシステム・ゲートウェイ・プロセスであるワークステーション・ハンドラ(WSH: Workstation Handler)に対して認証を行います。ネイティブ・クライアントの場合は、自身に対して認証を行います(後で説明)。認証が成功すると、認証ソフトウェアは、クライアントにセキュリティ・トークンを割り当てます。トークンとは、プロセス間の転送に適したオペークなデータ構造体です。WSHは、認証済のワークステーション・クライアントのトークンを安全に格納します。ネイティブ・クライアントの場合は、認証済のネイティブ・クライアント自身のトークンを安全に格納します。
信頼性のあるゲートウェイは、通過するクライアント・リクエストにセキュリティ・トークンを添付します。添付されたセキュリティ・トークンは、クライアント・リクエストのメッセージとともに送信され、送信先のサーバー・プロセスでの認可と監査で使用されます。
このモデルのゲートウェイでは、認証ソフトウェアがクライアントのIDを検証し、適切なトークンを生成することが期待されています。一方、サーバー側では、ゲートウェイ・プロセスで適切なセキュリティ・トークンが添付されることが期待されています。また、サーバー側では、クライアント・リクエストを処理するその他のサーバーによって、そのトークンが安全に配信されることも期待されています。
図1-3は、ワークステーション・クライアントとWSHとの間でセッションが確立されているときの、Oracle TuxedoシステムのATMI環境内の制御フローを示しています。ここでは、ワークステーション・クライアントとWSHが、メッセージを交換して相互に認証し合い、長期間にわたる接続を確立する様子を示しています。
まず、イニシエータ・プロセス(ミドルウェアのクライアント・プロセスと考えられます)は、Oracle Tuxedoの「セキュリティ・コンテキストの開始」関数を、戻りコードが成功または失敗を示すまで繰返し呼び出すことにより、セッション・コンテキストを作成します。セッション・コンテキストは、認証されたユーザーとID情報を関連付けます。
ワークステーション・クライアントが、ATMIアプリケーションに参加するためにCのtpinit(3c)またはCOBOLのTPINITIALIZE(3cbl)を呼び出すと、Oracle Tuxedoシステムは、まず内部の「資格取得」関数を呼び出して、セッション資格ハンドルを取得し、レスポンスを返します。次に、内部の「セキュリティ・コンテキストの開始」関数を呼び出して、セッション・コンテキストを取得します。「セキュリティ・コンテキストの開始」関数は、呼出し時に入力セッション・トークンを取り(セッション・トークンがある場合)、出力セッション・トークンを返します。セッション・トークンでは、ユーザーのIDを確認するためのプロトコルを使用します。イニシエータ・プロセスが出力セッション・トークンをセッションのターゲット・プロセス(WSH)に渡すと、出力セッション・トークンは、別の入力トークンと交換されます。トークンの交換は、双方のプロセスが相互認証を完了するまで繰り返されます。
セキュリティ・プロバイダの認証プラグインでは、セキュリティ実装用のセッション・トークンおよびセッション・コンテキストの内容が定義されています。したがって、ATMI認証では、セッション・トークンとセッション・コンテキストを不透明なオブジェクトとして扱う必要があります。交換されるトークンの数は定義されておらず、認証システムのアーキテクチャに応じて異なります。
ネイティブ・クライアントでセッションを開始する場合、イニシエータ・プロセスとターゲット・プロセスは同じです。このプロセスは、ミドルウェア・クライアント・プロセスと見なすことができます。ミドルウェア・クライアント・プロセスは、セキュリティ・プロバイダの認証プラグインを呼び出してネイティブ・クライアントを認証します。
認証に成功すると、信頼性のあるゲートウェイは、Oracle Tuxedoの内部関数を2つ呼び出し、クライアント用の認可トークンおよび監査トークンを取得します。これらのトークンは、ゲートウェイによって格納されます。これらのトークンの組合せは、セキュリティ・コンテキストのユーザーIDを表します。セキュリティ・トークンという用語は、集合的に認可トークンと監査トークンを表します。
デフォルトの認証の認可トークンには、次の2つの情報が設定されています。
また、デフォルトの認証を使用する場合、監査トークンにも、プリンシパル名とアプリケーション・キーが設定されます。
セッション・トークンと同様に、認可トークンと監査トークンもオペークであり、内容は、セキュリティ・プロバイダごとに異なります。認可トークンを使用すると、認可(パーミッション)をチェックすることができます。監査トークンを使用すると、監査情報を記録することができます。ATMIアプリケーションによっては、認可用と監査用のユーザーIDを別々に設定すると便利です。
図1-4に示すように、クライアントのサービス・リクエストがサーバーによって転送されるときに、サーバーのIDが付く場合があります。サーバーは、サービス・リクエストに添付されたクライアント・トークンを自らのトークンに置き換えてから、そのサービス・リクエストを適切なサービスに転送します。
| 注: | サーバーが自らの認可トークンと監査トークンを取得する方法、およびこれらのトークンを必要とする理由については、「プリンシパル名の指定」を参照してください。 |
上の図に示す機能を、サーバー・パーミッションのアップグレードと呼びます。この機能では、ドット付きのサービス(.TMIBのように名前の先頭にピリオドが付いた、システムに組み込まれているサービス)をサーバーが呼び出すたびに、サービス・リクエストにサーバーのIDが付き、サーバーに対するアクセス権が取得されます。サーバーのアクセス権とは、アプリケーション管理者(システム管理者)のアクセス権のことです。つまり、クライアントからドット付きのサービスを直接呼び出すことはできなくても、まずサーバーにリクエストを送信し、そのサーバーからドット付きのサービスにリクエストを転送することはできます。ドット付きサービスの詳細は、Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスの「MIB(5)」のリファレンス・ページにある.TMIBサービスの説明を参照してください。
ATMIアプリケーションで認証機能を実行するには、デフォルトのプラグインまたはカスタマイズしたプラグインを使用します。プラグインを選択するには、すべてのセキュリティ・プラグインを制御するツールである、Oracle Tuxedoレジストリを構成します。
デフォルトの認証プラグインを使用する場合、レジストリを構成する必要はありません。ただし、カスタマイズされた認証プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合せてレジストリを構成する必要があります。レジストリの詳細は、「Oracle Tuxedoレジストリの設定」を参照してください。
認可の機能により、管理者はATMIアプリケーションへのアクセスを制御できます。つまり、管理者は、認可の機能を使用して、ATMIアプリケーションのリソースまたは機能に対するアクセス権をプリンシパル (認証されたユーザー)に許可するかどうかを決定します。
ファンアウトとは、様々なプラグインの実装が接続された、アンブレラ(傘)型のプラグインです。図1-5に示すように、認可プラグインのインタフェースは、ファンアウトの構成で実装されます。
デフォルトの認可プラグインの実装は、ファンアウト・プラグインとデフォルトの認可プラグインで構成されます。カスタマイズされたプラグインの実装は、ファンアウト・プラグイン、デフォルトの認可プラグイン、および1つ以上のカスタム認可プラグインで構成されます。
ファンアウト・プラグイン・モデルでは、まず、呼出し側がファンアウト・プラグインにリクエストを送信します。受信されたリクエストは、下位のプラグインに渡され、各プラグインからレスポンスが返されます。最後に、ファンアウト・プラグインは、受け取った複数のレスポンスを1つのレスポンスにまとめ(複合レスポンス)、呼出し側に送信します。
認可リクエストの目的は、クライアント操作を許可するか、または操作の結果を変更しないままにするかを決めることです。各認可プラグインは、permit、denyまたはabstainのいずれかのレスポンスを返します。abstainレスポンスが返されると、認可プラグインの作成者は、元のプラグインでは対応できないこと、たとえば、プラグインのインストール後にシステムに追加された操作名などに対処できます。
表1-2は、認可のファンアウト・プラグインで作成されるコンポジット・レスポンスを示しています。デフォルトの認可の場合、コンポジット・レスポンスは、デフォルトの認可プラグインによってのみ決まります。
カスタマイズした認可として、銀行アプリケーションを例に取ります。この例では、ユーザーをCustomerグループのメンバーとし、次の条件が適用されるとします。
Customerグループのユーザーは、月曜日の午前10時に$500.00を引き出すことはできます。ただし、同じユーザーが、土曜日の午前中に同じ操作を行おうとしてもできません。
このほかにも、様々な状況が考えられます。いろいろな状況を想定し、ビジネス上のニーズに合った最適な状況を定義してください。
認可に関する一部の決定は、認可トークンに格納されているユーザーIDに基づいて行われます。認可トークンは、認証プラグインによって生成されるため、認証プラグインと認可プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。
Oracle Tuxedoシステムのプロセスまたはサーバー(/QサーバーのTMQUEUE(5)またはイベント・ブローカ・サーバーのTMUSREVT(5)など)は、クライアントからのリクエストを受け取ると認可プラグインを呼び出します。これに対し、認可プラグインは、操作前のチェックを行い、操作を許可するかどうかを返します。
クライアント操作が許可されると、Oracle Tuxedoシステムのプロセスまたはサーバーは、クライアント操作が完了した後で認可プラグインを呼び出すことができます。これに対し、認可プラグインは、操作後のチェックを行い、操作の結果を許可するかどうかを返します。
これらの呼出しは、アプリケーション・レベルの呼出しではなく、システム・レベルの呼出しです。ATMIアプリケーションは、認可プラグインを呼び出せません。
Oracle Tuxedoシステムに組み込まれているデフォルトの認可プラグインを使用する場合と、カスタマイズした認可プラグインを1つ以上使用する場合では、認可のプロセスが多少異なります。デフォルトのプラグインでは、操作後のチェックをサポートしていません。したがって、デフォルトの認可プラグインが、操作後のチェックを行うリクエストを受け取っても、リクエストはただちに返され、何も実行されません。
カスタマイズしたプラグインでは、操作前と操作後の両方のチェックをサポートしています。
クライアントから操作前のチェックの実行がリクエストされ、それに対してATMIのプロセスによってデフォルトの認可が呼び出されると、認可プラグインは、次のタスクを実行します。
認可トークンは、認証プラグインによって作成されるため、認可プラグインにはトークンの内容が記録されていません。ただし、認可プロセスではこの情報が必要です。
認可プラグインは、クライアントの認可トークン、アクセス制御リスト(ACL: Access Control List)、およびATMIアプリケーションのセキュリティ・レベル(ACLの構成(オプションまたは必須))を調べて、操作を許可するかどうかを決めます。
認可のファンアウト・プラグインは、デフォルトの認可プラグインの決定(permitまたはdeny)を受け取ると、その決定に従って動作します。
カスタマイズした1つ以上の認可プラグインを使用するユーザーは、Oracle Tuxedo製品のATMI環境で提供される別の機能を利用できます。つまり、操作の実行後にさらにチェックを行うことができます。
クライアントから操作前のチェックの実行がリクエストされ、それに対してATMIのプロセスによってカスタマイズした認可が呼び出されると、認可プラグインは、次のタスクを実行します。
認可プラグインは、操作、クライアントの認可トークン、および関連するデータを調べて、操作を許可するかどうかを決めます。関連するデータには、ユーザー・データおよびATMIアプリケーションのセキュリティ・レベルが含まれます。
認可プラグインは、認可の要件に合うよう、必要に応じてユーザー・データを変更してから操作を実行します。
認可のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(permit、deny、またはabstain)をチェックして、最終的な決定を行います。
クライアント操作が許可されると、ATMIのプロセスは、クライアント操作が完了した後でカスタマイズした認可を呼び出すことができます。その場合、認可プラグインは次のタスクを実行します。
操作後のチェック機能は、ラベル付けされた文書を扱うセキュリティ・モデルで便利です。たとえば、機密文書へのアクセスを許可されたユーザーが、最高機密文書を取り出す操作を実行したとします(通常、文書を識別するラベルの内容は、その文書が取り出されるまでわかりません)。この場合、操作後のチェックにより、操作の拒否または出力データの変更(機密情報の削除)を効率的に行うことができます。
ATMIアプリケーションで認可機能を実行するには、デフォルトのプラグインを使用するか、または1つ以上のプラグインをカスタマイズします。プラグインを選択するには、すべてのセキュリティ・プラグインを制御するツールである、Oracle Tuxedoレジストリを構成します。
デフォルトの認可プラグインを使用する場合、レジストリを構成する必要はありません。ただし、カスタマイズした認可プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合せてレジストリを構成する必要があります。レジストリの詳細は、「Oracle Tuxedoレジストリの設定」を参照してください。
監査とは、操作リクエストとその結果に関する情報を収集、格納、および配布する方法です。監査証跡の記録からは、ATMIアプリケーションのセキュリティ・レベルに違反するアクションを実行したプリンシパルや、そのようなアクションを実行しようとしたプリンシパルを判別できます。また、これらの記録から、試行された操作、失敗した操作、および成功した操作を判別することもできます。
監査方法(情報の収集、処理、保護、および配布の方法)は、監査プラグインによって異なります。
ファンアウトとは、様々なプラグインの実装が接続された、アンブレラ(傘)型のプラグインです。図1-6に示すように、監査プラグインのインタフェースは、ファンアウトの構成で実装されます。
デフォルトの監査プラグインの実装は、ファンアウト・プラグインとデフォルトの監査プラグインで構成されます。カスタマイズされたプラグインの実装は、ファンアウト・プラグイン、デフォルトの監査プラグイン、および1つ以上のカスタム監査プラグインで構成されます。
ファンアウト・プラグイン・モデルでは、まず、呼出し側がファンアウト・プラグインにリクエストを送信します。受信されたリクエストは、下位のプラグインに渡され、各プラグインからレスポンスが返されます。最後に、ファンアウト・プラグインは、受け取った複数のレスポンスを1つのレスポンスにまとめ(複合レスポンス)、呼出し側に送信します。
監査リクエストの目的は、イベントを記録することです。各監査プラグインは、success(監査が成功し、イベントが記録される)またはfailure(監査は失敗し、イベントは記録されない)のどちらかのレスポンスを返します。監査のファンアウト・プラグインの複合レスポンスは次のようになります。すべてのレスポンスがsuccessの場合、複合レスポンスはsuccessになり、それ以外の場合、複合レスポンスはfailureになります。
デフォルトの監査の場合、複合レスポンスは、デフォルトの監査プラグインによってのみ決まります。カスタマイズした監査の場合、複合レスポンスは、ファンアウト・プラグインの下位プラグインのレスポンスによって決まります。ファンアウト・プラグインの動作については、「認可プラグインのアーキテクチャ」を参照してください。
監査に関する一部の決定は、監査トークンに格納されているユーザーIDに基づいて行われます。監査トークンは、認証プラグインによって生成されるため、認証プラグインと監査プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。
ATMIのシステム・プロセスまたはサーバー(/QサーバーのTMQUEUE(5)またはイベント・ブローカ・サーバーのTMUSREVT(5)など)は、クライアントからのリクエストを受け取ると監査プラグインを呼び出します。監査プラグインは、操作が開始する前に呼び出されるため、操作の実行そのものを記録したり、データを格納することができます。データは、操作後の監査で使用できます。これに対し、監査プラグインは、操作前の監査を実行して、監査が成功したかどうかを返します。
ATMIのシステム・プロセスまたはサーバーは、クライアント操作が実行された後で監査プラグインを呼び出すことができます。これに対し、監査プラグインは、操作後の監査を実行して、監査が成功したかどうかを返します。
さらに、ATMIのシステム・プロセスまたはサーバーは、セキュリティ違反が発生した可能性がある場合、監査プラグインを呼び出すことがあります。(操作前または操作後の認可のチェックが失敗したり、セキュリティに対する攻撃が検出された場合、セキュリティ違反の疑いが生じます。)これに対し、監査プラグインは、操作後の監査を実行して、監査が成功したかどうかを返します。
これらの呼出しは、アプリケーション・レベルの呼出しではなく、システム・レベルの呼出しです。ATMIアプリケーションは、監査プラグインを呼び出せません。
Oracle Tuxedoシステムに組み込まれているデフォルトの監査プラグインを使用する場合と、カスタマイズした監査プラグインを1つ以上使用する場合では、監査のプロセスが多少異なります。デフォルトのプラグインでは、操作前の監査をサポートしていません。したがって、デフォルトの監査プラグインが、操作前の監査を行うリクエストを受け取っても、リクエストはただちに返され、何も実行されません。
カスタマイズしたプラグインでは、操作前と操作後の両方の監査をサポートしています。
デフォルトの監査の実装は、Oracle Tuxedoイベント・ブローカとユーザー・ログ(ULOG)で構成されます。これらのユーティリティは、セキュリティ違反だけをレポートします。試行された操作、失敗した操作、および成功した操作についてはレポートしません。
セキュリティ違反の疑いに対して操作後の監査を実行するため、ATMIプロセスによってデフォルトの監査が呼び出されると、監査プラグインは、次のタスクを実行します。
カスタマイズした1つ以上の監査プラグインを使用するユーザーは、Oracle Tuxedo製品のATMI環境で提供されるの別の機能を利用できます。つまり、操作の実行前に監査を行うことができます。
クライアントから操作前の監査の実行がリクエストされ、それに対してATMIのプロセスによってカスタマイズした監査が呼び出されると、監査プラグインは、次のタスクを実行します。
クライアント操作が実行されると、ATMIプロセスは、カスタマイズした監査を呼び出して操作後の監査を実行できます。その場合、監査プラグインは次のタスクを実行します。
操作前と操作後の監査を両方通過し、操作自体が成功した場合、その操作は成功したものとみなされます。操作前と操作後の両方の監査データを収集および格納する企業もありますが、これらのデータは大量のディスク領域を消費する可能性があります。
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段階の手順で確認されます。
Tuxedoプロセスでは、次の手順を使用してMINENCRYTPBITSおよびMAXENCRYPTBITSを処理します。
min-max値にデフォルトのmin-max値が収まる場合、ローカル・ソフトウェアは、この値をプロセスのmin-max値として割り当てます。min-maxのいずれかの値が構成されていない場合、欠落している値のかわりにデフォルト値が使用されます。たとえば、(0, max-value-configured)または(min-value-configured, 128)が使用されます。min-max値が指定されていない場合、ローカル・ソフトウェアは、最小値として0を割り当て、最大値としてデフォルトのmin-maxに対して可能な最高ビットの暗号化レートを割り当てます。つまり、LLEでは(0, 128)を割り当てます。 2つのプロセスのmin-max値が決まると、キー・サイズの調整が開始します。このネゴシエーション・プロセスを暗号化したり、見えないようにする必要はありません。調整されたキー・サイズは、ネットワーク接続が確立されている間は有効です。
表1-3は、2つのプロセス間で可能なmin-max値のすべての組合せを調整した結果のキー・サイズを示しています。上段のヘッダー行は、2つのプロセスのうち、片方のプロセスのmin-max値を示しています。左側の列は、もう一方のプロセスのmin-max値を示しています。
Oracle TuxedoシステムのATMI環境は、LLEの旧バージョンと互換性があります。
表1-4は、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ビットに構成されているリリース6.5のATMIアプリケーションと相互運用させようとすると、ネゴシエーションの結果は必ず56への自動アップグレードになります。
このネゴシエーション結果は、2つのサイトでともにリリース6.5が動作しており、LLEの最高レベルが40ビットに構成されている場合の結果と同じです。どちらの場合も、ネゴシエーションを行うと、56に自動的にアップグレードされます。
表1-5は、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ビットに構成されているリリース6.5より前のATMIアプリケーションと相互運用することはできません。共通のキー・サイズを調整しようとしてもできません。
ワークステーション・クライアントが初期化に費やせる時間は制限されています。デフォルトでは、LLEを使用しないATMIアプリケーションでは30秒、LLEを使用するATMIアプリケーションでは60秒に制限されています。この60秒には、暗号化されたリンクを調整する時間も含まれます。ただし、LLEが構成されている場合は、UBBCONFIGファイルのMAXINITTIMEパラメータでワークステーション・リスナー(WSL)のサーバーの値を変更するか、またはWS_MIB(5)にあるT_WSLクラスのTA_MAXINITTIME属性の値を変更することによって、制限を変更できます。
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暗号には、256ビット、128ビットおよび56ビット暗号があります。これについてはこの章で後から説明します。
図1-7に、SSLプロトコルのしくみを示します。
SSLプロトコルの実装は柔軟性が高いので、ほとんどの公開鍵インフラストラクチャに対応します。Tuxedoでは、SSLセキュリティ資格証明を格納するために2つの方法が提供されます。
ネットワーク・リンクの両端にある2つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の2段階の手順で確認されます。
Tuxedoプロセスでは、次の手順を使用してMINENCRYTPBITSおよびMAXENCRYPTBITSを処理します。
min-max値にデフォルトのmin-max値が収まる場合、ローカル・ソフトウェアは、この値をプロセスのmin-max値として割り当てます。min-maxのいずれかの値が構成されていない場合、欠落している値のかわりにデフォルト値が使用されます。たとえば、(0, max-value-configured)または(min-value-configured, 128)が使用されます。min-max値が指定されていない場合、ローカル・ソフトウェアは、最小値として0を割り当て、最大値として128を割り当てます。min-max値が40または56と構成されている場合は、デフォルトで112が使用されます。| 注: |
2つのプロセスのmin-max値が決まると、キー・サイズの調整が開始します。このネゴシエーション・プロセスを暗号化したり、見えないようにする必要はありません。調整されたキー・サイズは、ネットワーク接続が確立されている間は有効です。
表1-6は、2つのプロセス間で可能なmin-max値のすべての組合せを調整した結果のキー・サイズを示しています。上段のヘッダー行は、2つのプロセスのうち、片方のプロセスのmin-max値を示しています。左側の列は、もう一方のプロセスのmin-max値を示しています。
2つのTuxedoプロセスの間でSSLを使用するには、両方のプロセスでTuxedo 10.0以降を実行している必要があります(ただし、『CORBAアプリケーションにおけるセキュリティの使用』で説明されているCORBA SSL機能を使用する場合を除きます)。WSLプロセスとJSLプロセスに非SSLポートとSSLポートの両方を指定し、*DM_TDOMAIN内の個別のエントリにSSL接続またはLLE接続を指定できます。この方法により、個別のワークステーション・クライアントおよびTuxedoドメインをTuxedo 10にアップグレードするのに合わせ、ワークステーションやドメイン・アプリケーションを徐々にSSLに移行できます。
| 注: |
ワークステーション・クライアントが初期化に費やせる時間は制限されています。デフォルトでは、この間隔は60です。この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は、Tuxedoシステムの標準機能として実現されています。アプリケーションがセキュリティ資格証明の格納にOracle Walletを使用せず、LDAPを使用して証明書を取得する場合、管理者はインストール時にそのLDAPサーバーの名前、LDAPポート番号、LDAPフィルタ・ファイルの場所を用意しておく必要があります(デフォルトのLDAPフィルタ・ファイルの場所$TUXDIR/udataobj/security/bea_ldap_filter.datは、ほとんどのアプリケーションに適しています。)
インストール後にこの情報を変更する必要がある場合は、epifregedtコマンドを使用できます。
公開鍵によるセキュリティは、エンド・ツー・エンドのデジタル署名およびデータの暗号化を実現する、次の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ビットの暗号鍵を使用することができます。ATMIの公開鍵セキュリティ機能では暗号鍵の長さを128ビットに制限していますが、米国では実質的に、RC2にはどんな長さの鍵を使用することもできます。
Oracle Tuxedoをお使いのお客様は、このアルゴリズムのリストを拡張したり変更することはできません。
対称鍵アルゴリズムでは、同じ鍵を使用して、メッセージの暗号化と復号化を行います。公開鍵による暗号化システムでは、通信し合う2つのエンティティ間で送信されるメッセージの暗号化に対称鍵暗号化を使用します。対称鍵暗号は、公開鍵暗号より、少なくとも1000倍速く実行されます。
ブロック暗号は、対称鍵アルゴリズムの一種であり、固定長の平文(暗号化されていないテキスト)のブロックを、同じ長さの暗号文(暗号化されたテキスト)のブロックに変換します。この変換は、ランダムに生成されたセッション・キーの値に基づいて行われます。固定長は、ブロック・サイズと呼ばれます。
公開鍵によるセキュリティでは、MD5、SHA-1 (Secure Hash Algorithm 1)など、基盤となるプラグインでサポートされるすべてのメッセージ・ダイジェスト・アルゴリズムがサポートされます。MD5とSHA-1は、どちらも有名な一方向のハッシュ・アルゴリズムです。一方向のハッシュ・アルゴリズムでは、メッセージが「メッセージ・ダイジェスト」または「ハッシュ値」と呼ばれる固定長の数値文字列に変換されます。
MD5は高速処理可能な128ビット・ハッシュで、32ビット・マシンで使用することを想定しています。SHA-1は、160ビットのハッシュ値を生成する、セキュリティ・レベルの高いアルゴリズムですが、処理速度はMD5よりやや遅くなります。
メッセージ・ベースのデジタル署名は、メッセージの送信者のIDを証明し、その内容を特定のメッセージ・バッファとバインドすることにより、ATMIのセキュリティを強化します。企業間または企業と一般ユーザーの間で、インターネットを介してデータを送受信するATMIアプリケーションでは、送信側と受信側の両方で認証を行い、送信妨害のない通信を実現することが重要です。これらの条件は、セキュリティ保護されていない社内ネットワークを使用してATMIアプリケーションを導入する場合にも特に重要です。
メッセージ・ベースのデジタル署名では、エンド・ツー・エンドで内容がセキュリティ保護されます。つまり、メッセージ・バッファは、送信プロセスで発信され、受信プロセスで受け取られるまで保護されます。送信中には、一時的なメッセージ・キュー、ディスク・ベース・キュー、システム・プロセスなどの中継ポイントでも保護され、サーバー間のネットワーク・リンクで転送される間も保護されます。
図1-8は、エンド・ツー・エンド型のメッセージ・ベースのデジタル署名のしくみを示しています。
メッセージ・ベースのデジタル署名では、メッセージのメッセージ・ダイジェストを計算し、次に送信者の秘密鍵でメッセージ・ダイジェストを暗号化して、デジタル署名を生成します。受信者は、暗号化されたメッセージ・ダイジェストを署名者の公開鍵を使って復号化し、復号化したメッセージ・ダイジェストと、別途計算したメッセージ・ダイジェストを比較することによって、署名を検証します。署名者の公開鍵は、署名者の情報に含まれているデジタル証明書から参照するか、または、公開鍵の証明をユニークに識別する、発行者識別名および発行者固有のシリアル番号を参照して取得します。
デジタル証明書は、インターネットなどのネットワーク経由で、個人およびリソースを識別するために使用される電子ファイルです。デジタル証明書は、信頼性のある第三者機関である「認証局」によって認定された個人またはリソースの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は比較的新しい技術であるため、定義はあいまいです。たとえば、単に、公開鍵証明書に基づいた、信頼性を示す階層構造を指す場合があります。また、別のコンテキストでは、エンド・ユーザー用アプリケーションのデジタル署名および暗号化サービスを意味する場合もあります。
公開鍵インフラストラクチャを規定する単一の標準はありませんが、標準の策定を進める動きはあります。現時点では、標準が策定されるかどうか、または様々な相互運用レベルのPKIが複数誕生するかどうかは不明です。この意味で、PKIテクノロジの現状は、インターネットによる広範囲の接続が可能になるまでの、1980年代のLANおよびWANのテクノロジに似ているといえます。
図1-9に、PKI処理の流れを示します。
OracleがPKIベンダーとなる予定はありません。Oracleの公開鍵のプラグイン・インタフェースにより、Oracle Tuxedoのユーザーは、PKIソフトウェアのベンダーを自由に選択し、PKIのセキュリティ・ソリューションを使用できます。
メッセージ・ベースの暗号化では、データが秘密に扱われます。これは、企業間または企業と一般ユーザーの間で、インターネットを介してデータを送受信するATMIアプリケーションでは重要です。データの秘密性は、セキュリティ保護されていない社内ネットワークを使用してATMIアプリケーションを導入する場合にも特に重要です。
メッセージ・ベースの暗号化では、メッセージが意味のわからない状態に変換され、内容を変更しようとしてもできないため、メッセージの整合性が保たれます。
メッセージ・ベースの暗号化では、エンド・ツー・エンドで内容がセキュリティ保護されます。つまり、メッセージ・バッファは、送信プロセスで発信され、受信プロセスで受け取られるまで保護されます。送信中には、一時的なメッセージ・キュー、ディスク・ベース・キュー、システム・プロセスなどの中継ポイントでも保護され、サーバー間のネットワーク・リンクで転送される間も保護されます。
図1-10は、エンド・ツー・エンド型のメッセージ・ベースの暗号化のしくみを示しています。
メッセージは、対称鍵アルゴリズムとセッション・キーによって暗号化されます。次に、セッション・キーが受信者の公開鍵によって暗号化されます。さらに、受信者は、受信者の秘密鍵を使用して、暗号化されたセッション・キーを復号化します。最後に、受信者は、セッション・キーを使用して暗号化されたメッセージを復号化し、メッセージ内容を取得します。
| 注: | この図では、(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つのセキュリティ・レベルは、次のとおりです。
最も低いセキュリティ・レベルでは、認証は行われません。最も高いセキュリティ・レベルでは、アクセス制御リストの機能により、サービスを実行し、イベントをポストし、アプリケーション・キューのメッセージをキューに登録(または登録解除)するユーザーが決定されます。表1-9は、セキュリティ・レベルを簡単にまとめたものです。
| 注: | クライアントという用語はクライアント・プロセスと同義であり、実行中のクライアント・プログラムの特定のインスタンスを意味します。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で記述されている場合)。表1-10では、ユーザー名とクライアント名、および、TPINITバッファまたはTPINFDEF-RECレコード内のその他のセキュリティ関連フィールドを説明します。
認証されたセキュリティ・レベル(USER_AUTH、ACL、またはMANDATORY_ACL)では、ユーザー名、クライアント名、およびユーザー固有のデータは、Oracle Tuxedoシステムで変換されることなくAUTHSVRに転送されます。これらの情報が変換されるとすれば、ワークステーション・クライアントからネットワーク経由で送信されるときに暗号化が行われる場合のみです。
クライアントがATMIアプリケーションに参加するたびに、Oracle Tuxedoシステムはクライアントに32ビットのアプリケーション・キーを割り当てます。クライアントは、アプリケーションとの関連付けを解除し、別のユーザーとしてATMIアプリケーションに参加しないかぎり、このアプリケーション・キーをリセットできません。
割り当てられたアプリケーション・キーは、クライアントのセキュリティ資格証明です。クライアントは、TPSVCINFO構造体の一部として、すべてのサービス呼出しにappkeyフィールドを指定します。TPSVCINFOの詳細は、『Oracle Tuxedo ATMI C言語関数リファレンス』のtpservice(3c)を参照してください。
表1-11は、様々なセキュリティ・レベルとクライアントに割り当てられるアプリケーション・キーを示しています。アプリケーション・キーの割当ては、最後の項目を除き、すべてハードコーディングされます。
管理者(tmadmin(1)など)が起動する、ATMIのネイティブATMIクライアントからのメッセージ
|
||
さらに、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変数に定義された最初のパス名です。図1-11は、これらのファイルと、各リストを制御するための管理コマンドを示しています。
| 注: | 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アプリケーションに参加しようとするユーザーを認証します。
デフォルトのXAUTHSVRが実装されて拡張可能なセキュリティ管理が有効になっている場合、ユーザー、グループおよびACL定義は、プレーン・テキストではなくLDAPリポジトリに格納されます。これらの情報は、LDAPスキーマに対応する必要があります。LDAPスキーマの詳細は、「セキュリティの管理」の拡張セキュリティの有効化方法に関する項を参照してください。
XAUTHSVRサーバーは、LDAPリポジトリのユーザー、グループおよび権限の情報を使用して、ATMIアプリケーションへの参加やTuxedoリソースへのアクセスを希望するユーザーを認証します。
ACLおよびMANDATORY_ACLのセキュリティ・レベルは、Oracle TuxedoシステムのATMI環境でのデフォルトの認可実装です。
セキュリティ・レベルがACLの場合、対象アプリケーションのエンティティに関連するエントリがtpaclファイルまたはLDAP Orcljaznpermissionクラスになくても、クライアントはそのエンティティにアクセスできます。管理者は、このセキュリティ・レベルを使用して、セキュリティを強化したいリソースに対してのみアクセス権を構成できます。つまり、すべてのユーザーにアクセスを許可するサービス、イベント、およびアプリケーション・キューについて、tpaclファイルにエントリを追加する必要はありません。
セキュリティ・レベルがMANDATORY_ACLの場合、対象アプリケーションのエンティティに関連するエントリがtpaclファイルまたはLDAP Orcljaznpermissionクラスにないと、クライアントはそのエンティティにアクセスできません。したがって、このレベルは「必須」と呼ばれます。クライアントがアクセスを必要とするアプリケーション・エンティティごとに、tpaclファイルまたはLDAP Orcljaznpermissionクラス内にエントリが必要です。
ACLおよびMANDATORY_ACLのセキュリティ・レベルで、クライアントが、tpaclファイルまたはLDAP Orcljaznpermissionクラスにエントリがあるエンティティに対してアクセスしようとする場合、クライアントに関連するユーザーは、そのエンティティへのアクセスを許可されたグループのメンバーでなければなりません。そうでない場合、アクセスは拒否されます。
ATMIアプリケーションによっては、システム・レベルとアプリケーション・レベルの両方の認可を使用することが必要な場合もあります。tpaclファイルのエントリを使用すると、サービスに対するアクセスを許可するユーザーを制限できます。また、アプリケーションのロジックを使用して、データ依存型のアクセスを制御することもできます。たとえば、100万ドル以上のトランザクションを処理するユーザーを指定することができます。
先頭にピリオド(.)が付く管理サービス、イベント、およびアプリケーション・キューは、ACLによるパーミッションのチェック対象にはなりません。たとえば、.SysMachineBroadcast、.SysNetworkConfig、および.SysServerCleaningなどの管理イベントには、どのクライアントもサブスクライブできます。さらに、アプリケーション管理者、アプリケーション・オペレータ、およびアプリケーション管理者またはオペレータの権限で実行中のプロセスやサービス・リクエストは、ACLによるパーミッションのチェックの対象にはなりません。
ATMIアプリケーションをOracle Tuxedoリリース7.1より前(6.5以前)のOracle Tuxedoソフトウェアと相互運用させる場合、アプリケーションの開発者および管理者は、いくつかのセキュリティに関する問題を認識しておく必要があります。
ここで定義する相互運用性とは、現在のリリースのOracle Tuxedoソフトウェアが、以前のリリースのOracle Tuxedoソフトウェアとネットワーク経由で通信する機能のことです。具体的には、ドメイン間の相互運用性とiドメイン内の相互運用性があり、それぞれ次のことを意味します。
1つのATMIアプリケーションでOracle Tuxedoリリース7.1以降のソフトウェアを実行し、別のATMIアプリケーションでOracle Tuxedoのリリース7.1より前のソフトウェアを実行します。「ドメイン間の相互運用性」を参照してください。
複数マシンATMIアプリケーションの1つのマシンで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つだけ例外があります。『CORBAアプリケーションにおけるセキュリティ』で説明されているCORBA関連のSSL機能は、Tuxedo 8.0との相互運用および以前のWLE製品との相互運用に使用できます。 |
表1-12に示されている公開鍵によるセキュリティに関する相互運用性の規則は、Oracle Tuxedo7.1以上を実行するマシンと、Oracle Tuxedo 7.1より前のバージョンを実行するマシンが相互運用する場合に適用されます。規則の内容を明確にするため、各規則では、Oracle Tuxedo 7.1より前のバージョンを実行するワークステーション・クライアントの例を示しています。
ドメイン間の相互運用性の場合、リリース7.1以上のドメイン・ゲートウェイ(GWTDOMAIN)プロセスには、公開鍵によるセキュリティの相互運用性の規則が適用されます。
ドメイン内の相互運用性の場合、リリース7.1以上のネイティブ・クライアント、ワークステーション・ハンドラ(WSH)、またはローカル・ブリッジ・プロセスと通信するサーバー・プロセスには、図1-14のような、公開鍵によるセキュリティの相互運用性の規則が適用されます。ブリッジ・プロセスは、パイプ役を果たすだけであり、メッセージ・バッファの内容の復号化やデジタル署名の検証は行いません。
| 注: | 一般に、リリース7.1以上のWSHはデジタル署名を検証しません。しかし、リリース7.1より前のOracle Tuxedoソフトウェアを実行しているプロセスにデジタル署名付きのメッセージ・バッファを転送すると、WSHは、デジタル署名を検証してから削除します。 |
Oracle Tuxedoリリース7.1以上のソフトウェアを実行するATMIアプリケーションでは、デフォルトまたはカスタマイズした認証、認可、監査、および公開鍵セキュリティを自由に組み合せることができます。さらに、これらの4つのセキュリティ機能の任意の組合せは、リンク・レベルの暗号化とも互換性があります。
認可セキュリティ・トークンに少なくとも(1)認証されたユーザー名またはプリンシパル名、および(2)アプリケーション・キーの値(「アプリケーション・キー」で定義)が必要であることがアプリケーション開発者側で認識されていれば、デフォルトの認証とカスタマイズした認可、またはカスタマイズした認証とデフォルトの認可を組み合せて使用できます。
認可に関する一部の決定は、認可トークンに格納されているユーザーIDに基づいて行われます。認可トークンは、認証プラグインによって生成されるため、認証プラグインと認可プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。詳細は、「認証」および「認可」を参照してください。
監査セキュリティ・トークンに少なくとも(1)認証されたユーザー名またはプリンシパル名、および(2)アプリケーション・キーの値(「アプリケーション・キー」で定義)が必要であることがアプリケーション開発者側で認識されていれば、デフォルトの認証とカスタマイズした監査、またはカスタマイズした認証とデフォルトの監査を組み合せて使用できます。
監査に関する一部の決定は、監査トークンに格納されているユーザーIDに基づいて行われます。監査トークンは、認証プラグインによって生成されるため、認証プラグインと監査プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。詳細は、「認証」および「監査」を参照してください。
公開鍵によるセキュリティは、Oracle Tuxedoリリース7.1以上のソフトウェアでサポートされる、圧縮機能以外のすべての機能やプロセスと互換性があります。暗号化されたメッセージ・バッファは、圧縮機能を使用しても圧縮できません。ただし、公開鍵によるソフトウェアでは、メッセージ・バッファを暗号化する前に内容が圧縮されるため、ある程度サイズを節約できます。
この項では、公開鍵によるセキュリティと、次のATMI機能またはプロセスとの互換性および相互運用性について説明します。
GWTDOMAIN)データ依存型ルーティング機能の中心となるのは、プロセスが、受信したメッセージ・バッファの内容を調べることです。受信したメッセージ・バッファが暗号化されている場合、データ依存型ルーティング用に構成されたプロセスでは、受信者の秘密鍵を開き、公開鍵ソフトウェアがそのキーを使用してメッセージ・バッファを復号化できるようにしておく必要があります。データ依存型ルーティングでは、公開鍵ソフトウェアは、デジタル署名を検証しません。
復号化キーを使用できない場合、ルーティング操作は失敗します。システムからuserlog(3c)エラー・メッセージが返され、操作が失敗したことがレポートされます。
復号化キーを使用できる場合、プロセスは、暗号化されたメッセージ・バッファを復号化したコピーに基づいて、ルーティングに関する決定を行います。次の手順で実行されます。
その後、システムは、ルーティングに関する決定に基づいて、元の暗号化されたメッセージ・バッファを送信します。
公開鍵と秘密鍵は、ハンドルを介して表現および操作されます。ハンドルには、それに関連付けられたデータがあります。公開鍵のアプリケーション・プログラミング・インタフェース(API: Application Programming Interface)では、ハンドルのデータを使用することにより、ハンドルで指定される項目の検索やアクセスを行います。プロセスは、デジタル署名の生成、メッセージの暗号化、およびメッセージの復号化のために、キー・ハンドルを開きます。
キー・ハンドルはプロセスのリソースです。特定のスレッドやコンテキストにバインドされることはありません。キーを開くために必要な通信はいずれも、スレッドで現在アクティブなコンテキストの内部で実行されます。その後は、コンテキストが同じ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)プロセスには、デジタル署名および暗号化エンベロープがあります。さらに、これらのドメイン・ゲートウェイ・プロセスは、デジタル署名を検証し、デジタル署名と暗号化に関する管理システム・ポリシーを適用します。
図1-15は、ドメイン・ゲートウェイ・プロセスが、ローカルおよびリモートのATMIアプリケーションと対話する様子を示しています。この図に続く表では、デジタル署名が添付された暗号化メッセージ・バッファが、リリース7.1以上のドメイン・ゲートウェイ・プロセスでどのように扱われるかを示しています。
|
データ依存型ルーティング機能が適用され、ドメイン・ゲートウェイ・プロセスが適切な復号化キーを持たない場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、「データ依存型ルーティングとの互換性および相互運用性」を参照してください。)
|
||
ドメイン・ゲートウェイ・プロセスが、暗号化を必要とするグループ、ドメイン、またはマシンの内部で実行されている場合、ゲートウェイ・プロセスはメッセージを拒否します。ドメイン・ゲートウェイによって通知されたサービスが暗号化を必要とする場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、「暗号化ポリシーの設定」を参照してください。)
|
||
ドメイン・ゲートウェイ・プロセスが、デジタル署名を必要とするグループ、ドメイン、またはマシンの内部で実行されている場合、ゲートウェイ・プロセスはメッセージを拒否します。ドメイン・ゲートウェイによって通知されたサービスがデジタル署名を必要とする場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、「デジタル署名ポリシーの設定」を参照してください。)
|
||
|
データ依存型ルーティング機能が適用され、ドメイン・ゲートウェイ・プロセスが適切な復号化キーを持たない場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、「データ依存型ルーティングとの互換性および相互運用性」を参照してください。)
暗号化されたメッセージが、Oracle Tuxedoリリース7.1より前の(6.5以前) Oracle Tuxedoソフトウェアを実行するプロセスに送信される場合、ドメイン・ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、「7.1より前のリリースのソフトウェアとの相互運用性」および「公開鍵によるセキュリティ機能の相互運用性」を参照してください。)
|
||
ドメイン・ゲートウェイ・プロセスが、暗号化を必要とするグループ、ドメイン、またはマシンの内部で実行されている場合、ゲートウェイ・プロセスはメッセージを拒否します。ドメイン・ゲートウェイによって通知されたサービスが暗号化を必要とする場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、「暗号化ポリシーの設定」を参照してください。)
|
||
|
メッセージが、Oracle Tuxedoリリース7.1より前のOracle Tuxedoソフトウェアを実行するプロセスに送信され、リリース7.1より前のOracle Tuxedoソフトウェアとの相互運用性があると見なされている場合、ドメイン・ゲートウェイ・プロセスは、デジタル署名の検証と削除を行ってから、ネットワーク経由でメッセージを転送します。(詳細は、「7.1より前のリリースのソフトウェアとの相互運用性」および「公開鍵によるセキュリティ機能の相互運用性」を参照してください。)
|
||
ドメイン・ゲートウェイ・プロセスが、デジタル署名を必要とするグループ、ドメイン、またはマシンの内部で実行されている場合、ゲートウェイ・プロセスはメッセージを拒否します。ドメイン・ゲートウェイによって通知されたサービスがデジタル署名を必要とする場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、「デジタル署名ポリシーの設定」を参照してください。)
|
リリース7.1以降のATMIアプリケーションと、別のベンダーのゲートウェイ・プロセスを接続するドメイン・ゲートウェイ(GWTDOMAIN)のプロセスは、アウトバウンド・メッセージ・バッファに対して次のように動作します。
さらに、ドメイン・ゲートウェイ・プロセスは、ATMIアプリケーションの暗号化とデジタル署名に関する管理システムのポリシーを適用します。たとえば、ATMIアプリケーションのドメイン・レベルで、暗号化またはデジタル署名、あるいはその両方が必要な場合、ローカル・ドメイン・ゲートウェイのプロセスは、ほかのベンダーのゲートウェイ・プロセスから受信するすべてのメッセージを拒否します。
分散型のマルチ・ドメインTuxedoアプリケーションがパブリック・ネットワークや安全性の低い環境に拡張された場合、Tuxedoドメイン・ゲートウェイを潜在的脅威から確実に防御する必要があります。これらの環境には、安全性に問題のあるネットワークや、サービス拒否(DoS)攻撃などの悪意のある攻撃を開始または拡大させる信頼されていない参加者が含まれます。
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”
<LIBGW_CAT 5359> "警告: <ldom-name>に対する接続数は制限<%d>を超えています。<%d>秒間の一時停止を開始します。"
<LIBGW_CAT 5360> "情報: 接続リクエストの受入れを再開します。"
| 注: | 前述の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になります。
各表の最初の列には、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> "エラー: MACが必要ですが、リモート・ドメイン<rdom-name>はこの機能をサポートしていません"
<LIBGWT 1682> "エラー: MACが必要ですが、LLEもSECURITYも(<ldom-name>、<rdom-name>)の接続でサポートされていません"
<LIBGWT 1683> "エラー: リモート・ドメイン<rdom-name>でMACが必要ですが、ローカル・ドメイン<ldom-name>でサポートされていません"
<LIBGWT 1684> "エラー: MACはMACLEVELに関する合意(<ldom_name>は<%d>..<%d>、<rdom-name>は<%d>..<%d>)に失敗しました"
| 注: | このメッセージの"%d"プレースホルダーに対応するパラメータは、m1、Max1、m2、Max2です。 |
パスワード・ペア保護機能はインストール後に自動的にデプロイされるため、構成作業は必要ありません。この機能により、GWTDOMAINセキュリティ・メカニズムが強化され、また、同じリモート・パスワードによるデュアル・パスワード・ペアが使用できなかった以前のセキュリティの制限もなくなります。
パスワード・ペア保護は、ローカル・ドメインとリモート・ドメインの両方でサポートされている場合にのみ機能します。ローカル・ドメインとリモート・ドメインの両方でサポートされていない場合は、既存の動作が変更されることはありません。
  
|