目次 前 次 PDF


公開鍵によるセキュリティ機能の管理

公開鍵によるセキュリティ機能の管理
このトピックには次の項が含まれます:
ここで説明する作業は、CORBAアプリケーションでSSLプロトコルまたは証明書による認証を使用している場合にのみ実行してください。
注意:
Oracle Tuxedo CORBA JavaクライアントとOracle Tuxedo CORBA JavaクライアントORBはTuxedo 8.1で非推奨になり、サポートされなくなりました。すべてのOracle Tuxedo CORBA JavaクライアントおよびOracle Tuxedo CORBA JavaクライアントORBのテキスト・リファレンスとコード・サンプルは、サード・パーティ製のJava ORBライブラリを実装または実行する際の参考や、プログラマの参照用としてのみ使用してください。
サード・パーティのCORBA Java ORBのテクニカル・サポートは、各ベンダーによって提供されます。Oracle Tuxedoでは、サード・パーティのCORBA Java ORBに関する技術的なサポートまたはドキュメントは提供していません。
公開鍵によるセキュリティを使用するための要件
SSLプロトコルおよび公開鍵によるセキュリティ機能を使用して、プリンシパルとOracle Tuxedoドメイン間の通信を保護するには、専用のライセンスをインストールする必要があります。ライセンスのインストール方法については、『Oracle Tuxedoシステムのインストール』を参照してください。
また、公開鍵によるセキュリティを実装する前に、Lightweight Directory Access Protocolサーバーと所属組織用の認証局(市販または専用)を選択して設定する必要があります。
デジタル証明書と公開鍵/秘密鍵のペアが必要な場合
CORBAセキュリティ環境でSSLプロトコルを使用するには、秘密鍵と対応する公開鍵を含むデジタル署名付き証明書が必要です。必要なデジタル証明書および秘密鍵の数は、SSLプロトコルの使用方法によって異なります。
リモート・クライアントとIIOPリスナー/ハンドラ間のネットワーク接続を保護するためにSSLプロトコルを使用する場合、IIOPリスナー/ハンドラのデジタル証明書および秘密鍵を取得する必要があります。
SSLプロトコルを証明書による認証で使用する場合、IIOPリスナー/ハンドラだけでなく、CORBAアプリケーションにアクセスする各プリンシパルのデジタル証明書および秘密鍵を取得する必要があります。
使用するデジタル証明書の取得先は、信頼性のあるCAファイルで定義されている認証局でなければなりません。詳細は、4-7ページの「信頼性のある認証局の定義」を参照してください。
デジタル証明書のリクエスト
デジタル証明書を取得するには、デジタル署名リクエスト(CSR)と呼ばれる特定の形式でデジタル証明書のリクエストを提出する必要があります。CSRの作成方法は、利用する認証局によって異なります。通常、認証局では、公開鍵、秘密鍵、およびその公開鍵を含むCSRを提供します。CSRを作成するには、選択した認証局で説明されている手順に従います。
手順に従ってCSRを作成すると、認証局から次のファイルを受け取ります。
 
ファイル
説明
key.der
秘密鍵ファイル。
request.pem
認証局に提出するCSRファイル。内容は.demファイルと同じデータですが、電子メールへのコピーやWebフォームへの貼付けができるようにASCIIでエンコードされています。
認証局からデジタル証明書を購入するには、認証局の登録手順に従ってCSRを認証局に提出します。一部の認証局では、デジタル証明書をWeb経由で購入できます。
LDAPディレクトリ・サービスでの証明書の公開
デジタル証明書の保存方法としては、グローバル・ディレクトリ・サービスを使用するのが一般的です。ディレクトリ・サービスを使用すると、増え続けるユーザーに対してグローバルに利用可能にする情報を容易に管理できます。LDAPサーバーでは、様々なディレクトリ・サービスにアクセスできます。
SSLプロトコルを使用するように構成されたOracle Tuxedo製品のCORBAセキュリティ環境では、プリンシパルおよび認証局のデジタル証明書を、Netscape Directory ServiceやMicrosoft Active DirectoryなどのLDAPディレクトリ・サービスから取り出すことができます。SSLプロトコルまたは認証局を使用する前に、LDAPディレクトリ・サービスをインストールし、所属する組織に合せて構成する必要があります。Oracleでは、特定のLDAPディレクトリ・サービスを提供しておらず、また推奨もしていません。ただし、選択したLDAPディレクトリ・サービスは、X.500スキーム定義とLDAPバージョン2または3プロトコルをサポートしている必要があります。
LDAPディレクトリ・サービスは、オブジェクト・クラスの階層を定義します。様々なオブジェクト・クラスが多数ありますが、デジタル証明書に関連付けられるのは一部だけです。図4-1は、デジタル証明書に関連付けられる代表的なオブジェクト・クラスを示しています。
図4-1 デジタル証明書のLDAPディレクトリ構造
 
