| Oracle® Databaseセキュリティ・ガイド 12c リリース1 (12.1) B71285-10 |
|
 前 |
 次 |
Secure Sockets Layer認証を使用するようにOracle Databaseを構成できます。
内容は次のとおりです。
Secure Sockets Layer (SSL)は安全なネットワーク接続を目的に、Netscape社によって設計されました。
Transport Layer Security (TLS)は、Secure Sockets Layer (SSL)バージョン3.0の増分バージョンです。
SSLは最初にNetscape社によって開発されましたが、Internet Engineering Task Force (IETF)がその開発を引き継ぎ、名前をTransport Layer Security (TLS)に変更しました。
注意:
SSLが最も広く認識されている用語であるため、SSLでもTLSでも適切な場合、この章では説明を簡単にするためにSSLという用語を使用します。ただし、これらのプロトコルの使用方法または構成方法に違いがある場合、この章では、記述内容がSSLに該当するか、TLSに該当するかを明記します。
Oracle Databaseでは、これらのプロトコルのネイティブ暗号化およびデータ整合性機能だけでなく、SSL上でデジタル証明書を使用します。
Oracle DatabaseのSSL機能を使用してクライアントとサーバー間の通信を保護すると、次の操作を実行できます。
SSLを使用したクライアントとサーバー間の接続の暗号化
SSL通信用に構成されたOracleデータベース・サーバーに対するクライアントまたはサーバー(Oracle Application Server 10gなど)の認証
SSL機能は、単独で使用するか、Oracle Databaseでサポートされている他の認証方式と組み合せて使用できます。たとえば、SSLから提供されている暗号化をKerberosから提供されている認証と組み合せて使用できます。SSLでは、次の認証モードがサポートされます。
サーバーのみ、クライアントに対して自己認証を行います。
クライアントとサーバーは、互いに自己認証を行います。
クライアントもサーバーも、互いに自己認証を行わず、SSL暗号化機能を単独で使用します。
関連項目:
SSLの詳細は、Internet Engineering Task Forceが公開しているSSLプロトコルのバージョン3.0を参照してください。
Secure Sockets Layerによるネットワーク接続を開始する場合、クライアントとサーバーは、認証を行う前にSSLハンドシェイクを実行します。
ハンドシェイク・プロセスは次のようになります。
クライアントとサーバーは、どの暗号スイートを使用するかを設定します。これには、データ転送に使用する暗号化アルゴリズムも含まれます。
サーバーは証明書をクライアントに送信し、クライアントは、サーバーの証明書が信頼できるCAによって署名されていることを検証します。このステップにより、サーバーの身元が検証されます。
同様に、クライアント認証が必要な場合は、クライアントが自分自身の証明書をサーバーに送信し、サーバーは、クライアントの証明書が信頼できるCAによって署名されているかどうかを検証します。
クライアントとサーバーが、公開鍵暗号化を使用して鍵情報を交換します。この情報に基づき、双方でセッション鍵が生成されます。クライアントとサーバーとの間の以降の通信はすべて、このセッション鍵と、ネゴシエーションにより決定した暗号スイートを使用して、暗号化または復号化されます。
認証プロセスは次のとおりです。
クライアントで、ユーザーがSSLを使用してサーバーへのOracle Net接続を開始します。
SSLは、クライアントとサーバー間のハンドシェイクを実行します。
ハンドシェイクが成功すると、サーバーは、そのデータベースにアクセスするために必要な認可をユーザーが所有していることを検証します。
公開鍵インフラストラクチャ(PKI)は、組織全体のセキュリティ基盤を提供するネットワーク・コンポーネントの基質であり、信頼アサーションに基づいています。
内容は次のとおりです。
従来の秘密鍵または対称鍵の暗号化では、通信を保護する目的で2者以上が共有する1つの秘密鍵が必要です。
この鍵は、ユーザー間で送信される保護メッセージの暗号化および復号化に使用されるため、各ユーザーへは事前に安全な方法で鍵を配布する必要があります。この方法における問題点は、鍵を安全に転送し、格納することが困難なことです。
公開鍵の暗号化による公開鍵/秘密鍵のペアおよび鍵配布のための安全な方法を採用することで、この問題は解決します。対応する秘密鍵の所有者のみが復号化できるメッセージは、自由に使用できる公開鍵によって暗号化できます。秘密鍵は、その他のセキュリティ資格証明とともに、ウォレットと呼ばれる暗号化されたコンテナに、安全に格納されます。
公開鍵のアルゴリズムでは、メッセージの秘密は保証されますが、安全な通信は必ずしも保証されません。その理由は、通信者間の識別が検証されないためです。安全な通信を確立するには、メッセージの暗号化に使用される公開鍵が相手の受信者に実際に属していることを確認することが重要です。そうしないと、第三者が通信を傍受し、公開鍵のリクエストに割り込み、正当な鍵を独自の公開鍵に置き換えることが可能になります(介在者攻撃)。
この攻撃を回避するには、公開鍵の所有者の確認(認証と呼ばれるプロセス)が必要です。認証は、通信する双方の委託するサード・パーティの認証局(CA)によって行われます。
CAは、エンティティの名前、公開鍵および他のセキュリティ資格証明を含む公開鍵証明書を発行します。通常、このような資格証明には、CA名、CAの署名および証明書の有効日(開始日、終了日)が含まれています。
CAでは独自の秘密鍵を使用してメッセージを暗号化します。一方、そのメッセージの復号化には公開鍵が使用されるため、メッセージがCAによって暗号化されたものであるかどうかが確認されます。CA公開鍵は広く一般に知られているため、アクセスするたびに認証する必要はありません。このようなCA公開鍵はウォレットに格納されます。
Oracle環境の公開鍵インフラストラクチャ(PKI)のコンポーネントには、認証局、証明書、証明書失効リストおよびウォレットなどがあります。
内容は次のとおりです。
認証局(CA)は、ユーザー、データベース、管理者、クライアント、サーバーなどのエンティティの識別情報を証明する、信頼できるサード・パーティです。
エンティティが証明書を要求すると、CAはその識別情報を検証し、CAの秘密鍵を使用して署名した証明書を発行します。
CAごとに、証明書の発行時の識別情報要件が異なる可能性があります。CAの中には、要求者の識別情報をドライバのライセンスを使用して確認したり、要求者の指紋で識別情報を確認したり、証明書リクエスト・フォームが認証されていることを必要とするものがあります。
CAは、公開鍵が含まれている独自の証明書を発行します。各ネットワーク・エンティティには、信頼できるCA証明書のリストがあります。通信する前に、ネットワーク・エンティティは証明書を交換し、相互の証明書がそれぞれの信頼できるCA証明書リストのいずれかのCAによって署名されていることを確認します。
ネットワーク・エンティティは、同じCAから、または異なるCAから証明書を取得できます。デフォルトでは、Oracle Databaseは、新規ウォレットの作成時にVeriSign社、RSA社、Entrust社およびGTE CyberTrust社から信頼できる証明書を自動的にインストールします。
関連項目:
公開鍵ペアをユーザーIDにバインドする証明書にCAが署名すると、証明書は指定された期間有効になります。
ただし、ユーザー名の変更や秘密鍵の漏えいなどの特定のイベントが発生した場合は、有効期間が終了する前に証明書が無効になることがあります。この場合は、CAによって証明書が失効され、そのシリアル番号が証明書失効リスト(CRL)に追加されます。CAは、特定の公開鍵が、関連付けられているユーザーIDの確認に使用できなくなると、定期的にCRLを発行してユーザーに警告します。
サーバーまたはクライアントはOracle環境でユーザー証明書を受信すると、その有効期限、署名および失効ステータスをチェックして証明書を検証できます。証明書失効ステータスは、発行されたCRLに照らして検証することでチェックされます。証明書失効ステータス・チェックが有効になっている場合、サーバーはこの機能の構成方法に応じて適切なCRLを検索します。サーバーは、次の場所で(この順番で) CRLを検索します。
ローカル・ファイル・システム
Oracle Internet Directory
CRL配布ポイント。証明書が発行されたときの、CRL Distribution Point (CRL DP)X.509バージョン3の証明書拡張で指定されている場所。
注意:
他のOracle製品でCRLを使用するには、その製品のドキュメントを参照してください。CRLによる証明書の検証の実装は、Oracle Database 12c リリース1 (12.1)のSSLアダプタでのみ使用できます。
関連項目:
このPKIコンポーネントの構成および管理の詳細は、証明書失効リストによる証明書の検証を参照してください
ウォレットは、認証および署名資格証明(SSLで必要な秘密鍵、証明書、信頼できる証明書など)の格納に使用されるコンテナです。
Oracle環境では、SSL通信を行うどのエンティティにも、X.509バージョン3の証明書、秘密鍵および信頼できる証明書のリストが必要です。ただし、Diffie-Hellmanは例外です。
セキュリティ管理者は、サーバーのセキュリティ資格証明の管理にOracle Wallet Managerを使用します。ウォレットの所有者は、クライアントのセキュリティ資格証明の管理に使用します。具体的には、Oracle Wallet Managerは次のことを行うために使用します。
公開鍵と秘密鍵のペアの生成および証明書リクエストの作成
秘密鍵と一致するユーザー証明書の格納
信頼できる証明書の構成
関連項目:
Oracle Wallet Managerの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
Oracleウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
Oracleウォレットでの信頼できる証明書の管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
SSLのハードウェア・セキュリティ・モジュールには、様々な機能を処理するデバイスや、暗号情報を格納するハードウェア・デバイスなどがあります。
Oracle Databaseでは、これらのデバイスを次の機能に使用します。
秘密鍵などの暗号情報の格納
他のトランザクションに応答できるようにCPUを解放して、サーバーにおけるRSA操作の負荷を軽減する暗号操作の実行
暗号情報は、次の2つのタイプのハードウェア・デバイスに格納できます。
(サーバー側)鍵がボックスに格納され、トークンを使用して管理されるハードウェア・ボックス。
(クライアント側)トークンへの秘密鍵の格納をサポートするスマートカード・リーダー
Oracle環境では、RSA Security社の公開鍵暗号規格(PKCS)#11仕様に準拠しているAPIを使用したハードウェア・デバイスがサポートされています。
注意:
現在、SafeNETおよびnCipherデバイスがOracle Databaseで認定されています。
関連項目:
構成の詳細は、ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成を参照してください。
Secure Sockets Layer (SSL)をデータベースのユーザー名とパスワード、RADIUSおよびKerberosと同時に使用するようにOracle Databaseを構成できます。
内容は次のとおりです。
Secure Sockets Layerと他の認証方式の併用
関連項目:
複数の認証方式が指定されたsqlnet.oraファイルなど、サポートされている他の認証方式によるSSLの構成方法の詳細は、データ暗号化および整合性パラメータを参照してください。
Oracle DatabaseとSSLとの連携のアーキテクチャを理解することが重要です。
Secure Sockets LayerアーキテクチャのOracle Databaseの実装を示す図15-4では、Oracle DatabaseがSSLの上位のセッション・レイヤーで動作し、トランスポート・レイヤーでTCP/IPを使用していることを示しています。
このように機能が分離されているため、SSLを他のサポートされているプロトコルと同時に利用できます。
関連項目:
Oracleネットワーキング環境におけるスタック通信の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
Secure Sockets Layerは、Oracle Databaseでサポートされているその他の認証方式との併用が可能です。
図18-1は、Secure Sockets Layerが別の認証方式と併用されている構成を示しています。
この例では、最初のハンドシェイク(サーバー認証)を確立するためにSecure Sockets Layerが使用され、クライアントの認証に別の認証方式が使用されています。このプロセスは、次のとおりです。
クライアントがOracleデータベース・サーバーに接続しようとします。
Secure Sockets Layerによってハンドシェイクが実行され、その間にサーバーがクライアントに対して自己認証を行い、クライアントとサーバーの両方が使用する暗号スイートを設定します。
Secure Sockets Layerハンドシェイクが正常に完了すると、ユーザーはデータベースにアクセスしようとします。
Oracleデータベース・サーバーは、KerberosやRADIUSなどの非SSL認証方式を使用して、認証サーバーでユーザーを認証します。
認証サーバーによる検証が完了すると、Oracleデータベース・サーバーによってアクセス権と認可がユーザーに付与され、ユーザーはSSLを使用してデータベースに安全にアクセスできるようになります。
Oracle Databaseは、アプリケーション・プロキシベースのファイアウォールとステートフル・パケット・インスペクション・ファイアウォールの2つをサポートしています。
ファイアウォールは次のとおりです。
アプリケーション・プロキシベースのファイアウォール: Network Associates GauntletやAxent Raptorなど。
ステートフル・パケット・インスペクション・ファイアウォール: Check Point Firewall-1やCisco PIX Firewallなど。
SSLを有効にした場合、ステートフル・インスペクション・ファイアウォールは暗号化されたパケットを復号化しないため、アプリケーション・プロキシ・ファイアウォールと同じように動作します。
ファイアウォールは暗号化されたトラフィックを検査しません。ファイアウォールは、イントラネット・サーバーのSSLポート宛てのデータを検出すると、アクセス・ルールに基づいてターゲットIPアドレスを確認し、許可されたSSLポートに対してはSSLパケットを通過させ、他のすべてのパケットは拒否します。
いくつかのファイアウォール・ベンダーが提供しているOracle Net Firewall Proxyキットを使用すると、ファイアウォール・アプリケーションでデータベース・ネットワーク・トラフィックがサポートされます。プロキシ・キットをファイアウォールに実装すると、次の処理が実行されます。
Net Proxy (Oracle Net Firewall Proxyキットのコンポーネント)によってトラフィックのルーティング先が決定されます。
データベース・リスナーは、SSLハンドシェイクに参加するために、証明書 へのアクセスを要求します。リスナーはSSLパケットを検査し、ターゲット・データベースを識別して、ターゲット・データベースがクライアントのリスニングに使用しているポートを戻します。このポートは、SSLポートとして指定されている必要があります。
クライアントは、以降のすべての接続でこのサーバー指定ポートを使用して通信します。
他のOracle製品との通信や、サポート対象の認証方式および暗号化方式のタイプといった、SSLの使用に関する問題に注意する必要があります。
SSLを使用する場合は、次のことを考慮してください。
SSLを使用すると、Oracle Internet Directoryなどの他のOracle製品との安全な通信が可能になります。
SSLでは認証と暗号化の両方がサポートされているため、クライアント/サーバー接続が標準のOracle Net TCP/IPトランスポート(ネイティブ暗号化を使用)より多少遅くなります。
各SSL認証モードには、構成設定が必要となります。
マルチスレッド・クライアントでは、現在SSLを使用できません。
注意:
SSL暗号化を構成する場合は、非SSL暗号化を無効にする必要があります。このような暗号化を無効にするには、「厳密認証およびネットワーク暗号化の無効化」を参照してください。
関連項目:
ハードウェア・アクセラレータでSSLパフォーマンスを改善する方法の詳細は、ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成を参照してください
Secure Sockets Layerは、サーバーで構成してから、クライアントで構成する必要があります。
内容は次のとおりです。
インストール中、Oracleデータベース・サーバーとOracleクライアントに、Oracleウォレットの場所を除くSSLパラメータのデフォルトが設定されます。
次の手順に進む前に、ウォレットが作成されていることと、ウォレットに証明書があることを確認する必要があります。
関連項目:
Oracleウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。次に、ウォレットのサーバー上の場所を指定します。
注意:
リスナーでは、listener.oraファイルに定義されているウォレットを使用します。任意のデータベース・ウォレットを使用できます。Net Managerを使用してサーバーのSSLが構成されている場合、ウォレット・ロケーションはlistener.oraファイルとsqlnet.oraファイルに入力されています。listener.oraファイルは、Oracleクライアントには関係ありません。
リスナーが独自のウォレットを所有するようにリスナーのウォレット・ロケーションを変更するには、listener.oraを編集して新しい場所を入力します。
オプションで、Secure Sockets Layer暗号スイートを設定できます。
内容は次のとおりです。
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。
Secure Sockets Layerハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Databaseをインストールすると、表18-1のSecure Sockets Layer暗号スイートがデフォルトで設定され、リスト順にネゴシエートされます。デフォルトの順序は、SSL_CIPHER_SUITESパラメータを設定して上書きできます。
暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。
互換性。正常に接続するには、互換性のある暗号スイートを使用するようにサーバーとクライアントを構成する必要があります。
暗号の優先順位と強度。最高レベルのセキュリティを確保するために、最も強力なものから最も弱いものの順に暗号スイートの優先順位を設定します。
使用するセキュリティ・レベル。
パフォーマンスへの影響。
注意:
Diffie-Hellman 匿名認証について:
この暗号スイートを使用するようにサーバーを設定する場合は、同じ暗号スイートをクライアントにも設定する必要があります。設定しない場合、接続に失敗します。
Diffie-Hellman匿名を使用する暗号スイートを使用する場合、SSL_CLIENT_AUTHENTICATIONパラメータをFALSEに設定する必要があります。詳細は、手順1E: サーバーでのSSLクライアント認証の設定(オプション)を参照してください。
既知の不具合があり、クライアントを認証しないDH_ANONを含む暗号スイートを使用する場合でも、OCIクライアントでウォレットが必要です。
Oracle Databaseでは、Oracle Databaseをインストールするとデフォルトで設定される一連の暗号スイートがサポートされています。
表18-1に、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプを示します。
表18-1 Secure Sockets Layer暗号スイート
| 暗号スイート | 認証 | 暗号化 | データ整合性 | TLSの互換性 |
|---|---|---|---|---|
|
ECDHE_ECDSA |
AES 128 GCM |
SHA256 (SHA-2) |
TLS 1.2のみ |
|
ECDHE_ECDSA |
AES 128 CBC |
SHA-1 |
TLS 1.0以降 |
|
ECDHE_ECDSA |
AES 128 CBC |
SHA256 (SHA-2) |
TLS 1.2のみ |
|
ECDHE_ECDSA |
AES 256 CBC |
SHA-1 |
TLS 1.0以降 |
|
ECDHE_ECDSA |
AES 256 CBC |
SHA384 (SHA-2) |
TLS 1.2のみ |
|
ECDHE_ECDSA |
AES 256 GCM |
SHA384 (SHA-2) |
TLS 1.2のみ |
|
RSA |
AES 128 CBC |
SHA256 (SHA-2) |
TLS 1.2のみ |
|
RSA |
AES 128 GCM |
SHA256 (SHA-2) |
TLS 1.2のみ |
|
RSA |
AES 128 CBC |
SHA-1 |
TLS 1.0のみ |
|
RSA |
AES 256 CBC |
SHA-1 |
TLS 1.0以降 |
|
RSA |
AES 256 CBC |
SHA256 (SHA-2) |
TLS 1.2のみ |
|
RSA |
AES 256 GCM |
SHA384 (SHA-2) |
TLS 1.2のみ |
表18-2に、使用可能な暗号スイートを示しますが、これらは通信者の認証を提供しないため、介在者攻撃に対して無防備になる可能性があることに注意してください。機密データを保護する場合は、これらの暗号スイートを使用しないことをお薦めします。ただし、これらは、通信者が匿名を維持する場合や、相互認証によって発生するオーバーヘッドを望まない場合に有効です。
表18-2 SSL_DH Secure Sockets Layer暗号スイート
| 暗号スイート | 認証 | 暗号化 | データ整合性 | TLSの互換性 |
|---|---|---|---|---|
|
DH anon |
3DES EDE CBC |
SHA-1 |
TLS 3.0以降 |
SSL_VERSIONパラメータでは、サーバーが通信するシステムで実行する必要があるSSLのバージョンを定義します。
オプションで、sqlnet.oraファイルまたはlistener.oraファイルでSSL_VERSIONパラメータを設定できます。
これらのシステムで有効なバージョンを使用するように設定できます。sqlnet.oraにおけるこのパラメータのデフォルト設定はundeterminedで、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。
注意:
SSL 2.0はサーバー側でサポートされていません。
関連項目:
SSL_VERSIONパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
SSL_CLIENT_AUTHENTICATIONパラメータは、クライアントがSSLを使用して認証されるかどうかを制御します。
このパラメータはサーバーのsqlnet.oraファイルで設定する必要があります。SSL_CLIENT_AUTHENTICATIONパラメータのデフォルト値はTRUEです。
Diffie-Hellman匿名認証(DH_anon)を含む暗号スイートを使用する場合は、SSL_CLIENT_AUTHENTICATIONをFALSEに設定できます。
また、KerberosやRADIUSなどのOracle Databaseでサポートされている非SSL認証方式を使用してクライアントがサーバーに対して自己認証を行うようにする場合も、このパラメータをFALSEに設定できます。
注意:
既知の不具合があり、クライアントを認証しないDH_ANONを含む暗号スイートを使用する場合でも、OCIクライアントでウォレットが必要です。
サーバーでSSL_CLIENT_AUTHENTICATIONをFALSEに設定する手順:
sqlnet.oraファイルのSQLNET.AUTHENTICATION_SERVICESパラメータでは、SSL認証サービスを設定します。
このパラメータは、SSL認証とOracle Databaseでサポートされている別の認証方式を組み合せて使用する場合に設定します。たとえば、サーバーがSSLを使用してクライアントに対して自己認証を行い、クライアントがKerberosを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。
サーバーでSQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、テキスト・エディタを使用して、sqlnet.oraファイルのこのパラメータにSSL (TCPS)付きTCP/IPを追加します。たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。
SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)
SSL認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。
SSLをクライアントで構成する場合、サーバーDNを構成して、SSL付きTCP/IPをクライアントで使用します。
クライアントでウォレットが作成されていることと、クライアントに有効な証明書があることを確認する必要があります。
Oracle Wallet Managerを使用して、ウォレットが作成されていることを確認します。ウォレットの確認の詳細は、「手順1A: サーバーでのウォレット作成の確認」を参照してください。
関連項目:
ウォレットの一般情報は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
既存のウォレットを開く方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
ウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
次に、サーバーDNを構成し、クライアントでSSL付きのTCP/IPを使用します。
内容は次のとおりです。
サーバーDNを含み、クライアントでSSL付きのTCP/IPを使用するようにOracle Net Service名を構成できます。
これを実行するには、クライアント・ネットワーク構成ファイルで、サーバーDNマッチングおよびTCP/IPをSSL接続できるように、プロトコルとしてサーバーの識別名(DN)とTCPSを指定する必要があります。サーバーDNマッチングでは、サーバー証明書からDNに対してサーバーのグローバル・データベース名をマッチングすることで、データベース・サーバーが接続時にクライアントに対するIDの偽装が防止されます。
クライアント・ネットワーク構成ファイルのtnsnames.oraおよびlistener.oraを手動で編集して、サーバーのDNとTCP/IPをSSLプロトコルに指定する必要があります。tnsnames.oraファイルは、クライアントまたはLDAPディレクトリに配置できます。サーバーに配置される場合は、通常、listener.oraファイルと同じディレクトリに存在します。オペレーティング・システムに応じて、これらのファイルは次のディレクトリにあります。
(UNIXの場合) $ORACLE_HOME/network/admin/
(Windowsの場合) ORACLE_BASE\ORACLE_HOME\network\admin\
Oracle Net Managerを使用して、必要なクライアントSSL構成を指定できます。
関連項目:
サーバー照合パラメータの詳細は、次を参照してください。
Oracle Net Managerを使用してSSL付きTCP/IPを構成する方法の詳細は、次を参照してください。
Oracle Database Net Services管理者ガイド
『Oracle Database Net Servicesリファレンス・ガイド』
オプションで、SSL暗号スイートを設定できます。Oracle Databaseには、変更可能なデフォルトの暗号スイート設定が用意されています。
内容は次のとおりです。
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。
SSLハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Databaseをインストールすると、表18-1のSSL暗号スイートがデフォルトで設定されます。2つのエンティティが接続をネゴシエートするときに、この表のリスト順で暗号スイートが試行されます。デフォルトは、SSL_CIPHER_SUITESパラメータを設定して上書きできます。たとえば、Oracle Net Managerを使用して暗号スイートSSL_RSA_WITH_RC4_128_SHAを追加する場合、デフォルト設定の他のすべての暗号スイートは無視されます。
暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。
使用するセキュリティ・レベル。たとえば、Triple-DES暗号化は、DESよりも強力です。
パフォーマンスへの影響。たとえば、Triple-DES暗号化は、DESよりも低速です。Oracle DatabaseでSSLハードウェア・アクセラレータを使用する方法の詳細は、「ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成」を参照してください。
管理要件。クライアントに対して選択された暗号スイートは、サーバーに必要な暗号スイートと互換性がある必要があります。たとえば、Oracle Call Interface (OCI)ユーザーの場合、サーバーはクライアントに自己認証を求めます。この場合、証明書の交換を許可しないDiffie-Hellman匿名認証を利用する暗号スイートは使用できません。
通常、暗号スイートは最も強力なものから弱いものの順に優先順位を設定します。
表18-1に、現在サポートされているSecure Sockets Layer暗号スイートを示します。これらの暗号スイートは、Oracle Databaseをインストールするとデフォルトで設定されます。表では、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプも示されています。
注意:
sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATIONパラメータをtrueに設定する場合は、Diffie-Hellman匿名認証を使用するすべての暗号スイートを無効にします。設定しない場合、接続に失敗します。
SSL_VERSIONパラメータでは、クライアントが通信するシステムで実行する必要があるSSLのバージョンを定義します。
sqlnet.oraファイルでSSL_VERSIONパラメータを設定する必要があります。これらのシステムで有効なバージョンを使用するように設定できます。
sqlnet.oraにおけるこのパラメータのデフォルト設定はundeterminedで、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。「任意」を選択すると、TLS 1.0が最初に試行され、その後、SSL 3.0、SSL 2.0の順に試行されます。クライアントのSSLバージョンがサーバーで使用されているバージョンと互換性があることを確認します。
SQLNET.AUTHENTICATION_SERVICESパラメータは、SSL認証とOracle Databaseでサポートされている別の認証方式の併用を可能にします。
たとえば、サーバーがSSLを使用してクライアントに対して自己認証を行い、クライアントがRADIUSを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。
SQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、sqlnet.oraファイル(他のネットワーク構成ファイルと同じディレクトリにあります)を編集する必要があります。
プラットフォームに応じて、sqlnet.oraファイルは次のディレクトリにあります。
(UNIXの場合) $ORACLE_HOME/network/admin
(Windowsの場合) ORACLE_BASE\ORACLE_HOME\network\admin\
sqlnet.oraファイルでSQLNET.AUTHENTICATION_SERVICESパラメータを設定できます。
クライアントのSQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、テキスト・エディタを使用して、sqlnet.oraファイルのこのパラメータにSSL付きTCP/IP (TCPS)を追加します。
たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。
SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)
SSL認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。
sqlnet.oraファイルのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータは、データベース・サーバー認証時に使用する証明書を指定します
セキュリティ・モジュールに複数の証明書があるが、1つの証明書のみにクライアント認証の拡張鍵使用方法フィールドがあり、その証明書がまさに、データベースの認証に使用する証明書である場合、SQLNET.SSL_EXTENDED_KEY_USAGEパラメータを設定します。
たとえば、スマートカードに複数の証明書があり、そのうちの1つのみにclient authenticationの拡張鍵使用方法フィールドがあり、その証明書Cをデータベースの認証に使用する場合、このパラメータを設定します。Windowsクライアントでこのパラメータをclient authenticationに設定すると、MSCAPI証明書の選択ボックスが表示され、証明書Cが自動的に、サーバーへのクライアントのSSL認証に使用されます。
SQLNET.SSL_EXTENDED_KEY_USAGEを設定して、クライアント認証を設定できます。
クライアントのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータを設定するには、sqlnet.oraファイルを編集し、次の行を含めます。
SQLNET.SSL_EXTENDED_KEY_USAGE = "client authentication"
証明書のフィルタ処理を使用しない場合は、sqlnet.oraファイルからSQLNET.SSL_EXTENDED_KEY_USAGEパラメータ設定を削除します。
構成の完了後、データベースにログインします。
SQL*Plusを起動して、次のいずれかの接続コマンドを入力します。
クライアントにSSL認証を使用する場合は(sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATION=trueを設定)、次のように入力します。
CONNECT/@net_service_name
SSL認証を使用しない場合は(sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATION=falseを設定)、次のように入力します。
CONNECT username@net_service_name Enter password: password
関連項目:
証明書失効リストで証明書を検証するようにクライアントを構成する方法の詳細は、証明書失効リストによる証明書の検証を参照してください
Oracle Database SSLアダプタの使用中に一般的なエラーが発生する場合があります。
Oracle Netトレースを有効にして、エラーの原因を特定することが必要になる場合があります。トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
原因: 指定されたファイルをオープンできませんでした。通常、このエラーはウォレットが見つからないために発生します。
原因: 暗号化された秘密鍵の復号化に不正なパスワードが使用されました。このことは、多くの場合、自動ログイン・ウォレットが使用されていないために発生します。
原因: これは、2つのプロセス間のSSLハンドシェイク・ネゴシエーション中に発生する可能性がある一般的なエラーです。
原因: SSLプロトコルの一部である2つのプロセス間のネゴシエーション中にエラーが発生しました。このエラーは、両プロセスの接続で同じ暗号スイートがサポートされていない場合に発生する可能性があります。
原因: このエラーは、ピアが接続をクローズしたために発生しました。
原因: 基礎となるトランスポート層でエラーが発生したか、ピア・プロセスが突然停止したため、SSL接続がクローズしました。
原因: ピアが証明連鎖を提示したときに、その証明連鎖のチェックに失敗しました。この失敗の原因として、いくつかの問題が考えられます。
連鎖内のいずれかの証明書が期限切れになっています。
連鎖内のいずれかの証明書の認証局がトラスト・ポイントとして認識されていません。
いずれかの証明書の署名を検証できません。
原因: 証明書は、適切なX.509バージョン3の鍵使用方法の拡張機能を使用して作成されていません。
原因: 反対側から送信された証明書の妥当性チェックに失敗しました。このエラーは、証明書が期限切れか、失効済か、または他の理由で無効になっている場合に発生する可能性があります。
原因: インストールする証明書の既存のトラスト・ポイントを使用して証明連鎖を作成できません。通常、このエラーは、ピアによって完全な連鎖が提供されず、連鎖を完了するのに適切なトラスト・ポイントがない場合に戻されます。
オラクル社では、証明書失効リストを使用して証明書を検証できるツールを提供しています。
内容は次のとおりです。
指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。
証明書の検証には、次が該当するかどうかの判定が含まれます。
信頼できる認証局(CA)にデジタル署名された証明書があるかどうか。
証明書のデジタル署名が、証明書自体の別個に計算されたハッシュ値および証明書の署名者の(CAの)公開鍵に対応しているかどうか。
証明書が期限切れになっていないかどうか。
証明書が失効していないかどうか。
SSLネットワーク・レイヤーは、自動的に最初の3つの検証チェックを実行しますが、証明書が失効していないことを確認するには、証明書失効リスト(CRL)のチェックを構成する必要があります。CRLは、失効した証明書のリストを含む署名付きデータ構造体です。これは通常、元の証明書を発行したエンティティと同じエンティティによって発行され署名されます。(「証明書失効リスト(CRL)」を参照。)
使用するトラスト・ポイントすべてについてCRLが必要です。
トラスト・ポイントは、一定の信頼レベルで資格を与えられたサード・パーティ・アイデンティティからの信頼できる証明書です。
通常、信頼する認証局はトラスト・ポイントと呼ばれます。
Oracle Databaseでは証明書の失効状態をCRLに照らして確認します。
CRLはファイル・システム・ディレクトリ(Oracle Internet Directory)に存在するか、または証明書のCRL配布ポイント(CRL DP)拡張で指定された場所からダウンロードして入手します。
通常、CRL定義は数日間有効です。CRLをローカル・ファイル・システムまたはディレクトリに格納する場合、CRLを定期的に更新する必要があります。 CRL配布ポイント(CRL DP)を使用する場合、証明書が使用されるたびにCRLがダウンロードされるため、CRLを定期的に更新する必要はありません。
サーバーは、次の場所で(ここに示されている順番で)CRLを検索します。システムは、証明書のCAのDNと一致するCRLを検出すると、検索を停止します。
ローカル・ファイル・システム
システムは、まずsqlnet.oraファイルのSSL_CRL_FILEパラメータを確認し、それからSSL_CRL_PATHパラメータを確認します。システムは、これらの2つのパラメータが指定されていない場合、ウォレット・ロケーションで任意のCRLをチェックします。
注意: CRLをローカル・ファイル・システムに格納する場合、orapkiユーティリティを使用してCRLを定期的に更新する必要があります。詳細は、証明書検証用ハッシュ値によるCRLの名前変更を参照してください。
Oracle Internet Directory
サーバーは、ローカル・ファイル・システムでCRLを検出できず、ldap.oraファイルでディレクトリ接続情報が構成されている場合、このディレクトリを検索します。これは、CAの識別名(DN)およびCRLサブツリーのDNを使用してCRLサブツリーを検索します。
ディレクトリでCRLを検索するためには、サーバーに、適切に構成されたldap.oraファイルが存在している必要があります。Oracle Internet Directoryのドメイン・ネーム・システム(DNS)検出機能は使用できません。また、CRLをディレクトリに格納する場合、orapkiユーティリティを使用してCRLを定期的に更新する必要があることに注意してください。詳細は、Oracle Internet DirectoryへのCRLのアップロードを参照してください
CRL DP
CAが、証明書が発行されたときのCRL DP X.509、バージョン3、証明書拡張子内の位置を指定すると、その証明書用の失効情報を含む適切なCRLがダウンロードされます。現在、Oracle Databaseは、LDAPを介したCRLのダウンロードをサポートしています。
次のことに注意してください。
パフォーマンス上の理由から、ユーザー証明書のみがチェックされます。
CRLをローカル・ファイル・システムではなくディレクトリに格納することをお薦めします。
sqlnet.oraファイルを編集して、証明書失効リストによる証明書検証を構成できます。
内容は次のとおりです。
証明書失効ステータス・チェックを有効にするには、sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータをREQUIREDまたはREQUESTEDに設定する必要があります。
証明書失効ステータス・チェックを有効にするには、sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータをREQUIREDまたはREQUESTEDに設定する必要があります。
デフォルトでは、このパラメータはNONEに設定され、証明書失効ステータス・チェックはオフになっています。
注意:
CRLをローカル・ファイル・システムまたはOracle Internet Directoryに格納する場合は、コマンドライン・ユーティリティorapkiを使用して、ファイル・システム内のCRLの名前を変更するか、CRLをディレクトリにアップロードします。orapkiの使用方法の詳細は、証明書失効リストの管理を参照してください。
クライアントまたはサーバー用の証明書失効ステータス・チェックを有効にできます。
必須: 証明書失効ステータス・チェックが必須です。証明書が失効しているかCRLが見つからない場合、SSL接続は拒否されます。証明書がまだ失効していないことが確認された場合にのみ、SSL接続は許可されます。
リクエスト済: CRLが使用可能な場合に、証明書失効ステータス・チェックを実行します。証明書が失効している場合、SSL接続は拒否されます。CRLが見つからない場合や、証明書がまだ失効していない場合、SSL接続は許可されます。
パフォーマンス上の理由から、ユーザー証明書の失効のみがチェックされます。
証明書失効リストの管理では、証明書失効チェックを有効にする前に、CRLが正しい書式であることを確認する必要があります。
内容は次のとおりです。
Oracle Databaseには、証明書の管理を実行するために使用できるコマンドライン・ユーティリティorapkiがあります。
証明書失効ステータス・チェックを有効にするには、まず、使用するCAから受信したCRLがコンピュータで使用できるフォームである(ハッシュ値で名前変更されている)こと、またはコンピュータで使用できる場所にある(ディレクトリにアップロードされている)ことを確認してください。
LDAPコマンドライン・ツールを使用して、Oracle Internet DirectoryでCRLを管理することもできます。
注意:
CRLは、正常な検証を行うために、(期限切れになる前に)定期的に更新する必要があります。このタスクは、スクリプトでorapkiコマンドを使用して自動化できます。
CRLの管理に使用可能なorapkiコマンドをすべて表示できます。
CRLの管理に使用可能なorapkiコマンドとそのオプションをすべての表示するには、コマンドラインに次のように入力します。
orapki crl help
注意:
-summary、-completeまたは-walletコマンド・オプションの使用は、常にオプションです。これらのコマンド・オプションが指定されていなくても、コマンドは実行されます。
システムは、証明書を検証するとき、証明書を作成したCAが発行するCRLを見つける必要があります。
システムは、証明書の発行者名とCRLにある発行者名を照合して適切なCRLを検出します。
Oracle Net Managerの「証明書失効リスト・パス」フィールドにCRL格納場所を指定する(sqlnet.oraファイルのSSL_CRL_PATHパラメータを設定する)場合、orapkiユーティリティを使用して発行者名を表すハッシュ値を使用してCRLを名前変更します。ハッシュ値を作成すると、サーバーでCRLをロードできます。
UNIXオペレーティング・システムでは、orapkiによってCRLへのシンボリック・リンクが作成されます。Windowsオペレーティング・システムでは、CRLファイルのコピーが作成されます。どちらの場合も、orapkiによって作成されたシンボリック・リンクまたはコピーは、発行者名のハッシュ値を使用して名前が付けられます。その後、システムが証明書を検証するとき、同じハッシュ関数が使用されて、適切なCRLをロードできるようにリンク(またはコピー)の名前が計算されます。
オペレーティング・システムに応じて、次のコマンドのいずれかを入力して、ファイル・システムに格納されているCRLの名前を変更します。
UNIXファイル・システムに格納されているCRLの名前を変更するには:
orapki crl hash -crl crl_filename [-wallet wallet_location] -symlink crl_directory [-summary]
Windowsファイル・システムに格納されているCRLの名前を変更するには:
orapki crl hash -crl crl_filename [-wallet wallet_location] -copy crl_directory [-summary]
この指定では、crl_filenameはCRLファイルの名前、wallet_locationはCRLを発行したCAの証明書を含むウォレットの場所、crl_directoryはCRLがあるディレクトリです。
-walletおよび-summaryの使用はオプションです。-walletを指定すると、CRLの名前を変更する前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。-summaryオプションを指定すると、ツールによってCRL発行者名が表示されます。
ディレクトリでCRLを発行すると、企業全体でのCRL検証が可能になり、個々のアプリケーションに固有のCRLを構成する必要がなくなります。
すべてのアプリケーションで、一元的に管理可能なディレクトリに格納されたCRLを使用できるので、CRL管理および使用の管理オーバーヘッドが大幅に減ります。orapkiを使用してディレクトリにCRLをアップロードするユーザーは、ディレクトリ・グループCRLAdmins(cn=CRLAdmins,cn=groups,%s_OracleContextDN%)のメンバーである必要があります。これらのCRLには企業全体でアクセスできるため、これは特権操作です。この管理ディレクトリ・グループに追加するには、ディレクトリ管理者に連絡してください。
CRLをディレクトリにアップロードするには:
orapki crl upload -crl crl_location -ldap hostname:ssl_port -user username [-wallet wallet_location] [-summary]
この指定では、crl_locationはCRLがあるファイル名またはURL、hostnameおよびssl_port(認証なしのSSLポート)はディレクトリがインストールされているシステムに対するもの、usernameはCRLをCRLサブツリーに追加する権限があるディレクトリ・ユーザー、wallet_locationはCRLを発行したCAの証明書を含むウォレットの場所です。
-walletおよび-summaryの使用はオプションです。-walletを指定すると、CRLをディレクトリにアップロードする前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。-summaryオプションを指定すると、CRL発行者名、およびCRLがディレクトリに格納されているLDAPエントリがツールによって出力されます。
次の例では、orapkiユーティリティを使用してCRLをアップロードする方法を示しています。
orapki crl upload -crl /home/user1/wallet/crldir/crl.txt -ldap host1.example.com:3533 -user cn=orcladmin
注意:
orapkiユーティリティを使用すると、この操作の実行時にディレクトリ・パスワードの入力を求めるプロンプトが表示されます。
Diffie-HellmanベースのSSLサーバーが実行されているディレクトリのSSLポートを指定していることを確認してください。これは、認証を実行しないSSLポートです。サーバー認証も相互認証SSLポートも、orapkiユーティリティではサポートされていません。
orapkiを使用してディレクトリに格納されているすべてのCRLのリストを表示できます。特定のCRLを検出してローカル・コンピュータで表示またはダウンロードする際に、このリストを参照すると便利です。
このコマンドを使用すると、CRLを発行したCA(発行者)およびディレクトリのCRLサブツリー内の場所(DN)が表示されます。
Oracle Internet DirectoryでCRLを一覧表示するには:
orapki crl list -ldap hostname:ssl_port
hostnameおよびssl_portは、ディレクトリがインストールされているシステムに対するものです。これは、前の項で説明した認証なしのディレクトリのSSLポートであることに注意してください。
Oracle Internet Directory CRLは要約された形式で表示できるほか、CRLの失効した証明書のリストを要求することもできます。
Oracle Internet Directoryに格納されているCRLを要約された形式で表示するか、CRLの失効した証明書の完全なリストを要求できます。
サマリー・リストには、CRL発行者名およびその有効期間が記載されています。完全なリストには、そのCRLに含まれるすべての失効した証明書のリストが記載されています。
Oracle Internet DirectoryでCRLのサマリー・リストを表示するには:
orapki crl display -crl crl_location [-wallet wallet_location] -summary
crl_locationはディレクトリ内のCRLの場所です。orapki crl listコマンドを使用すると表示されるリストからCRLの位置を貼り付けると便利です。Oracle Internet Directoryに格納されているCRLの一覧表示を参照してください。
Oracle Internet Directoryに格納されている指定したCRLに含まれているすべての失効した証明書のリストを表示するには、コマンドラインに次のように入力します。
orapki crl display -crl crl_location [-wallet wallet_location] -complete
たとえば、orapkiコマンドを次のように入力します。
orapki crl display -crl $T_WORK/pki/wlt_crl/nzcrl.txt -wallet $T_WORK/pki/wlt_crl -complete
次の出力が生成されます。これには、CRL発行者のDN、発行日、次の更新日、および含まれる失効した証明書が示されます。
issuer = CN=root,C=us, thisUpdate = Sun Nov 16 10:56:58 PST 2003, nextUpdate = Mon Sep 30 11:56:58 PDT 2013, revokedCertificates = {(serialNo = 153328337133459399575438325845117876415, revocationDate - Sun Nov 16 10:56:58 PST 2003)}
CRL is valid
-walletオプションを使用すると、orapki crl displayコマンドにより、CAの証明書に対してCRLが検証されます。
-completeオプションを選択すると、CRLのサイズによっては、表示に時間がかかる場合があります。
Oracle Directory Manager(Oracle Internet Directoryに付属するグラフィカル・ユーザー・インタフェース)を使用して、ディレクトリ内のCRLを表示することもできます。CRLは、次のディレクトリの場所に格納されます。
cn=CRLValidation,cn=Validation,cn=PKI,cn=Products,cn=OracleContext
orapkiを使用してディレクトリからCRLを削除するユーザーは、ディレクトリ・グループCRLAdminsのメンバーである必要があります。
このディレクトリ管理グループの詳細は、Oracle Internet DirectoryへのCRLのアップロードを参照してください。
CRLをディレクトリから削除するには:
orapki crl delete -issuer issuer_name -ldap host:ssl_port -user username [-summary]
ここで、issuer_nameはCRLを発行したCAの名前、hostnameおよびssl_portはディレクトリがインストールされているシステムに対するもの、usernameはCRLをCRLサブツリーから削除する権限があるディレクトリ・ユーザーです。このポートは、認証を使用しないディレクトリのSSLポートであることが必要です。このポートの詳細は、「Oracle Internet DirectoryへのCRLのアップロード」を参照してください。
-summaryオプションを使用すると、削除されたCRL LDAPエントリがツールによって印刷されます。
たとえば、orapkiコマンドを次のように入力します。
orapki crl delete -issuer "CN=root,C=us" -ldap machine1:3500 -user cn=orcladmin -summary
次の出力が生成されます。これには、ディレクトリ内の削除されたCRLの場所が示されます。
Deleted CRL at cn=root cd45860c.rN,cn=CRLValidation,cn=Validation,cn=PKI,cn=Products,cn=OracleContext
CRLに対して証明書を検証するかどうかを判断するには、Oracle Netトレースを有効にできます。
CRLを使用して失効した証明書を検証すると、Oracle Netトレース・ファイルに次のエントリが記録され、entryとexitの間にエラー・メッセージは記録されません。
nzcrlVCS_VerifyCRLSignature: entry nzcrlVCS_VerifyCRLSignature: exit nzcrlVCD_VerifyCRLDate: entry nzcrlVCD_VerifyCRLDate: exit nzcrlCCS_CheckCertStatus: entry nzcrlCCS_CheckCertStatus: Certificate is listed in CRL nzcrlCCS_CheckCertStatus: exit
注意:
証明書検証に失敗した場合は、SSLハンドシェイク時にピアに「ORA-29024: 証明書の検証に失敗しました」というメッセージが表示されます。このメッセージが表示された場合は、証明書検証に関連するOracle Netトレース・ファイルのエラー・メッセージでエラーの解決方法を参照してください。
関連項目:
トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
証明書検証に関連するトレース・メッセージが生成されます。
これらのトレースメッセージは、Oracle Netトレース・ファイルのentryエントリとexitエントリの間に記録されることがあります。Oracle SSLは複数の場所でCRLを検索するため、トレースに複数のエラーが記録されることがあります。
エラーの解決方法の詳細は、次の表示される可能性があるエラー・メッセージのリストを確認できます。
原因: CRLの署名を検証できません。
原因: 現在の時刻が次の更新フィールド内の時刻より後になっています。このエラーは、CRL DPを使用している場合には表示されません。CRLは次の順番で検索されます。
ファイル・システム
Oracle Internet Directory
CRL DP
この検索で最初に見つかったCRLが最新であるとはかぎりません。
原因: 構成されている場所にCRLがありませんでした。構成で証明書検証が必須に指定されている場合、エラーORA-29024が戻されます。
原因: Oracle Internet Directoryの接続情報が設定されていません。これは致命的エラーではありません。続いてCRL DPが検索されます。
原因: CRL配布ポイント(CRL DP)を使用してCRLをフェッチできませんでした。このことは、証明書にCRL DP拡張で指定された場所がないか、CRL DP拡張で指定されたURLが正しくない場合に発生します。
Oracle Databaseでは、RSA Security社のPKCS #11仕様に準拠したAPIを使用するハードウェア・セキュリティ・モジュールがサポートされています。
通常、これらのハードウェア・デバイスは、トークンまたはスマートカードの秘密鍵を安全に格納および管理するため、または暗号処理を高速化するために使用されます。
内容は次のとおりです。
Oracle Databaseでハードウェア・セキュリティ・モジュールを使用する場合は、次のガイドラインに従ってください。
必要なハードウェア、ソフトウェアおよびPKCS #11ライブラリを取得するには、ハードウェア・デバイス・ベンダーにお問い合せください。
使用しているハードウェア・セキュリティ・モジュールに適したハードウェア、ソフトウェアおよびライブラリをインストールします。
ハードウェア・セキュリティ・モジュールのインストールをテストして、正常に動作することを確認します。詳細は、使用するデバイスのドキュメントを参照してください。
秘密鍵をトークンに格納する場合は、Oracle Wallet Managerを使用してPKCS11タイプのウォレットを作成し、PKCS #11ライブラリへの絶対パス(ライブラリ名を含む)を指定します。Oracle PKCS11ウォレットには、秘密鍵にアクセスするためのトークンを指す情報が格納されます。
PKCS #11情報が格納されたウォレットは、任意のOracleウォレットを使用する場合と同様に使用できます。ただし、秘密鍵をハードウェア・デバイスに格納し、暗号操作もそのデバイスで実行する場合を除きます。
関連項目:
ハードウェア・セキュリティ・モジュールの証明書を格納するためにOracleウォレットを作成する方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
暗号化処理でnCipherハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。
内容は次のとおりです。
nCipher社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。
これらのモジュールでは、鍵を安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。
暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。
デバイス上の秘密鍵の記憶領域が保護されます。
スマートカードを使用して鍵を管理できます。
注意:
Oracle Databaseで使用する認定済のハードウェアおよびソフトウェアを入手するには、nCipherの代理店にお問い合せください。
nCipherハードウェア・セキュリティ・モジュールを使用するには、特別なコンポーネントのセットが必要です。
これらのコンポーネントは次のとおりです。
nCipherハードウェア・セキュリティ・モジュール
サポートしているnCipher PKCS #11ライブラリ
次のプラットフォーム固有のPKCS#11ライブラリが必要です。
libcknfast.soライブラリ(UNIX 32ビットの場合)
libcknfast-64.soライブラリ(UNIX 64ビットの場合)
cknfast.dllライブラリ(Windowsの場合)
注意:
ハードウェア・セキュリティ・モジュールまたはセキュア・アクセラレータをインストールし、必要なライブラリを入手するには、nCipherの代理店にお問い合せください。
これらの作業は、Oracle DatabaseでnCipherハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。
nCipherハードウェア・セキュリティ・モジュールはnCipher PKCS #11ライブラリを使用します。
セキュア・アクセラレータを使用するには、Oracle Wallet Managerを使用してウォレットを作成するときに、nCipher PKCS #11ライブラリが格納されているディレクトリへの絶対パス(ライブラリ名を含む)を指定する必要があります。これにより、実行時にライブラリをロードできます。
通常、nCipherカードは次の場所にインストールされます。
/opt/nfast (UNIXの場合)
C:\nfast (Windowsの場合)
nCipher PKCS #11ライブラリは、通常のインストールでは次の場所に配置されます。
/opt/nfast/toolkits/pkcs11/libcknfast.so(UNIX 32ビットの場合)
/opt/nfast/toolkits/pkcs11/libcknfast-64.so(UNIX 64ビットの場合)
C:\nfast\toolkits\pkcs11\cknfast.dll (Windowsの場合)
注意:
Oracle Databaseの32ビット・リリースを使用する場合は32ビット・ライブラリ・バージョンを使用し、Oracle Databaseの64ビット・リリースを使用する場合は64ビット・ライブラリ・バージョンを使用します。たとえば、Oracle Database for Solaris Operating System (SPARC 64ビット)には、64ビットnCipher PKCS #11ライブラリを使用します。
暗号化処理でSafeNETハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。
内容は次のとおりです。
SafeNET社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。
これらのモジュールでは、鍵を安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。
暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。
デバイス上の秘密鍵の記憶領域が保護されます。
注意:
Oracle Databaseで使用する認定済のハードウェアおよびソフトウェアを入手するには、SafeNETの代理店にお問い合せください。
SafeNET Luna SAハードウェア・セキュリティ・モジュールを使用するには、特別なコンポーネントのセットが必要です。
これらのコンポーネントは次のとおりです。
SafeNET Luna SAハードウェア・セキュリティ・モジュール
サポートしているSafeNET Luna SA PKCS #11ライブラリ
次のプラットフォーム固有のPKCS#11ライブラリが必要です。
libCryptoki2.soライブラリ(UNIXの場合)
cryptoki.dllライブラリ(Windowsの場合)
注意:
ハードウェア・セキュリティ・モジュールまたはセキュア・アクセラレータをインストールし、必要なライブラリを入手するには、SafeNETの代理店にお問い合せください。
これらの作業は、Oracle DatabaseでSafeNETハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。
SafeNETハードウェア・セキュリティ・モジュールはSafeNET PKCS #11ライブラリを使用します。
セキュア・アクセラレータを使用するには、Oracle Wallet Managerを使用してウォレットを作成するときに、SafeNET PKCS #11ライブラリが格納されているディレクトリへの絶対パス(ライブラリ名を含む)を指定する必要があります。これにより、実行時にライブラリをロードできます。
通常、SafeNET Luna SAクライアントは次の場所にインストールされます。
/usr/lunasa (UNIXの場合)
C:\Program Files\LunaSA (Windowsの場合)
SafeNET Luna SA PKCS #11ライブラリは、通常のインストールでは次の場所に配置されます。
/usr/lunasa/lib/libCryptoki2.so (UNIXの場合)
C:\Program Files\LunaSA\cryptoki2.dll (Windowsの場合)
ハードウェア・セキュリティ・モジュールに関するトラブルシューティングのアドバイスを提供します。
内容は次のとおりです。
使用されているモジュールを検出するには、Oracle Netトレースをオンにします。
ウォレットにPKCS #11情報が含まれ、モジュールの秘密鍵が使用されている場合は、Oracle Netトレースに次のエントリが記録され、entryとexitの間にエラー・メッセージは記録されません。
nzpkcs11_Init: entry nzpkcs11CP_ChangeProviders: entry nzpkcs11CP_ChangeProviders: exit nzpkcs11GPK_GetPrivateKey: entry nzpkcs11GPK_GetPrivateKey: exit nzpkcs11_Init: exit ... nzpkcs11_Decrypt: entry nzpkcs11_Decrypt: exit nzpkcs11_Sign: entry nzpkcs11_Sign: exit
関連項目:
トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
PKCS #11ハードウェア・セキュリティ・モジュールの使用に関連するエラーが表示される場合があります。
原因: ウォレットの作成時に指定された場所にPKCS #11ライブラリが見つかりません。これは、ウォレットの作成後にライブラリが移動された場合にのみ発生します。
原因: ウォレットの作成に使用されたスマートカードがハードウェア・セキュリティ・モジュールのスロットにありません。
原因: これは、ウォレットの作成時に指定されたパスワードが正しくない場合、またはウォレットの作成後にPKCS #11デバイス・パスワードを変更し、Oracle Wallet Managerを使用してウォレットで更新しなかった場合に発生する可能性があります。
関連項目:
ハードウェア・セキュリティ証明書を格納するためにOracleウォレットを作成する方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
注意:
nCipherログ・ファイルは、モジュールがインストールされているディレクトリの次の場所にあります。
/log/logfile
関連項目:
nCipherデバイスとSafeNETデバイスのトラブルシューティングの詳細は、nCipherとSafeNETのドキュメントを参照してください。
