1 概要

次の項では、Oracle TuxedoのATMIアプリケーション用の様々なセキュリティ機能について説明します。

ノート:

Oracle Tuxedoには、ATMI (アプリケーション・トランザクション・モニター・インタフェース)アプリケーションとCORBAアプリケーションを作成するための2種類の環境が用意されています。この章では、ATMIアプリケーションに対するセキュリティ機能の実装方法を説明します。CORBAアプリケーションに対するセキュリティ機能の実装方法については、『CORBAアプリケーションにおけるセキュリティの使用』を参照してください。

• セキュリティとは
  
• セキュリティ・プラグイン
  
• ATMIセキュリティ機能
  
• オペレーティング・システム(OS)のセキュリティ
  
• 認証
  
• 認可
  
• 監査
  
• リンク・レベルの暗号化
  
• TLS暗号化
  
• 公開キーによるセキュリティ機能
  
• メッセージ・ベースのデジタル署名
  
• メッセージ・ベースの暗号化
  
• 公開キーの実装
  
• デフォルトの認証と認可
  
• セキュリティの相互運用性
  
• セキュリティ機能の互換性
  
• サービス拒否(DoS)の防御
  
• パスワード・ペア保護
  

1.1 セキュリティとは

セキュリティとは、コンピュータに保存されているデータまたはコンピュータ間でやりとりされるデータが危険にさらされないことを保証する技術です。ほとんどのセキュリティ機能では、パスワードおよびデータの暗号化を使用してセキュリティを実現します。パスワードとは、秘密の文字列であり、ユーザーは、これを入力することにより特定のプログラムやシステムにアクセスできます。データの暗号化とは、データを理解できない形式に変換することであり、変換されたデータは復号化のメカニズムがないと解読できません。

電子商取引などで使用される分散アプリケーションには、悪質なユーザーがデータを傍受したり、操作を中断したり、不正な情報を入力できるアクセス・ポイントが多数あります。ビジネスがより広い範囲に分散されるほど、こうした悪質なユーザーによる攻撃を受けやすくなります。したがって、このようなアプリケーションの基盤となる分散型のコンピューティング・ソフトウェア、つまりミドルウェアは、セキュリティ機能を備えている必要があります。

Oracle Tuxedo製品には、ATMIアプリケーション用のセキュリティ機能がいくつか用意されており、その大部分は、特定のニーズに合せてカスタマイズできます。

関連項目:

• セキュリティ・プラグイン
• ATMIセキュリティ機能
• セキュリティ管理のタスク
• セキュリティのプログラミングとは

1.2 セキュリティ・プラグイン

次の図に示すように、Oracle Tuxedo製品のATMI環境で使用できるセキュリティ機能は、1つを除いてすべてプラグイン・インタフェースによって実装されています。プラグイン・インタフェースにより、Oracle Tuxedoのユーザーは、独自のセキュリティ・プラグインを定義し、動的に追加できます。セキュリティ・プラグインは、特定のセキュリティ機能を実装するコード・モジュールです。

図1-1 Oracle Tuxedo ATMIのセキュリティ・プラグイン・アーキテクチャ

セキュリティ・プラグインのインタフェースの仕様は一般には公開されていませんが、サード・パーティのセキュリティ・ベンダーには公開されています。サード・パーティのセキュリティ・ベンダーは、オラクル社と専用契約を結ぶことでOracle Tuxedoのセキュリティ・プラグインを開発することができます。セキュリティ機能をカスタマイズする場合は、これらのセキュリティ・ベンダーにお問い合せください。たとえば、公開キーによるセキュリティ機能をカスタマイズする場合は、適切なセキュリティ・プラグインを提供するサード・パーティのセキュリティ・ベンダーに問い合せる必要があります。セキュリティ・プラグインの詳細(インストール手順および構成手順を含む)については、オラクル社の営業担当者にお問い合せください。

関連項目:

• ATMIセキュリティ機能

1.3 ATMIセキュリティ機能

Oracle Tuxedoシステムでは、様々な方法でセキュリティを実現できます。たとえば、ホスト・オペレーティング・システムのセキュリティ機能を使用して、ファイル、ディレクトリ、およびシステム・リソースへのアクセスを制御することができます。次の表では、Oracle TuxedoシステムのATMI環境で利用できるセキュリティ機能を説明します。

表1-1 ATMIのセキュリティ機能

セキュリティ機能	説明	プラグイン・インタフェース	デフォルトの実装
オペレーティング・システムのセキュリティ	ファイル、ディレクトリ、およびシステム・リソースへのアクセスを制御します。	N/A	N/A
認証	ユーザーまたはシステム・プロセスに対して指定されているIDを証明し、ID情報を安全に記録およびトランスポートし、必要に応じてID情報を利用可能にします。	1つのインタフェースとして実装されます。	デフォルトの認証プラグインには、認証なし、アプリケーション・パスワードを使用、ユーザー・レベルの認証を実行という3つのセキュリティ・レベルが用意されています。このデフォルトのプラグインは、Oracle Tuxedoシステムで最初に実現された、Oracle Tuxedoの従来の認証の実装と同じように機能します。
認可	IDおよびその他の情報に基づいて、リソースへのアクセスを制御します。	1つのインタフェースとして実装されます。	デフォルトの認可プラグインには、オプションのアクセス制御リストと必須のアクセス制御リストという2つのレベルのセキュリティが用意されています。このデフォルトのプラグインは、Oracle Tuxedoシステムで最初に実現された、Oracle Tuxedoの従来の認可の実装と同じように機能します。
監査	操作リクエストとその結果に関する情報を安全に収集、格納、および配布します。	1つのインタフェースとして実装されます。	デフォルトの監査機能は、Oracle Tuxedoイベント・ブローカおよびユーザー・ログ(ULOG)機能によって実装されます。
リンク・レベルの暗号化	対称キーによる暗号化を使用して、ATMIアプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージの秘密性を保護します。	N/A	RC4形式の対称キーによる暗号化
TLS暗号化	業界標準であるTLS プロトコルを使用して、ATMIアプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージの秘密性を保護します。(TLSは、SSLプロトコルの後継となる標準です。)	N/A	Oracle NZセキュリティ・レイヤー
公開キーによるセキュリティ機能	公開キー(非対称キー)による暗号化を使用して、ATMIアプリケーションのクライアントとサーバー間でエンド・ツー・エンドのデジタル署名とデータの秘密性を実現します。この機能は、PKCS-7標準に準拠しています。	6つのインタフェース として実装されます。	デフォルトの公開キーセキュリティでは、次のアルゴリズムがサポートされます。 RSA (公開キーのアルゴリズム) RSAおよびDSA (デジタル署名のアルゴリズム) DES-CBC、2つのキーによるTriple DES、およびRC2 (対称キーのアルゴリズム) MD5およびSHA-1 (メッセージ・ダイジェストのアルゴリズム)

関連項目:

• オペレーティング・システムのセキュリティ
• 認証
• 認可
• 監査
• リンク・レベルの暗号化
• TLS暗号化
• 公開キーによるセキュリティ機能

1.4 オペレーティング・システム(OS)のセキュリティ

ファイルに対するパーミッション設定などのセキュリティ機能を備えた、ホスト側のオペレーティング・システムでは、オペレーティング・システム・レベルのセキュリティが、第一レベルのセキュリティ機能になります。アプリケーション管理者は、ファイルに対してパーミッションを設定することにより、特定のユーザーまたはユーザー・グループに対して、アクセス権限を付与したり、拒否することができます。

ほとんどの場合、ATMIアプリケーションは、アプリケーション管理者によって管理されます。アプリケーション管理者は、アプリケーションを構成し、起動し、実行中のアプリケーションを動的にモニターし、必要に応じて変更します。ATMIアプリケーションは、管理者が起動し、実行するため、サーバー・プログラムは、管理者のパーミッションで実行されます。これで、サーバー・プログラムは安全であり、「信頼性がある」と見なされます。この方法は、基盤となるオペレーティング・システムのログイン・メカニズムとパーミッション設定(ファイル、ディレクトリ、およびシステム・リソースに対する読取り権と書込み権の設定)に基づいています。

クライアント・プログラムは、自分のパーミッションを持つユーザーによって直接実行されます。さらに、ネイティブ・クライアント(サーバー・プログラムと同じマシンで実行中のクライアント)を実行するユーザーは、UBBCONFIG構成ファイルにアクセスしたり、掲示板(ATMIアプリケーションを制御するパラメータおよびアプリケーションの統計情報を格納するために確保されている共有メモリーの一部)などのプロセス間通信(IPC)のメカニズムにアクセスできます。

より高度なセキュリティ機能を備えたプラットフォーム上のATMIアプリケーションでは、ファイルおよびIPCメカニズムに対するアクセスをアプリケーション管理者のみに限定し、管理者のパーミッション(UNIXホスト・マシンのsetuidコマンドまたは別のプラットフォームでの同等のコマンド)を使用して「信頼性のある」クライアント・プログラムを実行すると、より安全です。最も高いレベルのオペレーティング・システムのセキュリティを実現するには、ワークステーション・クライアントだけがアプリケーションにアクセスできるようにし、アプリケーション・サーバーおよび管理プログラムを実行するマシンではクライアント・プログラムを実行できないようにします。

関連項目:

• セキュリティ管理のタスク
• オペレーティング・システム(OS)のセキュリティ管理
• 『Oracle Tuxedoアプリケーションの設定』の「構成ファイルについて」および「構成ファイルの作成」
• 『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)に関する項

1.5 認証

認証機能とは、通信するプロセスどうしがお互いのIDを証明し合うことです。Oracle TuxedoシステムのATMI環境の認証プラグイン・インタフェースは、共有シークレット・パスワード、ワンタイム・パスワード、CHALLENGEレスポンス、Kerberosなどの認証技術を使用して、セキュリティ・プロバイダによる様々な認証プラグインに対応できます。インタフェースは、Generic Security Service (GSS) Application Programming Interface (API)の仕様に可能なかぎり厳密に従います。GSSAPIは、Internet Engineering Task Forceの公開されている標準です。認証プラグイン・インタフェースは、サード・パーティ・ベンダーのセキュリティ製品をできるだけ簡単にOracle Tuxedoシステムに統合できるように設計されています。ただし、セキュリティ製品はGSSAPIを使用して記述しておく必要があります。

• 認証プラグインのアーキテクチャ
  
• 委任された信用認証の理解
  
• セッションの確立
  
• 認可トークンおよび監査トークンの取得
  
• クライアント・トークンとサーバー・トークンの交換
  
• カスタマイズした認証の実装
  

1.5.1 認証プラグインのアーキテクチャ

認証セキュリティの基礎となるプラグイン・インタフェースは、1つのプラグインとして実装されます。このプラグインは、デフォルトの認証プラグインでもカスタマイズした認証プラグインでもかまいません。

1.5.2 委任された信用認証の理解

Oracle Tuxedoシステムなどの分散型のエンタープライズ・ミドルウェア環境で、エンド・ツー・エンドの相互認証を直接行う場合、特に、長時間の接続用に最適化されたセキュリティ・メカニズムでは、大幅にコストがかかります。クライアントから各サーバー・プロセスに対して直接ネットワーク接続を確立したり、サービス・リクエストの処理時に複数の認証メッセージを交換および検証するのは、非効率的です。かわりに、ATMIアプリケーションは、次の図のような、高信頼性委任型認証モデルを使用します:

図1-2 ATMI高信頼性委任型認証モデル

ワークステーション・クライアントは、起動時に、信頼性のあるシステム・ゲートウェイ・プロセスであるワークステーション・ハンドラ(WSH)に対して認証を行います。ネイティブ・クライアントの場合は、自身に対して認証を行います(後で説明)。認証が成功すると、認証ソフトウェアは、クライアントにセキュリティ・トークンを割り当てます。トークンとは、プロセス間の転送に適したオペークなデータ構造体です。WSHは、認証済のワークステーション・クライアントのトークンを安全に格納します。ネイティブ・クライアントの場合は、認証済のネイティブ・クライアント自身のトークンを安全に格納します。

信頼性のあるゲートウェイは、通過するクライアント・リクエストにセキュリティ・トークンを添付します。添付されたセキュリティ・トークンは、クライアント・リクエストのメッセージとともに送信され、送信先のサーバー・プロセスでの認可と監査で使用されます。

このモデルのゲートウェイでは、認証ソフトウェアがクライアントのIDを検証し、適切なトークンを生成することが期待されています。一方、サーバー側では、ゲートウェイ・プロセスで適切なセキュリティ・トークンが添付されることが期待されています。また、サーバー側では、クライアント・リクエストを処理するその他のサーバーによって、そのトークンが安全に配信されることも期待されています。

1.5.3 セッションの確立

次の図は、ワークステーション・クライアントとWSHとの間でセッションが確立されているときの、Oracle TuxedoシステムのATMI環境内の制御フローを示しています。ここでは、ワークステーション・クライアントとWSHが、メッセージを交換して相互に認証し合い、長期間にわたる接続を確立する様子を示しています。

図1-3 ATMI環境での制御フロー

まず、イニシエータ・プロセス(ミドルウェアのクライアント・プロセスと考えられます)は、Oracle Tuxedoの「セキュリティ・コンテキストの開始」関数を、戻りコードが成功または失敗を示すまで繰返し呼び出すことにより、セッション・コンテキストを作成します。セッション・コンテキストは、認証されたユーザーとID情報を関連付けます。

ワークステーション・クライアントが、ATMIアプリケーションに参加するためにCのtpinit(3c)またはCOBOLのTPINITIALIZE(3cbl)を呼び出すと、Oracle Tuxedoシステムは、まず内部の「資格取得」関数を呼び出して、セッション資格ハンドルを取得し、レスポンスを返します。次に、内部の「セキュリティ・コンテキストの開始」関数を呼び出して、セッション・コンテキストを取得します。「セキュリティ・コンテキストの開始」関数は、呼出し時に入力セッション・トークンを取り(セッション・トークンがある場合)、出力セッション・トークンを返します。セッション・トークンでは、ユーザーのIDを確認するためのプロトコルを使用します。イニシエータ・プロセスが出力セッション・トークンをセッションのターゲット・プロセス(WSH)に渡すと、出力セッション・トークンは、別の入力トークンと交換されます。トークンの交換は、双方のプロセスが相互認証を完了するまで繰り返されます。

セキュリティ・プロバイダの認証プラグインでは、セキュリティ実装用のセッション・トークンおよびセッション・コンテキストの内容が定義されています。したがって、ATMI認証では、セッション・トークンとセッション・コンテキストを不透明なオブジェクトとして扱う必要があります。交換されるトークンの数は定義されておらず、認証システムのアーキテクチャに応じて異なります。

ネイティブ・クライアントでセッションを開始する場合、イニシエータ・プロセスとターゲット・プロセスは同じです。このプロセスは、ミドルウェア・クライアント・プロセスと見なすことができます。ミドルウェア・クライアント・プロセスは、セキュリティ・プロバイダの認証プラグインを呼び出してネイティブ・クライアントを認証します。

1.5.4 認可トークンおよび監査トークンの取得