認証局から受け取ったデジタル証明書は、次のようにLDAPディレクトリ・サービスに保存します。
IIOPリスナー/ハンドラおよびプリンシパルのデジタル証明書は、オブジェクト・クラスのuserCertificate属性を定義して、LDAPディレクトリ・サービスに保存されます。通常、これらのデジタル証明書は、X.500で定義されているstrongAuthenticationUserオブジェクト・クラスのインスタンスとして保存されます。
認証局のデジタル証明書は、オブジェクト・クラスのcaCertificate属性を定義して、LDAPディレクトリ・サービスに保存されます。通常、これらのデジタル証明書は、X.500で定義されているcertificateAuthorityクラスのインスタンスとして保存されます。
別のクラスを使用するLDAPスキームでは、4-4ページの「LDAP検索フィルタ・ファイルの編集」で説明するように、LDAP検索ファイルを変更する必要があります。
Oracle Tuxedo製品では、デジタル証明書をPrivacy Enhanced Mail (PEM)形式でディレクトリ・サービスに保存する必要があります。
LDAPディレクトリ・サービスをCORBAセキュリティ環境に統合する方法については、『Oracle Tuxedoシステムのインストール』を参照してください。
LDAP検索フィルタ・ファイルの編集
SSLプロトコルまたは証明書による認証を使用するようにCORBAアプリケーションを構成する場合、LDAP検索フィルタ・ファイルをカスタマイズして、ディレクトリ・サービスの検索スコープを限定するか、デジタル証明書を保持するオブジェクト・クラスを指定します。LDAP検索フィルタ・ファイルをカスタマイズすると、パフォーマンスが大幅に向上する場合があります。Oracle Tuxedo製品には、次のLDAP検索フィルタが付属しています。
認証局に割り当てられているデジタル証明書用のディレクトリ・サービスを検索するフィルタ・スタンザ。このフィルタを使用すると、検索範囲がcertificationAuthorityオブジェクト・クラスのインスタンスに限定されます。
プリンシパルに割り当てられているデジタル証明書用のディレクトリ・サービスを検索するフィルタ・スタンザ。このフィルタを使用すると、検索範囲がstrongAuthenticationUserオブジェクト・クラスのインスタンスに限定されます。
ディレクトリ・サービスのスキームがデジタル証明書をcertificationAuthorityおよびstrongAuthenticationUser以外のオブジェクト・クラスに格納するように定義されている場合、LDAP検索フィルタ・ファイルを変更して、それらのオブジェクト・クラスを指定する必要があります。
LDAP検索フィルタ・ファイルの場所は、Oracle Tuxedo製品のインストール時に指定します。詳細は、『Oracle Tuxedoシステムのインストール』を参照してください。
LDAP検索フィルタ・ファイルは、管理者アカウントで所有する必要があります。このファイルを保護して、ファイルのオーナーだけが読み書き権限を持つようにすることをお薦めします。
プリンシパルおよび認証局のデジタル証明書の検索を制限するには、次のタグで示されるLDAP検索フィルタ・ファイル内のフィルタ・スタンザを変更する必要があります。
BEA_person_lookup
BEA_issuer_lookup
これらのタグは、ディレクトリ・サービスで情報を検索するためのフィルタ式を含むLDAP検索フィルタ・ファイル内のスタンザを識別します。これらOracle固有のタグを使用すると、LDAP検索フィルタ・ファイルのスタンザを、組織内のほかのLDAP対応アプリケーションが使用する共通のLDAP検索フィルタ・ファイルに保存できます。
Oracle Tuxedo製品がSSLプロトコルおよびデジタル証明書用に使用するLDAP検索フィルタ・ファイルのスタンザの例を次に示します。
���BEA_person_lookup���
���.*��� ��� ��� ���(&(objectClass=strongAuthenticationUser) (mail=%v))���
���e-mail address���
���(&(objectClass=strongAuthenticationUser) (mail=%v))���
���start of e-mail address���
���BEA_issuer_lookup���
���.*��� ��� ��� ���(&(objectClass=certificationAuthority)
(cn=%v)��� ���exact match cn���
(sn=%v))��� ���exact match sn���
BEA_person_lookupは、LDAPディレクトリ・サービスで電子メール・アドレスを使用してプリンシパルを検索するように指定します。
BEA_issuer_lookupには、LDAPディレクトリ・サービスで一般名(cn)を使用してプリンシパルを検索するように指定します。
LDAP検索フィルタ・ファイルの詳細は、それぞれのLDAP対応ディレクトリ・サービスのドキュメントを参照してください。
共通ロケーションにある秘密鍵
通常、プリンシパルがCSRを生成すると、秘密鍵の入ったファイルを受け取ります。プリンシパルが認証プロセスで自身のIDを証明する場合には、この秘密鍵のファイルが必要になります。秘密鍵ファイルのオーナーだけが読取り権限を持ち、その他すべてのユーザーはファイルにアクセスできないように、秘密鍵ファイルの保護機能を指定します。秘密鍵ファイルは、PEMエンコードされたPKCS #8保護形式で保存する必要があります。
Oracle Tuxedoシステムでは、次のように、プリンシパルの電子メール・アドレスを使用して秘密鍵ファイルの名前を作成します。
1.
名前の@はアンダースコア(_)で置き換えられます。
2.
ドット(.)以降のすべての文字は削除されます。
3.
.PEMファイル拡張子がファイルに追加されます。
たとえば、プリンシパルの名前がmilozzi@bigcompany.comの場合、生成される秘密鍵ファイルはmilozzi_bigcompany.pemです。この命名規則では、ユーザー名が同じで電子メール・ドメインが異なる複数のプリンシパルが社内に存在してもかまいません。
Oracle Tuxedoソフトウェアでは、次のディレクトリで秘密鍵ファイルが検索されます。
Window 2000
%HOMEDRIVE%\%HOMEPATH%
UNIX
$HOME
また、Oracle Tuxedoソフトウェアでは、次のディレクトリでも秘密鍵ファイルが検索されます。
$TUXDIR/udataobj/security/keys
オーナーだけが読取り権限を持ち、その他すべてのユーザーはディレクトリにファイルにアクセスできないように、$TUXDIR/udataobj/security/keysディレクトリを保護する必要があります。
リスト4-1に、秘密鍵ファイルの例を示します。
リスト4-1 秘密鍵ファイルの例
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIICoDAaBgkqhkiG9w0BBQMwDQQItSFrtYcfKygCAQUEggKAEgrMxo8gYB/MOSXG
...
-----END ENCRYPTED PRIVATE KEY-----
 
