次の項では、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環境で使用できるセキュリティ機能を説明します。
|
|
|
|
|
|
|
ファイル、ディレクトリ、およびシステム・リソースへのアクセスを制御します。 |
|
|
|
|
ユーザーまたはシステム・プロセスに対して指定されているIDを証明し、ID情報を安全に記録およびトランスポートし、必要に応じてID情報を利用可能にします。 |
|
デフォルトの認証プラグインには、 認証なし、 アプリケーション・パスワード、 ユーザー・レベルの認証という3つのレベルのセキュリティが用意されています。このデフォルトのプラグインは、Oracle Tuxedoシステムで最初に実現された、Oracle Tuxedoの従来の認証の実装と同じように機能します。
|
|
|
IDおよびその他の情報に基づいて、リソースへのアクセスを制御します。 |
|
デフォルトの認可プラグインには、 オプションのアクセス制御リストと 必須のアクセス制御リストという2つのレベルのセキュリティが用意されています。このデフォルトのプラグインは、Oracle Tuxedoシステムで最初に実現された、Oracle Tuxedoの従来の認可の実装と同じように機能します。
|
|
|
操作リクエストとその結果に関する情報を安全に収集、格納、および配布します。 |
|
デフォルトの監査機能は、Oracle Tuxedoイベント・ブローカおよびユーザー・ログ( ULOG)機能によって実装されます。 |
|
|
対称鍵による暗号化を使用して、ATMIアプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージの秘密性を保護します。
|
|
|
|
|
業界標準であるTLS プロトコルを使用して、ATMIアプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージの秘密性を保護します。 (TLSは、SSLプロトコルの後継となる標準です。) |
|
|
|
|
公開鍵( 非対称鍵)による暗号化を使用して、ATMIアプリケーションのクライアントとサーバー間でエンド・ツー・エンドのデジタル署名とデータの秘密性を実現します。この機能は、PKCS-7標準に準拠しています。 |
|
デフォルトの公開鍵セキュリティでは、次のアルゴリズムがサポートされます。 |
ファイルに対するパーミッション設定などのセキュリティ機能を備えた、ホスト側のオペレーティング・システムでは、オペレーティング・システム・レベルのセキュリティが、第一レベルのセキュリティ機能になります。アプリケーション管理者は、ファイルに対してパーミッションを設定することにより、特定のユーザーまたはユーザー・グループに対して、アクセス権限を付与したり、拒否することができます。
ほとんどの場合、ATMIアプリケーションは、アプリケーション管理者によって管理されます。アプリケーション管理者は、アプリケーションを構成し、起動し、実行中のアプリケーションを動的にモニターし、必要に応じて変更します。ATMIアプリケーションは、管理者が起動し、実行するため、サーバー・プログラムは、管理者のパーミッションで実行されます。これで、サーバー・プログラムは安全であり、「信頼性がある」と見なされます。この方法は、基盤となるオペレーティング・システムのログイン・メカニズムとパーミッション設定(ファイル、ディレクトリ、およびシステム・リソースに対する読取り権と書込み権の設定)に基づいています。
クライアント・プログラムは、自分のパーミッションを持つユーザーによって直接実行されます。さらに、ネイティブ・クライアント(サーバー・プログラムと同じマシンで実行中のクライアント)を実行するユーザーは、
UBBCONFIG構成ファイルにアクセスしたり、掲示板(ATMIアプリケーションを制御するパラメータおよびアプリケーションの統計情報を格納するために確保されている共有メモリーの一部)などのプロセス間通信(IPC)のメカニズムにアクセスできます。
より高度なセキュリティ機能を備えたプラットフォーム上のATMIアプリケーションでは、ファイルおよびIPCメカニズムに対するアクセスをアプリケーション管理者のみに限定し、管理者のパーミッション(UNIXホスト・マシンの
setuidコマンドまたは別のプラットフォームでの同等のコマンド)を使用して「信頼性のある」クライアント・プログラムを実行すると、より安全です。最も高いレベルのオペレーティング・システムのセキュリティを実現するには、ワークステーション・クライアントだけがアプリケーションにアクセスできるようにし、アプリケーション・サーバーおよび管理プログラムを実行するマシンではクライアント・プログラムを実行できないようにします。
|
•
|
『Oracle Tuxedoアプリケーションの設定』の 構成ファイルに関する項および 構成ファイルの作成に関する項
|
認証機能とは、通信するプロセスどうしがお互いの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つの情報が設定されています。
|
•
|
アプリケーション・キー - リクエスト・メッセージを開始するクライアントを一意に識別する32ビット値。詳細は、 「アプリケーション・キー」を参照してください。
|
また、デフォルトの認証を使用する場合、監査トークンにも、プリンシパル名とアプリケーション・キーが設定されます。
セッション・トークンと同様に、認可トークンと監査トークンもオペークであり、内容は、セキュリティ・プロバイダごとに異なります。認可トークンを使用すると、認可(パーミッション)をチェックすることができます。監査トークンを使用すると、監査情報を記録することができます。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は、認可のファンアウト・プラグインで作成されるコンポジット・レスポンスを示しています。デフォルトの認可の場合、コンポジット・レスポンスは、デフォルトの認可プラグインによってのみ決まります。
|
|
|
すべて permit、または permitと abstainの組合せの場合 |
|
|
|
|
|
|
deny ATMIアプリケーションの UBBCONFIGファイルの SECURITYパラメータが MANDATORY_ACLに設定されている場合
permit ATMIアプリケーションの UBBCONFIGファイルの SECURITYパラメータが設定されていないか、または、 MANDATORY_ACL以外の値に設定されている場合
|
カスタマイズした認可として、銀行アプリケーションを例に取ります。この例では、ユーザーを
Customerグループのメンバーとし、次の条件が適用されるとします。
|
•
|
デフォルトの認可プラグインでは、 Customerグループのユーザーであれば、誰でも特定の口座から引出しを行えます。 |
|
•
|
カスタマイズした認可プラグインでは、 Customerグループのユーザーであれば、誰でも特定の口座から引出しを行えます。ただし、引出しを行えるのは、月曜日から金曜日の午前9時から午後5時までです。 |
|
•
|
カスタマイズした2つ目の認可プラグインでは、 Customerグループのユーザーであれば、誰でも特定の口座から引出しを行えます。ただし、引き出せるのは、$10,000未満の金額です。 |
Customerグループのユーザーは、月曜日の午前10時に$500.00を引き出すことはできます。ただし、同じユーザーが、土曜日の午前中に同じ操作を行おうとしてもできません。
このほかにも、様々な状況が考えられます。いろいろな状況を想定し、ビジネス上のニーズに合った最適な状況を定義してください。
認可に関する一部の決定は、
認可トークンに格納されているユーザーIDに基づいて行われます。認可トークンは、認証プラグインによって生成されるため、認証プラグインと認可プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。
Oracle Tuxedoシステムのプロセスまたはサーバー(/Qサーバーの
TMQUEUE(5)またはイベント・ブローカ・サーバーの
TMUSREVT(5)など)は、クライアントからのリクエストを受け取ると認可プラグインを呼び出します。これに対し、認可プラグインは、操作前のチェックを行い、操作を許可するかどうかを返します。
|
•
|
操作が許可された場合、システムはクライアント・リクエストを実行します。 |
|
•
|
操作が許可されない場合、システムはクライアント・リクエストを実行しません。 |
クライアント操作が許可されると、Oracle Tuxedoシステムのプロセスまたはサーバーは、クライアント操作が完了した後で認可プラグインを呼び出すことができます。これに対し、認可プラグインは、操作後のチェックを行い、操作の結果を許可するかどうかを返します。
|
•
|
許可される場合、システムは操作の結果を受け付けます。 |
|
•
|
許可されない場合、システムは、操作の結果を変更するか、または操作をロールバックし(元に戻し)ます。 |
これらの呼出しは、アプリケーション・レベルの呼出しではなく、システム・レベルの呼出しです。ATMIアプリケーションは、認可プラグインを呼び出せません。
Oracle Tuxedoシステムに組み込まれているデフォルトの認可プラグインを使用する場合と、カスタマイズした認可プラグインを1つ以上使用する場合では、認可のプロセスが多少異なります。デフォルトのプラグインでは、操作後のチェックをサポートしていません。したがって、デフォルトの認可プラグインが、操作後のチェックを行うリクエストを受け取っても、リクエストはただちに返され、何も実行されません。
カスタマイズしたプラグインでは、操作前と操作後の両方のチェックをサポートしています。
クライアントから操作前のチェックの実行がリクエストされ、それに対してATMIのプロセスによってデフォルトの認可が呼び出されると、認可プラグインは、次のタスクを実行します。
|
1.
|
認証プラグインを呼び出して、クライアントの認可トークンから情報を取得します。 |
認可トークンは、認証プラグインによって作成されるため、認可プラグインにはトークンの内容が記録されていません。ただし、認可プロセスではこの情報が必要です。
認可プラグインは、クライアントの認可トークン、アクセス制御リスト(ACL: Access Control List)、およびATMIアプリケーションのセキュリティ・レベル(ACLの構成(オプションまたは必須))を調べて、操作を許可するかどうかを決めます。
認可のファンアウト・プラグインは、デフォルトの認可プラグインの決定(
permitまたは
deny)を受け取ると、その決定に従って動作します。
|
•
|
クライアント操作が許可された場合、ファンアウト・プラグインは呼出し側のプロセスに permitを返します。システムはクライアント・リクエストを実行します。 |
|
•
|
クライアント操作が拒否された場合、ファンアウト・プラグインは呼出し側のプロセスに denyを返します。システムはクライアント・リクエストを実行しません。 |
カスタマイズした1つ以上の認可プラグインを使用するユーザーは、Oracle Tuxedo製品のATMI環境で提供される別の機能を利用できます。つまり、操作の実行後にさらにチェックを行うことができます。
クライアントから操作前のチェックの実行がリクエストされ、それに対してATMIのプロセスによってカスタマイズした認可が呼び出されると、認可プラグインは、次のタスクを実行します。
|
1.
|
認証プラグインを呼び出して、クライアントの認可トークンから情報を取得します。 |
認可プラグインは、操作、クライアントの認可トークン、および関連するデータを調べて、操作を許可するかどうかを決めます。関連するデータには、ユーザー・データおよびATMIアプリケーションのセキュリティ・レベルが含まれます。
認可プラグインは、認可の要件に合うよう、必要に応じてユーザー・データを変更してから操作を実行します。
認可のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(
permit、
deny、または
abstain)をチェックして、最終的な決定を行います。
|
•
|
クライアント操作が許可された場合、ファンアウト・プラグインは呼出し側のプロセスに permitを返します。システムはクライアント・リクエストを実行します。 |
|
•
|
操作が拒否された場合、ファンアウト・プラグインは呼出し側のプロセスに denyを返します。システムはクライアント・リクエストを実行しません。 |
クライアント操作が許可されると、ATMIのプロセスは、クライアント操作が完了した後でカスタマイズした認可を呼び出すことができます。その場合、認可プラグインは次のタスクを実行します。
|
1.
|
認証プラグインを呼び出して、クライアントの認可トークンから情報を取得します。 |
認可プラグインは、操作、クライアントの認可トークン、および関連するデータを調べて、操作の結果を許可するかどうかを決めます。関連するデータには、ユーザー・データおよびATMIアプリケーションのセキュリティ・レベルが含まれます。
認可のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(
permit、
deny、または
abstain)をチェックして、最終的な決定を行います。
|
•
|
ファンアウト・プラグインは、操作の結果が受け入れ可能と判断した場合、呼出し元プロセスに permitを返します。システムは操作の結果を受け付けます。 |
|
•
|
操作が拒否された場合、ファンアウト・プラグインは呼出し側のプロセスに denyを返します。システムは、操作の結果を変更するか、または操作をロールバックし(元に戻し)ます。 |
操作後のチェック機能は、ラベル付けされた文書を扱うセキュリティ・モデルで便利です。たとえば、機密文書へのアクセスを許可されたユーザーが、最高機密文書を取り出す操作を実行したとします(通常、文書を識別するラベルの内容は、その文書が取り出されるまでわかりません)。
この場合、操作後のチェックにより、操作の拒否または出力データの変更(機密情報の削除)を効率的に行うことができます。
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.
|
認証プラグインを呼び出して、クライアントの監査トークンから情報を取得します。 |
監査トークンは、認証プラグインによって作成されるため、監査プラグインにはトークンの内容が記録されていません。ただし、監査プロセスではこの情報が必要です。
監査プラグインは、クライアントの監査トークン、および操作後の監査リクエストで配信されたセキュリティ違反を調べます。
|
3.
|
操作後の監査が成功したかどうかの結果を発行します。 |
監査のファンアウト・プラグインは、デフォルトの監査プラグインからの決定(
successまたは
failure)を受け取ると、その決定に従って動作します。
|
•
|
successは、操作後の監査が成功したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスに successを返し、セキュリティ違反を記録します。
|
|
•
|
failureは、操作後の監査が失敗したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスに failureを返します。
|
カスタマイズした1つ以上の監査プラグインを使用するユーザーは、Oracle Tuxedo製品のATMI環境で提供されるの別の機能を利用できます。つまり、操作の実行前に監査を行うことができます。
クライアントから操作前の監査の実行がリクエストされ、それに対してATMIのプロセスによってカスタマイズした監査が呼び出されると、監査プラグインは、次のタスクを実行します。
|
1.
|
認証プラグインを呼び出して、クライアントの監査トークンから情報を取得します。 |
監査プラグインはクライアントの監査トークンを調べて、そのデータが後で操作後の監査に必要となる場合は、ユーザー・データを格納することができます。
|
3.
|
操作前の監査が成功したかどうかの結果を発行します。 |
監査のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(
successまたは
failure)をチェックして、最終的な決定を行います。
|
•
|
複合レスポンスが successの場合は、操作前の監査が成功したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスに successを返し、クライアントによる操作の試行を記録します。 |
|
•
|
複合レスポンスが failureの場合は、操作前の監査が失敗したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスに failureを返します。 |
クライアント操作が実行されると、ATMIプロセスは、カスタマイズした監査を呼び出して操作後の監査を実行できます。その場合、監査プラグインは次のタスクを実行します。
|
1.
|
認証プラグインを呼び出して、クライアントの監査トークンから情報を取得します。 |
監査プラグインは、クライアントの監査トークン、操作後の監査リクエストで配信された完了ステータス、および操作前の監査時に格納されたデータを調べます。
|
3.
|
操作後の監査が成功したかどうかの結果を発行します。 |
監査のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(
successまたは
failure)をチェックして、操作後の監査が成功したか、または失敗したかを決定します。
|
•
|
複合レスポンスが successの場合は、操作後の監査が成功したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスに successを返し、操作が完了したことを示すステータスを記録します。 |
|
•
|
複合レスポンスが failureの場合は、操作後の監査が失敗したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスに failureを返します。 |
操作前と操作後の監査を両方通過し、操作自体が成功した場合、その操作は成功したものとみなされます。操作前と操作後の両方の監査データを収集および格納する企業もありますが、これらのデータは大量のディスク領域を消費する可能性があります。
ATMIアプリケーションで監査機能を実行するには、デフォルトのプラグインを使用するか、または1つ以上のプラグインをカスタマイズします。プラグインを選択するには、すべてのセキュリティ・プラグインを制御するツールである、Oracle Tuxedoレジストリを構成します。
デフォルトの監査プラグインを使用する場合、レジストリを構成する必要はありません。ただし、カスタマイズした認可プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合せてレジストリを構成する必要があります。レジストリの詳細
を参照してください。
リンク・レベルの暗号化(LLE: Link-Level Encryption)は、ATMIアプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージの秘密性を保護します。また、対称鍵による暗号化技術であるRC4を使用します。RC4では、暗号化と復号化の際に同じ鍵を使用します。
LLEを使用する場合、Oracle Tuxedoシステムは、データを暗号化してからネットワーク・リンク上に送信し、データがネットワーク・リンクを離れると復号化します。システムは、データが通過するすべてのリンクで、この暗号化/復号化プロセスを繰り返します。したがって、LLEはポイント・ツー・ポイント機能と呼ばれます。
LLEは、ATMIアプリケーションの次の種類のリンクで使用できます。
|
•
|
ワークステーション・クライアントからワークステーション・ハンドラ(WSH)へのリンク |
|
•
|
管理ユーティリティ( tmbootまたは tmshutdown)と tlistenとのリンク |
LLEセキュリティには、0ビット(暗号化なし)、56ビット(国際版)、および128ビット(米国およびカナダ版)の3つのレベルがあります。国際版のLLEでは、0ビットと56ビットの暗号化が可能です。米国およびカナダ版のLLEでは、0ビット、56ビット、および128ビットの暗号化が可能です。
LLEの制御パラメータおよび基本となる通信プロトコルは、リンクの種類によって異なります。ただし、次の点では基本的に同じです。
|
•
|
イニシエータ・プロセスが通信セッションを開始します。 |
|
•
|
前述の両方のプロセスでは、リンク・レベルの暗号化機能が認識され、次の2つの構成パラメータが設定されます。 |
最初の構成パラメータは、プロセスが受け入れる暗号化の
最低レベルです。これは、0、56、128のいずれかのキー長で指定します。
2番目の構成パラメータは、プロセスがサポートできる暗号化の
最高レベルです。これも、0、56、128のいずれかのキー長で指定します。
次の説明では、前述の2つのパラメータを(
min,
max)の形式で表記します。たとえば、あるプロセスの値が(56, 128)の場合は、56ビットから128ビットまでの暗号化がサポートされることを示します。
ネットワーク・リンクの両端にある2つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の2段階の手順で確認されます。
|
1.
|
各プロセスで、それぞれの min- max値が確認されます。 |
|
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の旧バージョンと互換性があります。
Oracle Tuxedoリリース6.5との相互運用性
表1-4は、ATMIアプリケーションの2つのプロセスのうち、片方がリリース6.5で動作しており、もう一方がリリース7.1以上で動作しているときの、調整結果のキー・サイズを示しています。上段のヘッダー行は、リリース7.1以上で動作するプロセスの
min-
max値を示しています。左側の列は、リリース6.5で動作するプロセスの
min-
max値を示しています。
表1-4
Oracle Tuxedoリリース6.5と相互運用するときのキー・サイズのネゴシエーション結果
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
現在のOracle Tuxedoインストールが(0, 56)、(0, 128)、(56, 56)、または(56, 128)に構成されている場合、LLEの最大レベルが40ビットに構成されているリリース6.5のATMIアプリケーションと相互運用させようとすると、ネゴシエーションの結果は必ず56への自動アップグレードになります。
このネゴシエーション結果は、2つのサイトでともにリリース6.5が動作しており、LLEの最高レベルが40ビットに構成されている場合の結果と同じです。どちらの場合も、ネゴシエーションを行うと、56に自動的にアップグレードされます。
Oracle Tuxedoリリース6.5より前のバージョンとの相互運用性
表1-5は、ATMIアプリケーションの2つのプロセスのうち、片方がリリース6.5より前のバージョンで動作しており、もう一方がリリース7.1以上で動作しているときの、調整結果のキー・サイズを示しています。上段のヘッダー行は、リリース7.1以上で動作するプロセスの
min-
max値を示しています。左側の列は、リリース6.5より前のバージョンで動作するプロセスの
min-
max値を示しています。
表1-5
Oracle Tuxedoリリース6.5より前のバージョンと相互運用するときのキー・サイズのネゴシエーション結果
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
現在の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アプリケーションの設定』の ネットワークへのATMIアプリケーションの分散に関する項および 分散型のATMIアプリケーション用の構成ファイルの作成に関する項
|
Oracle Tuxedo製品では、業界標準のSSLプロトコルを使用して、クライアント・アプリケーションとサーバー・アプリケーション間で安全な通信を確立します。SSLプロトコルを使用する場合、プリンシパルはデジタル証明書を使用して、自身のIDをピアに対して証明します。
|
注意:
|
実際に使用されているネットワーク・プロトコルは、SSLプロトコルの後継に当たるTLSです。しかしながらこのドキュメントでは、一般的な用法に従い、このプロトコルをSSL暗号化と呼んでいます。 |
LLEと同じく、SSLプロトコルをパスワードによる認証で使用すると、クライアント・アプリケーションとOracle Tuxedoドメイン間の通信の機密性と整合性を保護できます。SSLプロトコルをパスワードによる認証で使用する場合、
tmloadcfコマンドを入力したときに
SEC_PRINCIPAL_NAME パラメータで定義したIIOPリスナー/ハンドラ(IIOP、ワークステーション、またはJOLT)のパスワードの入力を求められます。
SSLは、ATMIアプリケーションの次の種類のリンクで使用できます。
|
•
|
クライアントからサーバー・ハンドラ(IIOP、ワークステーション、またはJOLT)へのリンク |
|
•
|
管理ユーティリティ( tmbootまたは tmshutdown)と tlistenとのリンク |
使用可能なSSL暗号には、256ビット、128ビットおよび56ビット暗号があります。これについてはこの章で後から説明します。
|
1.
|
ターゲット・プロセスは、デジタル証明書を開始元アプリケーションに提示します。 |
|
2.
|
開始元アプリケーションは、信頼性のある認証局のリストとターゲット・プロセスのデジタル証明書を照合します。 |
|
3.
|
開始元アプリケーションがターゲット・プロセスのデジタル証明書を検証すると、アプリケーションとターゲット・プロセス間でSSL接続が確立されます。 |
開始元アプリケーションは、パスワードまたは証明書による認証を使用して、自身をOracle Tuxedoドメインに対して認証します。
SSLプロトコルの実装は柔軟性が高いので、ほとんどの公開鍵インフラストラクチャに対応します。Tuxedoでは、SSLセキュリティ資格証明を格納するために2つの方法が提供されます。
|
•
|
Oracle WalletはTuxedo 12cの新機能です。Oracle Walletは、プロセスのための秘密鍵、証明書チェーン、信頼性のある証明書を1つのPKCS12ファイルに格納します。このファイルは、Oracleツールや他のセキュリティ・ベンダーのツールを使用して作成できます。 |
|
•
|
Tuxedoの以前のリリースで使用されたプラグイン・フレームワークも、セキュリティ資格証明を格納するために使用できます。Oracle Tuxedo製品で使用できるプラグインのデフォルト実装では、デジタル証明書をLDAP対応のディレクトリに格納する必要があります。LDAP対応であれば、どのディレクトリ・サービスでもかまいません。また、Tuxedoアプリケーションで使用するデジタル証明書および秘密鍵の取得先の認証局を選択する必要があります。LDAP対応のディレクトリ・サービスおよび認証局を準備してからでないと、SSLプロトコルをTuxedoアプリケーションで使用できません。 |
Tuxedo12.2.2は、TLS、1.2、1.1および1.0がサポートされていますが、いくつかのTuxedoの以前のリリースでは、TLS1.0のみをサポートしています。SSLサーバーとクライアントの間で安全なネットワーク接続が確立されている場合、使用対象のTLSバージョンがネゴシエーションされます。SSLサーバーとして機能する場合、Tuxedoコンポーネントは常にTLS1.2/1.1/1.0の開始リクエストを受け入れます。SSLクライアントとして機能する場合、Tuxedo12.2.2コンポーネントは次のルールに準拠しています。
|
•
|
WSCには自己適応機能があります。つまり、TLS 1.2を使用してTuxedo 12.2.2リスナーに接続でき、TLS 1.0を使用して古いリリース・リスナーに自動的に接続できます。 |
|
•
|
GWTDOMAIN、COBRAクライアント、GWWSアウトバウンドHTTPSでは、デフォルトでTLS1.2を使用します。Tuxedo 12.1.3 GA以前のリリースに接続する場合、TLSバージョンをTLS 1.0に変更する必要があります。 |
|
•
|
GWTDOMAINがSSLクライアントとSSLサーバーの両方として機能している場合、SSLクライアント側に指定されているTLSバージョンのみが有効になります。 |
|
•
|
Tuxedo 12.2.2マスターマシンが以前のリリースのスレーブマシンにMPモードで接続する場合、tmbootコマンドを実行する前にtlistenをマスターマシンで起動する必要があります。 |
表1-6は、TuxedoコンポーネントがTLSバージョンを処理する方法を示しています。
ネットワーク・リンクの両端にある2つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の2段階の手順で確認されます。
|
1.
|
各プロセスで、それぞれの min- max値が確認されます。 |
|
2.
|
両方のプロセスでサポートされる、キーの最大サイズが算出されます。 |
Tuxedoプロセスでは、次の手順を使用して
MINENCRYTPBITSおよび
MAXENCRYPTBITSを処理します。
|
•
|
構成されている min- max値にデフォルトの min- max値が収まる場合、ローカル・ソフトウェアは、この値をプロセスの min- max値として割り当てます。 |
|
•
|
min-maxのいずれかの値が構成されていない場合、欠落している値のかわりにデフォルト値が使用されます。たとえば、(0, max-value-configured)または(min-value-configured, 128)が使用されます。
|
|
•
|
特定の種類のリンクの構成で、 min- max値が指定されていない場合、ローカル・ソフトウェアは、最小値として0を割り当て、最大値として128を割り当てます。 |
|
•
|
暗号化鍵の最小サイズは112です。 min-max値が40または56と構成されている場合は、デフォルトで112が使用されます。 |
|
•
|
暗号化レベルの構成情報は、リンク・レベルのセキュリティのタイプとは関係なく処理されます。 |
|
•
|
/WSクライアントの場合、デフォルトの MAXENCRYPTBITSは256で、構成されている実際のリンク・レベル・セキュリティに従って調整されます。 |
2つのプロセスの
min-
max値が決まると、キー・サイズの調整が開始します。このネゴシエーション・プロセスを暗号化したり、見えないようにする必要はありません。調整されたキー・サイズは、ネットワーク接続が確立されている間は有効です。
表1-7は、2つのプロセス間で可能な
min-
max値のすべての組合せを調整した結果のキー・サイズを示しています。上段のヘッダー行は、2つのプロセスのうち、片方のプロセスの
min-
max値を示しています。左側の列は、もう一方のプロセスの
min-
max値を示しています。
表1-7
プロセス間のネゴシエーション結果(112,112)から(112,256)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表1-8
プロセス間のネゴシエーション結果(128,128)から(256,256)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2つのTuxedoプロセスの間でSSLを使用するには、両方のプロセスでTuxedo 10.0以降を実行している必要があります(ただし、『CORBAアプリケーションにおけるセキュリティの使用』で説明されているCORBA SSL機能を使用する場合を除きます)。WSLプロセスとJSLプロセスに非SSLポートとSSLポートの両方を指定し、*DM_TDOMAIN内の個別のエントリにSSL接続またはLLE接続を指定できます。この方法により、個別のワークステーション・クライアントおよびTuxedoドメインをTuxedo 10にアップグレードするのに合わせ、ワークステーションやドメイン・アプリケーションを徐々にSSLに移行できます。
|
•
|
MPモード・アプリケーションでは、Tuxedoドメイン内のすべてのマシンをTuxedo 10.0にアップグレードするまでは、BRIDGEプロセスとtlistenプロセスの間でSSLを使用することはできません。 |
|
•
|
0ビットSSL暗号(アプリケーション・データの暗号化を行わない)は、Tuxedo 12.1.1よりも前のリリースで許可されていましたが、Tuxedo 12.1.1以降で使用されるOracle NZセキュリティ・レイヤーでは許可されません。 |
ワークステーション・クライアントが初期化に費やせる時間は制限されています。デフォルトでは、この間隔は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-9の暗号化スイートがサポートされています。
表1-9
ATMIセキュリティ環境でサポートされているSSL暗号スイート
|
|
|
|
TLS_RSA_WITH_AES_256_CBC_SHA
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA
|
|
|
|
|
|
|
|
|
|
|
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
|
|
|
SSL_DH_anon_WITH_DES_CBS_SHA
|
|
|
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_DBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
|
|
|
SSLは、Tuxedoシステムの標準機能として実現されています。アプリケーションがセキュリティ資格証明の格納にOracle Walletを使用せず、LDAPを使用して証明書を取得する場合、管理者はインストール時にそのLDAPサーバーの名前、LDAPポート番号、LDAPフィルタ・ファイルの場所を用意しておく必要があります(デフォルトのLDAPフィルタ・ファイルの場所
$TUXDIR/udataobj/security/bea_ldap_filter.datは、ほとんどのアプリケーションに適しています。)
インストール後にこの情報を変更する必要がある場合は、
epifregedtコマンドを使用できます。
|
•
|
『Oracle Tuxedoアプリケーションの設定』の ネットワークへのATMIアプリケーションの分散に関する項および 分散型のATMIアプリケーション用の構成ファイルの作成に関する項
|
公開鍵によるセキュリティは、エンド・ツー・エンドのデジタル署名およびデータの暗号化を実現する、次の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 (Data Encryption Standard for Cipher Block Chaining) |
DES-CBCは、CBC (Cipher Block Chaining)モードで実行する64ビットのブロック暗号です。56ビット(64ビットの暗号化キーから8パリティ・ビットを引いたもの)のキーを使用し、米国以外の国でも使用できます。
|
•
|
2つの鍵によるTriple-DES (Data Encryption Standard) |
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を特定の公開鍵に安全な方法でバインドします
。公開鍵は重複しないため、公開鍵からオーナーを特定できます。
デジタル証明書は、特定の公開鍵が特定のサブスクライバ(所有者)に属することを検証します。証明書の受信者は、証明書に記載されている公開鍵を使用して、その公開鍵に対応する秘密鍵でデジタル署名が作成されたことを検証します。検証が成功すると、証明書で指定されたサブスクライバが、対応する秘密鍵の所有者であること、および、そのサブスクライバによってデジタル署名が作成されたことを、一連の処理で確認できたことになります。
証明書には、次のような様々な情報が含まれています。
|
•
|
サブスクライバ(所持者、オーナー)の名前、およびサブスクライバをユニークに識別するためのその他のID情報(証明書を使用するWebサーバーのURL、個人の電子メール・アドレスなど) |
|
•
|
証明書の有効期間または存続期間(開始日と終了日を定義) |
最も広く知られている証明書の形式は、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.
|
サブスクライバは、認証局(CA)にデジタル証明を申し込みます。 |
|
2.
|
CAは、サブスクライバのIDを検証し、デジタル証明書を発行します。 |
|
4.
|
サブスクライバは、秘密鍵で電子メッセージにデジタル署名して、送信者が認証済であること、メッセージが完全であること、およびメッセージを否認できないことを確認します。その後、メッセージを受信者に送信します。 |
|
5.
|
受信者は、メッセージを受信すると、サブスクライバの公開鍵でデジタル署名を検証し、リポジトリでサブスクライバの証明書のステータスと有効性をチェックします。 |
|
6.
|
サブスクライバの証明書に関するステータス・チェックの結果が、リポジトリから受信者に返されます。 |
OracleがPKIベンダーとなる予定はありません。Oracleの公開鍵のプラグイン・インタフェースにより、Oracle Tuxedoのユーザーは、PKIソフトウェアのベンダーを自由に選択し、PKIのセキュリティ・ソリューションを使用できます。
メッセージ・ベースの暗号化では、データが秘密に扱われます。これは、企業間または企業と一般ユーザーの間で、インターネットを介してデータを送受信するATMIアプリケーションでは重要です。データの秘密性は、セキュリティ保護されていない社内ネットワークを使用してATMIアプリケーションを導入する場合にも特に重要です。
メッセージ・ベースの暗号化では、メッセージが意味のわからない状態に変換され、内容を変更しようとしてもできないため、メッセージの整合性が保たれます。
メッセージ・ベースの暗号化では、エンド・ツー・エンドで内容がセキュリティ保護されます。つまり、メッセージ・バッファは、送信プロセスで発信され、受信プロセスで受け取られるまで保護されます。送信中には、一時的なメッセージ・キュー、ディスク・ベース・キュー、システム・プロセスなどの中継ポイントでも保護され、サーバー間のネットワーク・リンクで転送される間も保護されます。
図1-10は、エンド・ツー・エンド型のメッセージ・ベースの暗号化のしくみを示しています。
メッセージは、対称鍵アルゴリズムとセッション・キーによって暗号化されます。次に、セッション・キーが受信者の公開鍵によって暗号化されます。さらに、受信者は、受信者の秘密鍵を使用して、暗号化されたセッション・キーを復号化します。最後に、受信者は、セッション・キーを使用して暗号化されたメッセージを復号化し、メッセージ内容を取得します。
|
注意:
|
この図では、(1)メッセージを暗号化する直前にデータを圧縮する、および(2)メッセージを復号化した直後にデータを解凍する、という2つの手順が説明されていません。 |
暗号化は、ATMIのメッセージ・バッファ単位で行われます。したがって、メッセージ・ベースの暗号化は、既存のATMIのプログラミング・インタフェースおよび通信パラダイムと互換性があります。暗号化のプロセスは、単一のマシン内にある2つのプロセス間で送受信されるメッセージに対して行われる場合も、2つのマシン間でネットワークを介して送受信されるメッセージに対して行われる場合も同じです。
公開鍵セキュリティのベースとなるプラグイン・インタフェースは、6つのコンポーネント・インタフェースから成り、それぞれのコンポーネントは、1つ以上のプラグインを必要とします。これらのインタフェースを好みのプラグインでインスタンス化すれば、メッセージ・ベースのカスタム・デジタル署名とメッセージ・ベースの暗号化をATMIアプリケーションに持ち込むことができます。
6つのコンポーネント・インタフェースを次に示します。
公開鍵の初期化インタフェースによって、公開鍵ソフトウェアは、公開鍵と秘密鍵を開くことができます。たとえば、ゲートウェイ・プロセスでは、メッセージを復号化してから転送するために、特定の秘密鍵へのアクセスが必要なこともあります。このインタフェースは、ファンアウトとして実装されます。
鍵管理インタフェースによって、公開鍵ソフトウェアは、公開鍵と秘密鍵を管理および使用することができます。なお、メッセージ・ダイジェストとセッション・キーは、このインタフェースを使用して暗号化および復号化されますが、公開鍵暗号を使用するバルク・データの暗号化は行われません。バルク・データの暗号化は、対称鍵暗号を使用して行われます。
証明ルックアップ・インタフェースによって、公開鍵ソフトウェアは、所定の
プリンシパルに対する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システムのATMI環境に用意されている、デフォルトの認証および認可のプラグインは、Oracle Tuxedoで最初に実現された、従来のOracle Tuxedoの認証および認可の実装と同じように機能します。
アプリケーション管理者は、デフォルトの認証および認可のプラグインを使用して、5つのうち、1つのセキュリティ・レベルをATMIアプリケーションに構成できます。5つのセキュリティ・レベルは、次のとおりです。
最も低いセキュリティ・レベルでは、認証は行われません。最も高いセキュリティ・レベルでは、アクセス制御リストの機能により、サービスを実行し、イベントをポストし、アプリケーション・キューのメッセージをキューに登録(または登録解除)するユーザーが決定されます。
表1-10は、セキュリティ・レベルを簡単にまとめたものです。
表1-10
デフォルトの認証と認可のセキュリティ・レベル
|
|
|
|
|
ATMIアプリケーションに参加する前にクライアントを検証する必要はありません。 このセキュリティ・レベルでATMIアプリケーションに参加すると、ユーザーはすべてのアプリケーション・リソースにアクセスできます。 |
|
|
アプリケーション管理者は、ATMIアプリケーション全体に対して1つのパスワードを定義します。クライアントがアプリケーションに参加するには、パスワードを提示しなければなりません。 このセキュリティ・レベルでATMIアプリケーションに参加できると、ユーザーはすべてのアプリケーション・リソースにアクセスできます。 |
|
|
ATMIアプリケーションに参加するには、各クライアントは、アプリケーション・パスワードのほか、有効なユーザー名とユーザー固有のデータ(パスワードなど)を提示しなければなりません。 このセキュリティ・レベルでATMIアプリケーションに参加できると、ユーザーはすべてのアプリケーション・リソースにアクセスできます。 |
|
|
クライアントは、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。 このセキュリティ・レベルでATMIアプリケーションに参加すると、ユーザーによるアプリケーション・リソースへのアクセスは制限されます。つまり、ACLデータベースに格納されているアプリケーション・リソースのリストにより、各リソースを使用できるユーザーが制限されます。特定のリソースのリストに含まれていないユーザーは、オプションのACLまたは必須のACLが使用されていても、そのリソースにはアクセスできません。 ATMIアプリケーションのセキュリティ・レベルが「オプションのACL」に設定されている場合、ACLデータベースにエントリがないリソースには、誰でもアクセスできます。 |
|
|
クライアントは、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。 このセキュリティ・レベルでATMIアプリケーションに参加すると、ユーザーによるアプリケーション・リソースへのアクセスは制限されます。つまり、ACLデータベースに格納されているアプリケーション・リソースのリストにより、各リソースを使用できるユーザーが制限されます。特定のリソースのリストに含まれていないユーザーは、オプションのACLまたは必須のACLが使用されていても、そのリソースにはアクセスできません。 ATMIアプリケーションのセキュリティ・レベルが「必須のACL」に設定されている場合、ACLデータベースにエントリがないリソースには、どのユーザーもアクセスできません。 |
|
注意:
|
クライアントという用語は クライアント・プロセスと同義であり、実行中のクライアント・プログラムの特定のインスタンスを意味します。ATMIクライアント・プログラムは、任意の数の個別インスタンスのアクティブ・メモリー内に存在することができます。
|
アプリケーション管理者は、
UBBCONFIG構成ファイルの
SECURITYパラメータに適切な値を設定することにより、セキュリティ・レベルを指定できます。
デフォルト値は
NONEです。
SECURITYに
USER_AUTH、
ACL、または
MANDATORY_ACLを設定した場合、アプリケーション管理者は、システム側で提供される
AUTHSVRという名前の認証サーバーを構成しなければなりません。
AUTHSVRは、ユーザー単位で認証を行います。
アプリケーション開発者は、
AUTHSVRを、ATMIアプリケーションに固有のロジックを持つ認証サーバーに置き換えることができます。たとえば、広く使用されているKerberosのメカニズムを使用して認証を行うため、認証サーバーをカスタマイズすることもできます。
クライアント・プロセスは、ATMIアプリケーションに参加すると、ユーザー・クライアント名(ユーザーとクライアントを組み合せた名前)およびアプリケーション・キー
(ユニークなクライアント識別子)を持ちます。
|
•
|
ユーザー・クライアント名は、ユーザー名とクライアント名で構成され、セキュリティ、管理、および通信に使用されます。 |
|
•
|
アプリケーション・キーは32ビット値であり、クライアントのかわりに呼び出され、アクセス制御のチェック機能で使用されます。 |
2つのクライアント名
tpsysadmおよび
tpsysopが、特殊なセマンティクス用に用意されています。
tpsysadmはアプリケーション管理者として扱われ、
tpsysopはアプリケーション・オペレータとして扱われます。
認証されたクライアントは、ATMIアプリケーションに参加すると、ユーザー名とクライアント名を
TPINITバッファの
tpinit(3c)に渡すか(アプリケーションがCで記述されている場合)、または、
TPINFDEF-RECレコードの
TPINITIALIZE(3cbl)に渡します(アプリケーションがCOBOLで記述されている場合)。
表1-11では、ユーザー名とクライアント名、および、
TPINITバッファまたは
TPINFDEF-RECレコード内のその他のセキュリティ関連フィールドを説明します。
表1-11
TPINITバッファおよびTPINFDEF-RECレコードのセキュリティ関連フィールド
|
|
|
|
|
|
|
30文字までの文字列で構成するユーザー名。 USER_AUTH、 ACL、または MANDATORY_ACLのセキュリティ・レベルには必須です。ユーザー名は呼出し側を表します。 |
|
|
|
30文字までの文字列で構成するクライアント名。 USER_AUTH、 ACL、または MANDATORY_ACLのセキュリティ・レベルには必須です。クライアント名はクライアント・プログラムを表します。 |
|
|
|
アプリケーション・パスワード。 APP_PW、 USER_AUTH、 ACL、または MANDATORY_ACLのセキュリティ・レベルには必須です。 tpinit()または TPINITIALIZE()は、このパスワードを TUXCONFIGファイル*に格納された構成済のアプリケーション・パスワードと比較して検証します。 |
|
|
|
|
|
|
|
ユーザー固有のデータ**。 USER_AUTH、 ACL、または MANDATORY_ACLのセキュリティ・レベルには必須です。 tpinit()または TPINITIALIZE()は、ユーザー固有のデータを認証サーバーに転送し、検証します。認証サーバーは AUTHSVRです。 |
|
|
認証されたセキュリティ・レベル(
USER_AUTH、
ACL、または
MANDATORY_ACL)では、ユーザー名、クライアント名、およびユーザー固有のデータは、Oracle Tuxedoシステムで変換されることなく
AUTHSVRに転送されます。これらの情報が変換されるとすれば、ワークステーション・クライアントからネットワーク経由で送信されるときに暗号化が行われる場合のみです。
クライアントがATMIアプリケーションに参加するたびに、Oracle Tuxedoシステムはクライアントに32ビットのアプリケーション・キーを割り当てます。クライアントは、アプリケーションとの関連付けを解除し、別のユーザーとしてATMIアプリケーションに参加しないかぎり、このアプリケーション・キーをリセットできません。
割り当てられたアプリケーション・キーは、クライアントのセキュリティ資格証明です。クライアントは、
TPSVCINFO構造体の一部として、すべてのサービス呼出しに
appkeyフィールドを指定します。
TPSVCINFOの詳細は、
『Oracle Tuxedo ATMI C言語関数リファレンス』の
tpservice(3c)を参照してください。
表1-12は、様々なセキュリティ・レベルとクライアントに割り当てられるアプリケーション・キーを示しています。アプリケーション・キーの割当ては、最後の項目を除き、すべてハードコーディングされます。
|
|
|
|
|
|
管理者( tmadmin(1)など)が起動する、ATMIのネイティブATMIクライアントからのメッセージ |
0x80000000 (管理者のアプリケーション・キー) |
|
|
tpsysadmというクライアント名で tpinit()または TPINITIALIZE()を呼び出し、管理者によって実行されるネイティブATMIクライアントからのメッセージ
|
0x80000000 (管理者のアプリケーション・キー) |
tpsysopというクライアント名で tpinit()または TPINITIALIZE()を呼び出し、管理者によって実行されるネイティブATMIクライアントからのメッセージ
|
0xC0000000 (オペレータのアプリケーション・キー) |
tpsysadmおよび tpsysop以外の任意のATMIクライアントからのメッセージ
|
|
USER_AUTH、 ACL、または MANDATORY_ACL
|
tpsysadmというクライアント名で tpinit()または TPINITIALIZE()を呼び出し、管理者とバイパス認証によって実行されるネイティブATMIクライアントからのメッセージ
|
0x80000000 (管理者のアプリケーション・キー) |
tpsysadmというクライアント名で tpinit()または TPINITIALIZE()を呼び出す認証済ATMIクライアントからのメッセージ
|
0x80000000 (管理者のアプリケーション・キー) |
tpsysopというクライアント名で tpinit()または TPINITIALIZE()を呼び出す認証済ATMIクライアントからのメッセージ
|
0xC0000000 (オペレータのアプリケーション・キー) |
tpsysadmや tpsysop以外のATMIクライアント名で tpinit()または TPINITIALIZE()を呼び出す認証済ATMIクライアントからのメッセージ
|
アプリケーション・キーは、下位17 (UID)と次の上位14ビットのグループ識別子 (GID)です。残りの上位ビットは0です。 AUTHSVRは、このアプリケーション・キーの値を返します。 |
ユーザー識別子(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によるパーミッションのチェックの対象にはなりません。
|
•
|
『Oracle Tuxedoアプリケーションの設定』の 構成ファイルに関する項および 構成ファイルの作成に関する項
|
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より前のソフトウェアを実行します。
「ドメイン内の相互運用性」を参照してください。
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がインストールされている場合にのみ使用できます。
Oracle Tuxedoソフトウェアを実行しているマシン間のネットワーク・リンクでSSL暗号化を使用できるのは、両方のマシンでTuxedo 10.0以降を実行している場合のみです。LLE暗号化は、それ以前のバージョンのTuxedoを実行しているマシン間のネットワーク・リンクでも使用できます。
|
注意:
|
SSL暗号化の相互運用性規則には1つだけ例外があります。 『CORBAアプリケーションにおけるセキュリティ』で説明されているCORBA関連のSSL機能は、Tuxedo 8.0との相互運用および以前のWLE製品との相互運用に使用できます。 |
表1-13に示されている公開鍵によるセキュリティに関する相互運用性の規則は、Oracle Tuxedo 7.1以上を実行するマシンが、Oracle Tuxedo 7.1より前のソフトウェアを実行するマシンと相互運用するように構成されている場合に適用されます。規則の内容を明確にするため、各規則では、Oracle Tuxedo 7.1より前のバージョンを実行するワークステーション・クライアントの例を示しています。
表1-13
公開鍵によるセキュリティ機能の相互運用性に関する規則
|
|
|
|
Oracle Tuxedoリリース7.1より前のソフトウェアを実行するマシン宛の暗号化済のメッセージ・バッファは、マシンに送信されません。 |
7.1より前のリリースのワークステーション・クライアント宛の暗号化済のメッセージ・バッファは、ワークステーション・クライアントに送信されません。 |
「暗号化済」とは、リンク・レベルの暗号化ではなく、メッセージ・ベースの公開鍵の暗号化を意味します。 |
Oracle Tuxedoリリース7.1より前のソフトウェアを実行するマシンから受信したメッセージ・バッファは、暗号化を必要とするプロセスに転送されると、受け付けられません。 |
リリース7.1より前のワークステーション・クライアントからの受信したメッセージ・バッファには、暗号化エンベロープが添付されておらず、暗号化を必要とするプロセスに転送された場合は、受け付けられません。 |
ENCRYPTION_REQUIRED構成パラメータについては、 「暗号化ポリシーの設定」を参照してください。
|
Oracle Tuxedoリリース7.1より前のソフトウェアを実行するマシン宛に送信されたメッセージ・バッファは、デジタル署名が検証および削除されてから、古いマシンに送信されます。 |
デジタル署名は、検証されると、7.1より前のリリースのワークステーション・クライアント宛の送信メッセージ・バッファから削除されます。 |
送信メッセージ・バッファは、デジタル署名されているが暗号化は されていないと見なされます。送信メッセージ・バッファがデジタル署名されており、さらに暗号化されている場合、そのメッセージは復号化されず、デジタル署名は検証されないため、メッセージは古いマシンに送信されません。 |
リリース7.1より前のOracle Tuxedoソフトウェアを実行しているマシンからの着信メッセージ・バッファは、デジタル署名を必要とするプロセスに転送された場合は、受け付けられません。 |
7.1より前のリリースのワークステーション・クライアントからの受信メッセージ・バッファには、デジタル署名が添付されていないため、デジタル署名を必要とするプロセスに転送された場合は受け付けられません。 |
SIGNATURE_REQUIRED構成パラメータについては、 「デジタル署名ポリシーの設定」を参照してください。
|
ドメイン間の相互運用性の場合、リリース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機能またはプロセスとの互換性および相互運用性について説明します。
データ依存型ルーティングとの互換性および相互運用性
データ依存型ルーティング機能の中心となるのは、プロセスが、受信したメッセージ・バッファの内容を調べることです。受信したメッセージ・バッファが暗号化されている場合、データ依存型ルーティング用に構成されたプロセスでは、受信者の秘密鍵を開き、公開鍵ソフトウェアがそのキーを使用してメッセージ・バッファを復号化できるようにしておく必要があります。データ依存型ルーティングでは、公開鍵ソフトウェアは、デジタル署名を検証しません。
復号化キーを使用
できない場合、ルーティング操作は失敗します。システムから
userlog(3c)エラー・メッセージが返され、操作が失敗したことがレポートされます。
復号化キーを使用できる場合、プロセスは、暗号化されたメッセージ・バッファを復号化した
コピーに基づいて、ルーティングに関する決定を行います。次の手順で実行されます。
|
1.
|
公開鍵ソフトウェアは、暗号化されたメッセージ・バッファのコピーを作成し、復号化キーを使用してそのバッファを復号化します。 |
|
2.
|
プロセスは、これによって得られた平文(暗号化されていないテキスト)のメッセージ内容を読み取り、ルーティングに関する決定を行います。 |
|
3.
|
公開鍵ソフトウェアは、プライバシを保護するため、平文のメッセージ内容をゼロ値で上書きします。 |
その後、システムは、ルーティングに関する決定に基づいて、元の暗号化されたメッセージ・バッファを送信します。
公開鍵と秘密鍵は、ハンドルを介して表現および操作されます。
ハンドルには、それに関連付けられたデータがあります。公開鍵のアプリケーション・プログラミング・インタフェース(API: Application Programming Interface)では、ハンドルのデータを使用することにより、ハンドルで指定される項目の検索やアクセスを行います。プロセスは、デジタル署名の生成、メッセージの暗号化、およびメッセージの復号化のために、キー・ハンドルを開きます。
キー・ハンドルはプロセスのリソースです。特定のスレッドやコンテキストにバインドされることはありません。キーを開くために必要な通信はいずれも、スレッドで現在アクティブなコンテキストの内部で実行されます。その後は、コンテキストが同じATMIアプリケーションに関連付けられているかどうかとは無関係に、プロセス内のどのコンテキストでもそのキーを使用できます。
キーの内部データ構造は
スレッド・セーフです。つまり、複数のスレッドが1つのキーに同時にアクセスできます。
一般に、
TMUSREVT(5)システム・サーバーは、暗号化されたメッセージ・バッファを復号化しないで処理します。つまり、メッセージがOracle Tuxedoのイベント・ブローカ・コンポーネントを通過しても、デジタル署名と暗号化エンベロープは何の影響も受けません。ただし、次の場合、イベント・ブローカ・コンポーネントは、ポストされたメッセージ・バッファを復号化する必要があります。
|
•
|
メッセージの内容に基づいてサブスクリプションのフィルタ式を評価する場合 |
イベント・ブローカが適切な復号化キーにアクセスできない場合、そのサブスクリプションのフィルタ式はfalseとみなされ、サブスクリプションは不一致とみなされます。
|
•
|
メッセージの内容へのアクセスが必要な、サブスクリプションの通知アクション( userlog(3c)プロセスまたはシステム・コマンド)を実行する場合 |
イベント・ブローカが適切な復号化キーにアクセスできない場合、そのサブスクリプションの通知アクションは失敗し、システムからは
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以上のドメイン・ゲートウェイ・プロセスでどのように扱われるかを示しています。
表1-14
リリース7.1以上のドメイン・ゲートウェイ(GWTDOMAIN)プロセスの動作
|
|
|
|
インバウンド・メッセージ(リモート・プロセスから発信され、ネットワーク接続を経由して受信されるメッセージ) |
暗号化エンベロープあり、デジタル署名はあってもなくても可 |
ドメイン・ゲートウェイ・プロセスはメッセージを受け付け、暗号化された形式で転送します。 データ依存型ルーティング機能が適用され、ドメイン・ゲートウェイ・プロセスが適切な復号化キーを 持たない場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、 「データ依存型ルーティングとの互換性および相互運用性」を参照してください。) |
|
|
|
ドメイン・ゲートウェイ・プロセスが、暗号化を必要とするグループ、ドメイン、またはマシンの内部で実行されている場合、ゲートウェイ・プロセスはメッセージを拒否します。 ドメイン・ゲートウェイによって通知されたサービスが暗号化を 必要とする場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、 「暗号化ポリシーの設定」を参照してください。) ドメイン・ゲートウェイが暗号化を必要としない場合、ゲートウェイ・プロセスはメッセージを受け付け、転送します。 |
|
|
|
ドメイン・ゲートウェイ・プロセスは、デジタル署名を検証し、メッセージにデジタル署名を添付して転送します。 |
|
|
|
ドメイン・ゲートウェイ・プロセスが、デジタル署名を必要とするグループ、ドメイン、またはマシンの内部で実行されている場合、ゲートウェイ・プロセスはメッセージを拒否します。 ドメイン・ゲートウェイによって通知されたサービスがデジタル署名を 必要とする場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、 「デジタル署名ポリシーの設定」を参照してください。) ドメイン・ゲートウェイがデジタル署名を必要としない場合、ゲートウェイ・プロセスはメッセージを受け付け、転送します。 |
アウトバウンド・メッセージ(ローカル・プロセスから発信され、ネットワーク接続を経由して転送されるメッセージ) |
暗号化エンベロープあり、デジタル署名はあってもなくても可 |
ドメイン・ゲートウェイ・プロセスはメッセージを受け付け、暗号化してネットワーク経由で転送します。 データ依存型ルーティング機能が適用され、ドメイン・ゲートウェイ・プロセスが適切な復号化キーを 持たない場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、 「データ依存型ルーティングとの互換性および相互運用性」を参照してください。) 暗号化されたメッセージが、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)のプロセスは、アウトバウンド・メッセージ・バッファに対して次のように動作します。
|
2.
|
デジタル署名がある場合は、デジタル署名を検証してから削除します。 |
|
3.
|
平文メッセージをネットワーク経由でベンダーのゲートウェイ・プロセスに送信します。 |
さらに、ドメイン・ゲートウェイ・プロセスは、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の定義は次のとおりです。
接続の最大数。最小
limit値は0、最大値は2,147,483,647です。
limitに達している(あるいは超えている)ときに受信リクエストがあった場合、GWTDOMAINは指定した時間(duration)だけ一時停止します。同時に、一時停止をトリガーする現在の受信リクエストは受け付けられません。ポーリングは、
durationの経過後に再開されます。
limitを0に設定すると、ドメイン・ゲートウェイは受信接続リクエストを受け付けません。つまり、「OUTGOING_ONLY」接続ポリシーになります。
制限(
limit)に達したときに受信接続でポーリングを一時停止する時間(秒)。デフォルト値は(SCANUNIT * SANITYSCAN)秒です。最小
duration値は5、最大値は65,535です。
前に閉じられた接続をカウントするためのGWTDOMAINチェック・ポイントからの時間間隔(秒)。値を指定しない場合、
durationと同じデフォルト値が指定されます。最小
period値は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に達しているとき、次のような状況であるとします。
|
•
|
前の60秒で50の接続が閉じられました(送信接続と受信接続を含む)。 |
duration値が指定されていないので、GWTDOMAINは
durationのデフォルト値(SCANUNIT * SANITYSCAN秒)だけポーリングと新たな受信接続リクエストの受付けを停止します。
|
注意:
|
一時停止をトリガーした現在の受信接続も受け付けらず、一時停止時間の終了時に閉じられます。 |
# UBBCONFIG
...
*SERVERS
GWTDOMAIN SRVGRP=GWGRP1 SRVID=2 CLOPT= ���-A -- -x 200::60���
次のような場合、USERLOGにメッセージが出力されます。
|
•
|
事前に設定した接続制限数に達する新しい接続リクエストが着信する場合。 |
<LIBGW_CAT 5359> "警告: <ldom-name>に対する接続数は制限<%d>を超えています。<%d>秒間の一時停止を開始します。"
|
•
|
GWTDOMAINが新たに受信接続リクエストのチェックを再開する場合。 |
<LIBGW_CAT 5360> "情報: 接続リクエストの受入れを再開します。"
|
注意:
|
前述の2つのメッセージは、USERLOGがいっぱいになるのを回避するために「メッセージ調整」メカニズムを使用して制御できます。 |
|
•
|
limitを0に指定して、GWTDOMAINが起動する場合。
|
<LIBGW_CAT 5361> "INFO: <ldom-name>に対する接続制限が0に設定されています。受信した接続リクエストは受け付けられません。"
メッセージの正常性チェックは、この機能を使用して強化され、GWTDOMAINが攻撃を受けてクラッシュしないように保護します。この機能はインストール後に自動的にデプロイされるため、構成作業は必要ありません。
メッセージ認証コード(MAC)をメッセージと関連付けると、Tuxedoドメイン・ゲートウェイでメッセージを検証および認証することができます。MACを使用すると、ドメイン・ゲートウェイは、各種DoS攻撃(メッセージの改ざん、メッセージの偽造、メッセージのリプレイ攻撃など)に対して防御することができます。
この機能は、LLEまたはドメインSECURITYが構成されている場合にのみ有効です。MACは接続が確立した後に機能します。リモート・ドメイン・ゲートウェイからのMACメッセージが検証および認証に失敗すると、対応する接続が切断されます。保留メッセージもすべて破棄され、現行のすべてのサービス・リクエストが失敗します。
セッションでMACを有効にするかどうかは、セッション・ネゴシエーション・フェーズ時にGWTDOMAINによって決定されます。MACを有効にできるのは、セッションでLLEまたはSECURITYがサポートされていて、アクティブになっている場合のみです。
MACを有効にするためにSECURITY機能をサポートする必要はありませんが、SECURITYは「介在者」の攻撃に対する防御に使用できるのでお薦めします。
MACが有効な場合、ドメイン間のリクエストに対するスループットとレスポンス時間が低下する可能性があります。
この機能は、2つの新しいキーワード(MACとMACLEVEL)を使用して、DMCONFIGファイルのDM_TDOMAINセクションで構成できます。MACはセッションでMACの機能を切り替えるために使用され、MACLEVELはMACレベルを指定するために使用されます。
|
注意:
|
MACLEVELの数値が大きいければ、暗号化という点ではより強力なアルゴリズムになりますが、同時にパフォーマンスは低下します。 |
|
|
|
|
|
|
|
|
|
|
|
機能をオンにします。確立されたセッションのMACサポートは、2つのドメイン・ゲートウェイ間のネゴシエーション結果に依存します。 |
|
|
|
機能をオンにします。次の場合は、セッションを設定できません。
|
•
|
リモート・ドメインでMAC機能がサポートされていないか、無効になっています。 |
|
•
|
LLEとドメインSECURITYが利用できません。 |
|
|
|
|
MACでメッセージ・ヘッダーのみを保護。これがデフォルト値です。 |
|
|
|
MD5ベースのアルゴリズムを使用してMACでメッセージ全体を保護。 |
|
|
|
SHA1ベースのアルゴリズムを使用してMACでメッセージ全体を保護。 |
|
|
|
SHA256ベースのアルゴリズムを使用してMACでメッセージ全体を保護。 |
# DMCONFIG
...
*DM_TDOMAIN
���RDOM��� NWADDR=���//RHOST:RPORT���
MAC=���ON���
MACLEVEL=1
MIBを使用してMACを動的に設定する場合、既存のドメイン・セッションは影響を受けません。この設定は、新しい接続でのみ有効です。
MIBインタフェースをサポートするための2つの新しい属性(
TA_DMMACと
TA_DMMACLEVEL)がT_DM_TDOMAIN
クラス定義の属性表に追加されます。
表1-16
DM_MIB(5): T_DM_TDOMAINクラス定義の属性表
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TA_DMMAC="{OFF|ON|MANDATORY}"
リモート・ドメイン・アクセス・ポイントでのみ有効です。リモート・ドメインへの接続時にMAC機能をアクティブにするかどうか指定します。サポートされる値は、"OFF"、"ON"、"MANDATORY"です。
ドメイン・ゲートウェイへの接続でMAC機能を使用しない場合に指定します。
ドメイン・ゲートウェイへの接続でMAC機能を使用する場合に指定します。
ドメイン・ゲートウェイへの接続でMAC機能を使用する必要がある場合に指定します。使用しない場合は接続を正常に確立できません。
TA_DMMACLEVEL="{0|1|2|3}"
リモート・ドメイン・アクセス・ポイントでのみ有効です。MACでメッセージ全体を保護する場合に指定します。 "0"は、MACでメッセージ・ヘッダーのみを保護する場合に指定します。 "1"、"2"、"3"は、MD5、SHA1、SHA256に基づいたアルゴリズムを使用してMACでメッセージ全体を保護する場合に指定します。
リスト1-4
MAC属性を取得するサンプル・スクリプト
SRVCNM .TMIB
TA_OPERATION GET
TA_CLASS T_DM_TDOMAIN
TA_DMACCESSPOINT RDOM
TA_DMNWADDR //host:port
リスト17
MAC属性を更新するサンプル・スクリプト
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
DOM1およびDOM2という2つのドメインがあるとします。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機能が設定された後に出力されます。
<LIBGWT 1686> "情報: MACはセッション(<ldom-name>、<rdom-name>)でサポートされていません"
|
注意:
|
このメッセージは、MACが"ON"に設定されている場合にのみドメインに出力されます。 |
<LIBGWT 1687> "情報: MACはセッション(<ldom-name>、<rdom-name>)に対してオンになっており、実効MACLEVELは<%d>です"
次のエラー・メッセージは、セッションネゴシエーションおよびMAC検証フェーズ時に表示されます。これらのメッセージが出力されると、接続は切断されます。
|
•
|
セッションでMACが必須ですが、ネゴシエーション時にMACがサポートされていない場合。 |
<LIBGWT 1681> "エラー: MACが必要ですが、リモート・ドメイン<rdom-name>はこの機能をサポートしていません"
|
•
|
MACが必須ですが、ネゴシエーション時にLLEもSECURITYもサポートされていない場合。 |
<LIBGWT 1682> "エラー: MACが必要ですが、LLEもSECURITYも(<ldom-name>、<rdom-name>)の接続でサポートされていません"
|
•
|
リモート・ドメインでMACが必須ですが、ローカル・ドメインでMACがサポートされていない場合。 |
<LIBGWT 1683> "エラー: リモート・ドメイン<rdom-name>でMACが必要ですが、ローカル・ドメイン<ldom-name>でサポートされていません"
|
•
|
MACネゴシエーションでMACLEVELに関する合意に失敗した場合。 |
<LIBGWT 1684> "エラー: MACはMACLEVELに関する合意(<ldom_name>は<%d>..<%d>、<rdom-name>は<%d>..<%d>)に失敗しました"
|
注意:
|
このメッセージの"%d"プレースホルダーに対応するパラメータは、m1、Max1、m2、Max2です。 |
<LIBGWT 1685> "エラー: <rdom-name>からのメッセージに無効なMACがあります"
パスワード・ペア保護機能はインストール後に自動的にデプロイされるため、構成作業は必要ありません。この機能により、GWTDOMAINセキュリティ・メカニズムが強化され、また、同じリモート・パスワードによるデュアル・パスワード・ペアが使用できなかった以前のセキュリティの制限もなくなります。
パスワード・ペア保護は、ローカル・ドメインとリモート・ドメインの両方でサポートされている場合にのみ機能します。ローカル・ドメインとリモート・ドメインの両方でサポートされていない場合は、既存の動作が変更されることはありません。