認証に成功すると、信頼性のあるゲートウェイは、Oracle Tuxedoの内部関数を2つ呼び出し、クライアント用の認可トークンおよび監査トークンを取得します。これらのトークンは、ゲートウェイによって格納されます。これらのトークンの組合せは、セキュリティ・コンテキストのユーザーIDを表します。セキュリティ・トークンという用語は、集合的に認可トークンと監査トークンを表します。

デフォルトの認証の認可トークンには、次の2つの情報が設定されています。

• プリンシパル名 - 認証されたユーザーの名前
• アプリケーション・キー - リクエスト・メッセージを開始するクライアントを一意に識別する32ビット値。詳細は、「アプリケーション・キー」を参照してください。

また、デフォルトの認証を使用する場合、監査トークンにも、プリンシパル名とアプリケーション・キーが設定されます。

セッション・トークンと同様に、認可トークンと監査トークンもオペークであり、内容は、セキュリティ・プロバイダごとに異なります。認可トークンを使用すると、認可(パーミッション)をチェックすることができます。監査トークンを使用すると、監査情報を記録することができます。ATMIアプリケーションによっては、認可用と監査用のユーザーIDを別々に設定すると便利です。

1.5.5 クライアント・トークンとサーバー・トークンの交換

次の図に示すように、クライアントのサービス・リクエストがサーバーによって転送されるときに、サーバーのIDが設定される場合があります。サーバーは、サービス・リクエストに添付されたクライアント・トークンを自らのトークンに置き換えてから、そのサービス・リクエストを適切なサービスに転送します。

図1-4 サーバー・パーミッションのアップグレード例

ノート:

サーバーが自らの認可トークンと監査トークンを取得する方法、およびこれらのトークンを必要とする理由については、「プリンシパル名の指定」を参照してください。

上の図に示す機能を、サーバー・パーミッションのアップグレードと呼びます。この機能では、ドット付きのサービス(.TMIBのように名前の先頭にピリオドが付いた、システムに組み込まれているサービス)をサーバーが呼び出すたびに、サービス・リクエストにサーバーのIDが付き、サーバーに対するアクセス権が取得されます。サーバーのアクセス権とは、アプリケーション管理者(システム管理者)のアクセス権のことです。つまり、クライアントからドット付きのサービスを直接呼び出すことはできなくても、まずサーバーにリクエストを送信し、そのサーバーからドット付きのサービスにリクエストを転送することはできます。ドット付きサービスの詳細は、『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のMIB(5)のリファレンス・ページにあるTMIBサービスの説明を参照してください。

1.5.6 カスタマイズした認証の実装

ATMIアプリケーションで認証機能を実行するには、デフォルトのプラグインまたはカスタマイズしたプラグインを使用します。プラグインを選択するには、すべてのセキュリティ・プラグインを制御するツールである、Oracle Tuxedoレジストリを構成します。

デフォルトの認証プラグインを使用する場合、レジストリを構成する必要はありません。ただし、カスタマイズされた認証プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合せてレジストリを構成する必要があります。レジストリの詳細は、「Oracle Tuxedoレジストリの設定」を参照してください。

関連項目:

• デフォルトの認証と認可
• セキュリティ管理のタスク
• 認証の管理
• セキュリティを備えたATMIアプリケーションのプログラミング
• ATMIアプリケーションにクライアント・プログラムを参加させるためのセキュリティ・コードの記述方法

1.6 認可

認可の機能により、管理者はATMIアプリケーションへのアクセスを制御できます。つまり、管理者は、認可の機能を使用して、ATMIアプリケーションのリソースまたは機能に対するアクセス権をプリンシパル (認証されたユーザー)に許可するかどうかを決定します。

• 認可プラグインのアーキテクチャ
  
• 認可プラグインのしくみ
  
• カスタマイズした認可の実装
  

1.6.1 認可プラグインのアーキテクチャ

ファンアウトとは、様々なプラグインの実装が接続された、アンブレラ(傘)型のプラグインです。次の図に示すように、認可プラグインのインタフェースは、ファンアウトの構成で実装されます。

図1-5 認可プラグインのアーキテクチャ

デフォルトの認可プラグインの実装は、ファンアウト・プラグインとデフォルトの認可プラグインで構成されます。カスタマイズされたプラグインの実装は、ファンアウト・プラグイン、デフォルトの認可プラグイン、および1つ以上のカスタム認可プラグインで構成されます。

ファンアウト・プラグイン・モデルでは、まず、呼出し側がファンアウト・プラグインにリクエストを送信します。受信されたリクエストは、下位のプラグインに渡され、各プラグインからレスポンスが返されます。最後に、ファンアウト・プラグインは、受け取った複数のレスポンスを1つのレスポンスにまとめ(複合レスポンス)、呼出し側に送信します。

認可リクエストの目的は、クライアント操作を許可するか、または操作の結果を変更しないままにするかを決めることです。各認可プラグインは、permit、denyまたはabstainのいずれかのレスポンスを返します。abstainレスポンスが返されると、認可プラグインの作成者は、元のプラグインでは対応できないこと、たとえば、プラグインのインストール後にシステムに追加された操作名などに対処できます。

次の表は、認可のファンアウト・プラグインで作成されるコンポジット・レスポンスを示しています。デフォルトの認可の場合、コンポジット・レスポンスは、デフォルトの認可プラグインによってのみ決まります。

表1-2 認可のコンポジット・レスポンス

プラグインから返される値	複合レスポンス
すべてpermit、またはpermitとabstainの組合せの場合	permit
少なくとも1つがdenyの場合	deny
すべてabstainの場合	deny (パラメータATMIアプリケーションのUBBCONFIGファイルのSECURITYパラメータ がMANDATORY_ACLに設定されている場合) permit (SECURITYパラメータがATMIアプリケーションのUBBCONFIGファイルに設定されていない場合、またはMANDATORY_ACL以外の値に設定されている場合)

カスタマイズした認可として、銀行アプリケーションを例に取ります。この例では、ユーザーをCustomerグループのメンバーとし、次の条件が適用されるとします。

• デフォルトの認可プラグインでは、Customerグループのユーザーであれば、誰でも特定の口座から引出しを行えます。
• カスタマイズした認可プラグインでは、Customerグループのユーザーであれば、誰でも特定の口座から引出しを行えます。ただし、引出しを行えるのは、月曜日から金曜日の午前9時から午後5時までです。
• カスタマイズした2つ目の認可プラグインでは、Customerグループのユーザーであれば、誰でも特定の口座から引出しを行えます。ただし、引き出せるのは、$10,000未満の金額です。

Customerグループのユーザーは、月曜日の午前10時に$500.00を引き出すことはできます。ただし、同じユーザーが、土曜日の午前中に同じ操作を行おうとしてもできません。

このほかにも、様々な状況が考えられます。いろいろな状況を想定し、ビジネス上のニーズに合った最適な状況を定義してください。

1.6.2 認可プラグインのしくみ

認可に関する一部の決定は、認可トークンに格納されているユーザーIDに基づいて行われます。認可トークンは、認証プラグインによって生成されるため、認証プラグインと認可プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。

Oracle Tuxedoシステムのプロセスまたはサーバー(/QサーバーのTMQUEUE(5)またはイベント・ブローカ・サーバーのTMUSREVT(5)など)は、クライアントからのリクエストを受け取ると認可プラグインを呼び出します。これに対し、認可プラグインは、操作前のチェックを行い、操作を許可するかどうかを返します。

• 操作が許可された場合、システムはクライアント・リクエストを実行します。
• 操作が許可されない場合、システムはクライアント・リクエストを実行しません。

クライアント操作が許可されると、Oracle Tuxedoシステムのプロセスまたはサーバーは、クライアント操作が完了した後で認可プラグインを呼び出すことができます。これに対し、認可プラグインは、操作後のチェックを行い、操作の結果を許可するかどうかを返します。

• 許可される場合、システムは操作の結果を受け付けます。
• 許可されない場合、システムは、操作の結果を変更するか、または操作をロールバックし(元に戻し)ます。

これらの呼出しは、アプリケーション・レベルの呼出しではなく、システム・レベルの呼出しです。ATMIアプリケーションは、認可プラグインを呼び出せません。

Oracle Tuxedoシステムに組み込まれているデフォルトの認可プラグインを使用する場合と、カスタマイズした認可プラグインを1つ以上使用する場合では、認可のプロセスが多少異なります。デフォルトのプラグインでは、操作後のチェックをサポートしていません。したがって、デフォルトの認可プラグインが、操作後のチェックを行うリクエストを受け取っても、リクエストはただちに返され、何も実行されません。

カスタマイズしたプラグインでは、操作前と操作後の両方のチェックをサポートしています。

• デフォルトの認可
  
• カスタマイズした認可
  

1.6.2.1 デフォルトの認可

クライアントから操作前のチェックの実行がリクエストされ、それに対してATMIのプロセスによってデフォルトの認可が呼び出されると、認可プラグインは、次のタスクを実行します。

1. 認証プラグインを呼び出して、クライアントの認可トークンから情報を取得します。

   認可トークンは、認証プラグインによって作成されるため、認可プラグインにはトークンの内容が記録されていません。ただし、認可プロセスではこの情報が必要です。

2. 操作前のチェックを実行します。

   認可プラグインは、クライアントの認可トークン、アクセス制御リスト(ACL)、およびATMIアプリケーションのセキュリティ・レベル(ACLの構成(オプションまたは必須))を調べて、操作を許可するかどうかを決めます。

3. 操作を実行するかどうかを決定します。

   認可のファンアウト・プラグインは、デフォルトの認可プラグインの決定(permitまたはdeny)を受け取ると、その決定に従って動作します。

   • クライアント操作が許可された場合、ファンアウト・プラグインは呼出し側のプロセスにpermitを返します。システムはクライアント・リクエストを実行します。
   • クライアント操作が拒否された場合、ファンアウト・プラグインは呼出し側のプロセスにdenyを返します。システムはクライアント・リクエストを実行しません。

1.6.2.2 カスタマイズした認可

カスタマイズした1つ以上の認可プラグインを使用するユーザーは、Oracle Tuxedo製品のATMI環境で提供される別の機能を利用できます。つまり、操作の実行後にさらにチェックを行うことができます。

クライアントから操作前のチェックの実行がリクエストされ、それに対してATMIのプロセスによってカスタマイズした認可が呼び出されると、認可プラグインは、次のタスクを実行します。

1. 認証プラグインを呼び出して、クライアントの認可トークンから情報を取得します。
2. 操作前のチェックを実行します。

   認可プラグインは、操作、クライアントの認可トークン、および関連するデータを調べて、操作を許可するかどうかを決めます。関連するデータには、ユーザー・データおよびATMIアプリケーションのセキュリティ・レベルが含まれます。

   認可プラグインは、認可の要件に合うよう、必要に応じてユーザー・データを変更してから操作を実行します。

3. 操作を実行するかどうかを決定します。

   認可のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(permit、deny、またはabstain)をチェックして、最終的な決定を行います。

   • クライアント操作が許可された場合、ファンアウト・プラグインは呼出し側のプロセスにpermitを返します。システムはクライアント・リクエストを実行します。
   • 操作が拒否された場合、ファンアウト・プラグインは呼出し側のプロセスにdenyを返します。システムはクライアント・リクエストを実行しません。

クライアント操作が許可されると、ATMIのプロセスは、クライアント操作が完了した後でカスタマイズした認可を呼び出すことができます。その場合、認可プラグインは次のタスクを実行します。

1. 認証プラグインを呼び出して、クライアントの認可トークンから情報を取得します。
2. 操作後のチェックを行います。

   認可プラグインは、操作、クライアントの認可トークン、および関連するデータを調べて、操作の結果を許可するかどうかを決めます。関連するデータには、ユーザー・データおよびATMIアプリケーションのセキュリティ・レベルが含まれます。

3. 操作の結果を許可するかどうかを決定します。

   認可のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(permit、deny、またはabstain)をチェックして、最終的な決定を行います。

   • ファンアウト・プラグインは、操作の結果が受け入れ可能と判断した場合、呼出し元プロセスにpermitを返します。システムは操作の結果を受け付けます。
   • 操作が拒否された場合、ファンアウト・プラグインは呼出し側のプロセスにdenyを返します。システムは、操作の結果を変更するか、または操作をロールバックし(元に戻し)ます。

操作後のチェック機能は、ラベル付けされた文書を扱うセキュリティ・モデルで便利です。たとえば、機密文書へのアクセスを許可されたユーザーが、最高機密文書を取り出す操作を実行したとします(通常、文書を識別するラベルの内容は、その文書が取り出されるまでわかりません)。この場合、操作後のチェックにより、操作の拒否または出力データの変更(機密情報の削除)を効率的に行うことができます。

1.6.3 カスタマイズした認可の実装

ATMIアプリケーションで認可機能を実行するには、デフォルトのプラグインを使用するか、または1つ以上のプラグインをカスタマイズします。プラグインを選択するには、すべてのセキュリティ・プラグインを制御するツールである、Oracle Tuxedoレジストリを構成します。

デフォルトの認可プラグインを使用する場合、レジストリを構成する必要はありません。ただし、カスタマイズした認可プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合せてレジストリを構成する必要があります。レジストリの詳細は、「Oracle Tuxedoレジストリの設定」を参照してください。

関連項目:

• デフォルトの認証と認可
• セキュリティ管理のタスク
• 認可の管理
• セキュリティを備えたATMIアプリケーションのプログラミング

1.7 監査

監査とは、操作リクエストとその結果に関する情報を収集、格納、および配布する方法です。監査証跡の記録からは、ATMIアプリケーションのセキュリティ・レベルに違反するアクションを実行したプリンシパルや、そのようなアクションを実行しようとしたプリンシパルを判別できます。また、これらの記録から、試行された操作、失敗した操作、および成功した操作を判別することもできます。

監査方法(情報の収集、処理、保護、および配布の方法)は、監査プラグインによって異なります。

• 監査プラグインのアーキテクチャ
  
• 監査プラグインのしくみ
  
• カスタマイズした監査の実装
  

1.7.1 監査プラグインのアーキテクチャ

ファンアウトとは、様々なプラグインの実装が接続された、アンブレラ(傘)型のプラグインです。次の図に示すように、監査プラグインのインタフェースは、ファンアウトの構成で実装されます。

図1-6 監査プラグインのアーキテクチャ

デフォルトの監査プラグインの実装は、ファンアウト・プラグインとデフォルトの監査プラグインで構成されます。カスタマイズされたプラグインの実装は、ファンアウト・プラグイン、デフォルトの監査プラグイン、および1つ以上のカスタム監査プラグインで構成されます。

ファンアウト・プラグイン・モデルでは、まず、呼出し側がファンアウト・プラグインにリクエストを送信します。受信されたリクエストは、下位のプラグインに渡され、各プラグインからレスポンスが返されます。最後に、ファンアウト・プラグインは、受け取った複数のレスポンスを1つのレスポンスにまとめ(複合レスポンス)、呼出し側に送信します。

監査リクエストの目的は、イベントを記録することです。各監査プラグインは、success (監査が成功し、イベントが記録される)またはfailure (監査は失敗し、イベントは記録されない)のどちらかのレスポンスを返します。監査のファンアウト・プラグインの複合レスポンスは次のようになります。すべてのレスポンスがsuccessの場合、複合レスポンスはsuccessになり、それ以外の場合、複合レスポンスはfailureになります。