信頼性のある認証局の定義
SSL接続を確立する場合、CORBAのプロセス(クライアント・アプリケーションIIOPリスナー/ハンドラ)は、ピアのデジタル証明書のチェーンから認証局のIDおよび証明書を、信頼性のある認証局のリストと照合して、組織が信頼する認証局であることを確認します。このチェックは、Webブラウザで行われるチェックとほぼ同じです。照合が失敗した場合、SSL接続のイニシエータはターゲットの認証を拒否し、SSL接続を終了します。通常は、システム管理者が、信頼性のある認証局のリストを定義します。
信頼性のある認証局のデジタル証明書をLDAPディレクトリ・サービスから取り出します。PEM形式のデジタル証明書を切り取って、$TUXDIR/udataobj/security/certsにあるtrust_ca.cerというファイルに貼り付けます。trust_ca.cerは、任意のテキスト・エディタで編集できます。
trust_ca.cerファイルは、管理者アカウントで所有する必要があります。このファイルを保護して、ファイルのオーナーだけが読み書き権限を持つようにすることをお薦めします。
リスト4-2に、信頼性のある認証局ファイルの例を示します。
リスト4-2 信頼性のある認証局ファイルの例
-----BEGIN CERTIFICATE----
��MIIEuzCCBCSgAwIBAgIQKtZuM5AOzS9dZaIATJxIuDANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEg
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE----
��MIIEuzCCBCSgAwIBAgIQKtZuM5AOzS9dZaIATJxIuDANBgkqhkiG9w0BAQQFADCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy
dXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
...
-----END CERTIFICATE-----
 
