| Oracle® Database Advanced Security管理者ガイド 11gリリース2 (11.2) B56286-10 |
|
 前 |
 次 |
この章では、Oracle Advanced SecurityによってサポートされているSecure Sockets Layer (SSL)プロトコルとTransport Layer Security (TLS)プロトコルを構成して使用する方法について説明します。内容は次のとおりです。
Secure Sockets Layer (SSL)は、ネットワーク接続のセキュリティのために最初にNetscape社によって設計された業界標準プロトコルです。SSLでは、RSA公開鍵暗号化および対称鍵暗号化を組み合せて使用して、認証、暗号化およびデータ整合性を提供します。
この項の内容は次のとおりです。
SSLは最初にNetscape社によって開発されましたが、Internet Engineering Task Force (IETF)がその開発を引き継ぎ、名前をTransport Layer Security (TLS)に変更しました。基本的には、TLSはSSLバージョン3.0に段階的改善を加えるものです。
TLSバージョン1.1または1.2を使用する場合、次のいずれかのパッチをMy Oracle Supportからダウンロードします。
Linuxシステム: パッチ19207156: MES BUNDLE ON TOP OF RDBMS 11.2.0.4.2 DBPSU (April 2014 PSUが必要
Microsoft Windowsシステム: パッチ19651773: WINDOWS DB BUNDLE PATCH 11.2.0.4.10
Oracle Advanced Securityでは、これらのプロトコルのネイティブ暗号化およびデータ整合性機能だけでなく、SSL上でデジタル証明書を使用する認証をサポートします。
Oracle Advanced SecurityのSSL機能を使用してクライアントとサーバー間の通信を保護すると、次の操作を実行できます。
SSLを使用したクライアントとサーバー間の接続の暗号化
SSL通信用に構成されたOracleデータベース・サーバーに対するクライアントまたはサーバー(Oracle Application Server 10gなど)の認証
SSL機能は、単独で使用するか、Oracle Advanced Securityでサポートされている他の認証方式と組み合せて使用できます。たとえば、SSLから提供されている暗号化をKerberosから提供されている認証と組み合せて使用できます。SSLでは、次の認証モードがサポートされます。
サーバーのみ、クライアントに対して自己認証を行います。
クライアントとサーバーは、互いに自己認証を行います。
クライアントもサーバーも、互いに自己認証を行わず、SSL暗号化機能を単独で使用します。
|
関連項目:
|
SSLを介したネットワーク接続が開始されると、クライアントとサーバーでは次のようなステップを含むSSLハンドシェイクが実行されます。
クライアントとサーバーは、どの暗号スイートを使用するかを設定します。これには、データ転送に使用する暗号化アルゴリズムも含まれます。
サーバーは証明書をクライアントに送信し、クライアントは、サーバーの証明書が信頼できるCAによって署名されていることを検証します。このステップにより、サーバーの身元が検証されます。
同様に、クライアント認証が必要な場合は、クライアントが自分自身の証明書をサーバーに送信し、サーバーは、クライアントの証明書が信頼できるCAによって署名されているかどうかを検証します。
クライアントとサーバーが、公開鍵暗号化を使用して鍵情報を交換します。この情報に基づき、双方でセッション鍵が生成されます。クライアントとサーバーとの間の以降の通信はすべて、このセッション鍵と、ネゴシエーションにより決定した暗号スイートを使用して、暗号化または復号化されます。
クライアントで、ユーザーがSSLを使用してサーバーへのOracle Net接続を開始します。
SSLは、クライアントとサーバー間のハンドシェイクを実行します。
ハンドシェイクが成功すると、サーバーは、そのデータベースにアクセスするために必要な認可をユーザーが所有していることを検証します。
この項の内容は次のとおりです。
公開鍵インフラストラクチャ(PKI)は、組織全体のセキュリティ基盤を提供するネットワーク・コンポーネントの基質であり、信頼アサーションに基づいています。PKIが存在するのは、異なるネットワーク・エンティティが必要に応じて公開鍵暗号化を使用するセキュリティ・サービスにアクセスできるようにするためです。Oracleでは、RSA Security社の公開鍵暗号規格に基づき、Oracleサーバーおよびクライアントと相互運用する完全な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 Advanced Securityは、新規ウォレットの作成時にVeriSign社、RSA社、Entrust社およびGTE CyberTrust社から信頼できる証明書を自動的にインストールします。
Oracle Identity Managementインフラストラクチャの一部であるOracle Application Server Certificate Authorityは、Oracle Application Server 10g (9.0.4)で利用できる新しいOracle PKIコンポーネントです。
証明書は、エンティティの公開鍵が、信頼できる認証局(CA)によって署名されたときに作成されます。この証明書は、そのエンティティの識別情報が正しいこと、および公開鍵がそのエンティティに実際に属していることを保証します。
証明書には、エンティティの名前、公開鍵、有効期限、さらにシリアル番号および証明連鎖情報が含まれています。また、証明書に関連付けられた権限に関する情報が含まれている場合もあります。
ネットワーク・エンティティが証明書を受信すると、それが信頼できる証明書、つまり信頼できる認証局によって発行および署名された証明書であるか検証します。証明書は、期限切れになるか失効するまで有効です。
通常、公開鍵ペアをユーザー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 11g リリース2 (11.2)のSSLアダプタでのみ使用できます。 |
ウォレットは、認証および署名資格証明(SSLで必要な秘密鍵、証明書、信頼できる証明書など)の格納に使用されるコンテナです。Oracle環境では、SSL通信を行うどのエンティティにも、X.509バージョン3の証明書、秘密鍵および信頼できる証明書のリストが必要です。ただし、Diffie-Hellmanは例外です。
セキュリティ管理者は、サーバーのセキュリティ資格証明の管理にOracle Wallet Managerを使用します。ウォレットの所有者は、クライアントのセキュリティ資格証明の管理に使用します。具体的には、Oracle Wallet Managerは次のことを行うために使用します。
公開鍵と秘密鍵のペアの生成および証明書リクエストの作成
秘密鍵と一致するユーザー証明書の格納
信頼できる証明書の構成
|
注意: Oracle Advanced Security 11g リリース2 (11.2)をインストールすると、Oracle Wallet Managerリリース10.1もインストールされます。 |
Oracle Advanced Securityでは、これらのデバイスを次の機能に使用します。
秘密鍵などの暗号情報の格納
他のトランザクションに応答できるようにCPUを解放して、サーバーにおけるRSA操作の負荷を軽減する暗号操作の実行
暗号情報は、次の2つのタイプのハードウェア・デバイスに格納できます。
(サーバー側)鍵がボックスに格納され、トークンを使用して管理されるハードウェア・ボックス。
(クライアント側)トークンへの秘密鍵の格納をサポートするスマートカード・リーダー
Oracle環境では、RSA Security社の公開鍵暗号規格(PKCS)#11仕様に準拠しているAPIを使用したハードウェア・デバイスがサポートされています。
|
注意: 現在、SafeNETおよびnCipherデバイスがOracle Advanced Securityで認定されています。 |
SSLを次の各項で説明するデータベースのユーザー名とパスワード、RADIUSおよびKerberosと同時に使用するようにOracle Advanced Securityを構成できます。
Oracle Advanced Securityの実装アーキテクチャを示す図1-4では、Oracle Advanced SecurityがSSLの上位のセッション・レイヤーで動作し、トランスポート・レイヤーでTCP/IPを使用しています。このように機能が分離されているため、SSLを他のサポートされているプロトコルと同時に利用できます。
|
関連項目: Oracleネットワーキング環境におけるスタック通信の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
図13-1は、SSLがOracle Advanced Securityによってサポートされている別の認証方式と併用されている構成を示しています。
この例では、最初のハンドシェイク(サーバー認証)を確立するためにSSLが使用され、クライアントの認証に別の認証方式が使用されています。
クライアントがOracleデータベース・サーバーに接続しようとします。
SSLによってハンドシェイクが実行され、その間にサーバーがクライアントに対して自己認証を行い、クライアントとサーバーの両方が使用する暗号スイートを設定します。
SSLハンドシェイクが正常に完了すると、ユーザーはデータベースにアクセスしようとします。
Oracleデータベース・サーバーは、KerberosやRADIUSなどの非SSL認証方式を使用して、認証サーバーでユーザーを認証します。
認証サーバーによる検証が完了すると、Oracleデータベース・サーバーによってアクセス権と認可がユーザーに付与され、ユーザーはSSLを使用してデータベースに安全にアクセスできるようになります。
Oracle Advanced Securityでは、2つのタイプのファイアウォールがサポートされています。
Network Associates GauntletやAxent Raptorなどのアプリケーション・プロキシベースのファイアウォール
Check Point Firewall-1やPIX Firewallなどのステートフル・パケット・インスペクション・ファイアウォール
SSLを有効にした場合、ステートフル・インスペクション・ファイアウォールは暗号化されたパケットを復号化しないため、アプリケーション・プロキシ・ファイアウォールと同じように動作します。
ファイアウォールは暗号化されたトラフィックを検査しません。ファイアウォールは、イントラネット・サーバーのSSLポート宛てのデータを検出すると、アクセス・ルールに基づいてターゲットIPアドレスを確認し、許可されたSSLポートに対してはSSLパケットを通過させ、他のすべてのパケットは拒否します。
いくつかのファイアウォール・ベンダーが提供しているOracle Net Firewall Proxyキットを使用すると、ファイアウォール・アプリケーションでデータベース・ネットワーク・トラフィックがサポートされます。プロキシ・キットをファイアウォールに実装すると、次の処理が実行されます。
Net Proxy (Oracle Net Firewall Proxyキットのコンポーネント)によってトラフィックのルーティング先が決定されます。
データベース・リスナーは、SSLハンドシェイクに参加するために、証明書へのアクセスを要求します。リスナーはSSLパケットを検査し、ターゲット・データベースを識別して、ターゲット・データベースがクライアントのリスニングに使用しているポートを戻します。このポートは、SSLポートとして指定されている必要があります。
クライアントは、以降のすべての接続でこのサーバー指定ポートを使用して通信します。
SSLを使用する場合は、次のことを考慮してください。
SSLを使用すると、Oracle Internet Directoryなどの他のOracle製品との安全な通信が可能になります。
SSLでは認証と暗号化の両方がサポートされているため、クライアント/サーバー接続が標準のOracle Net TCP/IPトランスポート(ネイティブ暗号化を使用)より多少遅くなります。
各SSL認証モードには、構成設定が必要となります。
マルチスレッド・クライアントでは、現在SSLを使用できません。
Oracle Advanced Securityをクライアントとサーバーの両方にインストールします。このとき、Oracle Universal Installerによって、SSLライブラリとOracle Wallet Managerがコンピュータに自動的にインストールされます。
|
関連項目: Oracle Databaseプラットフォーム固有のインストール関連ドキュメント |
インストール中、Oracleデータベース・サーバーとOracleクライアントの両方に、Oracleウォレットの場所を除くすべてのSSLパラメータのデフォルトが設定されます。サーバーでSSLを構成するには、次の手順を実行します。
次の手順に進む前に、ウォレットが作成されていることを確認する必要があります。ウォレットの準備が完了していることを確認するには、Oracle Wallet Managerを使用してウォレットを開きます。ウォレットにステータスがReadyの証明書が含まれ、自動ログインがオンになっている必要があります。自動ログインがオンになっていない場合は、「ウォレット」メニューから選択し、ウォレットを再度保存します。自動ログインがオンになります。
Oracle Net Managerを起動します。
(UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。
netmgr
(Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。
「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。
「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。
「SSL」タブをクリックし、「SSL構成: サーバー」を選択します。
「ウォレット・ディレクトリ」ボックスで、Oracleウォレットが配置されているディレクトリを入力するか、「参照」をクリックし、ファイル・システムを検索してディレクトリを探します。
エンタープライズ・ユーザー・セキュリティ用にデータベースとディレクトリ間のSSL接続を構成する場合は、Database Configuration Assistantによって自動的にデータベース・ウォレットが作成され、データベースがディレクトリに登録されます。そのウォレットを使用して、SSLで認証されたエンタープライズ・ユーザー・セキュリティのデータベースPKI資格証明を格納する必要があります。
重要:
Oracle Wallet Managerを使用してウォレットを作成します。「ウォレットの新規作成」を参照してください。
Oracle Net Managerを使用して、sqlnet.oraファイルにウォレット・ロケーションを設定します。
「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルとlistener.oraファイルが次のエントリで更新されます。
wallet_location = (SOURCE= (METHOD=File) (METHOD_DATA= (DIRECTORY=wallet_location)))
|
注意: リスナーでは、listener.oraファイルに定義されているウォレットを使用します。任意のデータベース・ウォレットを使用できます。Net Managerを使用してサーバーのSSLが構成されている場合、ウォレット・ロケーションはlistener.oraファイルとsqlnet.oraファイルに入力されています。listener.oraファイルは、Oracleクライアントには関係ありません。
リスナーが独自のウォレットを所有するようにリスナーのウォレット・ロケーションを変更するには、 |
この項の内容は次のとおりです。
Secure Sockets Layer暗号スイートについて
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。SSLハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Advanced Securityをインストールすると、表13-1のSSL暗号スイートがデフォルトで設定され、リスト順にネゴシエートされます。デフォルトの順序は、SSL_CIPHER_SUITESパラメータを設定して上書きできます。たとえば、Oracle Net Managerを使用して暗号スイートSSL_RSA_WITH_3DES_EDE_CBC_SHAを追加する場合、デフォルト設定の他のすべての暗号スイートは無視されます。
暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。
互換性。正常に接続するには、互換性のある暗号スイートを使用するようにサーバーとクライアントを構成する必要があります。
暗号の優先順位と強度。最高レベルのセキュリティを確保するために、最も強力なものから最も弱いものの順に暗号スイートの優先順位を設定します。
使用するセキュリティ・レベル。たとえば、Triple-DES暗号化は、DESよりも強力です。
パフォーマンスへの影響。たとえば、Triple-DES暗号化は、DESよりも低速です。
|
注意: Diffie-Hellman 匿名認証について:
|
サポートされているSecure Sockets Layer暗号スイート
表13-1に、現行リリースのOracle Advanced SecurityでサポートされているSSL暗号スイートを示します。これらの暗号スイートは、Oracle Advanced Securityをインストールするとデフォルトで設定されます。次の表では、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプも示します。
表13-1 SSL暗号スイート
| 暗号スイート | 認証 | 暗号化 | データ整合性 |
|---|---|---|---|
|
SSL_RSA_WITH_3DES_EDE_CBC_SHA |
RSA |
3DES EDE CBC |
SHA-1 |
|
SSL_RSA_WITH_AES_128_CBC_SHA脚注 1 |
RSA |
AES 128 CBC |
SHA-1 |
|
SSL_RSA_WITH_AES_256_CBC_SHA脚注 1 |
RSA |
AES 256 CBC |
SHA-1 |
脚注 1 AES暗号は、Transport Layer Security (TLS 1.0)でのみ使用できます。
データベース・サーバーのSecure Sockets暗号スイートの指定
(UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。
netmgr
(Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。
「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。
「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。
「SSL」タブを選択し、「SSL構成: サーバー」を選択します。
「暗号スイートの構成」領域で、「追加」をクリックします。
使用可能な暗号スイートがダイアログ・ボックスに表示されます。米国内用の暗号スイートを表示するには、米国内用の暗号スイートの表示チェック・ボックスをクリックします。
スイートを選択し、「OK」をクリックします。
「暗号スイートの構成」リストが更新されます。
上矢印と下矢印を使用して、暗号スイートの優先順位を設定します。
「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルが次のエントリで更新されます。
SSL_CIPHER_SUITES= (SSL_cipher_suite1 [,SSL_cipher_suite2])
sqlnet.oraファイルまたはlistener.oraファイルでSSL_VERSIONパラメータを設定できます。このパラメータでは、サーバーが通信するシステムで実行する必要があるSSLのバージョンを定義します。これらのシステムで有効なバージョンを使用するように設定できます。sqlnet.oraにおけるこのパラメータのデフォルト設定はundeterminedです。これは、「Oracle Advanced Security」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。
サーバーのSSLバージョンを設定するには、次の手順を実行します。
「必要なSSLバージョン」リストのデフォルトは「任意」です。このデフォルトを受け入れるか、使用するSSLバージョンを選択します。
「ファイル」→「ネットワーク構成の保存」を選択します。
「任意」を選択した場合は、sqlnet.oraファイルが次のエントリで更新されます。
SSL_VERSION=UNDETERMINED
|
注意: SSL 2.0はサーバー側でサポートされていません。 |
|
関連項目: SSL_VERSION値の完全なリストについては、『Oracle Database Net Servicesリファレンス』を参照してください |
sqlnet.oraファイルのSSL_CLIENT_AUTHENTICATIONパラメータでは、SSLを使用してクライアントを認証するかどうかを制御します。デフォルト値はTRUEです。
Diffie-Hellman匿名認証(DH_anon)を含む暗号スイートを使用する場合は、このパラメータをFALSEに設定する必要があります。また、KerberosやRADIUSなどのOracle Advanced Securityでサポートされている非SSL認証方式を使用してクライアントがサーバーに対して自己認証を行うようにする場合も、このパラメータをFALSEに設定できます。
|
注意: 既知の不具合があり、クライアントを認証しないDH_ANONを含む暗号スイートを使用する場合でも、OCIクライアントでウォレットが必要です。 |
サーバーでSSL_CLIENT_AUTHENTICATIONをFALSEに設定する手順:
Oracle Net Managerの「SSL」ページで、「クライアントの認証が必要」の選択を解除します。
「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルが次のエントリで更新されます。
SSL_CLIENT_AUTHENTICATION=FALSE
|
関連項目: SSL_CLIENT_AUTHENTICATION値の完全なリストについては、『Oracle Database Net Servicesリファレンス』を参照してください |
sqlnet.oraファイルのSQLNET.AUTHENTICATION_SERVICESパラメータでは、SSL認証サービスを設定します。
このパラメータは、SSL認証とOracle Advanced Securityでサポートされている別の認証方式を組み合せて使用する場合に設定します。たとえば、サーバーがSSLを使用してクライアントに対して自己認証を行い、クライアントがKerberosを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。
サーバーにSQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、テキスト・エディタを使用してsqlnet.oraファイルでこのパラメータにSSL付きTCP/IP(TCPS)を追加します。たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。
SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)
SSL認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。
|
関連項目: AUTHENTICATION_SERVICES値の完全なリストについては、『Oracle Database Net Servicesリファレンス』を参照してください |
listener.oraファイルで、リスナーにSSL付きTCP/IPリスニング・エンドポイントを構成します。一般的なOracle Netクライアントには、ポート番号2484を使用することをお薦めします
|
関連項目:
|
次の手順に進む前に、クライアントでウォレットが作成されていることと、クライアントに有効な証明書があることを確認する必要があります。
|
関連項目:
|
この項の内容は次のとおりです。
サーバーDNSの構成とクライアントの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\
サーバーDNSの構成とクライアントのSSL付きTCP/IPの使用について
クライアントのtnsnames.oraファイルにSSL_SERVER_CERT_DNパラメータを追加して、データベース・サーバーのDNを次のように指定します。
(SECURITY= (SSL_SERVER_CERT_DN="cn=finance,cn=OracleContext,c=us,o=acme"))
クライアントは、この情報を使用して、各サーバーに予定しているDNのリストを取得して、サーバーのDNとそのサービス名が確実に一致するようにします。例13-1に、tnsnames.oraファイルのFinanceデータベースのエントリを示します。
または、管理者はサーバーのDNの共通名(CN)部分がサービス名と一致していることを確認できます。
クライアントのtnsnames.oraファイルに、ADDRESSパラメータのPROTOCOLとしてtcpsと入力します。この指定により、クライアントはSSL付きTCP/IPを使用して、SERVICE_NAMEパラメータに指定されたデータベースに接続します。例13-1は、tnsnames.oraファイル内の接続プロトコルとしてSSL付きTCP/IPを指定するエントリも示しています。
listener.oraファイルに、ADDRESSパラメータのPROTOCOLとしてtcpsと入力します。例13-2に、プロトコルとしてSSL付きTCP/IPを指定するエントリを示します。
Oracle Net Managerを起動します。
(UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。
netmgr
(Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。
「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。
「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。
「SSL」タブを選択します。
「SSL構成: クライアント」を選択します。
「ウォレット・ディレクトリ」ボックスで、Oracleウォレットが配置されているディレクトリを入力するか、「参照」をクリックし、ファイル・システムを検索してディレクトリを探します。
「サーバーX.509の名前に一致」リストから、次のいずれかのオプションを選択します。
「はい」: サーバーの識別名(DN)がそのサービス名と一致している必要があります。SSLによって証明書がサーバーからのものであることが確認され、一致した場合は接続が成功します。
このチェックは、デフォルト設定であるRSA暗号が選択されている場合にのみ実行できます。
「いいえ」(デフォルト): SSLによってDNとサービス名が一致するかどうかが確認されますが、強制はされません。結果に関係なく接続は成功しますが、一致しない場合はエラーが記録されます。
「クライアントで決定」: デフォルトを有効にします。
「いいえ」を選択すると、次のアラートが表示されます。
Security Alert Not enforcing the server X.509 name match allows a server to potentially fake its identity. Oracle recommends selecting YES for this option so that connections are refused when there is a mismatch.
「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
クライアントのsqlnet.oraファイルが次のエントリで更新されます。
SSL_CLIENT_AUTHENTICATION =TRUE wallet_location = (SOURCE= (METHOD=File) (METHOD_DATA= (DIRECTORY=wallet_location))) SSL_SERVER_DN_MATCH=(ON/OFF)
|
関連項目: サーバー照合パラメータの詳細は、次を参照してください。 Oracle Net Managerを使用してSSL付きTCP/IPを構成する方法の詳細は、次を参照してください。
|
この項の内容は次のとおりです。
クライアントのSecure Sockets Layer暗号スイートの設定について
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。SSLハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Advanced Securityをインストールすると、表13-1のSSL暗号スイートがデフォルトで設定されます。2つのエンティティが接続をネゴシエートするときに、この表のリスト順で暗号スイートが試行されます。デフォルトは、SSL_CIPHER_SUITESパラメータを設定して上書きできます。たとえば、Oracle Net Managerを使用して暗号スイートSSL_RSA_WITH_3DES_EDE_CBC_SHAを追加する場合、デフォルト設定の他のすべての暗号スイートは無視されます。
暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。
使用するセキュリティ・レベル。たとえば、Triple-DES暗号化は、DESよりも強力です。
パフォーマンスへの影響。たとえば、Triple-DES暗号化は、DESよりも低速です。Oracle Advanced SecurityでSSLハードウェア・アクセラレータを使用する方法の詳細は、「ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成」を参照してください。
管理要件。クライアントに対して選択された暗号スイートは、サーバーに必要な暗号スイートと互換性がある必要があります。たとえば、Oracle Call Interface (OCI)ユーザーの場合、サーバーはクライアントに自己認証を求めます。この場合、証明書の交換を許可しないDiffie-Hellman匿名認証を利用する暗号スイートは使用できません。
通常、暗号スイートは最も強力なものから弱いものの順に優先順位を設定します。
表13-1に、現行リリースのOracle Advanced SecurityでサポートされているSSL暗号スイートを示します。これらの暗号スイートは、Oracle Advanced Securityをインストールするとデフォルトで設定されます。表では、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプも示されています。
|
注意: sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATIONパラメータをtrueに設定する場合は、Diffie-Hellman匿名認証を使用するすべての暗号スイートを無効にします。設定しない場合、接続に失敗します。 |
クライアントのSecure Sockets Layer暗号スイートの設定
Oracle Net Managerを起動します。
(UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。
netmgr
(Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。
「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。
「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。
「SSL」タブを選択します。
「暗号スイートの構成」領域で、「追加」をクリックします。
使用可能な暗号スイートがダイアログ・ボックスに表示されます。
スイートを選択し、「OK」をクリックします。
次のように、「暗号スイートの構成」リストが更新されます。
上矢印と下矢印を使用して、暗号スイートの優先順位を設定します。
「ファイル」→「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルが次のエントリで更新されます。
SSL_CIPHER_SUITES= (SSL_cipher_suite1 [,SSL_cipher_suite2])
sqlnet.oraファイルでSSL_VERSIONパラメータを設定できます。このパラメータでは、クライアントが通信するシステムで実行する必要があるSSLのバージョンを定義します。これらのシステムで有効なバージョンを使用するように設定できます。sqlnet.oraにおけるこのパラメータのデフォルト設定はundeterminedです。これは、「Oracle Advanced Security」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。「任意」を選択すると、TLS 1.0が最初に試行され、その後、SSL 3.0、SSL 2.0の順に試行されます。クライアントのSSLバージョンがサーバーで使用されているバージョンと互換性があることを確認します。
クライアントに必要なSSLバージョンを設定するには、次の手順を実行します。
「必要なSSLバージョン」リストのデフォルト設定は「任意」です。このデフォルトを受け入れるか、構成するSSLバージョンを選択します。
「ファイル」→「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルが更新されます。「任意」を選択した場合は、次のエントリで更新されます。
SSL_VERSION=UNDETERMINED
|
関連項目: SSL_VERSION値の完全なリストについては、『Oracle Database Net Servicesリファレンス』を参照してください |
sqlnet.oraファイルのSQLNET.AUTHENTICATION_SERVICESパラメータでは、SSL認証サービスを設定します。通常、sqlnet.oraファイルは、他のネットワーク構成ファイルと同じディレクトリにあります。プラットフォームに応じて、sqlnet.oraファイルは次のディレクトリにあります。
(UNIXの場合) $ORACLE_HOME/network/admin
(Windowsの場合) ORACLE_BASE\ORACLE_HOME\network\admin\
SQLNET.AUTHENTICATION_SERVICESパラメータは、SSL認証とOracle Databaseでサポートされている別の認証方式を組み合せて使用する場合に設定します。たとえば、サーバーがSSLを使用してクライアントに対して自己認証を行い、クライアントがRADIUSを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。
クライアントのSQLNET.AUTHENTICATION_SERVICESパラメータを設定するには、テキスト・エディタを使用してsqlnet.oraファイルでこのパラメータにSSL付きTCP/IP(TCPS)を追加します。たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。
SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)
SSL認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。
|
関連項目: AUTHENTICATION_SERVICES値の完全なリストについては、『Oracle Database Net Servicesリファレンス』を参照してください |
sqlnet.oraファイルのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータは、データベース・サーバー認証時に使用する証明書を指定します。通常、sqlnet.oraファイルは、他のネットワーク構成ファイルと同じディレクトリにあります。プラットフォームに応じて、sqlnet.oraファイルは次のいずれかのディレクトリにあります。
(UNIXの場合) $ORACLE_HOME/network/admin
(Windowsの場合) ORACLE_BASE\ORACLE_HOME\network\admin\
セキュリティ・モジュールに複数の証明書があるが、1つの証明書のみにclient authenticationの拡張鍵使用方法フィールドがあり、その証明書がまさに、データベースの認証に使用する証明書である場合、SQLNET.SSL_EXTENDED_KEY_USAGEパラメータを設定します。たとえば、スマートカードに複数の証明書があり、そのうちの1つのみにclient authenticationの拡張鍵使用方法フィールドがあり、その証明書Cをデータベースの認証に使用する場合、このパラメータを設定します。Windowsクライアントでこのパラメータをclient authenticationに設定すると、MSCAPI証明書の選択ボックスが表示され、証明書Cが自動的に、サーバーへのクライアントのSSL認証に使用されます。
クライアントのSQLNET.SSL_EXTENDED_KEY_USAGEパラメータを設定するには、sqlnet.oraファイルを編集し、次の行を含めます。
SQLNET.SSL_EXTENDED_KEY_USAGE = "client authentication"
証明書のフィルタ処理を使用しない場合は、sqlnet.oraファイルからSQLNET.SSL_EXTENDED_KEY_USAGEパラメータ設定を削除します。
|
関連項目: SSL_EXTENDED_KEY_USAGE値の完全なリストについては、『Oracle Database Net Servicesリファレンス』を参照してください |
クライアントにSSL認証を使用する場合は(sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATION=trueを設定)、SQL*Plusを起動し、次のように入力します。
CONNECT/@net_service_name
クライアントにSSL認証を使用しない場合は(sqlnet.oraファイルでSSL_CLIENT_AUTHENTICATION=falseを設定)、SQL*Plusを起動し、次のように入力します。
CONNECT username@net_service_name Enter password: password
次の項では、Oracle Advanced SecurityのSSLアダプタの使用中に表示される可能性がある最も一般的なエラーについて説明します。
Oracle Netトレースを有効にして、エラーの原因を特定することが必要になる場合があります。トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
sqlnet.oraファイルに正しいウォレット・ロケーションが指定されていることを確認します。これは、ウォレットを保存したディレクトリと同じにする必要があります。
Oracle Netトレースを有効にして、開くことができないファイルの名前とその原因を調べます。
ウォレットを保存したときに自動ログインが有効になっていたことを確認します。「自動ログインの使用」を参照してください。
自動ログイン機能が使用されていない場合は、正しいパスワードを入力します。
Oracle Net Managerを使用して、クライアントとサーバーの両方のSSLバージョンが一致しているか、互換性があることを確認します。たとえば、サーバーでSSL 3.0のみを受け入れ、クライアントでTLS 1.0のみを受け入れる場合、SSL接続は失敗します。
Oracle Net Managerを使用して、クライアントとサーバーの両方で構成されている暗号スイートをチェックし、両方に互換性のある暗号スイートが設定されていることを確認します。
エラーが繰り返される場合は、Oracle Netトレースを有効にし、再接続してください。トレース出力をOracleカスタマ・サポートに連絡してください。
|
関連項目: クライアントとサーバーに互換性のある暗号スイートを設定する方法の詳細は、「手順3D: クライアントのSecure Sockets Layer暗号スイートの設定(オプション)」を参照してください。 |
|
注意: 暗号スイートを構成しない場合は、使用可能なすべての暗号スイートが有効になります。 |
ウォレットが検出されるように、sqlnet.oraファイルに正しいウォレット・ロケーションが指定されていることを確認します。
Oracle Net Managerを使用して、sqlnet.oraファイルに暗号スイートが正しく設定されていることを確認します。このエラーは、sqlnet.oraが手動で編集され、暗号スイート名の綴りが誤っている場合に発生することがあります。暗号スイート名で大/小文字が区別される文字列照合が使用されていることを確認します。
Oracle Net Managerを使用して、クライアントとサーバーの両方のSSLバージョンが一致しているか、互換性があることを確認します。このエラーは、サーバーとクライアントに指定されているSSLバージョンが一致しないために発生することがあります。たとえば、サーバーでSSL 3.0のみを受け入れ、クライアントでTLS 1.0のみを受け入れる場合、SSL接続は失敗します。
診断情報の詳細を確認するために、ピアでOracle Netトレースを有効にします。
Oracle Net Managerを使用して、クライアントとサーバーの両方のSSLバージョンが一致しているか、互換性があることを確認します。このエラーは、サーバーとクライアントに指定されているSSLバージョンが一致しないために発生することがあります。たとえば、サーバーでSSL 3.0のみを受け入れ、クライアントでTLS 1.0のみを受け入れる場合、SSL接続は失敗します。
Diffie-Hellman匿名暗号スイートを使用し、サーバーのlistener.oraファイルでSSL_CLIENT_AUTHENTICATIONパラメータがtrueに設定されている場合、クライアントは証明書をサーバーに渡しません。サーバーがクライアントの証明書を受信しない場合、クライアントを認証できないため接続がクローズされます。これを解決するには、別の暗号スイートを使用するか、このlistener.oraパラメータをfalseに設定します。
Oracle Netトレースを有効にし、トレース出力にネットワーク・エラーがないか確認します。
詳細は、「ORA-28862: SSL接続に失敗しました。」の「処置」を参照してください。
ウォレットにインストールされているすべての証明書が使用可能である(期限切れでない)こと。
ピア証明連鎖からの認証局の証明書が、ウォレットに信頼できる証明書として追加されています。Oracle Wallet Managerを使用して信頼できる証明書をインポートするには、「信頼できる証明書のインポート」を参照してください。
証明書をチェックして、有効かどうかを確認します。必要に応じて、新規の証明書を取得するか、送信者に証明書にエラーがあることを警告するか、または再送します。
サーバーのウォレットに、クライアントの証明書を検証検証するための適切なトラスト・ポイントがあることを確認します。トラスト・ポイントがない場合は、Oracle Wallet Managerを使用して、適切なトラスト・ポイントをウォレットにインポートします。詳細は、「信頼できる証明書のインポート」を参照してください。
証明書が失効していないこと、および証明書失効リスト(CRL)チェックがオンになっていることを確認します。詳細は、「証明書失効リストによる証明書検証の構成」を参照してください。
この項の内容は次のとおりです。
指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。証明書の検証には、次の項目の判定が含まれます。
信頼できる認証局(CA)にデジタル署名された証明書があるかどうか。
証明書のデジタル署名が、証明書自体の別個に計算されたハッシュ値および証明書の署名者の(CAの)公開鍵に対応しているかどうか。
証明書が期限切れになっていないかどうか。
証明書が失効していないかどうか。
SSLネットワーク・レイヤーは、自動的に最初の3つの検証チェックを実行しますが、証明書が失効していないことを確認するには、証明書失効リスト(CRL)のチェックを構成する必要があります。CRLは、失効した証明書のリストを含む署名付きデータ構造体です。これは通常、元の証明書を発行したエンティティと同じエンティティによって発行され署名されます。(「証明書失効リスト」を参照してください。)
使用するトラスト・ポイントすべてについてCRLが必要です。トラスト・ポイントは、一定の信頼レベルで資格を与えられたサード・パーティ・アイデンティティからの信頼できる証明書です。通常、信頼する認証局はトラスト・ポイントと呼ばれます。
証明書失効ステータスは、ファイル・システム・ディレクトリ(Oracle Internet Directory)にあるCRL、または証明書の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 Advanced Securityは、HTTPおよびLDAPを介したCRLのダウンロードをサポートしています。
この項の内容は次のとおりです。
証明書失効ステータス・チェックを有効にするには、sqlnet.oraファイルでSSL_CERT_REVOCATIONパラメータをREQUIREDまたはREQUESTEDに設定する必要があります。デフォルトでは、このパラメータはNONEに設定され、証明書失効ステータス・チェックはオフになっています。
|
注意: CRLをローカル・ファイル・システムまたはOracle Internet Directoryに格納する場合は、コマンドライン・ユーティリティorapkiを使用して、ファイル・システム内のCRLの名前を変更するか、CRLをディレクトリにアップロードします。orapkiの使用方法の詳細は、「証明書失効リストの管理」を参照してください。 |
(UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。
netmgr
(Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。
「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。
「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。
「SSL」タブを選択します。
「失効チェック」リストから次のいずれかのオプションを選択します。
必須
証明書失効ステータス・チェックが必須です。証明書が失効しているかCRLが見つからない場合、SSL接続は拒否されます。証明書がまだ失効していないことが確認された場合にのみ、SSL接続は許可されます。
リクエスト済
CRLが使用可能な場合に、証明書失効ステータス・チェックを実行します。証明書が失効している場合、SSL接続は拒否されます。CRLが見つからない場合や、証明書がまだ失効していない場合、SSL接続は許可されます。
パフォーマンス上の理由から、ユーザー証明書の失効のみがチェックされます。
(オプション)CRLがローカル・ファイル・システムに格納されている場合は、次のフィールドのいずれか、または両方を設定して、格納場所を指定します。これらのフィールドは、「失効チェック」が「必須」または「リクエスト済」に設定されている場合にのみ使用できます。
「証明書失効リスト・パス」:
CRLが格納されているディレクトリへのパスを入力するか、または「参照」をクリックし、ファイル・システムを検索して指定します。このパスを指定すると、sqlnet.oraファイルのSSL_CRL_PATHパラメータが設定されます。このパラメータでパスを指定しない場合、デフォルトはウォレット・ディレクトリです。DERエンコードされた(バイナリ形式)CRLおよびPEMエンコードされた(BASE64)CRLの両方がサポートされています。
「証明書失効リスト・ファイル」:
包括的CRLファイル(PEMエンコードされた(BASE64)CRLが優先度の順に1つのファイルに連結されたもの)へのパスを入力するか、または「参照」をクリックし、ファイル・システムを検索して指定します。このファイルを指定すると、sqlnet.oraファイルのSSL_CRL_FILEパラメータが設定されます。このパラメータを設定した場合、ファイルが指定された場所に存在する必要があります。存在しない場合、アプリケーションは起動中にエラーになります。
「証明書失効リスト・パス」を設定してCRLをローカル・ファイル・システム・ディレクトリに格納する場合は、orapkiユーティリティを使用して、システムが特定できるようにCRLの名前を変更する要があります。詳細は、「証明書検証用ハッシュ値によるCRLの名前変更」を参照してください。
(オプション)CRLをOracle Internet Directoryからフェッチする場合は、ディレクトリ・サーバーとポート情報をldap.oraファイルで指定する必要があります。
ldap.oraファイルを構成する場合は、ディレクトリに非SSLポートのみを指定する必要があります。CRLダウンロードはSSLプロトコルの一部として実行され、SSL接続内でのSSL接続の確立はサポートされません。
Oracle Internet Directoryの非SSLポートが無効になっている場合、Oracle Advanced SecurityのCRL機能は動作しません。
「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルが更新されます。
(UNIX) $ORACLE_HOME/binから、コマンドラインで次のコマンドを入力します。
netmgr
(Windows)「スタート」→「プログラム」→「Oracle - HOME_NAME」→「Configuration and Migration Tools」→「Net Manager」を選択します。
「Oracle Netの構成」を展開し、「ローカル」から「プロファイル」を選択します。
「ネーミング」リストから、「ネットワーク・セキュリティ」を選択します。
ネットワーク・セキュリティのタブ付きウィンドウが表示されます。
「SSL」タブを選択します。
「失効チェック」リストから「なし」を選択します。
「ファイル」メニューから、「ネットワーク構成の保存」を選択します。
sqlnet.oraファイルが次のエントリで更新されます。
SSL_CERT_REVOCATION=NONE
この項の内容は次のとおりです。
証明書失効ステータス・チェックを有効にするには、まず、使用するCAから受信したCRLがコンピュータで使用できるフォームである(ハッシュ値で名前変更されている)こと、またはコンピュータで使用できる場所にある(ディレクトリにアップロードされている)ことを確認してください。Oracle Advanced Securityには、この項で説明するタスクを実行するために使用できるコマンドライン・ユーティリティ(orapki)があります。
LDAPコマンドライン・ツールを使用して、Oracle Internet DirectoryでCRLを管理することもできます。
|
注意: CRLは、正常な検証を行うために、(期限切れになる前に)定期的に更新する必要があります。このタスクは、スクリプトでorapkiコマンドを使用して自動化できます。 |
コマンドラインで次のコマンドを入力することにより、CRLの管理に使用可能なorapkiコマンドをすべて表示できます。
orapki crl help
このコマンドにより、使用可能なすべてのCRL管理コマンドとそのオプションが表示されます。
|
注意: -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を使用してディレクトリに格納されているすべての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について失効した証明書の完全なリストを要求できます。サマリー・リストには、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: 証明書の検証に失敗しました」というメッセージが表示されます。このメッセージが表示された場合は、「ORA-29024: 証明書の検証に失敗しました」でエラーの解決方法を参照してください。 |
|
関連項目: トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
Oracle Netトレース・ファイルのentryエントリとexitエントリの間に、証明書検証に関連する次のトレース・メッセージが記録されることがあります。Oracle SSLは複数の場所でCRLを検索するため、トレースに複数のエラーが記録されることがあります。
エラーの解決方法の詳細は、次の表示される可能性があるエラー・メッセージのリストを確認してください。
Oracle Net Managerを使用して、正しいCRLの場所が構成されているかどうかを確認します。「証明書失効リストによる証明書検証の構成」を参照してください。
必要に応じて、orapkiユーティリティを使用してシステムで使用するCRLを次のように構成します。
ローカル・ファイル・システムに格納されているCRLの場合は、「証明書検証用ハッシュ値によるCRLの名前変更」を参照してください。
ディレクトリに格納されているCRLの場合は、「Oracle Internet DirectoryへのCRLのアップロード」を参照してください。
CRLを手動でダウンロードします。次に、それをローカル・ファイル・システムに格納するか、Oracle Internet Directoryに格納するかに応じて、次の手順を実行します。
CRLをローカル・ファイル・システムに格納する場合:
Oracle Net Managerを使用して、CRLディレクトリまたはファイルへのパスを指定します。「証明書失効リストによる証明書検証の構成」を参照してください。
orapkiユーティリティを使用して、システムで使用するCRLを構成します。「証明書検証用ハッシュ値によるCRLの名前変更」を参照してください。
CRLをOracle Internet Directoryに格納する場合:
Oracle Net Configuration Assistantを使用して、ディレクトリ接続情報を含むldap.oraファイルを作成し、構成します。
orapkiユーティリティを使用して、CRLをディレクトリにアップロードします。「Oracle Internet DirectoryへのCRLのアップロード」を参照してください。
この項の内容は次のとおりです。
Oracle Advanced Securityでは、RSA Security社のPKCS #11仕様に準拠したAPIを使用するハードウェア・セキュリティ・モジュールがサポートされています。通常、これらのハードウェア・デバイスは、トークンまたはスマートカードの秘密鍵を安全に格納および管理するため、または暗号処理を.高速化するために使用されます。
次の一般的なガイドラインは、Oracle Advanced Securityでハードウェア・セキュリティ・モジュールを使用する場合に適用されます。
必要なハードウェア、ソフトウェアおよびPKCS #11ライブラリを取得するには、ハードウェア・デバイス・ベンダーにお問い合せください。
使用しているハードウェア・セキュリティ・モジュールに適したハードウェア、ソフトウェアおよびライブラリをインストールします。
ハードウェア・セキュリティ・モジュールのインストールをテストして、正常に動作することを確認します。詳細は、使用するデバイスのドキュメントを参照してください。
秘密鍵をトークンに格納する場合は、Oracle Wallet Managerを使用してPKCS11タイプのウォレットを作成し、PKCS #11ライブラリへの絶対パス(ライブラリ名を含む)を指定します。Oracle PKCS11ウォレットには、秘密鍵にアクセスするためのトークンを指す情報が格納されます。
PKCS #11情報が格納されたウォレットは、任意のOracleウォレットを使用する場合と同様に使用できます。ただし、秘密鍵をハードウェア・デバイスに格納し、暗号操作もそのデバイスで実行する場合を除きます。
この項の内容は次のとおりです。
nCipher社製のハードウェア・セキュリティ・モジュールは、Oracle Advanced Securityで動作することが証明されています。これらのモジュールでは、鍵を安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。
暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。
デバイス上の秘密鍵の記憶領域が保護されます。
スマートカードを使用して鍵を管理できます。
|
注意: Oracle Advanced Securityで使用する認定済のハードウェアおよびソフトウェアを入手するには、nCipherの代理店にお問い合せください。 |
nCipherハードウェア・セキュリティ・モジュールを使用するには、次のコンポーネントが必要です。
nCipherハードウェア・セキュリティ・モジュール
サポートしているnCipher PKCS #11ライブラリ
次のプラットフォーム固有のPKCS#11ライブラリが必要です。
libcknfast.soライブラリ(UNIX 32ビットの場合)
libcknfast-64.soライブラリ(UNIX 64ビットの場合)
cknfast.dllライブラリ(Windowsの場合)
|
注意: ハードウェア・セキュリティ・モジュールまたはセキュア・アクセラレータをインストールし、必要なライブラリを入手するには、nCipherの代理店にお問い合せください。これらの作業は、Oracle Advanced SecurityでnCipherハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。 |
セキュア・アクセラレータを使用するには、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社製のハードウェア・セキュリティ・モジュールは、Oracle Advanced Securityで動作することが証明されています。これらのモジュールでは、鍵を安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。
暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。
デバイス上の秘密鍵の記憶領域が保護されます。
|
注意: Oracle Advanced Securityで使用する認定済のハードウェアおよびソフトウェアを入手するには、SafeNETの代理店にお問い合せください。 |
SafeNET Luna SAハードウェア・セキュリティ・モジュールを使用するには、次のコンポーネントが必要です。
SafeNET Luna SAハードウェア・セキュリティ・モジュール
サポートしているSafeNET Luna SA PKCS #11ライブラリ
次のプラットフォーム固有のPKCS#11ライブラリが必要です。
libCryptoki2.soライブラリ(UNIXの場合)
cryptoki.dllライブラリ(Windowsの場合)
|
注意: ハードウェア・セキュリティ・モジュールまたはセキュア・アクセラレータをインストールし、必要なライブラリを入手するには、SafeNETの代理店にお問い合せください。これらの作業は、Oracle Advanced SecurityでSafeNETハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。 |
セキュア・アクセラレータを使用するには、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ハードウェア・セキュリティ・モジュールの使用に関連します。
ウォレットの作成時にこのエラーが表示された場合は、パスワードが正しいことを確認し、再入力します。
ウォレットの作成後にパスワードを変更した場合は、Oracle Wallet Managerを使用してウォレットを開き、新しいパスワードを入力します。
|
注意: nCipherログ・ファイルは、モジュールがインストールされているディレクトリの次の場所にあります。
|
|
関連項目: nCipherデバイスとSafeNETデバイスのトラブルシューティングの詳細は、nCipherとSafeNETのドキュメントを参照してください。 |
Oracle Real Application Clusters (Oracle RAC)環境で使用するSecure Sockets Layerを構成できます。
この項の内容は次のとおりです。
Oracle RAC環境では、クライアントは3つのSCANリスナーのいずれかにアクセスし、それからデータベース・リスナーにルーティングされます。Secure Sockets Layerをサポートするには、すべてのリスナーにTCPSプロトコル・エンドポイントが必要です。次の手順により、データベース・ノード・リスナーおよびSCANリスナーにTCPSエンドポイントを追加します。
リスナー・リソースでTCPエンドポイントがサポートされていることを確認します。
例:
crsctl stat res -p |grep ENDPOINTS
次のような出力が表示されます。
ENDPOINTS=TCP:1521 <= database listener ENDPOINTS=TCP:1521 <= listener_scan1 ENDPOINTS=TCP:1521 <= listener_scan2 ENDPOINTS=TCP:1521 <= listener_scan3
データベース・リスナーにTCPSエンドポイントを追加します。
TCPポート番号と異なり、現在使用されていないポート番号をTCPS値に指定します。例:
srvctl modify listener -p "TCP:1521/TCPS:1523";
リスナーを再起動します。
srvctl stop listener srvctl start listener
リスナー構成を確認します。
srvctl config listener
次のような出力が表示されます。
Name: LISTENER
Network: 1, Owner: oracle
Home: CRS_home
End points: TCP:1521/TCPS:1523
リスナー・ステータスを確認します。
lsnrctl status Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=10.141.155.188)(PORT=1523))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.141.155.183)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.141.155.188)(PORT=1521)))
リスナー・リソースを再確認します。
crsctl stat res -p |grep ENDPOINTS ENDPOINTS=TCP:1521 TCPS:1523 <= database listener ENDPOINTS=TCP:1521 <= listener_scan1 ENDPOINTS=TCP:1521 <= listener_scan2 ENDPOINTS=TCP:1521 <= listener_scan3
ENDPOINTSの最初の行にTCPSフラグが含まれ、正しく構成されていることが示されています。次の手順で、このTCPSをSCANリスナーに追加します。
SCANリスナーにTCPSエンドポイントを追加します。
srvctl stop scan_listener srvctl stop scan srvctl modify scan_listener -p TCP:1521/TCPS:1523
または、次のようなコマンドを使用することもできます。
srvctl remove scan_listener -f srvctl add scan_listener -l LISTENER -p TCP:1521/TCPS:1523 srvctl start scan srvctl start scan_listener
SCANリスナーの構成を確認します。
まず、これまでに構成したすべてのリスナーを検索します。
srvctl config scan_listener SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521/TCPS:1523 SCAN Listener LISTENER_SCAN2 exists. Port: TCP:1521/TCPS:1523 SCAN Listener LISTENER_SCAN3 exists. Port: TCP:1521/TCPS:1523
次に個別のリスナーを確認します。次のコマンドは、SCANリスナー3を確認しています。
lsnrctl status listener_scan3 Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN3))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.141.155.186)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=10.141.155.186)(PORT=1523)))
すべてのリスナー・リソースが構成されていることを確認します。
crsctl stat res -p |grep ENDPOINTS
次の出力は、各行にTCPSフラグがあるため、すべて構成されていることを示しています。
ENDPOINTS=TCP:1521 TCPS:1523 <= database listener ENDPOINTS=TCP:1521 TCPS:1523 <= listener_scan1 ENDPOINTS=TCP:1521 TCPS:1523 <= listener_scan2 ENDPOINTS=TCP:1521 TCPS:1523 <= listener_scan3
PMONは、ローカル・リスナーに格納されているエンドポイント値をSCANリスナーに送信し、適切なサービス・ハンドラが作成されるようにする必要があります。この手順では、手順1: TCPSプロトコル・エンドポイントの構成で作成したデータベース・ノード・リスナーのTCPSエンドポイントを、各Oracle RACノードのローカル・リスナー起動パラメータに追加します。ローカル・リスナーのIPアドレスは、各ノードで一意です。ALTER SYSTEM文を発行する場合は、ローカル・インスタンスSID値を宣言する必要があります。(例: sid = 'instance')。
ノードを選択してローカル・リスナー・エンドポイントを指定します。
lsnrctl status |grep PORT
次のような出力結果が表示されます。PROTOCOL値によってTCPSプロトコル・エンドポイントを指定できます。
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=10.141.155.188)(PORT=1523))) <= new TCPS endpoint (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.141.155.183)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.141.155.188)(PORT=1521)))
データベース・インスタンスにSYSDBA管理者権限でログインします。
sqlplus / as sysdba
ローカル・リスナーの値を確認します。
SHOW PARAMETER LOCAL_LISTENER
次のような出力が表示されます。
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ local_listener string (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=10.141.155.188)(PORT=1521))))
手順1で指定したTCPSエンドポイントをlocal_listener値に追加します。また、SIDをローカル・ノード・インスタンス名に設定します。SPFILEの更新前に変更を検証できるよう、メモリーにスコープを設定します。
例:
ALTER SYSTEM SET local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=10.141.155.188)(PORT=1521))(ADDRESS=(PROTOCOL=TCPS)(HOST=10.141.155.188)(PORT=1523))))' scope=memory sid='NETRAC1';
ローカル・リスナーの値を再確認します。
SHOW PARAMETER LOCAL_LISTENER
次のような出力が表示されます。
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ local_listener string (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=10.141.155.188)(PORT=1521))(ADDRESS=(PROTOCOL=TCPS)(HOST=10.141.155.188)(PORT=1523))))
Oracle RACクラスタでインスタンス登録を制限するためにCOSTが使用されている場合、すべてのローカル・リスナーおよびノード・リスナーのCOST値のリストにTCPSを含める必要があります。TCPS規則がない場合、SCANリスナーのTCPSハンドラがブロック状態になります。詳細は、次の場所で、My Oracle Support(以前のOracleMetaLink)のDoc ID: 1537743.1「SSLクラスタにCOSTを実装した後、SCANリスナーのTCPSサービス・ハンドラがブロックされる」を参照してください。
次のようなALTER SYSTEM文を実行して、変更をSPFILEに書き込みます。
ALTER SYSTEM SET LOCAL_LISTENER='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=10.141.155.188)(PORT=1521))(ADDRESS=(PROTOCOL=TCPS)(HOST=10.141.155.188)(PORT=1523))))' scope=both sid='NETRAC1';
これらの手順を繰り返して残りのノードを更新し、すべてのノードでTCPSエンドポイントをSCANリスナーに正しく登録します。
証明書署名用の認証局(CA)の選択および使用方法は、サイトのポリシーに応じて異なります。正常なSSL接続を行うために、サーバーおよび接続先クライアントには、同一の信頼できる認証局によって署名された一意のSSL証明書が必要です。クラスタ用およびSSL経由でデータベースに接続するテスト・クライアント用に証明書リクエストを作成する必要があります。これらのリクエストに認証局の署名を得た後、署名付きユーザー証明書および信頼できるルート証明書を使用してウォレットを作成します。クラスタ・ウォレットおよびクライアント・ウォレットには一意のアイデンティティがありますが、同一の信頼できる証明書を共有します。これがSSL接続用の正しいウォレット設定です。
この項の内容は次のとおりです。
CAホームとして使用するディレクトリを作成します。CAホームのアクセスを、デジタル証明書の認可および署名可能なユーザーまたはユーザー・グループに制限します。
例:
cd $ORACLE_BASE mkdir CA; chmod 700 CA; cd CA; pwd /home/app/oracle/CA export CA_HOME=/home/app/oracle/CA
CAホームで、orapkiを使用して認証局ウォレットを作成します。
orapki wallet create -wallet $CA_HOME Enter password: CA_password Enter password again: CA_password
orapkiユーティリティにより、既知の信頼できる証明書が複数移入されたデフォルト・ウォレットが作成されます。これらの証明書はこの手順では使用しないため、次のコマンドで削除できます。
orapki wallet remove -trusted_cert_all -wallet $CA_HOME -pwd [CA_password]
CAウォレット用自己署名(ルート)証明書を作成します。
例:
orapki wallet add -wallet $CA_HOME -self_signed -dn "CN=Oracle test CA,O=Oracle,C=US" -keysize 1024 -validity 3650 -pwd [CA_password]
次のように指定します。
dnは識別名を指し、X509で書式設定された任意の有効な名前を使用できます(例: -dn CN=Widget Corp.,C=US)。
keysizeで鍵のビット・サイズを設定します。次の値が有効です: 512、1024または2048。
validityは必須で、現在の日付から数えてこの証明書が有効である日数を指定します。
ウォレットからルートCA証明書を抽出します。
このルート証明書はユーザー・ウォレットまたはアプリケーション・ウォレットで信頼できるCA証明書として使用され、PKCS12ウォレットを作成するユーザーに対し配布または公開できます。
例:
orapki wallet export -wallet $CA_HOME -dn "CN=Oracle test CA,O=Oracle,C=US" -cert testCAroot.cer -pwd [CA_password]
この段階で、$CA_HOMEにはewallet.p12 (PKCS12ウォレット)およびtestCAroot.cer base64証明書が含まれます。
ls -al total 16 drwx------ 2 psmith psmith 4096 Aug 23 15:15 . drwxrwxr-x 11 psmith psmith 4096 Aug 23 13:54 .. -rw------- 1 psmith psmith 2560 Aug 23 15:13 ewallet.p12 -rw------- 1 psmith psmith 706 Aug 23 15:15 testCAroot.cer
ウォレットが正常に作成されたことを確認します。
例:
orapki wallet display -wallet $CA_HOME -summary
Enter wallet password: CA_password
Requested Certificates:
User Certificates:
Subject: CN=Oracle test CA,O=Oracle,C=US
Trusted Certificates:
Subject: CN=Oracle test CA,O=Oracle,C=US
ウォレットおよびパスワードをバックアップします。
CAウォレットを使用すると、orapkiユーティリティを使用して、テスト環境内の様々なエンティティやプロセスからのデジタル証明書リクエストに署名し、認可されたデジタル・ユーザー証明書を発行できます。テスト環境内でPKI機能に関与している各エンティティに対してこの手順を繰り返します。有効なウォレットは、ルートCA証明書および署名付きユーザー証明書で構成されます。
CAホームの外のディレクトリまたは場所でユーザー・ウォレットを作成します。
例:
cd ~ mkdir user_wallet; cd user_wallet pwd /home/user_wallet export MY_WALLET=/home/user_wallet orapki wallet create -wallet $MY_WALLET Enter password: user_password Enter password again: user_password
orapkiユーティリティにより、既知の信頼できる証明書を複数インストール済のウォレットが作成されます。これらの証明書はこの手順では使用しないため、次のコマンドで削除できます。
orapki wallet remove -trusted_cert_all -wallet $MY_WALLET -pwd [user_password]
ユーザー・アイデンティティ(ユーザーDN)および証明書リクエストを作成します。
例:
orapki wallet add -wallet $USER_WALLET -dn "CN=testuser" -keysize 1024 -pwd [user_password] orapki wallet export -wallet $USER_WALLET -dn "CN=testuser" -request $USER_WALLET/testuser.req -pwd [user_password] ls ewallet.p12 testuser.req
この段階で、testuserリクエストはCAにより署名できます。この手順には、CAホーム・ウォレットへのアクセスおよびCAウォレットのパスワードが必要です。testuser.reqへの署名後、出力ファイルtestuser.cerが作成されます。
署名付き証明書を作成します。
例:
orapki cert create -wallet $CA_HOME -request $MY_WALLET/testuser.req -cert $USER_WALLET/testuser.cer -validity 3650 -pwd [CA_password]
ls
ewallet.p12 testuser.cer testuser.req
ルート証明書(testCAroot.cer)および署名付きユーザー証明書(testuser.cer)をユーザー・ウォレットにインポートします。
次の例では、$CA_HOMEからルート証明書を取得しています。または、ユーザーのウォレット・ディレクトリに証明書をコピーした後、ローカルにインポートすることもできます。
orapki wallet add -wallet $USER_WALLET -trusted_cert -cert $CA_HOME/testCAroot.cer -pwd [user_password] orapki wallet add -wallet $USER_WALLET -user_cert -cert $USER_WALLET/testuser.cer -pwd [user_password]
完了したウォレットを確認します。
例:
orapki wallet display -wallet $MY_WALLET -summary -pwd [user_password]
Requested Certificates:
User Certificates:
Subject: CN=testuser
Trusted Certificates:
Subject: CN=Oracle test CA,O=Oracle,C=US
手順3: クラスタおよびクライアントのSSL証明書およびウォレットの作成でクラスタ・ウォレットを作成した後、クラスタの各ノードにこのウォレットをコピーします。
データベース(PMON)から、および通常Grid Infrastructureホーム外で実行されているSCANリスナーとローカル・リスナーからアクセス可能な場所に配置する必要があることを除けば、ウォレットの配置に特定のルールはありません。
この手順では、ウォレットを次のディレクトリにコピーしたと想定します。
/u01/app/oracle/product/11.2.0.4/db_1/network/admin/wallet
cwallet.ssoファイルを作成します。
例:
orapki wallet create -wallet /u01/app/oracle/product/11.2.0.4/db_1/network/admin/wallet -auto_login
Enter password: password
cwallet.ssoは、ewallet.p12の不明瞭化されたミラー・コピーであり、PMONおよびリスナーからアクセスされるファイルです。クラスタにcwallet.ssoを作成する場合は、これをewallet.p12ファイルとともに各ノードのウォレット・ディレクトリにコピーできます。また、ewallet.p12がすでに配置されている場合は、cwallet.ssoウォレットを各ノードに別々に作成できます。
2つのウォレットが配置されていることを確認します。
例:
ls -al drwxr-xr-x. 2 oracle oracle 4096 Feb 7 11:12 . drwxr-xr-x. 5 oracle oracle 4096 Feb 15 11:00 .. -rw-------. 1 oracle oracle 2549 Feb 15 16:13 cwallet.sso -rw-------. 1 oracle oracle 2472 Feb 7 11:11 ewallet.p12
各ノードのPMONおよびリスナー・プロセスの両方からウォレットにアクセスできる必要があります。各ノードのsqlnet.oraおよびlistener.oraファイルに、ウォレット・ロケーションが定義されている必要があります。
$GRID_HOME/network/admin/listener.oraファイルを編集して次の設定を追加します。
SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /u01/app/oracle/product/11.2.0.4/db_1/network/admin/wallet) ) )
この例では、「手順4: 各クラスタ・ノードへのウォレットのコピーおよび不明瞭化されたウォレットの作成」に記載したウォレット・ディレクトリを使用します。通常、クラスタのリスナーはGrid Infrastructureのホーム・ディレクトリの外部で実行されています。
データベースの$ORACLE_HOME/network/admin/sqlnet.oraファイルを編集して、次の設定を追加します。
SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS) SSL_VERSION = 0 SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /u01/app/oracle/product/11.2.0.4/db_1/network/admin/wallet) ) )
この例では、「手順4: 各クラスタ・ノードへのウォレットのコピーおよび不明瞭化されたウォレットの作成」に記載したウォレット・ディレクトリを使用します。通常、クラスタのインスタンスはデータベースのホーム・ディレクトリの外部で実行されています。
各ノードに対してこの手順を繰り返します。
ウォレットを配置して.oraファイルを編集した後、PMONプロセスおよびリスナー・プロセスを再起動して新しいウォレット設定を認識させる必要があります。また、再起動に伴い、インスタンスによって「手順2: 各Oracle RACノードでのローカル・リスナー・パラメータの更新」で追加したローカル・リスナー値が使用されます。SCANリスナーに適切なTCPSハンドラがあることを確認し、必要に応じて不一致を修正します。
再起動のコマンドは次のとおりです。
srvctl stop listener srvctl start listener srvctl stop scan_listener srvctl start scan_listener srvctl stop database -d netrac srvctl start database -d netrac
SSL用に構成されたクラスタ環境における最も簡単なテスト方法は、クラスタ・ノードの1つでSSL接続を確立することです。
クラスタ・ノードの1つが存在しているコンピュータにログインします。
このノードのtnsnames.oraファイルにおいて、SCANリスナーのTCPSエンドポイントを使用する接続記述子を作成します。
例:
NETRACSSL = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = net-scan)(PORT = 1523)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = NETRAC.us.example.com) ) )
このTCPS接続記述子を使用して、SQL*Plusでこのデータベース・インスタンスに接続します。
例:
sqlplus psmith@netracssl
Enter password: password
リモート・クライアントに使用しているコンピュータで、ウォレット・ディレクトリ位置を作成します。
この位置情報を、リモート・クライアントのsqlnet.oraファイルに追加します。
例:
WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = C:\app\oracle\product\11.2.0.4\dbhome_1\NETWORK\ADMIN\wallet) ) )
「手順3: クラスタおよびクライアントのSSL証明書およびウォレットの作成」で作成したウォレットを、リモート・クライアントのウォレット・ディレクトリに移動します。
リモート・クライアント上にcwallet.ssoを作成します。
例:
orapki wallet create -wallet . -auto_login
Enter wallet password: password
これら2つのファイルがウォレット・ディレクトリに存在していることを確認します。
例:
cd $ORACLE_HOME/network/admin/wallet ls cwallet.sso ewallet.p12
listener.oraファイルにおいて、SCANリスナーのTCPSエンドポイントを使用する接続記述子を作成します。
例:
NETRACSSL = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = net-scan)(PORT = 1523)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = NETRAC.us.example.com) ) )
このTCPS接続記述子を使用して、SQL*Plusでこのデータベース・インスタンスに接続します。
例:
sqlplus psmith@netracssl
Enter password: password