デフォルトの監査の場合、複合レスポンスは、デフォルトの監査プラグインによってのみ決まります。カスタマイズした監査の場合、複合レスポンスは、ファンアウト・プラグインの下位プラグインのレスポンスによって決まります。ファンアウト・プラグインの動作については、「認可プラグインのアーキテクチャ」を参照してください。

1.7.2 監査プラグインのしくみ

監査に関する一部の決定は、監査トークンに格納されているユーザーIDに基づいて行われます。監査トークンは、認証プラグインによって生成されるため、認証プラグインと監査プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。

ATMIのシステム・プロセスまたはサーバー(/QサーバーのTMQUEUE(5)またはイベント・ブローカ・サーバーのTMUSREVT(5)など)は、クライアントからのリクエストを受け取ると監査プラグインを呼び出します。監査プラグインは、操作が開始する前に呼び出されるため、操作の実行そのものを記録したり、データを格納することができます。データは、操作後の監査で使用できます。これに対し、監査プラグインは、操作前の監査を実行して、監査が成功したかどうかを返します。

ATMIのシステム・プロセスまたはサーバーは、クライアント操作が実行された後で監査プラグインを呼び出すことができます。これに対し、監査プラグインは、操作後の監査を実行して、監査が成功したかどうかを返します。

さらに、ATMIのシステム・プロセスまたはサーバーは、セキュリティ違反が発生した可能性がある場合、監査プラグインを呼び出すことがあります。(操作前または操作後の認可のチェックが失敗したり、セキュリティに対する攻撃が検出された場合、セキュリティ違反の疑いが生じます。)これに対し、監査プラグインは、操作後の監査を実行して、監査が成功したかどうかを返します。

これらの呼出しは、アプリケーション・レベルの呼出しではなく、システム・レベルの呼出しです。ATMIアプリケーションは、監査プラグインを呼び出せません。

Oracle Tuxedoシステムに組み込まれているデフォルトの監査プラグインを使用する場合と、カスタマイズした監査プラグインを1つ以上使用する場合では、監査のプロセスが多少異なります。デフォルトのプラグインでは、操作前の監査をサポートしていません。したがって、デフォルトの監査プラグインが、操作前の監査を行うリクエストを受け取っても、リクエストはただちに返され、何も実行されません。

カスタマイズしたプラグインでは、操作前と操作後の両方の監査をサポートしています。

• デフォルトの監査
  
• カスタマイズした監査
  

1.7.2.1 デフォルトの監査

デフォルトの監査の実装は、Oracle Tuxedoイベント・ブローカとユーザー・ログ(ULOG)で構成されます。これらのユーティリティは、セキュリティ違反だけをレポートします。試行された操作、失敗した操作、および成功した操作についてはレポートしません。

セキュリティ違反の疑いに対して操作後の監査を実行するため、ATMIプロセスによってデフォルトの監査が呼び出されると、監査プラグインは、次のタスクを実行します。

1. 認証プラグインを呼び出して、クライアントの監査トークンから情報を取得します。

   監査トークンは、認証プラグインによって作成されるため、監査プラグインにはトークンの内容が記録されていません。ただし、監査プロセスではこの情報が必要です。

2. 操作後の監査を行います。

   監査プラグインは、クライアントの監査トークン、および操作後の監査リクエストで配信されたセキュリティ違反を調べます。

3. 操作後の監査が成功したかどうかの結果を発行します。

   監査のファンアウト・プラグインは、デフォルトの監査プラグインからの決定(successまたはfailure)を受け取ると、その決定に従って動作します。

   • successは、操作後の監査が成功したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスにsuccessを返し、セキュリティ違反を記録します。
   • failureは、操作後の監査が失敗したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスにfailureを返します。

1.7.2.2 カスタマイズした監査

カスタマイズした1つ以上の監査プラグインを使用するユーザーは、Oracle Tuxedo製品のATMI環境で提供されるの別の機能を利用できます。つまり、操作の実行前に監査を行うことができます。

クライアントから操作前の監査の実行がリクエストされ、それに対してATMIのプロセスによってカスタマイズした監査が呼び出されると、監査プラグインは、次のタスクを実行します。

1. 認証プラグインを呼び出して、クライアントの監査トークンから情報を取得します。
2. 操作前の監査を行います。

   監査プラグインはクライアントの監査トークンを調べて、そのデータが後で操作後の監査に必要となる場合は、ユーザー・データを格納することができます。

3. 操作前の監査が成功したかどうかの結果を発行します。

   監査のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(successまたはfailure)をチェックして、最終的な決定を行います。

   • 複合レスポンスがsuccessの場合は、操作前の監査が成功したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスにsuccessを返し、クライアントによる操作の試行を記録します。
   • 複合レスポンスがfailureの場合は、操作前の監査が失敗したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスにfailureを返します。

クライアント操作が実行されると、ATMIプロセスは、カスタマイズした監査を呼び出して操作後の監査を実行できます。その場合、監査プラグインは次のタスクを実行します。

1. 認証プラグインを呼び出して、クライアントの監査トークンから情報を取得します。
2. 操作後の監査を行います。

   監査プラグインは、クライアントの監査トークン、操作後の監査リクエストで配信された完了ステータス、および操作前の監査時に格納されたデータを調べます。

3. 操作後の監査が成功したかどうかの結果を発行します。

   監査のファンアウト・プラグインは、下位にある個々のプラグインのレスポンス(successまたはfailure)をチェックして、操作後の監査が成功したか、または失敗したかを決定します。

   • 複合レスポンスがsuccessの場合は、操作後の監査が成功したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスにsuccessを返し、操作が完了したことを示すステータスを記録します。
   • 複合レスポンスがfailureの場合は、操作後の監査が失敗したことを示します。監査のファンアウト・プラグインは、呼出し側のプロセスにfailureを返します。

操作前と操作後の監査を両方通過し、操作自体が成功した場合、その操作は成功したものとみなされます。操作前と操作後の両方の監査データを収集および格納する企業もありますが、これらのデータは大量のディスク領域を消費する可能性があります。

1.7.3 カスタマイズした監査の実装

ATMIアプリケーションで監査機能を実行するには、デフォルトのプラグインを使用するか、または1つ以上のプラグインをカスタマイズします。プラグインを選択するには、すべてのセキュリティ・プラグインを制御するツールである、Oracle Tuxedoレジストリを構成します。

デフォルトの監査プラグインを使用する場合、レジストリを構成する必要はありません。ただし、カスタマイズした認可プラグインを使用する場合は、ブラグインをインストールする前に、プラグインに合せてレジストリを構成する必要があります。

Oracle Tuxedoは、現在Oracle Platform Security Services (OPSS)プラグインをサポートしています。

1.8 リンク・レベルの暗号化

リンク・レベルの暗号化(LLE)は、ATMIアプリケーション内のマシン間をつなぐネットワーク・リンク上で送受信されるメッセージの秘密性を保護します。また、対称キーによる暗号化技術であるRC4を使用します。RC4では、暗号化と復号化の際に同じキーを使用します。

LLEを使用する場合、Oracle Tuxedoシステムは、データを暗号化してからネットワーク・リンク上に送信し、データがネットワーク・リンクを離れると復号化します。システムは、データが通過するすべてのリンクで、この暗号化/復号化プロセスを繰り返します。したがって、LLEはポイント・ツー・ポイント機能と呼ばれます。

LLEは、ATMIアプリケーションの次の種類のリンクで使用できます。

• ワークステーション・クライアントからワークステーション・ハンドラ(WSH)へのリンク
• ブリッジ間のリンク
• 管理ユーティリティ(tmbootまたはtmshutdown)とtlistenとのリンク
• ドメイン・ゲートウェイ間のリンク

LLEセキュリティには3つのレベルがあります:

• 0ビット(暗号化なし)
• 56ビット(国際)
• 128ビット(米国およびカナダ)

国際版のLLEでは、0ビットと56ビットの暗号化が可能です。米国およびカナダ版のLLEでは、0ビット、56ビット、および128ビットの暗号化が可能です。

• LLEのしくみ
  
• 暗号化キー・サイズのネゴシエーション
  
• LLEの旧バージョンとの互換性
  
• 初期化時のWSLおよびWSHの接続タイムアウト
  

1.8.1 LLEのしくみ

LLEの制御パラメータおよび基本となる通信プロトコルは、リンクの種類によって異なります。ただし、次の点では基本的に同じです。

• イニシエータ・プロセスが通信セッションを開始します。
• ターゲット・プロセスは、初期接続を受け取ります。
• 前述の両方のプロセスでは、リンク・レベルの暗号化機能が認識され、次の2つの構成パラメータが設定されます。

最初の構成パラメータは、プロセスが受け入れる暗号化の最低レベルです。これは、0、56、128のいずれかのキー長で指定します。

2番目の構成パラメータは、プロセスがサポートできる暗号化の最高レベルです。これも、0、56、128のいずれかのキー長で指定します。

次の説明では、前述の2つのパラメータを(min, max)の形式で表記します。たとえば、あるプロセスの値が(56, 128)の場合は、56ビットから128ビットまでの暗号化がサポートされることを示します。

1.8.2 暗号化キー・サイズのネゴシエーション

ネットワーク・リンクの両端にある2つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の2段階のステップで確認されます。

1. 各プロセスで、それぞれのmin-max値が確認されます。
2. 両方のプロセスでサポートされる、キーの最大サイズが算出されます。

• min-max値の決定
  
• 共通のキー・サイズの検索
  

1.8.2.1 min-max値の決定

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)を割り当てます。

1.8.2.2 共通のキー・サイズの検索

2つのプロセスのmin-max値が決まると、キー・サイズの調整が開始します。このネゴシエーション・プロセスを暗号化したり、見えないようにする必要はありません。調整されたキー・サイズは、ネットワーク接続が確立されている間は有効です。

次の表は、2つのプロセス間で可能なmin-max値のすべての組合せを調整した結果のキー・サイズを示しています。上段のヘッダー行は、2つのプロセスのうち、片方のプロセスのmin-max値を示しています。左側の列は、もう一方のプロセスのmin-max値を示しています。

表1-3 プロセス間のネゴシエーション結果

	(0, 0)	(0, 56)	(0, 128)	(56, 56)	(56, 128)	(128, 128)
(0, 0)	0	0	0	ERROR	ERROR	ERROR
(0, 56)	0	56	56	56	56	ERROR
(0, 128)	0	56	128	56	128	128
(56, 56)	ERROR	56	56	56	56	ERROR
(56, 128)	ERROR	56	128	56	128	128
(128, 128)	ERROR	ERROR	128	ERROR	128	128

1.8.3 LLEの旧バージョンとの互換性

Oracle TuxedoシステムのATMI環境は、LLEの旧バージョンと互換性があります。

• Oracle Tuxedoリリース6.5との相互運用性
  
• Oracle Tuxedoリリース6.5より前のバージョンとの相互運用性
  

1.8.3.1 Oracle Tuxedoリリース6.5との相互運用性

次の表で、2つのATMIアプリケーションの一方がリリース6.5で実行されていて、もう一方がリリース7.1以降で実行されているときに、合意されるキー・サイズ(存在する場合)を示します。上段のヘッダー行は、リリース7.1以上で動作するプロセスのmin-max値を示しています。左側の列は、リリース6.5で動作するプロセスのmin-max値を示しています。

表1-4 Oracle Tuxedoリリース6.5と相互運用するときのキー・サイズのネゴシエーション結果

	(0,0)	(0,56)	(0,128)	(56,56)	(56,128)	(128,128)
		0	0	ERROR	ERROR	ERROR
		40	40	ERROR	ERROR	ERROR
		40	128	ERROR	128	128
	ERROR	40	40	ERROR	ERROR	ERROR
	ERROR	40	128	ERROR	128	128
	ERROR	ERROR	128	ERROR	128	128

現在のOracle Tuxedoインストールが(0, 56)、(0, 128)、(56, 56)、または(56, 128)に構成されている場合、LLEの最大レベルが40ビットに構成されているリリース6.5のATMIアプリケーションと相互運用させようとすると、ネゴシエーションの結果は必ず56への自動アップグレードになります。

このネゴシエーション結果は、2つのサイトでともにリリース6.5が動作しており、LLEの最高レベルが40ビットに構成されている場合の結果と同じです。どちらの場合も、ネゴシエーションを行うと、56に自動的にアップグレードされます。

1.8.3.2 Oracle Tuxedoリリース6.5より前のバージョンとの相互運用性

次の表で、2つのATMIアプリケーションの一方がリリース6.5よりも前のバージョンで実行されていて、もう一方がリリース7.1以降で実行されているときに、合意されるキー・サイズ(存在する場合)を示します。上段のヘッダー行は、リリース7.1以上で動作するプロセスのmin-max値を示しています。左側の列は、リリース6.5より前のバージョンで動作するプロセスのmin-max値を示しています。

表1-5 Oracle Tuxedoリリース6.5より前のバージョンと相互運用するときのキー・サイズのネゴシエーション結果

	(0,0)	(0,56)	(0,128)	(56,56)	(56,128)	(128,128)
(0,0)	0	0	0	ERROR	ERROR	ERROR
(0,40)	0	56	56	56	56	ERROR
(0,128)	0	56	128	56	128	128
(40,40)	ERROR	56	56	56	56	ERROR
(40,128)	ERROR	56	128	56	128	128
(128,128)	ERROR	ERROR	128	ERROR	128	128

現在の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アプリケーションと相互運用することはできません。共通のキー・サイズを調整しようとしてもできません。

1.8.4 初期化時のWSLおよびWSHの接続タイムアウト

ワークステーション・クライアントが初期化に費やせる時間は制限されています。デフォルトでは、LLEを使用しないATMIアプリケーションでは30秒、LLEを使用するATMIアプリケーションでは60秒に制限されています。この60秒には、暗号化されたリンクを調整する時間も含まれます。ただし、LLEが構成されている場合は、UBBCONFIGファイルのMAXINITTIMEパラメータでワークステーション・リスナー(WSL)のサーバーの値を変更するか、WS_MIB(5) のT_WSLクラスのTA_MAXINITTIME属性の値を変更することによって、この時間制限を変更できます。

関連項目:

• セキュリティ管理のタスク
• リンク・レベルの暗号化の管理
• 『Oracle Tuxedoアプリケーションの設定』のネットワークへのATMIアプリケーションの分散に関する項および分散型のATMIアプリケーション用の構成ファイルの作成に関する項

1.9 TLS暗号化

Oracle Tuxedo製品では、業界標準のTLSプロトコルを使用して、クライアント・アプリケーションとサーバー・アプリケーション間で安全な通信を確立します。TLSプロトコルを使用する場合、プリンシパルはデジタル証明書を使用して、自身のIDをピアに対して証明します。

ノート:

実際に使用されているネットワーク・プロトコルは、TLSプロトコルの後継に当たるTLSです。しかしながらこのドキュメントでは、一般的な用法に従い、このプロトコルをTLS暗号化と呼んでいます。

LLEと同じく、TLSプロトコルをパスワードによる認証で使用すると、クライアント・アプリケーションとOracle Tuxedoドメイン間の通信の機密性と整合性を保護できます。TLSプロトコルをパスワードによる認証で使用する場合、tmloadcfコマンドを入力したときにSEC_PRINCIPAL_NAMEパラメータで定義したIIOPリスナー/ハンドラ(IIOP、ワークステーション、またはJOLT)のパスワードの入力を求められます。