ピア規則ファイルの作成
ネットワーク・リンク経由の通信では、接続先のピアが意図したピアまたは許可されたピアであることの確認が重要です。このチェックを行わないと、安全な接続を確立して、安全なメッセージをやり取りしたり、有効なデジタル証明書のチェーンを受信したりすることはできますが、中間者攻撃を受ける危険は残ります。ピア検証を行うには、ピアの証明書に含まれている情報を、ピアの信頼性を検証するための規則を指定した情報リストと照合します。システム管理者は、このピア規則ファイルを管理します。
ピア規則は、peer_val.rulというASCIIファイルで管理されます。peer_val.rulファイルを、Oracle Tuxedoディレクトリ構造の次の場所に格納します。
$TUXDIR/udataobj/security/certs
リスト4-3に、ピア規則ファイルの例を示します。
リスト4-3 ピア規則ファイルの例
#
# This file contains the list of rules for validating if
# a peer is authorized as the target of a secure connection
#
O=Ace Industry
O=���Acme Systems, Inc.���; OU=Central Engineering;L=Herkimer;S=NY
O=���Ball, Corp.���, C=US
o=Ace Industry, ou=QA, cn=www.ace.com
 
ピア規則ファイルの各規則は、キーで識別される要素のセットで構成されます。Oracle Tuxedo製品は、表4-1に示すキー名を認識します。
 
表4-1 ピア規則ファイルでサポートされているキー
キー
属性
CN
CommonName
SN
SurName
L
LocalityName
S
StateOrProvinceName
O
OrganizationName
OU
OrganizationalUnitName
C
CountryName
E
EmailAddress
各キーの後ろには、オプションの空白文字、=、オプションの空白文字、および比較対象の値が続きます。キーでは大文字/小文字は区別されません。規則で指定された各要素がサブジェクトの識別名に入っており、要素の値が大文字/小文字の区別および区切りも含めて規則で指定された値と一致していないかぎり、規則は一致となりません。
ピア規則ファイルの各行には、安全な接続を確立するかどうかを決定するための1つの規則が入っています。規則は複数の行にまたがってはならず、規則全体を1行に収めなければなりません。規則の各要素を区切るには、カンマ(,)またはセミコロン(;)を使用します。
シャープ記号(#)で始まる行は注釈です。注釈は、組織名と同じ行に表示できません。
次のいずれかの条件に該当する場合は、値を一重引用符で囲む必要があります。
文字列に次のいずれかの文字が含まれる場合
, + = "" <CR> < > # ;
文字列の前または後ろに空白がある場合
文字列に空白が連続する場合
Oracle Tuxedo製品では、デフォルトで、ピア情報がピア規則ファイルと照合されます。このチェックを省略する場合は、空のピア規則ファイルを作成します。
 

Copyright ©1994, 2017,Oracle and/or its affiliates. All rights reserved