22 Secure Sockets Layer認証の構成
Secure Sockets Layer認証を使用するようにOracle Databaseを構成できます。
- Secure Sockets LayerおよびTransport Layer Security
Secure Sockets Layer (SSL)は安全なネットワーク接続を目的に、Netscape社によって設計されました。 - Oracle DatabaseでのSecure Sockets Layerを使用した認証
Secure Sockets Layerは、暗号化やデータ・アクセス・コントロールなどのOracle Databaseの中核機能と連携します。 - Oracle環境におけるSecure Sockets Layerの機能: SSLハンドシェイク
Secure Sockets Layerによるネットワーク接続を開始する場合、クライアントとサーバーは、認証を行う前にSSLハンドシェイクを実行します。 - Oracle環境における公開キー・インフラストラクチャ
公開キー・インフラストラクチャ(PKI)は、組織全体のセキュリティ基盤を提供するネットワーク・コンポーネントの基質であり、信頼アサーションに基づいています。 - Secure Sockets Layerと他の認証方式の併用
SSLをデータベースのユーザー名とパスワード、RADIUSおよびKerberosと同時に使用するようにOracle Databaseを構成できます。 - Secure Sockets Layerとファイアウォール
Oracle Databaseは、アプリケーション・プロキシベースのファイアウォールとステートフル・パケット・インスペクション・ファイアウォールの2つをサポートしています。 - Secure Sockets Layer使用時の問題
他のOracle製品との通信や、サポート対象の認証方式および暗号化方式のタイプといった、SSLの使用に関する問題に注意する必要があります。 - Secure Sockets Layerの有効化
Secure Sockets Layerは、サーバーで構成してから、クライアントで構成する必要があります。 - Secure Sockets Layer構成のトラブルシューティング
Oracle Database SSLアダプタの使用中に一般的なエラーが発生する場合があります。 - 証明書失効リストによる証明書の検証
オラクル社では、証明書失効リストを使用して証明書を検証できるツールを提供しています。 - ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
Oracle Databaseでは、RSA Security社のPKCS #11仕様に準拠したAPIを使用するハードウェア・セキュリティ・モジュールがサポートされています。
親トピック: 厳密認証の管理
Secure Sockets LayerおよびTransport Layer Security
Secure Sockets Layer (SSL)は安全なネットワーク接続を目的に、Netscape社によって設計されました。
- Secure Sockets LayerとTransport Layer Securityの違い
Transport Layer Security (TLS)は、Secure Sockets Layer (SSL)バージョン3.0の増分バージョンです。 - マルチテナント環境でのTransport Layer Securityの使用
Transport Layer Security (TLS)はアプリケーション・コンテナに使用できます。 - Oracle Internet DirectoryによるTransport Layer Security認証の使用の有効化
Oracle Internet Directory (OID)でTransport Layer Security (TLS)を使用できるようにするには、ウォレットと証明書を作成し、tnsnames.ora
およびsqlnet.ora
を変更します。
親トピック: Secure Sockets Layer認証の構成
Secure Sockets LayerとTransport Layer Securityの違い
Transport Layer Security (TLS)は、Secure Sockets Layer (SSL)バージョン3.0の増分バージョンです。
SSLは最初にNetscape社によって開発されましたが、Internet Engineering Task Force (IETF)がその開発を引き継ぎ、名前をTransport Layer Security (TLS)に変更しました。
ノート:
説明を簡単にするため、このドキュメントでは、SSLまたはTLSのどちらも適切な場合、SSLが最も広く認識されている用語であるためSSLという用語を使用します。ただし、これらのプロトコルの使用方法または構成方法に違いがある場合、この章では、記述内容がSSLに該当するか、TLSに該当するかを明記します。
マルチテナント環境でのTransport Layer Securityの使用
Transport Layer Security (TLS)はアプリケーション・コンテナに使用できます。
Oracle DatabaseでのSecure Sockets Layerを使用した認証
Secure Sockets Layerは、暗号化およびデータ・アクセス・コントロールなど、Oracle Databaseの中核機能と連携します。
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認証の構成
Oracle環境におけるSecure Sockets Layerの機能: SSLハンドシェイク
Secure Sockets Layerによるネットワーク接続を開始する場合、クライアントとサーバーは、認証を行う前にSSLハンドシェイクを実行します。
ハンドシェイク・プロセスは次のようになります。
-
クライアントとサーバーは、どの暗号スイートを使用するかを設定します。これには、データ転送に使用する暗号化アルゴリズムも含まれます。
-
サーバーは証明書をクライアントに送信し、クライアントは、サーバーの証明書が信頼できるCAによって署名されていることを検証します。このステップにより、サーバーの身元が検証されます。
-
同様に、クライアント認証が必要な場合は、クライアントが自分自身の証明書をサーバーに送信し、サーバーは、クライアントの証明書が信頼できるCAによって署名されているかどうかを検証します。
-
クライアントとサーバーが、公開キー暗号化を使用してキー情報を交換します。この情報に基づき、双方でセッション・キーが生成されます。クライアントとサーバーとの間の以降の通信はすべて、このセッション・キーと、ネゴシエーションにより決定した暗号スイートを使用して、暗号化または復号化されます。
認証プロセスは次のとおりです。
-
クライアントで、ユーザーがSSLを使用してサーバーへのOracle Net接続を開始します。
-
SSLは、クライアントとサーバー間のハンドシェイクを実行します。
-
ハンドシェイクが成功すると、サーバーは、そのデータベースにアクセスするために必要な認可をユーザーが所有していることを検証します。
親トピック: Secure Sockets Layer認証の構成
Oracle環境における公開キー・インフラストラクチャ
公開キー・インフラストラクチャ(PKI)は、組織全体のセキュリティ基盤を提供するネットワーク・コンポーネントの基質であり、信頼アサーションに基づいています。
- 公開キーの暗号化について
従来の秘密キーまたは対称キーの暗号化では、安全な通信を確立する目的で2者以上が共有する1つの秘密キーが必要です。 - Oracle環境における公開キー・インフラストラクチャ・コンポーネント
Oracle環境の公開キー・インフラストラクチャ(PKI)のコンポーネントには、認証局、証明書、証明書失効リストおよびウォレットなどがあります。
親トピック: Secure Sockets Layer認証の構成
公開キーの暗号化について
従来の秘密キーまたは対称キーの暗号化では、安全な通信を確立する目的で2者以上が共有する1つの秘密キーが必要です。
このキーは、ユーザー間で送信される保護メッセージの暗号化および復号化に使用されるため、各ユーザーへは事前に安全な方法でキーを配布する必要があります。この方法における問題点は、キーを安全に転送し、格納することが困難なことです。
公開キーの暗号化による公開キー/秘密キーのペアおよびキー配布のための安全な方法を採用することで、この問題は解決します。対応する秘密キーの所有者のみが復号化できるメッセージは、自由に使用できる公開キーによって暗号化できます。秘密キーは、その他のセキュリティ資格証明とともに、ウォレットと呼ばれる暗号化されたコンテナに、安全に格納されます。
公開キーのアルゴリズムでは、メッセージの秘密は保証されますが、安全な通信は必ずしも保証されません。その理由は、通信者間の識別が検証されないためです。安全な通信を確立するには、メッセージの暗号化に使用される公開キーが相手の受信者に実際に属していることを確認することが重要です。そうしないと、第三者が通信を傍受し、公開キーのリクエストに割り込み、正当なキーを独自の公開キーに置き換えることが可能になります(介在者攻撃)。
この攻撃を回避するには、公開キーの所有者の確認(認証と呼ばれるプロセス)が必要です。認証は、通信する双方の委託するサード・パーティの認証局(CA)によって行われます。
CAは、エンティティの名前、公開キーおよび他のセキュリティ資格証明を含む公開キー証明書を発行します。通常、このような資格証明には、CA名、CAの署名および証明書の有効日(開始日、終了日)が含まれています。
CAでは独自の秘密キーを使用してメッセージを暗号化します。一方、そのメッセージの復号化には公開キーが使用されるため、メッセージがCAによって暗号化されたものであるかどうかが確認されます。CA公開キーは広く一般に知られているため、アクセスするたびに認証する必要はありません。このようなCA公開キーはウォレットに格納されます。
親トピック: Oracle環境における公開キー・インフラストラクチャ
Oracle環境における公開キー・インフラストラクチャ・コンポーネント
Oracle環境の公開キー・インフラストラクチャ(PKI)のコンポーネントには、認証局、証明書、証明書失効リストおよびウォレットなどがあります。
- 認証局
認証局(CA)は、ユーザー、データベース、管理者、クライアント、サーバーなどのエンティティの識別情報を証明する、信頼できるサード・パーティです。 - 証明書
証明書は、エンティティの公開キーが、信頼できる認証局(CA)によって署名されたときに作成されます。 - 証明書失効リスト
公開キー・ペアをユーザーIDにバインドする証明書にCAが署名すると、証明書は指定された期間有効になります。 - ウォレット
ウォレットは、認証および署名資格証明(SSLで必要な秘密キー、証明書、信頼できる証明書など)の格納に使用されるコンテナです。 - ハードウェア・セキュリティ・モジュール
SSLのハードウェア・セキュリティ・モジュールには、様々な機能を処理するデバイスや、暗号情報を格納するハードウェア・デバイスなどがあります。
親トピック: Oracle環境における公開キー・インフラストラクチャ
認証局
認証局(CA)は、ユーザー、データベース、管理者、クライアント、サーバーなどのエンティティの識別情報を証明する、信頼できるサード・パーティです。
エンティティが証明書を要求すると、CAはその識別情報を検証し、CAの秘密キーを使用して署名した証明書を発行します。
CAごとに、証明書の発行時の識別情報要件が異なる可能性があります。CAの中には、要求者の識別情報をドライバのライセンスを使用して確認したり、要求者の指紋で識別情報を確認したり、証明書リクエスト・フォームが認証されていることを必要とするものがあります。
CAは、公開キーが含まれている独自の証明書を発行します。各ネットワーク・エンティティには、信頼できるCA証明書のリストがあります。通信する前に、ネットワーク・エンティティは証明書を交換し、相互の証明書がそれぞれの信頼できるCA証明書リストのいずれかのCAによって署名されていることを確認します。
ネットワーク・エンティティは、同じCAから、または異なるCAから証明書を取得できます。デフォルトでは、Oracle Databaseは、新規ウォレットの作成時にVeriSign社、RSA社、Entrust社およびGTE CyberTrust社から信頼できる証明書を自動的にインストールします。
関連トピック
証明書
証明書は、エンティティの公開キーが、信頼できる認証局(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 12cリリース1 (12.1)以降のSSLアダプタでのみ使用できます。
関連トピック
ウォレット
ウォレットは、認証および署名資格証明(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を構成できます。
- アーキテクチャ: Oracle DatabaseとSecure Sockets Layer
Oracle DatabaseとSSLとの連携のアーキテクチャを理解することが重要です。 - Secure Sockets Layerと他の認証方式の併用
Secure Sockets Layerは、Oracle Databaseでサポートされているその他の認証方式との併用が可能です。
親トピック: Secure Sockets Layer認証の構成
アーキテクチャ: Oracle DatabaseとSecure Sockets Layer
Oracle DatabaseとSSLとの連携のアーキテクチャを理解することが重要です。
Secure Sockets LayerアーキテクチャのOracle Databaseの実装を示す図19-4では、Oracle DatabaseがSSLの上位のセッション・レイヤーで動作し、トランスポート・レイヤーでTCP/IPを使用していることを示しています。
このように機能が分離されているため、SSLを他のサポートされているプロトコルと同時に利用できます。
関連項目:
Oracleネットワーキング環境におけるスタック通信の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
Secure Sockets Layerと他の認証方式の併用
Secure Sockets Layerは、Oracle Databaseでサポートされているその他の認証方式との併用が可能です。
図22-1に、Secure Sockets Layerが別の認証方式と併用されている構成を示します。
この例では、最初のハンドシェイク(サーバー認証)を確立するためにSecure Sockets Layerが使用され、クライアントの認証に別の認証方式が使用されています。このプロセスは、次のとおりです。
-
クライアントがOracleデータベース・サーバーに接続しようとします。
-
Secure Sockets Layerによってハンドシェイクが実行され、その間にサーバーがクライアントに対して自己認証を行い、クライアントとサーバーの両方が使用する暗号スイートを設定します。
-
Secure Sockets Layerハンドシェイクが正常に完了すると、ユーザーはデータベースにアクセスしようとします。
-
Oracleデータベース・サーバーは、KerberosやRADIUSなどの非SSL認証方式を使用して、認証サーバーでユーザーを認証します。
-
認証サーバーによる検証が完了すると、Oracleデータベース・サーバーによってアクセス権と認可がユーザーに付与され、ユーザーはSSLを使用してデータベースに安全にアクセスできるようになります。
Secure Sockets Layerとファイアウォール
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ポートとして指定されている必要があります。
-
クライアントは、以降のすべての接続でこのサーバー指定ポートを使用して通信します。
親トピック: Secure Sockets Layer認証の構成
Secure Sockets Layer使用時の問題
他のOracle製品との通信や、サポート対象の認証方式および暗号化方式のタイプといった、SSLの使用に関する問題に注意する必要があります。
SSLを使用する場合は、次のことを考慮してください。
-
SSLを使用すると、Oracle Internet Directoryなどの他のOracle製品との安全な通信が可能になります。
-
SSLでは認証と暗号化の両方がサポートされているため、クライアント/サーバー接続が標準のOracle Net TCP/IPトランスポート(ネイティブ暗号化を使用)より多少遅くなります。
-
各SSL認証モードには、構成設定が必要となります。
ノート:
SSL暗号化を構成する場合は、非SSL暗号化を無効にする必要があります。このような暗号化を無効にするには、厳密認証およびネイティブ・ネットワーク暗号化の無効化を参照してください。
親トピック: Secure Sockets Layer認証の構成
Secure Sockets Layerの有効化
Secure Sockets Layerは、サーバーで構成してから、クライアントで構成する必要があります。
- ステップ1: サーバーでのSecure Sockets Layerの構成
インストール中、Oracleデータベース・サーバーとOracleクライアントに、Oracleウォレットの場所を除くSSLパラメータのデフォルトが設定されます。 - ステップ2: クライアントでのSecure Sockets Layerの構成
SSLをクライアントで構成する場合、サーバーDNを構成して、SSL付きTCP/IPをクライアントで使用します。 - ステップ3: データベース・インスタンスへのログイン
構成の完了後、データベースにログインします。
親トピック: Secure Sockets Layer認証の構成
ステップ1: サーバーでのSecure Sockets Layerの構成
インストール中、Oracleデータベース・サーバーとOracleクライアントに、Oracleウォレットの場所を除くSSLパラメータのデフォルトが設定されます。
- ステップ1A: サーバーでのウォレット作成の確認
次のステップに進む前に、ウォレットが作成されていることと、ウォレットに証明書があることを確認する必要があります。 - ステップ1B: サーバーでのデータベース・ウォレット・ロケーションの指定
次に、ウォレットのサーバー上の場所を指定します。 - ステップ1C: サーバーでのSecure Sockets Layer暗号スイートの設定(オプション)
オプションで、Secure Sockets Layer暗号スイートを設定できます。 - ステップ1D: サーバーでの必要なSecure Sockets Layerバージョンの設定(オプション)
SSL_VERSION
パラメータでは、サーバーが通信するシステムで実行する必要があるSSLのバージョンを定義します。 - ステップ1E: サーバーでのSSLクライアント認証の設定(オプション)
SSL_CLIENT_AUTHENTICATION
パラメータは、クライアントがSSLを使用して認証されるかどうかを制御します。 - ステップ1F: サーバーでの認証サービスとしてのSSLの設定(オプション)
sqlnet.ora
ファイルのSQLNET.AUTHENTICATION_SERVICES
パラメータでは、SSL認証サービスを設定します。 - ステップ1G: サーバーおよびクライアントでのSSLv3の無効化(オプション)
SSLv3はSecure Sockets Layerバージョン3のことです。 - ステップ1H: SSL付きTCP/IPを使用するリスニング・エンドポイントのサーバーでの作成
SSL付きTCP/IPを使用するリスニング・エンドポイントをサーバーで構成できます。
親トピック: Secure Sockets Layerの有効化
ステップ1A: サーバーでのウォレット作成の確認
次のステップに進む前に、ウォレットが作成されていることと、ウォレットに証明書があることを確認する必要があります。
関連項目:
Oracleウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。ステップ1B: サーバーでのデータベース・ウォレット・ロケーションの指定
次に、ウォレットのサーバー上の場所を指定します。
ノート:
リスナーでは、listener.ora
ファイルに定義されているウォレットを使用します。任意のデータベース・ウォレットを使用できます。Net Managerを使用してサーバーのSSLが構成されている場合、ウォレット・ロケーションはlistener.ora
ファイルとsqlnet.ora
ファイルに入力されています。listener.ora
ファイルは、Oracleクライアントには関係ありません。
リスナーが独自のウォレットを所有するようにリスナーのウォレット・ロケーションを変更するには、listener.ora
を編集して新しい場所を入力します。
ステップ1C: サーバーでのSecure Sockets Layer暗号スイートの設定(オプション)
オプションで、Secure Sockets Layer暗号スイートを設定できます。
- Secure Sockets Layer暗号スイートについて
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。 - SSL暗号スイートの認証、暗号化、整合性およびTLSバージョン
Oracle Databaseでは、Oracle Databaseをインストールするとデフォルトで設定される一連の暗号スイートがサポートされています。 - データベース・サーバーのSecure Sockets暗号スイートの指定
最初に、データベース・サーバーのSecure Sockets暗号スイートを指定する必要があります。
Secure Sockets Layer暗号スイートについて
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。
Secure Sockets Layerハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Databaseをインストールすると、表22-1のSecure Sockets Layer暗号スイートがデフォルトで設定され、リスト順にネゴシエートされます。デフォルトの順序は、SSL_CIPHER_SUITES
パラメータを設定して上書きできます。SSL_CIPHER_SUITES
パラメータの設定は必ずカッコで囲んでください(例: SSL_CIPHER_SUITES=(ssl_rsa_with_aes_128_cbc_sha256)
)。そうしないと、暗号スイート設定が正しく解析されません。
暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。
-
互換性。正常に接続するには、互換性のある暗号スイートを使用するようにサーバーとクライアントを構成する必要があります。
-
暗号の優先順位と強度。最高レベルのセキュリティを確保するために、最も強力なものから最も弱いものの順に暗号スイートの優先順位を設定します。
-
使用するセキュリティ・レベル。
-
パフォーマンスへの影響。
ノート:
Diffie-Hellman 匿名認証について:
-
この暗号スイートを使用するようにサーバーを設定する場合は、同じ暗号スイートをクライアントにも設定する必要があります。設定しない場合、接続に失敗します。
-
Diffie-Hellman匿名を使用する暗号スイートを使用する場合、
SSL_CLIENT_AUTHENTICATION
パラメータをFALSE
に設定する必要があります。詳細は、ステップ1E: サーバーでのSSLクライアント認証の設定(オプション)を参照してください。 -
既知の不具合があり、クライアントを認証しないDH_ANONを含む暗号スイートを使用する場合でも、OCIクライアントでウォレットが必要です。
-
SSL暗号スイートの認証、暗号化、整合性およびTLSバージョン
Oracle Databaseでは、Oracle Databaseをインストールするとデフォルトで設定される一連の暗号スイートがサポートされています。
表22-1に、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプを示します。
Oracle Database 20c以降では、Transport Layer Securityプロトコル・バージョン1.0 (TLS 1.0)は非推奨となっています。セキュリティ要件を満たすために、セキュリティのベスト・プラクティスに従って、かわりにTLS 1.2を使用することをお薦めします。
表22-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のみ |
表22-2に、使用可能な暗号スイートを示しますが、これらは通信者の認証を提供しないため、介在者攻撃に対して無防備になる可能性があることに注意してください。機密データを保護する場合は、これらの暗号スイートを使用しないことをお薦めします。ただし、これらは、通信者が匿名を維持する場合や、相互認証によって発生するオーバーヘッドを望まない場合に有効です。
表22-2 SSL_DH Secure Sockets Layer暗号スイート
暗号スイート | 認証 | 暗号化 | データ整合性 | TLSの互換性 |
---|---|---|---|---|
|
DH anon |
3DES EDE CBC |
SHA-1 |
TLS 3.0以降 |
ステップ1D: サーバーでの必要なSecure Sockets Layerバージョンの設定(オプション)
SSL_VERSION
パラメータでは、サーバーが通信するシステムで実行する必要があるSSLのバージョンを定義します。
オプションで、sqlnet.ora
ファイルまたはlistener.ora
ファイルでSSL_VERSION
パラメータを設定できます。
これらのシステムで有効なバージョンを使用するように設定できます。sqlnet.ora
におけるこのパラメータのデフォルト設定はundetermined
で、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。
ノート:
SSL 2.0はサーバー側でサポートされていません。
関連項目:
SSL_VERSION
パラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
ステップ1E: サーバーでのSSLクライアント認証の設定(オプション)
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
に設定するには:
ステップ1F: サーバーでの認証サービスとしてのSSLの設定(オプション)
sqlnet.ora
ファイルのSQLNET.AUTHENTICATION_SERVICES
パラメータでは、SSL認証サービスを設定します。
このパラメータは、SSL認証とOracle Databaseでサポートされている別の認証方式を組み合せて使用する場合に設定します。たとえば、サーバーがSSLを使用してクライアントに対して自己認証を行い、クライアントがKerberosを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。
-
サーバーに
SQLNET.AUTHENTICATION_SERVICES
パラメータを設定するには、テキスト・エディタを使用してsqlnet.ora
ファイルでこのパラメータにSSL付きTCP/IP(TCPS)を追加します。たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)
SSL認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。
ステップ1G: サーバーおよびクライアントでのSSLv3の無効化(オプション)
SSLv3はSecure Sockets Layerバージョン3のことです。
ADD_SSLV3_TO_DEFAULT
sqlnet.ora
パラメータをFALSE
に設定する必要があります。ADD_SSLV3_TO_DEFAULT
は、SSL_VERSION
パラメータが設定されていない場合にのみ適用されます。(SSLバージョンのデフォルト・リストが使用されることを意味します)。
ステップ2: クライアントでのSecure Sockets Layerの構成
SSLをクライアントで構成する場合、サーバーDNを構成して、SSL付きTCP/IPをクライアントで使用します。
- ステップ2A: クライアント・ウォレット作成の確認
クライアントでウォレットが作成されていることと、クライアントに有効な証明書があることを確認する必要があります。 - ステップ2B: サーバーDN一致の構成とクライアントでのSSL付きTCP/IPの使用
次に、サーバーDN一致を構成し、クライアントでSecure Sockets Layer (SSL)付きのTCP/IPを使用します。 - ステップ2C: 必要なクライアントSSL構成の指定(ウォレット・ロケーション)
Oracle Net Managerを使用して、必要なクライアントSSL構成を指定できます。 - ステップ2D: 単一データベース・クライアントからの様々な証明書の使用による複数データベースへの接続
オプションで、クライアントを、様々な証明書およびウォレットを使用して複数のOracle Databaseサーバーに接続するように構成できます。 - ステップ2E: クライアントのSecure Sockets Layer暗号スイートの設定(オプション)
オプションで、SSL暗号スイートを設定できます。Oracle Databaseにはデフォルトの暗号スイート設定が用意されています。 - ステップ2F: 必要なSSLバージョンのクライアントでの設定(オプション)
SSL_VERSION
パラメータでは、クライアントが通信するシステムで実行する必要があるSSLのバージョンを定義します。 - ステップ2G: クライアントにおける認証サービスとしてのSSLの設定(オプション)
sqlnet.ora
ファイルのSQLNET.AUTHENTICATION_SERVICES
パラメータでは、SSL認証サービスを設定します。 - ステップ2H: クライアントでの認証に使用する証明書の指定(オプション)
証明書が複数ある場合は、sqlnet.ora
ファイルのSQLNET.SSL_EXTENDED_KEY_USAGE
パラメータで正しい証明書を指定できます。
親トピック: Secure Sockets Layerの有効化
ステップ2A: クライアント・ウォレット作成の確認
クライアントでウォレットが作成されていることと、クライアントに有効な証明書があることを確認する必要があります。
-
Oracle Wallet Managerを使用して、ウォレットが作成されていることを確認します。ウォレットの確認の詳細は、「ステップ1A: サーバーでのウォレット作成の確認」を参照してください。
関連項目:
-
ウォレットの一般情報は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
-
既存のウォレットを開く方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
-
ウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
ステップ2B: サーバーDN一致の構成とクライアントでのSSL付きTCP/IPの使用
次に、サーバーDN一致を構成し、クライアントでSecure Sockets Layer (SSL)付きのTCP/IPを使用します。
- サーバーDN一致の構成とクライアントでのSSL付きTCP/IPの使用について
サーバー証明書の証明書チェーンの検証に加えて、サーバーDN一致を使用して追加のチェックを実行できます。 - サーバーDN一致の構成とクライアントでのSSL付きTCP/IPの使用
サーバーDN一致を構成し、クライアントでSSL付きTCP/IPを使用するようにtnsnames.ora
とlistener.ora
ファイルを編集する必要があります。
サーバーDN一致の構成とクライアントでのSSL付きTCP/IPの使用について
サーバー証明書の証明書チェーンの検証に加えて、サーバーDN一致を使用して追加のチェックを実行できます。
サーバーDN一致を含み、クライアントでSSL付きのTCP/IPを使用するようにOracle Net Service名を構成できます。これを実行するには、クライアント・ネットワーク構成ファイルで、サーバーDNマッチングおよびTCP/IPをSSL接続できるように、プロトコルとしてサーバーの識別名(DN)とTCPS
を指定する必要があります。サーバーDN一致はオプションですが、クライアントにセキュリティのレイヤーが追加されるため、お薦めします。これにより、クライアントはサーバーに対してこのチェックを実行できます。
部分DN一致または完全DN一致のいずれかを構成できます。SSL_SERVER_DN_MATCH
パラメータをTRUE
に設定すると、部分DN一致が自動的に実行されます。次に、クライアントはDN情報のサーバー証明書をチェックします。完全DN一致により、クライアントはサーバーの完全なDNと照合できます。完全DN一致を実行する場合は、SSL_SERVER_CERT_DN
パラメータにサーバーのDNを指定する必要があります。
部分または完全DN一致のいずれかを使用すると、ホスト証明書の作成方法と管理方法に基づいて柔軟性が向上します。たとえば、クライアントがhostname=finance.us.example.com
を使用してサーバーへの接続を試みるとします。部分DN一致では、クライアントはサーバーの証明書をチェックして、CN=finance
がサーバーのDNであることを確認します。部分DN一致の場合、ホスト名(finance
)のみがチェックされ、完全修飾ドメイン名(finance.us.example.com
)はチェックされません。完全DN一致と部分DN一致の両方について、SSL_SERVER_DN_MATCH
パラメータをTRUE
に設定する必要があります。
クライアント・ネットワーク構成ファイルのtnsnames.ora
を手動で編集して、サーバーのDNとTCP/IPをSSLプロトコルに指定する必要があります。tnsnames.ora
ファイルは、クライアントまたはLDAPディレクトリに配置できます。サーバーに配置される場合は、通常、listener.ora
ファイルと同じディレクトリに存在します。tnsnames.ora
ファイルは、通常、TNS_ADMIN
環境変数で指定された設定にあります。TNS_ADMIN
が設定されていない場合、tnsnames.ora
は次のディレクトリの場所に存在します。
-
(UNIXの場合)
$ORACLE_HOME
/network/admin/
-
(Windowsの場合)
ORACLE_BASE
\
ORACLE_HOME
\network\admin\
ステップ2C: 必要なクライアントSSL構成の指定(ウォレット・ロケーション)
Oracle Net Managerを使用して、必要なクライアントSSL構成を指定できます。
関連項目:
サーバー照合パラメータの詳細は、次を参照してください。
Oracle Net Managerを使用してSSL付きTCP/IPを構成する方法の詳細は、次を参照してください。
ステップ2D: 単一データベース・クライアントからの様々な証明書の使用による複数データベースへの接続
オプションで、クライアントを、様々な証明書およびウォレットを使用して複数のOracle Databaseサーバーに接続するように構成できます。
- 単一データベース・クライアントからの様々な証明書の使用による複数データベースへの接続について
この機能により、マルチスレッド化されたクライアントで、同時に実行される複数のSecure Sockets Layer (SSL)セッションのために、証明書が異なる複数のウォレットを使用できます。 - クライアント接続での個別のSSLセッションの有効化
1つのクライアント接続で複数の個別のSecure Sockets Layer (SSL)セッションを使用できるように、tnsnames.ora
ファイルのWALLET_LOCATION
パラメータを構成できます。
単一データベース・クライアントからの様々な証明書の使用による複数データベースへの接続について
この機能により、マルチスレッド・クライアントは、同時Secure Sockets Layer (SSL)セッションに対して異なる証明書を持つ複数のウォレットを使用できます。
この機能は、単一のクライアントで様々なウォレットおよび証明書を使用して様々なOracle Databasesに接続する必要がある場合に使用します。たとえば、複数のプラガブル・データベース(PDB)へのアクセスが必要なクライアントが、それぞれ独自のID (証明書)を持つ場合です。この機能により、クライアントが各PDBの正しいIDに接続するように構成できます。構成が完了すると、マルチスレッド・クライアントは、同時SSLセッションで異なる証明書を持つ複数のウォレットにアクセスできるようになります。
ステップ2E: クライアントのSecure Sockets Layer暗号スイートの設定(オプション)
オプションで、SSL暗号スイートを設定できます。Oracle Databaseにはデフォルトの暗号スイート設定が用意されています。
- クライアントのSecure Sockets Layer暗号スイートの設定について
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。 - クライアントのSecure Sockets Layer暗号スイートの設定
Oracle Net Managerを使用して、クライアントSSL暗号スイートを設定できます。
クライアントのSecure Sockets Layer暗号スイートの設定について
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。
SSLハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Databaseをインストールすると、表22-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匿名認証を利用する暗号スイートは使用できません。
通常、暗号スイートは最も強力なものから弱いものの順に優先順位を設定します。
表22-1に、現在サポートされているSecure Sockets Layer暗号スイートを示します。これらの暗号スイートは、Oracle Databaseをインストールするとデフォルトで設定されます。表では、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプも示されています。
ノート:
sqlnet.ora
ファイルでSSL_CLIENT_AUTHENTICATION
パラメータをtrue
に設定する場合は、Diffie-Hellman匿名認証を使用するすべての暗号スイートを無効にします。設定しない場合、接続に失敗します。
ステップ2F: 必要なSSLバージョンのクライアントでの設定(オプション)
SSL_VERSION
パラメータでは、クライアントが通信するシステムで実行する必要があるSSLのバージョンを定義します。
sqlnet.ora
ファイルでSSL_VERSION
パラメータを設定する必要があります。これらのシステムで有効なバージョンを使用するように設定できます。
sqlnet.ora
におけるこのパラメータのデフォルト設定はundetermined
で、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。「任意」を選択すると、TLS 1.0が最初に試行され、その後、SSL 3.0、SSL 2.0の順に試行されます。クライアントのSSLバージョンがサーバーで使用されているバージョンと互換性があることを確認します。
ステップ2G: クライアントにおける認証サービスとしてのSSLの設定(オプション)
sqlnet.ora
ファイルのSQLNET.AUTHENTICATION_SERVICES
パラメータでは、SSL認証サービスを設定します。
- SQLNET.AUTHENTICATION_SERVICESパラメータについて
SQLNET.AUTHENTICATION_SERVICES
パラメータは、SSL認証とOracle Databaseでサポートされている別の認証方式の併用を可能にします。 - SQLNET.AUTHENTICATION_SERVICESパラメータの設定
sqlnet.ora
ファイルでSQLNET.AUTHENTICATION_SERVICES
パラメータを設定できます。
SQLNET.AUTHENTICATION_SERVICESパラメータについて
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.AUTHENTICATION_SERVICESパラメータの設定
sqlnet.ora
ファイルでSQLNET.AUTHENTICATION_SERVICES
パラメータを設定できます。
-
クライアントの
SQLNET.AUTHENTICATION_SERVICES
パラメータを設定するには、テキスト・エディタを使用して、sqlnet.ora
ファイルのこのパラメータにSSL付きTCP/IP (TCPS
)を追加します。たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。
SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)
SSL認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。
ステップ2H: クライアントでの認証に使用する証明書の指定(オプション)
証明書が複数ある場合は、sqlnet.ora
ファイルのSQLNET.SSL_EXTENDED_KEY_USAGE
パラメータで正しい証明書を指定できます。
- SQLNET.SSL_EXTENDED_KEY_USAGEパラメータについて
sqlnet.oraファイルのSQLNET.SSL_EXTENDED_KEY_USAGE
パラメータは、データベース・サーバー認証時に使用する証明書を指定します。 - SQLNET.SSL_EXTENDED_KEY_USAGEパラメータの設定
SQLNET.SSL_EXTENDED_KEY_USAGE
を設定して、クライアント認証を設定できます。
SQLNET.SSL_EXTENDED_KEY_USAGEパラメータについて
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.SSL_EXTENDED_KEY_USAGE
パラメータを設定するには、sqlnet.ora
ファイルを編集し、次の行を含めます。SQLNET.SSL_EXTENDED_KEY_USAGE = "client authentication"
証明書のフィルタ処理を使用しない場合は、sqlnet.ora
ファイルからSQLNET.SSL_EXTENDED_KEY_USAGE
パラメータ設定を削除します。
ステップ3: データベース・インスタンスへのログイン
構成の完了後、データベースにログインします。
-
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
-
関連トピック
親トピック: Secure Sockets Layerの有効化
Secure Sockets Layer構成のトラブルシューティング
Oracle Database SSLアダプタの使用中に一般的なエラーが発生する場合があります。
Oracle Netトレースを有効にして、エラーの原因を特定することが必要になる場合があります。トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
- ORA-28759: ファイルのオープンに失敗しました
-
原因: 指定されたファイルをオープンできませんでした。通常、このエラーはウォレットが見つからないために発生します。
- ORA-28786: 暗号化された秘密キーの復号化に失敗しました
-
原因: 暗号化された秘密キーの復号化に不正なパスワードが使用されました。このことは、多くの場合、自動ログイン・ウォレットが使用されていないために発生します。
- ORA-28858: SSLプロトコル・エラーが発生しました
-
原因: これは、2つのプロセス間のSSLハンドシェイク・ネゴシエーション中に発生する可能性がある一般的なエラーです。
- ORA-28859 SSLでネゴシエーションに失敗しました
-
原因: SSLプロトコルの一部である2つのプロセス間のネゴシエーション中にエラーが発生しました。このエラーは、両プロセスの接続で同じ暗号スイートがサポートされていない場合に発生する可能性があります。
- ORA-28862: SSL接続に失敗しました。
-
原因: このエラーは、ピアが接続をクローズしたために発生しました。
- ORA-28865: SSL接続はクローズしました。
-
原因: 基礎となるトランスポート層でエラーが発生したか、ピア・プロセスが突然停止したため、SSL接続がクローズしました。
- ORA-28868: ピア証明連鎖のチェックに失敗しました。
-
原因: ピアが証明連鎖を提示したときに、その証明連鎖のチェックに失敗しました。この失敗の原因として、いくつかの問題が考えられます。
-
連鎖内のいずれかの証明書が期限切れになっています。
-
連鎖内のいずれかの証明書の認証局がトラスト・ポイントとして認識されていません。
-
いずれかの証明書の署名を検証できません。
-
- ORA-28885: 必須のキー使用方法のある証明書が見つかりません。
-
原因: 証明書は、適切なX.509バージョン3のキー使用方法の拡張機能を使用して作成されていません。
- ORA-29024: 証明書の検証に失敗しました
-
原因: 反対側から送信された証明書の妥当性チェックに失敗しました。このエラーは、証明書が期限切れか、失効済か、または他の理由で無効になっている場合に発生する可能性があります。
- ORA-29223: 証明連鎖を作成できませんでした
-
原因: インストールする証明書の既存のトラスト・ポイントを使用して証明連鎖を作成できません。通常、このエラーは、ピアによって完全な連鎖が提供されず、連鎖を完了するのに適切なトラスト・ポイントがない場合に戻されます。
親トピック: Secure Sockets Layer認証の構成
証明書失効リストによる証明書の検証
オラクル社では、証明書失効リストを使用して証明書を検証できるツールを提供しています。
- 証明書失効リストによる証明書検証について
指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。 - 使用するCRLの選択方法
使用するトラスト・ポイントすべてについてCRLが必要です。 - CRLチェックの動作の仕組み
Oracle Databaseでは証明書の失効状態をCRLに照らして確認します。 - 証明書失効リストによる証明書検証の構成
sqlnet.ora
ファイルを編集して、証明書失効リストによる証明書検証を構成できます。 - 証明書失効リストの管理
証明書失効リストの管理では、証明書失効チェックを有効にする前に、CRLが正しい書式であることを確認する必要があります。 - CRL証明書検証のトラブルシューティング
CRLに対して証明書を検証するかどうかを判断するには、Oracle Netトレースを有効にできます。 - 証明書検証に関連するOracle Netトレース・ファイルのエラー・メッセージ
証明書検証に関連するトレース・メッセージが生成されます。
親トピック: Secure Sockets Layer認証の構成
証明書失効リストによる証明書検証について
指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。
証明書の検証には、次が該当するかどうかの判定が含まれます。
-
信頼できる認証局(CA)にデジタル署名された証明書があるかどうか。
-
証明書のデジタル署名が、証明書自体の別個に計算されたハッシュ値および証明書の署名者の(CAの)公開キーに対応しているかどうか。
-
証明書が期限切れになっていないかどうか。
-
証明書が失効していないかどうか。
SSLネットワーク・レイヤーは、自動的に最初の3つの検証チェックを実行しますが、証明書が失効していないことを確認するには、証明書失効リスト(CRL)のチェックを構成する必要があります。CRLは、失効した証明書のリストを含む署名付きデータ構造体です。これは通常、元の証明書を発行したエンティティと同じエンティティによって発行され署名されます。(「証明書失効リスト(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
に設定する必要があります。
証明書失効ステータス・チェックを有効にするには、sqlnet.ora
ファイルでSSL_CERT_REVOCATION
パラメータをREQUIRED
またはREQUESTED
に設定する必要があります。
デフォルトでは、このパラメータはNONE
に設定され、証明書失効ステータス・チェックはオフになっています。
ノート:
CRLをローカル・ファイル・システムまたはOracle Internet Directoryに格納する場合は、コマンドライン・ユーティリティorapki
を使用して、ファイル・システム内のCRLの名前を変更するか、CRLをディレクトリにアップロードします。
関連トピック
親トピック: 証明書失効リストによる証明書検証の構成
クライアントまたはサーバー用の証明書失効ステータス・チェックの有効化
クライアントまたはサーバー用の証明書失効ステータス・チェックを有効にできます。
関連トピック
親トピック: 証明書失効リストによる証明書検証の構成
証明書失効リストの管理
証明書失効リストの管理では、証明書失効チェックを有効にする前に、CRLが正しい書式であることを確認する必要があります。
- 証明書失効リストの管理について
Oracle Databaseには、証明書の管理を実行するために使用できるコマンドライン・ユーティリティorapki
があります。 - CRLを管理するコマンドのorapkiヘルプの表示
CRLの管理に使用可能なorapki
コマンドをすべて表示できます。 - 証明書検証用ハッシュ値によるCRLの名前変更
システムは、証明書を検証するとき、証明書を作成したCAが発行するCRLを見つける必要があります。 - Oracle Internet DirectoryへのCRLのアップロード
ディレクトリでCRLを発行すると、企業全体でのCRL検証が可能になり、個々のアプリケーションに固有のCRLを構成する必要がなくなります。 - Oracle Internet Directoryに格納されているCRLの一覧表示
orapki
を使用してディレクトリに格納されているすべてのCRLのリストを表示できます。特定のCRLを検出してローカル・コンピュータで表示またはダウンロードする際に、このリストを参照すると便利です。 - Oracle Internet DirectoryでのCRLの表示
Oracle Internet Directory CRLは要約された形式で表示できるほか、CRLの失効した証明書のリストを要求することもできます。 - Oracle Internet DirectoryからのCRLの削除
orapki
を使用してディレクトリからCRLを削除するユーザーは、ディレクトリ・グループCRLAdmins
のメンバーである必要があります。
親トピック: 証明書失効リストによる証明書の検証
証明書失効リストの管理について
Oracle Databaseには、証明書の管理を実行するために使用できるコマンドライン・ユーティリティorapki
があります。
証明書失効ステータス・チェックを有効にするには、まず、使用するCAから受信したCRLがコンピュータで使用できるフォームである(ハッシュ値で名前変更されている)こと、またはコンピュータで使用できる場所にある(ディレクトリにアップロードされている)ことを確認してください。
LDAPコマンド行ツールを使用して、Oracle Internet DirectoryでCRLを管理することもできます。
ノート:
CRLは、正常な検証を行うために、(期限切れになる前に)定期的に更新する必要があります。このタスクは、スクリプトでorapki
コマンドを使用して自動化できます。
親トピック: 証明書失効リストの管理
CRLを管理するコマンドのorapkiヘルプの表示
CRLの管理に使用可能なorapki
コマンドをすべて表示できます。
-
CRLの管理に使用可能な
orapki
コマンドとそのオプションをすべての表示するには、コマンドラインに次のように入力します。orapki crl help
ノート:
-summary
、-complete
または-wallet
コマンド・オプションの使用は、常にオプションです。これらのコマンド・オプションが指定されていなくても、コマンドは実行されます。
親トピック: 証明書失効リストの管理
証明書検証用ハッシュ値によるCRLの名前変更
システムは、証明書を検証するとき、証明書を作成した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発行者名が表示されます。
親トピック: 証明書失効リストの管理
Oracle Internet Directoryへの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
ユーティリティではサポートされていません。
親トピック: 証明書失効リストの管理
Oracle Internet Directoryに格納されているCRLの一覧表示
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の表示
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
親トピック: 証明書失効リストの管理
Oracle Internet DirectoryからのCRLの削除
orapki
を使用してディレクトリからCRLを削除するユーザーは、ディレクトリ・グループCRLAdmins
のメンバーである必要があります。
-
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ポートであることが必要です。
-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証明書検証のトラブルシューティング
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トレース・ファイルのエラー・メッセージ
証明書検証に関連するトレース・メッセージが生成されます。
これらのトレースメッセージは、Oracle Netトレース・ファイルのentry
エントリとexit
エントリの間に記録されることがあります。Oracle SSLは複数の場所でCRLを検索するため、トレースに複数のエラーが記録されることがあります。
エラーの解決方法の詳細は、次の表示される可能性があるエラー・メッセージのリストを確認できます。
- RSAステータスでCRLの署名検証に失敗しました
-
原因: CRLの署名を検証できません。
- RSAステータスでCRLの日付検証に失敗しました
-
原因: 現在の時刻が次の更新フィールド内の時刻より後になっています。このエラーは、CRL DPを使用している場合には表示されません。CRLは次の順番で検索されます。
-
ファイル・システム
-
Oracle Internet Directory
-
CRL DP
この検索で最初に見つかったCRLが最新であるとはかぎりません。
-
- CRLが見つかりませんでした
-
原因: 構成されている場所にCRLがありませんでした。構成で証明書検証が必須に指定されている場合、エラーORA-29024が戻されます。
- Oracle Internet Directoryのホスト名またはポート番号が設定されていません
-
原因: Oracle Internet Directoryの接続情報が設定されていません。これは致命的エラーではありません。続いてCRL DPが検索されます。
- CRL DPからのCRLのフェッチ: CRLが見つかりません
-
原因: CRL配布ポイント(CRL DP)を使用してCRLをフェッチできませんでした。このことは、証明書にCRL DP拡張で指定された場所がないか、CRL DP拡張で指定されたURLが正しくない場合に発生します。
親トピック: 証明書失効リストによる証明書の検証
ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
Oracle Databaseでは、RSA Security社のPKCS #11仕様に準拠したAPIを使用するハードウェア・セキュリティ・モジュールがサポートされています。
通常、これらのハードウェア・デバイスは、トークンまたはスマートカードの秘密キーを安全に格納および管理するため、または暗号処理を高速化するために使用されます。
- SSLでハードウェア・セキュリティ・モジュールを使用するための一般的なガイドライン
Oracle Databaseでハードウェア・セキュリティ・モジュールを使用する場合は、次のガイドラインに従ってください。 - nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
暗号化処理でnCipherハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。 - SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
暗号化処理でSafeNETハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。 - ハードウェア・セキュリティ・モジュールの使用時のトラブルシューティング
ハードウェア・セキュリティ・モジュールに関するトラブルシューティングのアドバイスを提供します。
親トピック: Secure Sockets Layer認証の構成
SSLでハードウェア・セキュリティ・モジュールを使用するための一般的なガイドライン
Oracle Databaseでハードウェア・セキュリティ・モジュールを使用する場合は、次のガイドラインに従ってください。
-
必要なハードウェア、ソフトウェアおよびPKCS #11ライブラリを取得するには、ハードウェア・デバイス・ベンダーにお問い合せください。
-
使用しているハードウェア・セキュリティ・モジュールに適したハードウェア、ソフトウェアおよびライブラリをインストールします。
-
ハードウェア・セキュリティ・モジュールのインストールをテストして、正常に動作することを確認します。詳細は、使用するデバイスのドキュメントを参照してください。
-
秘密キーをトークンに格納する場合は、Oracle Wallet Managerを使用して
PKCS11
タイプのウォレットを作成し、PKCS #11ライブラリへの絶対パス(ライブラリ名を含む)を指定します。OraclePKCS11
ウォレットには、秘密キーにアクセスするためのトークンを指す情報が格納されます。
PKCS #11情報が格納されたウォレットは、任意のOracleウォレットを使用する場合と同様に使用できます。ただし、秘密キーをハードウェア・デバイスに格納し、暗号操作もそのデバイスで実行する場合を除きます。
関連項目:
ハードウェア・セキュリティ・モジュールの証明書を格納するためにOracleウォレットを作成する方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
暗号化処理でnCipherハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。
- nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について
nCipher社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。 - nCipherハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント
nCipherハードウェア・セキュリティ・モジュールを使用するには、特別なコンポーネントのセットが必要です。 - nCipherハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件
nCipherハードウェア・セキュリティ・モジュールはnCipher PKCS #11ライブラリを使用します。
nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について
nCipher社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。
これらのモジュールでは、キーを安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。
-
暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。
-
デバイス上の秘密キーの記憶領域が保護されます。
-
スマートカードを使用してキーを管理できます。
ノート:
Oracle Databaseで使用する認定済のハードウェアおよびソフトウェアを入手するには、nCipherの代理店にお問い合せください。
nCipherハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント
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ハードウェア・セキュリティ・モジュールは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ハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。
- SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について
SafeNET社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。 - SafeNET Luna SAハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント
SafeNET Luna SAハードウェア・セキュリティ・モジュールを使用するには、特別なコンポーネントのセットが必要です。 - SafeNETハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件
SafeNETハードウェア・セキュリティ・モジュールはSafeNET PKCS #11ライブラリを使用します。
SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について
SafeNET社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。
これらのモジュールでは、キーを安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。
-
暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。
-
デバイス上の秘密キーの記憶領域が保護されます。
ノート:
Oracle Databaseで使用する認定済のハードウェアおよびソフトウェアを入手するには、SafeNETの代理店にお問い合せください。
SafeNET Luna SAハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント
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ハードウェア・セキュリティ・モジュールは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トレース・ファイルのエラー
使用されているモジュールを検出するには、Oracle Netトレースをオンにします。 - ハードウェア・セキュリティ・モジュールの使用に関連するエラー・メッセージ
PKCS #11ハードウェア・セキュリティ・モジュールの使用に関連するエラーが表示される場合があります。
Oracle Netトレース・ファイルのエラー
使用されているモジュールを検出するには、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ハードウェア・セキュリティ・モジュールの使用に関連するエラーが表示される場合があります。
- ORA-43000: PKCS11ライブラリが見つかりません
-
原因: ウォレットの作成時に指定された場所にPKCS #11ライブラリが見つかりません。これは、ウォレットの作成後にライブラリが移動された場合にのみ発生します。
- ORA-43001: PKCS11トークンが見つかりません
-
原因: ウォレットの作成に使用されたスマートカードがハードウェア・セキュリティ・モジュールのスロットにありません。
- ORA-43002: PKCS11パスワードが無効です
-
原因: これは、ウォレットの作成時に指定されたパスワードが正しくない場合、またはウォレットの作成後にPKCS #11デバイス・パスワードを変更し、Oracle Wallet Managerを使用してウォレットで更新しなかった場合に発生する可能性があります。
関連項目:
ハードウェア・セキュリティ証明書を格納するためにOracleウォレットを作成する方法の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
ノート:
nCipherログ・ファイルは、モジュールがインストールされているディレクトリの次の場所にあります。
/log/logfile
関連項目:
nCipherデバイスとSafeNETデバイスのトラブルシューティングの詳細は、nCipherとSafeNETのドキュメントを参照してください。