TLSは、ATMIアプリケーション・リンクを次の方法で保護するために使用されます:

• クライアントからサーバー・ハンドラ(IIOP、ワークステーション、またはJOLT)へのリンク
• ブリッジ間のリンク
• 管理ユーティリティ(tmbootまたはtmshutdown)とtlistenとのリンク
• ドメイン・ゲートウェイ間のリンク

使用可能なTLS暗号には、256ビット、128ビットおよび56ビット暗号があります。これについてはこの章で後から説明します。

• TLSプロトコルのしくみ
  
• TLSプロトコルを使用するための要件
  
• TLSバージョンのネゴシエーションおよび構成
  
• 暗号化キー・サイズのネゴシエーション
  
• TLSの旧バージョンとの互換性
  
• 初期化時のWSLおよびWSHの接続タイムアウト
  
• サポートされている暗号スイート
  
• TLSインストール
  

1.9.1 TLSプロトコルのしくみ

TLSプロトコルは次のように機能します:

1. ターゲット・プロセスは、デジタル証明書を開始元アプリケーションに提示します。
2. 開始元アプリケーションは、信頼性のある認証局のリストとターゲット・プロセスのデジタル証明書を照合します。
3. 開始元アプリケーションがターゲット・プロセスのデジタル証明書を検証すると、アプリケーションとターゲット・プロセス間でTLS接続が確立されます。

開始元アプリケーションは、パスワードまたは証明書による認証を使用して、自身をOracle Tuxedoドメインに対して認証します。

次の図に、このTLSプロトコルのしくみを示します。

図1-7 TuxedoアプリケーションでのTLSプロトコルのしくみ

1.9.2 TLSプロトコルを使用するための要件

TLSプロトコルの実装は柔軟性が高いので、ほとんどの公開キーインフラストラクチャに対応します。Tuxedoでは、TLSセキュリティ資格証明を格納するために2つの方法が提供されます:

• Oracle WalletはTuxedo 12cの新機能です。Oracle Walletは、プロセスのための秘密キー、証明書チェーン、信頼性のある証明書を1つのPKCS12ファイルに格納します。このファイルは、Oracleツールや他のセキュリティ・ベンダーのツールを使用して作成できます。
• Tuxedoの以前のリリースで使用されたプラグイン・フレームワークも、セキュリティ資格証明を格納するために使用できます。Oracle Tuxedo製品で使用できるプラグインのデフォルト実装では、デジタル証明書をLDAP対応のディレクトリに格納する必要があります。LDAP対応であれば、どのディレクトリ・サービスでもかまいません。また、Tuxedoアプリケーションで使用するデジタル証明書および秘密キーの取得先の認証局を選択する必要があります。LDAP対応のディレクトリ・サービスおよび認証局を準備してからでないと、TLSプロトコルをTuxedoアプリケーションで使用できません。

1.9.3 TLSバージョンのネゴシエーションおよび構成

Tuxedo12.2.2は、TLS、1.2、1.1および1.0がサポートされていますが、いくつかのTuxedoの以前のリリースでは、TLS1.0のみをサポートしています。TLSサーバーとクライアントの間で安全なネットワーク接続が確立されている場合、使用対象のTLSバージョンがネゴシエーションされます。TLSサーバーとして機能する場合、Tuxedoコンポーネントは常にTLS1.2/1.1/1.0の開始リクエストを受け入れます。TLSクライアントとして機能する場合、Tuxedo 12.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がTLSクライアントとTLSサーバーの両方として機能している場合、TLSクライアント側に指定されているTLSバージョンのみが有効になります。
• Tuxedo 12.2.2マスターマシンが以前のリリースのスレーブマシンにMPモードで接続する場合、tmbootコマンドを実行する前にtlistenをマスターマシンで起動する必要があります。

表1-6 デフォルトのTLSバージョンおよび関連パラメータ

TLSクライアントが次である場合	使用されるデフォルトのTLSバージョンが次である場合	次を使用してTLSバージョンを変更可能
GWTDOMAIN	TLS 1.2	DMCONFIGのTLSバージョン・パラメータ。詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』を参照してください。
WSC	自己適応	環境変数WSNADDR
CORBAクライアント(Tobj_Bootstrap)	TLS 1.2	Tobj_Bootstrapコンストラクタnaddressパラメータまたは環境変数TOBJADDR。詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』を参照してください。
GWWSアウトバウンド	TLS 1.2	SALTデプロイメント・ファイル内のアウトバウンドのエンド・ポイントの新しい属性<TLSversion>。詳細は、「SALTアプリケーションの構成」を参照してください。

1.9.4 暗号化キー・サイズのネゴシエーション

ネットワーク・リンクの両端にある2つのプロセスが通信し合うには、まず、これらのプロセスの暗号化キーのサイズが合っていなければなりません。これは、次の2段階のステップで確認されます。

1. 各プロセスで、それぞれのmin-max値が確認されます。
2. 両方のプロセスでサポートされる、キーの最大サイズが算出されます。

• min-max値の決定
  
• 共通のキー・サイズの検索
  

1.9.4.1 min-max値の決定

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で、構成されている実際のリンク・レベル・セキュリティに従って調整されます。

1.9.4.2 共通のキー・サイズの検索

2つのプロセスのmin-max値が決まると、キー・サイズの調整が開始します。このネゴシエーション・プロセスを暗号化したり、見えないようにする必要はありません。調整されたキー・サイズは、ネットワーク接続が確立されている間は有効です。

次の表は、2つのプロセス間で可能なmin-max値のすべての組合せを調整した結果のキー・サイズを示しています。上段のヘッダー行は、2つのプロセスのうち、片方のプロセスのmin-max値を示しています。左側の列は、もう一方のプロセスのmin-max値を示しています。

表1-7 プロセス間のネゴシエーション結果(112,112)から(112,256)

	(112,112)	(112,128)	(112,256)
(112,112)	112	112	112
(112,128)	112	128	128
(112,256)	112	128	256
(128,128)	ERROR	128	128
(128,256)	ERROR	128	256
(256,256)	ERROR	ERROR	256

表1-8 プロセス間のネゴシエーション結果(128,128)から(256,256)

	(128,128)	(128,256)	(256,256)
(112,112)	ERROR	ERROR	ERROR
(112,128)	128	128	ERROR
(112,256)	128	256	256
(128,128)	128	128	ERROR
(128,256)	128	256	256
(256,256)	ERROR	256	256

1.9.5 TLSの旧バージョンとの互換性

2つのTuxedoプロセスの間でTLSを使用するには、両方のプロセスでTuxedo 10.0以降を実行している必要があります(ただし、『CORBAアプリケーションにおけるセキュリティの使用』で説明されているCORBA TLS機能を使用する場合を除きます)。WSLプロセスとJSLプロセスに非TLSポートとTLSポートの両方を指定し、DMCONFIGファイルの*DM_TDOMAINセクション内の個別のエントリにTLS接続またはLLE接続を指定できます。この方法により、個別のワークステーション・クライアントおよびTuxedoドメインをTuxedo 10にアップグレードするのに合わせ、ワークステーションやドメイン・アプリケーションを徐々にTLSに移行できます。

関連項目:

• MPモード・アプリケーションでは、Tuxedoドメイン内のすべてのマシンをTuxedo 10.0以降にアップグレードするまでは、BRIDGEプロセスとtlistenプロセスの間でTLSを使用することはできません。
• 0ビットTLS暗号(アプリケーション・データの暗号化を行わない)は、Tuxedo 12.1.1よりも前のリリースで許可されていましたが、Tuxedo 12.1.1以降で使用されるOracle NZセキュリティ・レイヤーでは許可されません。

1.9.6 初期化時のWSLおよびWSHの接続タイムアウト

ワークステーション・クライアントが初期化に費やせる時間は制限されています。デフォルトでは、この間隔は60です。この60秒には、暗号化されたリンクを調整する時間も含まれます。ただし、WSLが構成されている場合は、UBBCONFIGファイルのMAXINITTIMEパラメータでワークステーション・リスナー(WSL)のサーバーの値を変更するか、またはWS_MIB(5)のT_WSLクラスのTA_MAXINITTIME属性の値を変更することによって、時間制限を変更できます。

1.9.7 サポートされている暗号スイート

暗号スイートとは、通信の整合性を保護するためのキー暗号アルゴリズム、対称暗号アルゴリズム、およびSecure Hash AlgorithmからなるTLS暗号化方式のことです。たとえば、暗号スイートRSA_WITH_RC4_128_MD5では、キー暗号用にRSA、バルク暗号化用に128ビット・キーのRC4、メッセージ・ダイジェスト用にMD5を使用します。ATMIセキュリティ環境では、次の表の暗号化スイートがサポートされています。

表1-9 ATMIセキュリティ環境でサポートされているSSL/TLS暗号スイート

暗号スイート	キー暗号の種類	対称キーの強度
TLS_RSA_WITH_AES_256_CBC_SHA	RSA	256
TLS_RSA_WITH_AES_128_CBC_SHA	RSA	128
SSL_RSA_WITH_RC4_128_SHA	RSA	128
SSL_RSA_WITH_RC4_128_MD5	RSA	128
SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA	RSA	112
SSL_RSA_WITH_DES_CBC_SHA SSL_DH_anon_WITH_DES_CBS_SHA	RSA	56
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	RSA	40

1.9.8 TLSインストール

TLSは、Tuxedoシステムの標準機能として実現されています。アプリケーションがセキュリティ資格証明の格納にOracle Walletを使用せず、LDAPを使用して証明書を取得する場合、管理者はインストール時にそのLDAPサーバーの名前、LDAPポート番号、LDAPフィルタ・ファイルの場所を用意しておく必要があります(デフォルトのLDAPフィルタ・ファイルの場所$TUXDIR/udataobj/security/bea_ldap_filter.datは、ほとんどのアプリケーションに適しています。)

この情報は、インストール後にepifregedtコマンドを使用して変更できます。

関連項目:

• セキュリティ管理のタスク
• TLS暗号化の管理
• 『Oracle Tuxedoアプリケーションの設定』のネットワークへのATMIアプリケーションの分散に関する項および分散型のATMIアプリケーション用の構成ファイルの作成に関する項
• CORBAアプリケーションにおけるセキュリティの使用

1.10 公開キーによるセキュリティ機能

公開キーによるセキュリティは、エンド・ツー・エンドのデジタル署名およびデータの暗号化を実現する、次の2つの機能を提供します。

• メッセージ・ベースのデジタル署名
• メッセージ・ベースの暗号化

メッセージ・ベースのデジタル署名により、メッセージの受信者は、送信元と送信メッセージの両方を識別し、認証できます。デジタル署名では、送信元と送信メッセージの内容が確実に証明されます。送信メッセージには、送信者の署名が添付されているため、送信者はメッセージを送信した事実を否認することはできません。たとえば、ある人が自分の銀行口座から引出しを行った後で、その処理が別の人によって行われたと主張することはできません。

さらに、メッセージ・ベースの暗号化では、指定した受信者だけがメッセージを復号化できるため、メッセージの機密性が保たれます。

• PKCS-7への準拠
  
• サポートされている公開キーのアルゴリズム
  

1.10.1 PKCS-7への準拠

RSA Laboratoriesを中心とする主要な通信会社のグループによって規定された、非公式でありながら業界では認知されている公開キーソフトウェアの標準があります。これをPKCS (Public-Key Cryptography Standards)と言います。Oracle TuxedoのATMI環境の公開キーソフトウェアは、PKCS-7標準に準拠しています。

PKCS-7は、ハイブリッド型の暗号化システムのアーキテクチャです。つまり、メッセージを暗号化するときは、ランダムなセッション・キーを用いた対称キーのアルゴリズムを使用し、ランダムなセッション・キーを暗号化するときは、公開キーのアルゴリズムを使用します。乱数ジェネレータにより、通信のたびに新しいセッション・キーが作成されます。これで、以前の通信を利用した攻撃を防ぐことができます。

1.10.2 サポートされている公開キーのアルゴリズム

公開キーの基底のアルゴリズムは、いずれもよく知られており、一般に市販されています。ATMIアプリケーションに最も適したアルゴリズムを選択するには、処理速度、セキュリティのレベル、およびライセンスに関する制約を考慮してください。たとえば、米国政府は、外国に輸出できるアルゴリズムを制限しています。

• 公開キーのアルゴリズム
  
• デジタル署名のアルゴリズム
  
• 対称キーのアルゴリズム
  
• メッセージ・ダイジェスト・アルゴリズム
  

1.10.2.1 公開キーのアルゴリズム

Oracle TuxedoのATMI環境の公開キーによるセキュリティでは、RSA、ElGamal、Rabinなど、基盤となるプラグインでサポートされるすべての公開キーのアルゴリズムがサポートされます。(RSAは、RSAアルゴリズムの発明者の頭文字(Rivest、Shamir、Adelman)を取ったものです。)これらのアルゴリズムはすべて、デジタル署名と暗号化に使用できます。

RSAなど、公開キー(または非対称キー)のアルゴリズムは、次の2つのキーの組合せによって実装されます。これらのキーは異なりますが、数学的には関連性があります。

• 公開キー。広範囲にわたって公開されるキーであり、デジタル署名を検証したり、データを理解できない形式に変換するために使用します。
• 秘密キー。秘密に扱われるキーであり、デジタル署名を作成したり、データを元の形式に戻すために使用します。

1.10.2.2 デジタル署名のアルゴリズム

Oracle TuxedoのATMI環境のデジタル署名によるセキュリティでは、RSA、ElGamal、Rabin、Digital Signature Algorithm (DSA)など、基盤となるプラグインでサポートされるすべてのデジタル署名アルゴリズムがサポートされます。DSA以外のすべてのアルゴリズムは、デジタル署名と暗号化に使用できます。DSAは、デジタル署名には使用できますが、暗号化には使用できません。

デジタル署名のアルゴリズムは、単にデジタル署名を実現するための公開キーアルゴリズムです。DSAも公開キーアルゴリズム、つまり、公開-秘密キー・ペアによって実装するアルゴリズムですが、デジタル署名用です。暗号化には適用できません。

1.10.2.3 対称キーのアルゴリズム

公開キー・セキュリティでは、次の3つの対称キー・アルゴリズムをサポートしています。

• DES-CBC (Data Encryption Standard - Cipher Block Chaining)

  DES-CBCは、Cipher Block Chaining (CBC)モードの64ビット・ブロックの暗号文です。56ビット(64ビットの暗号化キーから8パリティ・ビットを引いたもの)のキーを使用し、米国以外の国でも使用できます。

• 2キー形式トリプルDES (Data Encryption Standard)

  2キー形式トリプルDESは、Encrypt-Decrypt-Encrypt (EDE)モードの128ビット・ブロックの暗号です。2つのキーによるTriple DESでは、56ビット(実際には112ビット)のキーを使用します。米国から輸出することは禁止されています。

  現在では、トリプルDESによるDES暗号キーを保護および転送する方式が一般的となっています。つまり、入力データ(この場合にはシングルDESキー)を暗号化し、解読してから、もう一度暗号化します(暗号化 - 復号化 - 暗号化処理)。このうち、2回行われる暗号化では、両方とも同じ暗号キーが使用されます。
• RC2 (Rivest’s Cipher 2)

  RC2は、40 - 128ビットの範囲で、暗号キーのサイズを変更できるブロック暗号です。DESより高速であり、40ビットの暗号キーは輸出できます。米国籍の企業の海外子会社および海外支店であれば、56ビットの暗号キーを使用することができます。ATMIの公開キー・セキュリティ機能では暗号キーの長さを128ビットに制限していますが、米国では実質的に、RC2にはどんな長さのキーを使用することもできます。

Oracle Tuxedoをお使いのお客様は、このアルゴリズムのリストを拡張したり変更することはできません。

対称キー・アルゴリズムでは、同じキーを使用して、メッセージの暗号化と復号化を行います。公開キーによる暗号化システムでは、通信し合う2つのエンティティ間で送信されるメッセージの暗号化に対称キー暗号化を使用します。対称キー暗号は、公開キー暗号より、少なくとも1000倍速く実行されます。

ブロック暗号は、対称キー・アルゴリズムの一種であり、固定長の平文(暗号化されていないテキスト)のブロックを、同じ長さの暗号文(暗号化されたテキスト)のブロックに変換します。この変換は、ランダムに生成されたセッション・キーの値に基づいて行われます。固定長は、ブロック・サイズと呼ばれます。

1.10.2.4 メッセージ・ダイジェスト・アルゴリズム

公開キーによるセキュリティでは、MD5、SHA-1 (Secure Hash Algorithm 1)など、基盤となるプラグインでサポートされるすべてのメッセージ・ダイジェスト・アルゴリズムがサポートされます。MD5とSHA-1は、どちらも有名な一方向のハッシュ・アルゴリズムです。一方向のハッシュ・アルゴリズムでは、メッセージがメッセージ・ダイジェストまたはハッシュ値と呼ばれる固定長の数値文字列に変換されます。

MD5は高速処理可能な128ビット・ハッシュで、32ビット・マシンで使用することを想定しています。SHA-1は、160ビットのハッシュ値を生成する、セキュリティ・レベルの高いアルゴリズムですが、処理速度はMD5よりやや遅くなります。

関連項目:

• メッセージ・ベースのデジタル署名
• メッセージ・ベースの暗号化
• 公開キーの実装
• セキュリティ管理のタスク
• 公開キーセキュリティの管理
• セキュリティを備えたATMIアプリケーションのプログラミング
• データの整合性と機密性を保護するためのセキュリティ・コードの記述方法

1.11 メッセージ・ベースのデジタル署名

メッセージ・ベースのデジタル署名は、メッセージの送信者のIDを証明し、その内容を特定のメッセージ・バッファとバインドすることにより、ATMIのセキュリティを強化します。企業間または企業と一般ユーザーの間で、インターネットを介してデータを送受信するATMIアプリケーションでは、送信側と受信側の両方で認証を行い、送信妨害のない通信を実現することが重要です。これらの条件は、セキュリティ保護されていない社内ネットワークを使用してATMIアプリケーションを導入する場合にも特に重要です。

メッセージ・ベースのデジタル署名では、エンド・ツー・エンドで内容がセキュリティ保護されます。つまり、メッセージ・バッファは、送信プロセスで発信され、受信プロセスで受け取られるまで保護されます。送信中には、一時的なメッセージ・キュー、ディスク・ベース・キュー、システム・プロセスなどの中継ポイントでも保護され、サーバー間のネットワーク・リンクで転送される間も保護されます。

次の図は、エンド・ツー・エンド型のメッセージ・ベースのデジタル署名のしくみを示しています。

図1-8 ATMI PKCS-7のエンド・ツー・エンドのデジタル署名

メッセージ・ベースのデジタル署名では、メッセージのメッセージ・ダイジェストを計算し、次に送信者の秘密キーでメッセージ・ダイジェストを暗号化して、デジタル署名を生成します。受信者は、暗号化されたメッセージ・ダイジェストを署名者の公開キーを使って復号化し、復号化したメッセージ・ダイジェストと、別途計算したメッセージ・ダイジェストを比較することによって、署名を検証します。署名者の公開キーは、署名者の情報に含まれているデジタル証明書から参照するか、または、公開キーの証明をユニークに識別する、発行者識別名および発行者固有のシリアル番号を参照して取得します。

• デジタル証明書
  
• 認証局
  
• 証明書のリポジトリ
  
• 公開キー・インフラストラクチャ
  

1.11.1 デジタル証明書

デジタル証明書は、インターネットなどのネットワーク経由で、個人およびリソースを識別するために使用される電子ファイルです。デジタル証明書は、信頼性のある第三者機関である「認証局」によって認定された個人またはリソースのIDを特定の公開キーに安全な方法でバインドします。公開キーは重複しないため、公開キーからオーナーを特定できます。

デジタル証明書は、特定の公開キーが特定のサブスクライバ(所有者)に属することを検証します。証明書の受信者は、証明書に記載されている公開キーを使用して、その公開キーに対応する秘密キーでデジタル署名が作成されたことを検証します。検証が成功すると、証明書で指定されたサブスクライバが、対応する秘密キーの所有者であること、および、そのサブスクライバによってデジタル署名が作成されたことを、一連の処理で確認できたことになります。

証明書には、次のような様々な情報が含まれています。

• サブスクライバ(所持者、オーナー)の名前、およびサブスクライバをユニークに識別するためのその他のID情報(証明書を使用するWebサーバーのURL、個人の電子メール・アドレスなど)
• サブスクライバの公開キー
• 証明書を発行した認証局の名前
• シリアル番号。
• 証明書の有効期間または存続期間(開始日と終了日を定義)

最も広く知られている証明書の形式は、ITU-T X.509国際規格によって定義された形式です。したがって、X.509準拠のATMIアプリケーションであれば、証明書の読み書きを行えます。Oracle TuxedoのATMI環境の公開キーによるセキュリティ機能では、X.509バージョン3 (X.509v3)準拠の証明書が認識されます。

1.11.2 認証局

証明書は、認証局(CA)によって発行されます。証明書と公開キーの発行対象に対してIDを保証できる、信頼性のある第三者機関または企業は、CAとなることができます。CAは、証明書の作成時に秘密キーを使用して証明書に署名し、デジタル署名を取得します。次に、CAは署名付きの証明書をサブスクライバに返します。証明書とCAの署名の組合せにより、有効な証明書が作成されます。

サブスクライバおよびその他の人が、CAのデジタル署名を検証するには、CAの公開キーを使用します。CAは、そのキーを公開するか、または上位レベルのCAの証明書(下位レベルのCAの公開キーの有効性を証明)を発行して、公開キーを利用可能にします。2つ目の方法を用いると、CAが階層化されます。

暗号化メッセージの受信者が、信頼する上位CAによって署名された証明書を持ち、この証明書にCAの公開キーが含まれている場合は、CAの秘密キーの信頼性を再帰的に高めることができます。この意味で、証明書は、デジタル署名の信頼性を確認する足がかりとなります。つまり、最終的には、いくつかの上位CAの公開キーの信頼性を確認するだけで済みます。一連の証明書を確認することにより、多数のユーザー署名の信頼性を証明できます。

つまり、デジタル署名は通信エンティティのIDを証明しますが、署名の信頼度は、署名を検証するための公開キーを信頼できる、というレベルと同じです。

ノート:

Oracle Tuxedoの公開キー・プラグイン・インタフェースでは、ユーザーはCAを自由に選択できます。

1.11.3 証明書のリポジトリ

検証での公開キーの使用を促進するため、デジタル証明書をリポジトリに公開するか、別の方法で利用しやすくすることができます。リポジトリは、証明書およびその他の情報で構成されるデータベースであり、リポジトリ内の情報は、取得したり、デジタル署名を検証するために使用できます。必要に応じて検証プログラムでリポジトリ内の証明書をリクエストすることで、自動的に取得を行うことができます。

1.11.4 公開キー・インフラストラクチャ

公開キー・インフラストラクチャは、公開キー暗号のアプリケーションをサポートするプロトコル、サービス、および標準で構成されます。PKIは比較的新しい技術であるため、定義はあいまいです。たとえば、単に、公開キー証明書に基づいた、信頼性を示す階層構造を指す場合があります。また、別のコンテキストでは、エンド・ユーザー用アプリケーションのデジタル署名および暗号化サービスを意味する場合もあります。

公開キーインフラストラクチャを規定する単一の標準はありませんが、標準の策定を進める動きはあります。現時点では、標準が策定されるかどうか、または様々な相互運用レベルのPKIが複数誕生するかどうかは不明です。この意味で、PKIテクノロジの現状は、インターネットによる広範囲の接続が可能になるまでの、1980年代のLANおよびWANのテクノロジに似ているといえます。

PKIには、次のようなサービスがあります。

• キー登録。公開キーの新しい証明書を発行します。
• 証明書の取消し。すでに発行した証明書を取り消します。
• キー選択。パーティの公開キーを取得します。
• 信頼性の評価。証明書の有効性、および証明書で認可される操作を決定します。

次の図に、このPKI処理の流れを示します。

図1-9 PKIの処理の流れ

1. サブスクライバは、認証局(CA)にデジタル証明を申し込みます。
2. CAは、サブスクライバのIDを検証し、デジタル証明書を発行します。
3. CAは、リポジトリに証明書を公開します。
4. サブスクライバは、秘密キーで電子メッセージにデジタル署名して、送信者が認証済であること、メッセージが完全であること、およびメッセージを否認できないことを確認します。その後、メッセージを受信者に送信します。
5. 受信者は、メッセージを受信すると、サブスクライバの公開キーでデジタル署名を検証し、リポジトリでサブスクライバの証明書のステータスと有効性をチェックします。
6. サブスクライバの証明書に関するステータス・チェックの結果が、リポジトリから受信者に返されます。

ノート:

Oracle Tuxedoでは、選択したベンダーのPKIソフトウェアに基づいたPKIセキュリティ・ソリューションを、Oracle Tuxedoの公開キー・プラグイン・インタフェースを介して利用できます。

関連項目:

• 公開キーの実装
• セキュリティ管理のタスク
• 公開キーセキュリティの管理
• セキュリティを備えたATMIアプリケーションのプログラミング
• データの整合性と機密性を保護するためのセキュリティ・コードの記述方法

1.12 メッセージ・ベースの暗号化

メッセージ・ベースの暗号化では、データが秘密に扱われます。これは、企業間または企業と一般ユーザーの間で、インターネットを介してデータを送受信するATMIアプリケーションでは重要です。データの秘密性は、セキュリティ保護されていない社内ネットワークを使用してATMIアプリケーションを導入する場合にも特に重要です。

メッセージ・ベースの暗号化では、メッセージが意味のわからない状態に変換され、内容を変更しようとしてもできないため、メッセージの整合性が保たれます。

メッセージ・ベースの暗号化では、エンド・ツー・エンドで内容がセキュリティ保護されます。つまり、メッセージ・バッファは、送信プロセスで発信され、受信プロセスで受け取られるまで保護されます。送信中には、一時的なメッセージ・キュー、ディスク・ベース・キュー、システム・プロセスなどの中継ポイントでも保護され、サーバー間のネットワーク・リンクで転送される間も保護されます。

次の図は、エンド・ツー・エンド型のメッセージ・ベースの暗号化のしくみを示しています。

図1-10 ATMI PKCS-7のエンド・ツー・エンドの暗号化

メッセージは、対称キー・アルゴリズムとセッション・キーによって暗号化されます。次に、セッション・キーが受信者の公開キーによって暗号化されます。さらに、受信者は、受信者の秘密キーを使用して、暗号化されたセッション・キーを復号化します。最後に、受信者は、セッション・キーを使用して暗号化されたメッセージを復号化し、メッセージ内容を取得します。

ノート:

次の図では、このプロセスの他の2つのステップが示されていません。(1)メッセージを暗号化する直前のデータの圧縮、および(2)メッセージを復号化した直後のデータの解凍です。

暗号化は、ATMIのメッセージ・バッファ単位で行われます。したがって、メッセージ・ベースの暗号化は、既存のATMIのプログラミング・インタフェースおよび通信パラダイムと互換性があります。暗号化のプロセスは、単一のマシン内にある2つのプロセス間で送受信されるメッセージに対して行われる場合も、2つのマシン間でネットワークを介して送受信されるメッセージに対して行われる場合も同じです。

関連項目:

• 公開キーの実装
• セキュリティ管理のタスク
• 公開キーセキュリティの管理
• セキュリティを備えたATMIアプリケーションのプログラミング
• データの整合性と機密性を保護するためのセキュリティ・コードの記述方法

1.13 公開キーの実装

公開キーセキュリティのベースとなるプラグイン・インタフェースは、6つのコンポーネント・インタフェースから成り、それぞれのコンポーネントは、1つ以上のプラグインを必要とします。これらのインタフェースを好みのプラグインでインスタンス化すれば、メッセージ・ベースのカスタム・デジタル署名とメッセージ・ベースの暗号化をATMIアプリケーションに持ち込むことができます。

6つのコンポーネント・インタフェースを次に示します。

• 公開キーの初期化
• キーの管理
• 証明書のルックアップ
• 証明書の解析
• 証明書の検証
• 証明資料のマッピング

• 公開キーの初期化
  
• キーの管理
  
• 証明書のルックアップ
  
• 証明書の解析
  
• 証明書の検証
  
• 証明資料のマッピング
  
• カスタマイズした公開キーの実装
  
• デフォルトの公開キーの実装
  

1.13.1 公開キーの初期化

公開キーの初期化インタフェースによって、公開キー・ソフトウェアは、公開キーと秘密キーを開くことができます。たとえば、ゲートウェイ・プロセスでは、メッセージを復号化してから転送するために、特定の秘密キーへのアクセスが必要なこともあります。このインタフェースは、ファンアウトとして実装されます。

1.13.2 キーの管理

キー管理インタフェースによって、公開キー・ソフトウェアは、公開キーと秘密キーを管理および使用することができます。なお、メッセージ・ダイジェストとセッション・キーは、このインタフェースを使用して暗号化および復号化されますが、公開キー暗号を使用するバルク・データの暗号化は行われません。バルク・データの暗号化は、対称キー暗号を使用して行われます。

1.13.3 証明書のルックアップ

証明ルックアップ・インタフェースによって、公開キーソフトウェアは、所定のプリンシパルに対するX.509v3証明書を取得できます。プリンシパルは認証されたユーザーです。証明書データベースは、Lightweight Directory Access Protocol (LDAP)、Microsoft Active Directory、Netware Directory Service (NDS)、またはローカル・ファイルなど、適切なツールを使用して格納することができます。

1.13.4 証明書の解析

証明書解析インタフェースによって、公開キーソフトウェアは、簡単なプリンシパル名とX.509v3証明書を関連付けることができます。パーサーは、証明書を解析して、証明書に関連付けるプリンシパル名を生成します。

1.13.5 証明書の検証

証明書検証インタフェースによって、公開キーソフトウェアは、特定のビジネス・ロジックに基づいてX.509v3証明書を検証することができます。このインタフェースはファンアウトとして実装されているため、Oracle Tuxedoのユーザーは、自分自身のビジネス・ルールを使用して証明書の有効性を判定できます。

1.13.6 証明資料のマッピング

証明資料のマッピング・インタフェースによって、公開キー・ソフトウェアは、キーを開くために必要な証明資料へのアクセス、認可トークンの提供、および監査トークンの提供を行うことができます。

1.13.7 カスタマイズした公開キーの実装

ATMIアプリケーションに公開キーセキュリティを提供するには、カスタム・プラグインを使用します。プラグインを選択するには、すべてのセキュリティ・プラグインを制御するツールである、Oracle Tuxedoレジストリを構成します。

カスタム公開キープラグインを使用する場合は、公開キープラグイン用のレジストリを構成してから、それらのプラグインをインストールする必要があります。レジストリの詳細は、「Oracle Tuxedoレジストリの設定」を参照してください。

1.13.8 デフォルトの公開キーの実装

デフォルト公開キーの実装では、次のアルゴリズムをサポートしています。

• 公開キーアルゴリズム: RSA
• デジタル署名アルゴリズム: RSAおよびDSA
• 対称キー・アルゴリズム:
  • DES-CBC
  • 2つのキーによるTriple-DES
  • RC2
• メッセージ・ダイジェスト・アルゴリズム:
  • MD5
  • SHA-1

関連項目:

• 公開キーの実装
• セキュリティ管理のタスク
• 公開キーセキュリティの管理
• セキュリティを備えたATMIアプリケーションのプログラミング
• データの整合性と機密性を保護するためのセキュリティ・コードの記述方法

1.14 デフォルトの認証と認可

Oracle TuxedoシステムのATMI環境に用意されている、デフォルトの認証および認可のプラグインは、Oracle Tuxedoで最初に実現された、従来のOracle Tuxedoの認証および認可の実装と同じように機能します。

アプリケーション管理者は、デフォルトの認証および認可のプラグインを使用して、5つのうち、1つのセキュリティ・レベルをATMIアプリケーションに構成できます。5つのレベルには次が含まれます:

• 認証なし
• アプリケーション・パスワードによるセキュリティ
• ユーザー・レベルの認証
• オプションのアクセス制御リスト(ACL)
• 必須のアクセス制御リスト(ACL)

最も低いセキュリティ・レベルでは、認証は行われません。最も高いセキュリティ・レベルでは、アクセス制御リストの機能により、サービスを実行し、イベントをポストし、アプリケーション・キューのメッセージをキューに登録(または登録解除)するユーザーが決定されます。次の表は、セキュリティ・レベルを簡単にまとめたものです:

表1-10 デフォルトの認証と認可のセキュリティ・レベル

セキュリティ・レベル	説明
認証なし	ATMIアプリケーションに参加する前にクライアントを検証する必要はありません。このセキュリティ・レベルでATMIアプリケーションに参加すると、ユーザーはすべてのアプリケーション・リソースにアクセスできます。
アプリケーション・パスワード	アプリケーション管理者は、ATMIアプリケーション全体に対して1つのパスワードを定義します。クライアントがアプリケーションに参加するには、パスワードを提示しなければなりません。このセキュリティ・レベルでATMIアプリケーションに参加できると、ユーザーはすべてのアプリケーション・リソースにアクセスできます。
ユーザー・レベルの認証	ATMIアプリケーションに参加するには、各クライアントは、アプリケーション・パスワードのほか、有効なユーザー名とユーザー固有のデータ(パスワードなど)を提示しなければなりません。このセキュリティ・レベルでATMIアプリケーションに参加できると、ユーザーはすべてのアプリケーション・リソースにアクセスできます。
オプションのアクセス制御リスト(ACL)	クライアントは、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。このセキュリティ・レベルでATMIアプリケーションに参加すると、ユーザーによるアプリケーション・リソースへのアクセスは制限されます。つまり、ACLデータベースに格納されているアプリケーション・リソースのリストにより、各リソースを使用できるユーザーが制限されます。特定のリソースのリストに含まれていないユーザーは、オプションのACLまたは必須のACLが使用されていても、そのリソースにはアクセスできません。ATMIアプリケーションのセキュリティ・レベルが「オプションのACL」に設定されている場合、ACLデータベースにエントリがないリソースには、誰でもアクセスできます。
必須のアクセス制御リスト(ACL)	クライアントは、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。このセキュリティ・レベルでATMIアプリケーションに参加すると、ユーザーによるアプリケーション・リソースへのアクセスは制限されます。つまり、ACLデータベースに格納されているアプリケーション・リソースのリストにより、各リソースを使用できるユーザーが制限されます。特定のリソースのリストに含まれていないユーザーは、オプションのACLまたは必須のACLが使用されていても、そのリソースにはアクセスできません。ATMIアプリケーションのセキュリティ・レベルが「必須のACL」に設定されている場合、ACLデータベースにエントリがないリソースには、どのユーザーもアクセスできません。

ノート:

クライアントという用語はクライアント・プロセスと同義であり、実行中のクライアント・プログラムの特定のインスタンスを意味します。ATMIクライアント・プログラムは、任意の数の個別インスタンスのアクティブ・メモリー内に存在することができます。

アプリケーション管理者は、UBBCONFIG構成ファイルのSECURITYパラメータに適切な値を設定することにより、セキュリティ・レベルを指定できます。

セキュリティ・レベル	SECURITYパラメータに設定する値
認証なし	NONE
アプリケーション・パスワードによるセキュリティ	APP_PW
ユーザー・レベルの認証	USER_AUTH
オプションのアクセス制御リスト(ACL)	ACL
必須のアクセス制御リスト(ACL)	MANDATORY_ACL

デフォルトはNONEです。SECURITYにUSER_AUTH、ACL、またはMANDATORY_ACLを設定した場合、アプリケーション管理者は、システム側で提供されるAUTHSVRという名前の認証サーバーを構成しなければなりません。AUTHSVRは、ユーザー単位で認証を行います。

アプリケーション開発者は、AUTHSVRを、ATMIアプリケーションに固有のロジックを持つ認証サーバーに置き換えることができます。たとえば、広く使用されているKerberosのメカニズムを使用して認証を行うため、認証サーバーをカスタマイズすることもできます。

• クライアントの名前付け
  
• ユーザー、グループ、およびACLのファイル
  
• 省略可能なACLと必須のACL
  

1.14.1 クライアントの名前付け

クライアント・プロセスは、ATMIアプリケーションに参加すると、ユーザー・クライアント名(ユーザーとクライアントを組み合せた名前)およびアプリケーション・キー (ユニークなクライアント識別子)を持ちます。

• ユーザー・クライアント名は、ユーザー名とクライアント名で構成され、セキュリティ、管理、および通信に使用されます。
• アプリケーション・キーは32ビット値であり、クライアントのかわりに呼び出され、アクセス制御のチェック機能で使用されます。

2つのクライアント名tpsysadmおよびtpsysopが、特殊なセマンティクス用に用意されています。tpsysadmはアプリケーション管理者として扱われ、tpsysopはアプリケーション・オペレータとして扱われます。

• ユーザー/クライアント名
  
• アプリケーション・キー
  

1.14.1.1 ユーザー/クライアント名

認証されたクライアントは、ATMIアプリケーションに参加すると、ユーザー名とクライアント名をTPINITバッファのtpinit(3c)に渡すか(アプリケーションがCで記述されている場合)、または、TPINFDEF-RECレコードのTPINITIALIZE(3cbl)に渡します(アプリケーションがCOBOLで記述されている場合)。次の表では、ユーザー名とクライアント名、および、TPINITバッファまたはTPINFDEF-RECレコード内のその他のセキュリティ関連フィールドを説明します:

表1-11 TPINITバッファおよびTPINFDEF-RECレコードのセキュリティ関連フィールド

TPINIT	TPINFDEF-REC	説明
usrname	USRNAME	30文字までの文字列で構成するユーザー名。USER_AUTH、ACL、またはMANDATORY_ACLのセキュリティ・レベルには必須です。ユーザー名は呼出し側を表します。
cltname	CLTNAME	30文字までの文字列で構成するクライアント名。USER_AUTH、ACL、またはMANDATORY_ACLのセキュリティ・レベルには必須です。クライアント名はクライアント・プログラムを表します。
passwd	PASSWD	アプリケーション・パスワード。APP_PW、USER_AUTH、ACL、またはMANDATORY_ACLのセキュリティ・レベルには必須です。tpinit()またはTPINITIALIZE()は、このパスワードをTUXCONFIG ファイル*に格納された構成済のアプリケーション・パスワードと比較して検証します。
datalen	DATALEN	後に続くユーザー固有のデータ**の長さ。
data	N/A	ユーザー固有のデータ**。USER_AUTH、ACL、またはMANDATORY_ACLのセキュリティ・レベルには必須です。tpinit()またはTPINITIALIZE()は、ユーザー固有のデータを認証サーバーに転送し、検証します。認証サーバーはAUTHSVRです。
*バイナリ形式のUBBCONFIGファイル。**通常、ユーザー・パスワード。

認証されたセキュリティ・レベル(USER_AUTH、ACL、またはMANDATORY_ACL)では、ユーザー名、クライアント名、およびユーザー固有のデータは、Oracle Tuxedoシステムで変換されることなくAUTHSVRに転送されます。これらの情報が変換されるとすれば、ワークステーション・クライアントからネットワーク経由で送信されるときに暗号化が行われる場合のみです。

1.14.1.2 アプリケーション・キー

クライアントがATMIアプリケーションに参加するたびに、Oracle Tuxedoシステムはクライアントに32ビットのアプリケーション・キーを割り当てます。クライアントは、アプリケーションとの関連付けを解除し、別のユーザーとしてATMIアプリケーションに参加しないかぎり、このアプリケーション・キーをリセットできません。

割り当てられたアプリケーション・キーは、クライアントのセキュリティ資格証明です。クライアントは、TPSVCINFO構造体の一部として、すべてのサービス呼出しにappkeyフィールドを指定します。TPSVCINFOの詳細は、『Oracle Tuxedo ATMI C関数リファレンス』のtpservice(3c)を参照してください。

次の表に、様々なセキュリティ・レベルとクライアントでアプリケーション・キーがどのように設定されるかを示します。アプリケーション・キーの割当ては、最後の項目を除き、すべてハードコーディングされます。

表1-12 アプリケーション・キーの割当て

セキュリティ・レベル	メッセージのタイプ	割り当てられるアプリケーション・キー
任意のセキュリティ・レベル	管理者(tmadmin(1)など)が起動する、ATMIのネイティブATMIクライアントからのメッセージ	0x80000000 (管理者のアプリケーション・キー)
NONEまたはAPP_PW	tpsysadmというクライアント名でtpinit()またはTPINITIALIZE()を呼び出し、管理者によって実行されるネイティブATMIクライアントからのメッセージ	0x80000000 (管理者のアプリケーション・キー)
	tpsysopというクライアント名でtpinit()またはTPINITIALIZE()を呼び出し、管理者によって実行されるネイティブATMIクライアントからのメッセージ	0xC0000000 (オペレータのアプリケーション・キー)
	tpsysadmおよびtpsysop以外の任意のATMIクライアントからのメッセージ	-1
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ビットのuser identifier (UID)および次の上位14ビットのgroup identifier (GID)です。残りの上位ビットは0です。AUTHSVRは、このアプリケーション・キーの値を返します。

さらに、Cプログラムのtpsvrinit(3c)またはtpsvrdone(3c) (COBOLではTPSVRINIT(3cbl)またはTPSVRDONE(3cbl))から発信されるメッセージには、管理者のアプリケーション・キーである0x80000000が割り当てられます。クライアントのアプリケーション・キーは、クライアント側で発生し、サーバーに渡されるメッセージに割り当てられます。この規則の例外については、「クライアント・トークンとサーバー・トークンの交換」を参照してください。

ユーザー識別子(UID)は、特定のユーザーを示すため、アプリケーション側で使用される識別子であり、0 - 128Kの整数で表されます。グループ識別子(GID)は、アプリケーション・グループを示すため、アプリケーション側で使用される識別子であり、0 - 16Kの整数で表されます。

1.14.2 ユーザー、グループ、およびACLのファイル

アクセス制御機能を使用するため、アプリケーション管理者は、(1)ユーザー、(2)グループ、および(3)グループとアプリケーション・エンティティ(サービス、イベント、およびアプリケーション・キューなど)のマッピング・リストを管理する必要があります。3つ目のアプリケーション・エンティティへのグループのマッピング・リストは、アクセス制御リスト(ACL)と呼ばれます。

クライアントがサービスなどのアプリケーション・リソースに対してアクセスを試みると、システム側では、クライアントのアプリケーション・キーをチェックし、ユーザーが属するグループを識別します。次に、システムは、ACLにあるターゲット・リソースをチェックし、そのリソースに対するアクセス権がクライアントのグループに付与されているかどうかを判別します。アプリケーション管理者、アプリケーション・オペレータ、およびアプリケーション管理者またはオペレータの権限で実行中のプロセスやサービス・リクエストは、ACLによるパーミッションのチェックの対象にはなりません。

ユーザー、グループ、およびACLのファイルは、application_rootディレクトリに置かれています。application _rootは、APPDIR変数に定義された最初のパス名です。次の図は、これらのファイルと、各リストを制御するための管理コマンドを示しています。

図1-11 デフォルトのユーザー、グループ、およびACLのファイル

ノート:

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リソースへのアクセスを希望するユーザーを認証します。

1.14.3 省略可能なACLと必須のACL

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アプリケーションのプログラミング
• ATMIアプリケーションにクライアント・プログラムを参加させるためのセキュリティ・コードの記述方法
• 『Oracle Tuxedoアプリケーションの設定』の「構成ファイルについて」および「構成ファイルの作成」
• 『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)に関する項
• 『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のAUTHSVR(5)に関する項

1.15 セキュリティの相互運用性

ATMIアプリケーションをOracle Tuxedoリリース7.1より前(6.5以前)のOracle Tuxedoソフトウェアと相互運用させる場合、アプリケーションの開発者および管理者は、いくつかのセキュリティに関する問題を認識しておく必要があります。

ここで定義する相互運用性とは、現在のリリースのOracle Tuxedoソフトウェアが、以前のリリースのOracle Tuxedoソフトウェアとネットワーク経由で通信する機能のことです。具体的には、「ドメイン間の相互運用性」と「ドメイン内の相互運用性」があり、それぞれ次のことを意味します。

• ドメイン間の相互運用性

  1つのATMIアプリケーションでOracle Tuxedoリリース7.1以降のソフトウェアを実行し、別のATMIアプリケーションでOracle Tuxedoのリリース7.1より前のソフトウェアを実行します。

  図1-12 ドメイン間の相互運用性

  
  

  

  
  
• ドメイン内の相互運用性

  複数マシンATMIアプリケーションの1つのマシンでOracle Tuxedoリリース7.1以降のソフトウェアを実行し、同じアプリケーションの別のマシンでOracle Tuxedoのリリース7.1より前のソフトウェアを実行します。

  図1-13 ドメイン内の相互運用性

  
  

  

  
  

• 7.1より前のリリースのソフトウェアとの相互運用性
  
• リンク・レベルの暗号化の相互運用性
  
• TLS暗号化の相互運用性
  
• 公開キーによるセキュリティ機能の相互運用性
  

1.15.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を使用するときの認証と認可に関するセキュリティ問題については、「相互運用性のポリシーの指定」を参照してください。

1.15.2 リンク・レベルの暗号化の相互運用性

Oracle Tuxedoソフトウェアを実行するマシン間でネットワーク・リンクが確立されると、リンク・レベルの暗号化を使用してデータを暗号化してからネットワーク・リンク経由で送信し、データがネットワーク・リンクを離れると復号化することができます。ただし、リンク・レベルの暗号化は、送信側と受信側の両方のマシンの両方にLLEがインストールされている場合にのみ使用できます。

LLEとOracle Tuxedoリリース7.1より前のソフトウェアとの相互運用性については、「LLEの旧バージョンとの互換性」を参照してください。

1.15.3 TLS暗号化の相互運用性

Oracle Tuxedoソフトウェアを実行しているマシン間のネットワーク・リンクでTLS暗号化を使用できるのは、両方のマシンでTuxedo 10.0以降を実行している場合のみです。LLE暗号化は、それ以前のバージョンのTuxedoを実行しているマシン間のネットワーク・リンクでも使用できます。

ノート:

TLS暗号化の相互運用性規則には1つだけ例外があります。『CORBAアプリケーションにおけるセキュリティの使用』で説明されているCORBA関連のTLS機能は、Tuxedo 8.0以上との相互運用および以前のWLE製品との相互運用に使用できます。

1.15.4 公開キーによるセキュリティ機能の相互運用性

次の表に示されている公開キーによるセキュリティに関する相互運用性の規則は、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は、デジタル署名を検証してから削除します。

関連項目:

• セキュリティ機能の互換性
• 相互運用性のポリシーの指定
• デジタル署名ポリシーの設定
• 暗号化ポリシーの設定

1.16 セキュリティ機能の互換性

Oracle Tuxedoリリース7.1以上のソフトウェアを実行するATMIアプリケーションでは、デフォルトまたはカスタマイズした認証、認可、監査、および公開キーセキュリティを自由に組み合せることができます。さらに、これらの4つのセキュリティ機能の任意の組合せは、リンク・レベルの暗号化とも互換性があります。

• デフォルトまたはカスタマイズした認証と認可の組合せ
  
• デフォルトまたはカスタマイズした認証と監査の組合せ
  
• 公開キーによるセキュリティ機能の互換性の問題
  

1.16.1 デフォルトまたはカスタマイズした認証と認可の組合せ

認可セキュリティ・トークンに少なくとも(1)認証されたユーザー名またはプリンシパル名、および(2)アプリケーション・キーの値(「アプリケーション・キー」で定義)が必要であるという制約がアプリケーション開発者側で認識されていれば、デフォルトの認証とカスタマイズした認可、またはカスタマイズした認証とデフォルトの認可を組み合せて使用できます。

認可に関する一部の決定は、認可トークンに格納されているユーザーIDに基づいて行われます。認可トークンは、認証プラグインによって生成されるため、認証プラグインと認可プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。詳細は、「認証」および「認可」を参照してください。

1.16.2 デフォルトまたはカスタマイズした認証と監査の組合せ

監査セキュリティ・トークンに少なくとも(1)認証されたユーザー名またはプリンシパル名、および(2)アプリケーション・キーの値(「アプリケーション・キー」で定義)が必要であるという制約がアプリケーション開発者側で認識されていれば、デフォルトの認証とカスタマイズした監査、またはカスタマイズした認証とデフォルトの監査を組み合せて使用できます。

監査に関する一部の決定は、監査トークンに格納されているユーザーIDに基づいて行われます。監査トークンは、認証プラグインによって生成されるため、認証プラグインと監査プラグインのプロバイダは、これらのプラグインが協調動作することを保証する必要があります。詳細は、「認証」および「監査」を参照してください。

1.16.3 公開キーによるセキュリティ機能の互換性の問題

公開キーによるセキュリティは、Oracle Tuxedoリリース7.1以上のソフトウェアでサポートされる、圧縮機能以外のすべての機能やプロセスと互換性があります。暗号化されたメッセージ・バッファは、圧縮機能を使用しても圧縮できません。ただし、公開キーによるソフトウェアでは、メッセージ・バッファを暗号化する前に内容が圧縮されるため、ある程度サイズを節約できます。

この項では、公開キーによるセキュリティと、次のATMI機能またはプロセスとの互換性および相互運用性について説明します。

• データ依存型ルーティング
• スレッド
• イベント・ブローカ
• /Q
• トランザクション
• ドメイン・ゲートウェイ(GWTDOMAINs)
• その他のベンダーのゲートウェイ

• データ依存型ルーティングとの互換性および相互運用性
  
• スレッドとの互換性および相互運用性
  
• イベント・ブローカとの互換性および相互運用性
  
• /Qとの互換性および相互運用性
  
• トランザクションとの互換性および相互運用性
  
• ドメイン・ゲートウェイとの互換性および相互運用性
  
• ほかのベンダーのゲートウェイとの互換性および相互運用性
  

1.16.3.1 データ依存型ルーティングとの互換性および相互運用性

データ依存型ルーティング機能の中心となるのは、プロセスが、受信したメッセージ・バッファの内容を調べることです。受信したメッセージ・バッファが暗号化されている場合、データ依存型ルーティング用に構成されたプロセスでは、受信者の秘密キーを開き、公開キー・ソフトウェアがそのキーを使用してメッセージ・バッファを復号化できるようにしておく必要があります。データ依存型ルーティングでは、公開キーソフトウェアは、デジタル署名を検証しません。

復号化キーを使用できない場合、ルーティング操作は失敗します。システムからuserlog(3c)エラー・メッセージが返され、操作が失敗したことがレポートされます。

復号化キーを使用できる場合、プロセスは、暗号化されたメッセージ・バッファを復号化したコピーに基づいて、ルーティングに関する決定を行います。次の手順で実行されます。

1. 公開キー・ソフトウェアは、暗号化されたメッセージ・バッファのコピーを作成し、復号化キーを使用してそのバッファを復号化します。
2. プロセスは、これによって得られた平文(暗号化されていないテキスト)のメッセージ内容を読み取り、ルーティングに関する決定を行います。
3. 公開キーソフトウェアは、プライバシを保護するため、平文のメッセージ内容をゼロ値で上書きします。

その後、システムは、ルーティングに関する決定に基づいて、元の暗号化されたメッセージ・バッファを送信します。

1.16.3.2 スレッドとの互換性および相互運用性

公開キーと秘密キーは、ハンドルを介して表現および操作されます。ハンドルには、それに関連付けられたデータがあります。公開キーのアプリケーション・プログラミング・インタフェース(API)では、ハンドルのデータを使用することにより、ハンドルで指定される項目の検索やアクセスを行います。プロセスは、デジタル署名の生成、メッセージの暗号化、およびメッセージの復号化のために、キー・ハンドルを開きます。

キー・ハンドルはプロセスのリソースです。特定のスレッドやコンテキストにバインドされることはありません。キーを開くために必要な通信はいずれも、スレッドで現在アクティブなコンテキストの内部で実行されます。その後は、コンテキストが同じATMIアプリケーションに関連付けられているかどうかとは無関係に、プロセス内のどのコンテキストでもそのキーを使用できます。

キーの内部データ構造はスレッド・セーフです。つまり、複数のスレッドが1つのキーに同時にアクセスできます。

1.16.3.3 イベント・ブローカとの互換性および相互運用性

一般に、TMUSREVT(5)システム・サーバーは、暗号化されたメッセージ・バッファを復号化しないで処理します。つまり、メッセージがOracle Tuxedoのイベント・ブローカ・コンポーネントを通過しても、デジタル署名と暗号化エンベロープは何の影響も受けません。ただし、次の場合、イベント・ブローカ・コンポーネントは、ポストされたメッセージ・バッファを復号化する必要があります。

• メッセージの内容に基づいてサブスクリプションのフィルタ式を評価する場合

  イベント・ブローカが適切な復号化キーにアクセスできない場合、そのサブスクリプションのフィルタ式はfalseとみなされ、サブスクリプションは不一致とみなされます。

• メッセージの内容へのアクセスが必要な、サブスクリプションの通知アクション(userlog(3c)プロセスまたはシステム・コマンド)を実行する場合

  イベント・ブローカが適切な復号化キーにアクセスできない場合、そのサブスクリプションの通知アクションは失敗し、システムからはuserlog(3c)エラー・メッセージが返されて、処理が失敗したことがレポートされます。

• システム構成に基づき、データ依存型ルーティング用のメッセージ内容にアクセスする、サブスクリプションの通知アクションを実行する場合

  イベント・ブローカが適切な復号化キーにアクセスできない場合、そのサブスクリプションの通知アクションは失敗し、システムからはuserlog(3c)エラー・メッセージが返されて、処理が失敗したことがレポートされます。

  トランザクション型のサブスクリプションの場合、トランザクションは「ロールバックのみ」とマーキングされます。

• 暗号化を必要とする管理システムのポリシーに準拠する場合(「暗号化ポリシーの設定」を参照)。

  イベント・ブローカが適切な復号化キーにアクセスできない場合、tppost(3c)操作は失敗し、システムからはuserlog(3c)エラー・メッセージが返されて、処理が失敗したことがレポートされます。

• デジタル署名を必要とする管理システムのポリシーに従い、ポストされた暗号化メッセージに有効なデジタル署名が添付されているかどうかを検証する場合(「デジタル署名ポリシーの設定」を参照)。

  イベント・ブローカが適切な復号化キーにアクセスできない場合、tppost(3c)操作は失敗し、システムからはuserlog(3c)エラー・メッセージが返されて、処理が失敗したことがレポートされます。

1.16.3.4 /Qとの互換性および相互運用性

一般に、TMQUEUE(5)またはTMQFORWARD(5)のシステム・サーバーは、暗号化されたメッセージ・バッファを復号化しないで処理します。つまり、メッセージがOracle Tuxedoの/Qコンポーネントを通過しても、署名と暗号化エンベロープは何の影響も受けません。ただし、次の場合、/Qコンポーネントは、キューに登録されたメッセージ・バッファを復号化する必要があります。

• システム構成に基づき、データ依存型ルーティング用のメッセージ内容にアクセスする必要のある、TMQFORWARDを実行する場合

  TMQFORWARDが適切な復号化キーにアクセスできない場合、転送操作は失敗します。システムからはメッセージがキューに返され、userlog(3c)エラー・メッセージを生成して失敗をレポートします

  再試行を周期的に何度か繰り返すと、TMQFORWARDにより、読込み不可能なメッセージがエラー・キューに格納される場合があります。

  再試行を周期的に何度か繰り返すと、TMQFORWARDにより、読込み不可能なメッセージがエラー・キューに格納される場合があります。

• 暗号化を必要とする管理システムのポリシーに準拠する場合(「暗号化ポリシーの設定」を参照)。

  /Qコンポーネントが適切な復号化キーにアクセスできない場合、tpenqueue(3c)操作は失敗し、システムからはuserlog(3c)エラー・メッセージが返されて、処理が失敗したことがレポートされます。

• デジタル署名を必要とする管理システムのポリシーに従い、キューに登録された暗号化メッセージに有効な署名が添付されているかどうかを検証する場合(「デジタル署名ポリシーの設定」を参照)。

  /Qコンポーネントが適切な復号化キーにアクセスできない場合、tpenqueue(3c)操作は失敗し、システムからはuserlog(3c)エラー・メッセージが返されて、処理が失敗したことがレポートされます。

呼出し側プロセスに有効な復号化キーがないと、非トランザクション型のtpdequeue(3c)操作により、キューに登録された暗号化済メッセージが破壊されます。

無効な署名が添付されたメッセージがキューに登録された場合(またはそのメッセージがキュー内で破壊または改ざんされた場合)にそのメッセージをキューから取り出そうとすると失敗します。非トランザクション型のtpdequeue(3c)操作は、このようなメッセージを破壊します。トランザクション型のtpdequeue(3c)操作を行うと、トランザクションのロールバックが発生し、以降、キューからメッセージを取り出そうとしても失敗します。

1.16.3.5 トランザクションとの互換性および相互運用性

公開キーによるセキュリティ操作(キーの開閉、デジタル署名のリクエスト、暗号化のリクエスト)はトランザクション型ではないため、トランザクションのロールバックによって元に戻すことはできません。ただし、トランザクションは、公開キーの操作時に発生する次の障害によってロールバックされる場合があります。

• トランザクション型のリクエストまたは応答メッセージを復号化できない場合、関連するトランザクションはロールバックされます。
• デジタル署名が無効か、または欠落していたためにトランザクション型のリクエストまたは応答メッセージが廃棄された場合、関連するトランザクションはロールバックされます。
• 暗号化またはデジタル署名を必要とする管理システムのポリシーに違反したため、トランザクション型のリクエストまたは応答メッセージが拒否された場合、関連するトランザクションはロールバックされます。

1.16.3.6 ドメイン・ゲートウェイとの互換性および相互運用性

Oracle Tuxedoリリース7.1以上のソフトウェアを実行する2つのATMIアプリケーションを接続するドメイン・ゲートウェイ(GWTDOMAIN)プロセスには、デジタル署名および暗号化エンベロープがあります。さらに、これらのドメイン・ゲートウェイ・プロセスは、デジタル署名を検証し、デジタル署名と暗号化に関する管理システム・ポリシーを適用します。

次の図は、ドメイン・ゲートウェイ・プロセスが、ローカルおよびリモートのATMIアプリケーションと対話する様子を示しています。

図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より前のリリースのソフトウェアとの相互運用性」および「公開キーによるセキュリティ機能の相互運用性」を参照してください。)
アウトバウンド・メッセージ	アウトバウンド・メッセージ	ドメイン・ゲートウェイ・プロセスが、デジタル署名を必要とするグループ、ドメイン、またはマシンの内部で実行されている場合、ゲートウェイ・プロセスはメッセージを拒否します。ドメイン・ゲートウェイによって通知されたサービスがデジタル署名を必要とする場合、ゲートウェイ・プロセスはメッセージを拒否します。(詳細は、「デジタル署名ポリシーの設定」を参照してください。)ドメイン・ゲートウェイがデジタル署名を必要としない場合、ゲートウェイ・プロセスはメッセージを受け付け、ネットワーク経由で転送します。

1.16.3.7 ほかのベンダーのゲートウェイとの互換性および相互運用性

リリース7.1以降のATMIアプリケーションと、別のベンダーのゲートウェイ・プロセスを接続するドメイン・ゲートウェイ(GWTDOMAIN)のプロセスは、アウトバウンド・メッセージ・バッファに対して次のように動作します。

1. 暗号化されたメッセージを復号化します。
2. デジタル署名がある場合は、デジタル署名を検証してから削除します。
3. 平文メッセージをネットワーク経由でベンダーのゲートウェイ・プロセスに送信します。

さらに、ドメイン・ゲートウェイ・プロセスは、ATMIアプリケーションの暗号化とデジタル署名に関する管理システムのポリシーを適用します。たとえば、ATMIアプリケーションのドメイン・レベルで、暗号化またはデジタル署名、あるいはその両方が必要な場合、ローカル・ドメイン・ゲートウェイのプロセスは、ほかのベンダーのゲートウェイ・プロセスから受信するすべてのメッセージを拒否します。

関連項目:

• セキュリティの相互運用性
• 相互運用性のポリシーの指定
• デジタル署名ポリシーの設定
• 暗号化ポリシーの設定

1.17 サービス拒否(DoS)の防御

分散型のマルチ・ドメインTuxedoアプリケーションがパブリック・ネットワークや安全性の低い環境に拡張された場合、Tuxedoドメイン・ゲートウェイを潜在的脅威から確実に防御する必要があります。これらの環境には、安全性に問題のあるネットワークや、サービス拒否(DoS)攻撃などの悪意のある攻撃を開始または拡大させる信頼されていない参加者が含まれます。

Tuxedo TDomainゲートウェイ(GWTDOMAIN)では、DoS攻撃に対する防御に次の機能が使用されます。

接続数の制限

メッセージ正常性チェック

メッセージ認証コード(MAC)の使用

• 接続数の制限
  
• 接続制限数の設定
  
• メッセージ正常性チェック
  
• メッセージ認証コード(MAC)の使用
  
• メッセージ認証コード(MAC)の設定
  

1.17.1 接続数の制限

デーモン・サーバーであるGWTDOMAINは、既知のTCPポートで待機して受信接続リクエストを受け付けます。この場合、接続フラッド攻撃の危険にさらされます。これはDoS攻撃の一種で、攻撃者がポート・スキャン・プログラムなど特定のツールを使用し、GWTDOMAINと多数の同時接続を確立しようとし続けます。この攻撃により、ドメイン・ゲートウェイは、接続リクエストを受け付けて各接続にリソースを割り当てることにコンピューティング・パワー(時間やメモリーなど)を浪費してしまいます。

この問題は、GWTDOMAINで接続数を制限することによって回避できます。GWTDOMAINの詳細は、「GWTDOMAIN(5)」を参照してください。

1.17.2 接続制限数の設定

接続数の制限機能を使用するには、UBBCONFIGファイルの*SERVERSセクションを変更する必要があります。

• UBBCONFIGファイル
  
• メッセージ
  

1.17.2.1 UBBCONFIGファイル

GWTDOMAINのパラメータを指定するために使用されるCLOPTは"-x"であり、-x limit [:{[ duration ][: period ]}]という構文が使用されます。各オプションはコロン(:)で区切ります。

ノート:

コロン(:)は、2つのオプション間でのみ使用します。たとえば、「:duration」や「limit::」などの構成は無効です。

オプションdurationおよびperiodは、値が指定されなければデフォルト値が使用されます。

パフォーマンス上の理由からタイミングは正確ではありません。1秒の誤差が生じる可能性があります。

現在のアクティブな接続数と指定した前の期間(period)で閉じられた接続数の合計がlimitより大きい場合、GWTDOMAINは秒単位で指定した時間(duration)だけ一時停止します。

ノート:

現在のアクティブな接続数には、アクティブな受信接続とアクティブな送信接続の両方が含まれます。前のperiodで閉じられた接続数には、閉じられた受信時接続と閉じられた送信時接続の両方が含まれます。しかし、GWTDOMAINが一時停止した場合、閉じられた接続はカウントされません。

limit、durationおよびperiodの定義は次のとおりです。

limit

接続の最大数。最小limit値は0、最大値は2,147,483,647です。

limitに達している(あるいは超えている)ときに受信リクエストがあった場合、GWTDOMAINは指定した時間(duration)だけ一時停止します。同時に、一時停止をトリガーする現在の受信リクエストは受け付けられません。ポーリングは、durationの経過後に再開されます。

limitを0に設定すると、ドメイン・ゲートウェイは受信接続リクエストを受け付けません。つまり、「OUTGOING_ONLY」接続ポリシーになります。

duration

制限(limit)に達したときに受信接続でポーリングを一時停止する時間(秒)。デフォルト値は(SCANUNIT * SANITYSCAN)秒です。最小duration値は5、最大値は65,535です。

period

前に閉じられた接続をカウントするためのGWTDOMAINチェック・ポイントからの時間間隔(秒)。値を指定しない場合、durationと同じデフォルト値が指定されます。最小period値は0、最大値は65,535です。

periodに0を指定した場合、前の期間(period)で閉じられた接続数は常に0になるため、limitではアクティブな接続のみがカウントされます。

• 例
  

1.17.2.1.1 例

次の例に、GWTDOMAINのlimitが同時ソケット接続数512に設定されている例を示します。limitが512に達しているときに受信リクエストがあった場合、GWTDOMAINは300秒(5分)間だけポーリングと新たな受信接続リクエストの受付けを停止します。periodは0に指定されているので、アクティブな接続数のみがカウントされます。

リスト1-1 UBBCONFIGファイルの例1

        # UBBCONFIG
         ...
         *SERVERS
         GWTDOMAIN SRVGRP=GWGRP1 SRVID=2 CLOPT= “-A -- -x
         512:300:0”

次の例に、GWTDOMAINのlimitが同時ソケット接続数200に設定されている例を示します。limitが200に達しているとき、次のような状況であるとします。

• 100の送信接続があります。
• 50の受信接続があります。
• 前の60秒で50の接続が閉じられました(送信接続と受信接続を含む)
• 現在の受信接続がリクエストされています。

duration値が指定されていないので、GWTDOMAINはdurationのデフォルト値(SCANUNIT * SANITYSCAN秒)だけポーリングと新たな受信接続リクエストの受付けを停止します。

ノート:

一時停止をトリガーした現在の受信接続も受け付けらず、一時停止時間の終了時に閉じられます。

リスト1-2 UBBCONFIGファイルの例2

        # UBBCONFIG
         ...
         *SERVERS
         GWTDOMAIN SRVGRP=GWGRP1 SRVID=2 CLOPT= “-A -- -x
         200::60”

1.17.2.2 メッセージ

次のような場合、USERLOGにメッセージが出力されます。

• 事前に設定した接続制限数に達する新しい接続リクエストが着信する場合。

  <LIBGW_CAT 5359> "WARN: The number of connections for
                 <ldom-name> exceeds limit <%d>, start to suspend for
                 <%d> seconds"

• GWTDOMAINが新たに受信接続リクエストのチェックを再開する場合。

  <LIBGW_CAT 5360> "INFO: Resume accepting connection
                 request"

  ノート:

  前述の2つのメッセージは、USERLOGがいっぱいになるのを回避するために「メッセージ調整」メカニズムを使用して制御できます。
• limitを0に指定して、GWTDOMAINが起動する場合。

  <LIBGW_CAT 5361> "INFO: The connection limit for
                 <ldom-name> is set to 0. No incoming connection request will
                 be accepted."

1.17.3 メッセージ正常性チェック

メッセージの正常性チェックは、この機能を使用して強化され、GWTDOMAINが攻撃を受けてクラッシュしないように保護します。この機能はインストール後に自動的にデプロイされるため、構成作業は必要ありません。

1.17.4 メッセージ認証コード(MAC)の使用

メッセージ認証コード(MAC)をメッセージと関連付けると、Tuxedoドメイン・ゲートウェイでメッセージを検証および認証することができます。MACを使用すると、ドメイン・ゲートウェイは、各種DoS攻撃(メッセージの改ざん、メッセージの偽造、メッセージのリプレイ攻撃など)に対して防御することができます。

この機能は、LLEまたはドメインSECURITYが構成されている場合にのみ有効です。MACは接続が確立した後に機能します。リモート・ドメイン・ゲートウェイからのMACメッセージが検証および認証に失敗すると、対応する接続が切断されます。保留メッセージもすべて破棄され、現行のすべてのサービス・リクエストが失敗します。

セッションでMACを有効にするかどうかは、セッション・ネゴシエーション・フェーズ時にGWTDOMAINによって決定されます。MACを有効にできるのは、セッションでLLEまたはSECURITYがサポートされていて、アクティブになっている場合のみです。

ノート:

SSLでは、MACは使用できません。

MACを有効にするためにSECURITY機能をサポートする必要はありませんが、SECURITYは「介在者」の攻撃に対する防御に使用できるのでお薦めします。

• パフォーマンスへの影響
  

1.17.4.1 パフォーマンスへの影響

MACが有効な場合、ドメイン間のリクエストに対するスループットとレスポンス時間が低下する可能性があります。

1.17.5 メッセージ認証コード(MAC)の設定

MAC機能を構成する場合、2つの方法が利用できます。 DMCONFIGファイル構成とMIB構成です。

• DMCONFIGファイル構成
  
• MIB構成
  

1.17.5.1 DMCONFIGファイル構成

この機能は、2つの新しいキーワード(MACとMACLEVEL)を使用して、DMCONFIGファイルのDM_TDOMAINセクションで構成できます。MACはセッションでMACの機能を切り替えるために使用され、MACLEVELはMACレベルを指定するために使用されます。

ノート:

MACLEVELの数値が大きいければ、暗号化という点ではより強力なアルゴリズムになりますが、同時にパフォーマンスは低下します。

表1-15 DMCONFIGファイルのキーワード

キーワード	オプション	定義
MAC	OFF	機能をオフにします。これはデフォルト値です。
	ON	機能をオンにします。確立されたセッションのMACサポートは、2つのドメイン・ゲートウェイ間のネゴシエーション結果に依存します。
	MANDATORY	機能をオンにします。次の場合は、セッションを設定できません。 リモート・ドメインでMAC機能がサポートされていないか、無効になっています。 LLEとドメインSECURITYが利用できません。
MACLEVEL	0	MACでメッセージ・ヘッダーのみを保護。これがデフォルト値です。
	1	MD5ベースのアルゴリズムを使用してMACでメッセージ全体を保護。
	2	SHA1ベースのアルゴリズムを使用してMACでメッセージ全体を保護。
	3	SHA256ベースのアルゴリズムを使用してMACでメッセージ全体を保護。

DMCONFIG構成の例を次に示します。

リスト1-3 DMCONFIGファイル構成

# DMCONFIG
...
*DM_TDOMAIN
“RDOM” NWADDR=”//RHOST:RPORT”
       MAC=”ON”
       MACLEVEL=1

1.17.5.2 MIB構成

MIBを使用してMACを動的に設定する場合、既存のドメイン・セッションは影響を受けません。この設定は、新しい接続でのみ有効です。

MIBインタフェースをサポートするための2つの新しい属性(TA_DMMACとTA_DMMACLEVEL)がT_DM_TDOMAINクラス定義の属性表に追加されます。

表1-16 DM_MIB(5): T_DM_TDOMAINクラス定義の属性表

属性	データ型	権限	値	デフォルト
TA_DMMAC	string	rw-------	string “{OFF|ON|MANDATORY}”	“OFF”
TA_DMMACLEVEL	string	rw-------	string "{0|1|2|3}"	“0”

TA_DMMAC="{OFF|ON|MANDATORY}"

リモート・ドメイン・アクセス・ポイントでのみ有効です。リモート・ドメインへの接続時にMAC機能をアクティブにするかどうか指定します。サポートされる値は、"OFF"、"ON"、"MANDATORY"です。

"OFF"

ドメイン・ゲートウェイへの接続でMAC機能を使用しない場合に指定します。

"ON"

ドメイン・ゲートウェイへの接続でMAC機能を使用する場合に指定します。

"MANDATORY"

ドメイン・ゲートウェイへの接続でMAC機能を使用する必要がある場合に指定します。使用しない場合は接続を正常に確立できません。

TA_DMMACLEVEL="{0|1|2|3}"

リモート・ドメイン・アクセス・ポイントでのみ有効です。MACでメッセージ全体を保護する場合に指定します。 "0"は、MACでメッセージ・ヘッダーのみを保護する場合に指定します。 "1"、"2"、"3"は、MD5、SHA1、SHA256に基づいたアルゴリズムを使用してMACでメッセージ全体を保護する場合に指定します。

次のリストに、ud32を使用してMAC属性を取得する方法と更新する方法の例をそれぞれ示します。

リスト MAC属性を取得するサンプル・スクリプト

SRVCNM .TMIB
         TA_OPERATION GET
         TA_CLASS T_DM_TDOMAIN
         TA_DMACCESSPOINT RDOM
         TA_DMNWADDR //host:port

リスト 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

• MACネゴシエーション
  
• メッセージ
  
• ERRORメッセージ
  

1.17.5.2.1 MACネゴシエーション

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(m 1 , m 2 )<=negotiated MACLEVEL<=min(Max 1 , Max 2)。この関係が満たされていない場合は、接続が閉じられて対応するエラー・メッセージがUSERLOGに記録されます。

1.17.5.2.2 メッセージ

USERLOGに次のメッセージが出力されます。

INFOメッセージ

次のINFOメッセージは、MACに関する合意がなされて1つのセッションでMAC機能が設定された後に出力されます

• MACがセッションでサポートされていない場合。

  <LIBGWT 1686> "INFO: MAC is not supported for session(<ldom-name>, <rdom-name>"

  ノート:

  このメッセージは、MACが"ON"に設定されているドメインのみで出力されます。
• MACがセッションで有効になっている場合。

  <LIBGWT 1687> "INFO: MAC is turned on for session(<ldom-name>, <rdom-name>) and effective MACLEVEL is <%d>"

1.17.5.2.3 ERRORメッセージ

次のエラー・メッセージは、セッションネゴシエーションおよびMAC検証フェーズ時に表示されます。これらのメッセージが出力されると、接続は切断されます。

• セッションでMACが必須ですが、ネゴシエーション時にMACがサポートされていない場合。

  <LIBGWT 1681> "ERROR: MAC is MANDATORY but remote domain <rdom-name> does not support this feature"

• MACが必須ですが、ネゴシエーション時にLLEもSECURITYもサポートされていない場合。

  <LIBGWT 1682> "ERROR: MAC is MANDATORY but neither LLE nor SECURITY is supported for connection of (<ldom-name>,<rdom-name>)"

• リモート・ドメインでMACが必須ですが、ローカル・ドメインでMACがサポートされていない場合。

  <LIBGWT 1683> "ERROR: MAC is MANDATORY in remote domain <rdom-name> but not supported in local domain <ldom-name>"

• MACネゴシエーションでMACLEVELに関する合意に失敗した場合。

  <LIBGWT 1684> "ERROR: MAC failed to make an agreement on MACLEVEL (<ldom_name> is <%d>..<%d>,<rdom-name> is <%d>..<%d>)"

  ノート:

  このメッセージの"%d"プレースホルダーに対応するパラメータは、m1、Max1、m2、Max2です。
• MACが検証および認証に失敗した場合。

  <LIBGWT 1685> "ERROR: Message from <rdom-name> has invalid MAC"

1.18 パスワード・ペア保護

パスワード・ペア保護機能はインストール後に自動的にデプロイされるため、構成作業は必要ありません。この機能により、GWTDOMAINセキュリティ・メカニズムが強化され、また、同じリモート・パスワードによるデュアル・パスワード・ペアが使用できなかった以前のセキュリティの制限もなくなります。

パスワード・ペア保護は、ローカル・ドメインとリモート・ドメインの両方でサポートされている場合にのみ機能します。ローカル・ドメインとリモート・ドメインの両方でサポートされていない場合は、既存の動作が変更されることはありません。