23 Transport Layer Security認証の構成
Transport Layer Security認証を使用するようにOracle Databaseを構成できます。
- Transport Layer SecurityおよびSecure Sockets Layer
以前はSecure Sockets Layer (SSL)と呼ばれていたTransport Layer Security (TLS)は、安全なネットワーク接続を目的に、Netscape社によって設計されました。 - Oracle DatabaseでのTransport Layer Securityを使用した認証
Transport Layer Securityは、暗号化およびデータ・アクセス・コントロールなど、Oracle Databaseの中核機能と連携します。 - Oracle環境におけるTransport Layer Securityの機能: TLSハンドシェイク
Transport Layer Securityによるネットワーク接続を開始する場合、クライアントとサーバーは、認証を行う前にTLSハンドシェイクを実行します。 - Oracle環境における公開キー・インフラストラクチャ
公開キー・インフラストラクチャ(PKI)は、組織全体のセキュリティ基盤を提供するネットワーク・コンポーネントの基質であり、信頼アサーションに基づいています。 - Transport Layer Securityと他の認証方式の併用
TLSをデータベースのユーザー名とパスワード、RADIUSおよびKerberosと同時に使用するようにOracle Databaseを構成できます。 - Transport Layer Securityとファイアウォール
Oracle Databaseは、アプリケーション・プロキシベースのファイアウォールとステートフル・パケット・インスペクション・ファイアウォールの2つをサポートしています。 - Transport Layer Security使用時の問題
他のOracle製品との通信や、サポート対象の認証方式および暗号化方式のタイプといった、TLSの使用に関する問題に注意する必要があります。 - クライアント・ウォレットを使用しないTransport Layer Security接続
データベース・サーバーに対して共通のルート証明書を使用するTransport Layer Security (TLS)接続には、クライアント・ウォレットは必要ありません。 - クライアント・ウォレットを使用するTransport Layer Security接続
Transport Layer Securityは、サーバーで構成してから、クライアントで構成する必要があります。 - Transport Layer SecurityのOracleウォレット検索順序
Oracle Databaseは、Transport Layer Security (TLS)環境でサーバーのウォレットを検索するための複数のルートを用意しています。 - Oracle Real Application Clusters環境でのTransport Layer Security接続
Oracle RACツールを使用してOracle Real Application Clusters (Oracle RAC)環境でTransport Layer Security (TLS)接続を構成し、Oracle Database構成ファイルを変更できます。 - Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成
Microsoft証明書ストア(MCS)でこの構成を実行するには、orapki
コマンドライン・ツールを使用して証明書を生成し、Oracleウォレットを操作します。 - Transport Layer Security構成のトラブルシューティング
Oracle Database SSLアダプタの使用中に一般的なエラーが発生する場合があります。 - 証明書失効リストによる証明書の検証
オラクル社では、証明書失効リストを使用して証明書を検証できるツールを提供しています。 - ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
Oracle Databaseでは、RSA Security社のPKCS #11仕様に準拠したAPIを使用するハードウェア・セキュリティ・モジュールがサポートされています。
親トピック: 厳密認証の管理
23.1 Transport Layer SecurityおよびSecure Sockets Layer
以前はSecure Sockets Layer (SSL)と呼ばれていたTransport Layer Security (TLS)は、安全なネットワーク接続を目的に、Netscape社によって設計されました。
- Transport Layer SecurityとSecure Sockets Layerの違い
Transport Layer Security (TLS)は、Secure Sockets Layer (SSL)バージョン3.0の増分バージョンです。 - マルチテナント環境でのTransport Layer Securityの使用
Transport Layer Security (TLS)はアプリケーション・コンテナのマルチテナント環境で使用できます。
23.1.1 Transport Layer SecurityとSecure Sockets Layerの違い
Transport Layer Security (TLS)は、Secure Sockets Layer (SSL)バージョン3.0の増分バージョンです。
SSLは最初にNetscape社によって開発されましたが、Internet Engineering Task Force (IETF)がその開発を引き継ぎ、名前をTransport Layer Security (TLS)に変更しました。TLSはIETF標準です。
Oracle DatabaseではTLSが実装されているため、Oracle Databaseセキュリティ・ガイドでは、Secure Sockets LayerおよびSSLのかわりに、Transport Layer SecurityおよびTLSという用語が使用されています。ただし、Oracle Databaseライブラリ内の他のドキュメントでは、以前のSecure Socket LayerおよびSSLという用語が引き続き使用されている場合があります。これらのプロトコルの使用方法または構成方法に違いがある場合、Oracle Databaseセキュリティ・ガイドでは、記述内容がSSLに該当するか、TLSに該当するかを明記します。
Oracle Databaseソフトウェアでは、古い用語の一部が引き続き使用されています。たとえば、netmgr
ツールでは、引き続きSecure Socket LayerおよびSSLの用語が使用されています。SSL_SERVER_CERT_DN
などの多くのSSLパラメータでは、古い用語が使用されています。暗号スイートの名前とエラー・メッセージ内の言い回しにも、SSL用語が使用されています。ただし、これらのすべての機能は、Transport Layer Securityと連携して、適用されます。
23.2 Oracle DatabaseでのTransport Layer Securityを使用した認証
Transport Layer Securityは、暗号化およびデータ・アクセス・コントロールなど、Oracle Databaseの中核機能と連携します。
Oracle DatabaseのTLS機能を使用してクライアントとサーバー間の通信を保護すると、次の操作を実行できます
-
TLSを使用したクライアントとサーバー間の接続の暗号化
-
TLS通信用に構成されたOracleデータベース・サーバーに対するクライアントまたはサーバー(Oracle Application Server 10gなど)の認証
TLS機能は、単独で使用するか、Oracle Databaseでサポートされている他の認証方式と組み合せて使用できます。たとえば、TLSから提供されている暗号化をKerberosから提供されている認証と組み合せて使用できます。TLSでは、次の認証モードがサポートされます。
-
サーバーのみ、クライアントに対して自己認証を行います。
-
クライアントとサーバーは、互いに自己認証を行います。
-
クライアントもサーバーも、互いに自己認証を行わず、TLS暗号化機能を単独で使用します
関連項目:
TLSの詳細は、Internet Engineering Task Forceが公開しているTLSプロトコルのバージョン3.0を参照してください
23.3 Oracle環境におけるTransport Layer Securityの機能: TLSハンドシェイク
Transport Layer Securityによるネットワーク接続を開始する場合、クライアントとサーバーは、認証を行う前にTLSハンドシェイクを実行します。
ハンドシェイク・プロセスは次のようになります。
-
クライアントとサーバーは、どの暗号スイートを使用するかを設定します。これには、データ転送に使用する暗号化アルゴリズムも含まれます。
-
サーバーは証明書をクライアントに送信し、クライアントは、サーバーの証明書が信頼できるCAによって署名されていることを検証します。このステップにより、サーバーの身元が検証されます。
-
同様に、クライアント認証が必要な場合は、クライアントが自分自身の証明書をサーバーに送信し、サーバーは、クライアントの証明書が信頼できるCAによって署名されているかどうかを検証します。
-
クライアントとサーバーが、公開キー暗号化を使用してキー情報を交換します。この情報に基づき、双方でセッション・キーが生成されます。キーは少なくとも二者(通常はクライアントとサーバー)によって共有され、単一の通信セッション中のデータ暗号化に使用されます。セッション・キーは通常、ネットワーク・トラフィックを暗号化するために使用されます。クライアントとサーバーはセッションの開始時にセッション・キーをネゴシエーションすることができ、そのキーはそのセッションの関係者間のすべてのネットワーク・トラフィックを暗号化するために使用されます。クライアントとサーバーが新しいセッションで再び通信する場合は、新しいセッション・キーをネゴシエーションします。クライアントとサーバーとの間の以降の通信はすべて、このセッション・キーと、ネゴシエーションにより決定した暗号スイートを使用して、暗号化または復号化されます。
認証プロセスは次のとおりです。
-
クライアントで、ユーザーがTLSを使用してサーバーへのOracle Net接続を開始します。
-
TLSは、クライアントとサーバー間のハンドシェイクを実行します。
-
ハンドシェイクが成功すると、サーバーは、そのデータベースにアクセスするために必要な認可をユーザーが所有していることを検証します。
23.4 Oracle環境における公開キー・インフラストラクチャ
公開キー・インフラストラクチャ(PKI)は、組織全体のセキュリティ基盤を提供するネットワーク・コンポーネントの基質であり、信頼アサーションに基づいています。
- 公開キーの暗号化について
従来の秘密キーまたは対称キーの暗号化では、安全な通信を確立する目的で2者以上が共有する1つの秘密キーが必要です。 - Oracle環境における公開キー・インフラストラクチャ・コンポーネント
Oracle環境の公開キー・インフラストラクチャ(PKI)のコンポーネントには、認証局、証明書、証明書失効リストおよびウォレットなどがあります。
23.4.1 公開キーの暗号化について
従来の秘密キーまたは対称キーの暗号化では、安全な通信を確立する目的で2者以上が共有する1つの秘密キーが必要です。
このキーは、ユーザー間で送信される保護メッセージの暗号化および復号化に使用されるため、各ユーザーへは事前に安全な方法でキーを配布する必要があります。この方法における問題点は、キーを安全に転送し、格納することが困難なことです。
公開キーの暗号化による公開キー/秘密キーのペアおよびキー配布のための安全な方法を採用することで、この問題は解決します。対応する秘密キーの所有者のみが復号化できるメッセージは、自由に使用できる公開キーによって暗号化できます。秘密キーは、その他のセキュリティ資格証明とともに、ウォレットと呼ばれる暗号化されたコンテナに、安全に格納されます。
公開キーのアルゴリズムでは、メッセージの秘密は保証されますが、安全な通信は必ずしも保証されません。その理由は、通信者間の識別が検証されないためです。安全な通信を確立するには、メッセージの暗号化に使用される公開キーが相手の受信者に実際に属していることを確認することが重要です。そうしないと、第三者が通信を傍受し、公開キーのリクエストに割り込み、正当なキーを独自の公開キーに置き換えることが可能になります(第三者攻撃)。
この攻撃を回避するには、公開キーの所有者の確認(認証と呼ばれるプロセス)が必要です。認証は、通信する双方の委託するサード・パーティの認証局(CA)によって行われます。
CAは、エンティティの名前、公開キーおよび他のセキュリティ資格証明を含む公開キー証明書を発行します。通常、このような資格証明には、CA名、CAの署名および証明書の有効日(開始日、終了日)が含まれています。
CAでは独自の秘密キーを使用してメッセージを暗号化します。一方、そのメッセージの復号化には公開キーが使用されるため、メッセージがCAによって暗号化されたものであるかどうかが確認されます。CA公開キーは広く一般に知られているため、アクセスするたびに認証する必要はありません。このようなCA公開キーはウォレットに格納されます。
親トピック: Oracle環境における公開キー・インフラストラクチャ
23.4.2 Oracle環境における公開キー・インフラストラクチャ・コンポーネント
Oracle環境の公開キー・インフラストラクチャ(PKI)のコンポーネントには、認証局、証明書、証明書失効リストおよびウォレットなどがあります。
- 認証局
認証局(CA)は、ユーザー、データベース、管理者、クライアント、サーバーなどのエンティティの識別情報を証明する、信頼できるサード・パーティです。 - 証明書
証明書は、エンティティの公開キーが、信頼できる認証局(CA)によって署名されたときに作成されます。 - 証明書失効リスト
公開キー・ペアをユーザーIDにバインドする証明書にCAが署名すると、証明書は指定された期間有効になります。 - ウォレット
ウォレットは、認証および署名資格証明(TLSで必要な秘密キー、証明書、信頼できる証明書など)の格納に使用されるコンテナです。 - ハードウェア・セキュリティ・モジュール
SSLのハードウェア・セキュリティ・モジュールには、様々な機能を処理するデバイスや、暗号情報を格納するハードウェア・デバイスなどがあります。
親トピック: Oracle環境における公開キー・インフラストラクチャ
23.4.2.1 認証局
認証局(CA)は、ユーザー、データベース、管理者、クライアント、サーバーなどのエンティティの識別情報を証明する、信頼できるサード・パーティです。
エンティティが証明書を要求すると、CAはその識別情報を検証し、CAの秘密キーを使用して署名した証明書を発行します。
CAごとに、証明書の発行時の識別情報要件が異なる可能性があります。CAの中には、要求者の識別情報をドライバのライセンスを使用して確認したり、要求者の指紋で識別情報を確認したり、証明書リクエスト・フォームが認証されていることを必要とするものがあります。
CAは、公開キーが含まれている独自の証明書を発行します。各ネットワーク・エンティティには、信頼できるCA証明書のリストがあります。通信する前に、ネットワーク・エンティティは証明書を交換し、相互の証明書がそれぞれの信頼できるCA証明書リストのいずれかのCAによって署名されていることを確認します。
ネットワーク・エンティティは、同じCAから、または異なるCAから証明書を取得できます。
関連トピック
23.4.2.2 証明書
証明書は、エンティティの公開キーが、信頼できる認証局(CA)によって署名されたときに作成されます。
この証明書は、そのエンティティの識別情報が正しいこと、および公開キーがそのエンティティに実際に属していることを保証します。
証明書には、エンティティの名前、公開キー、有効期限、さらにシリアル番号および証明連鎖情報が含まれています。(証明書チェーンは、エンド・ユーザーまたはサブスクライバの証明書とその認証局の証明書を含む、順序付けられた証明書のリストです。)また、証明書に関連付けられた権限に関する情報が含まれている場合もあります。
ネットワーク・エンティティが証明書を受信すると、それが信頼できる証明書、つまり信頼できる認証局によって発行および署名された証明書であるか検証します。証明書は、期限切れになるか失効するまで有効です。
23.4.2.3 証明書失効リスト
公開キー・ペアをユーザーIDにバインドする証明書にCAが署名すると、証明書は指定された期間有効になります。
ただし、ユーザー名の変更や秘密キーの漏えいなどの特定のイベントが発生した場合は、有効期間が終了する前に証明書が無効になることがあります。この場合は、CAによって証明書が失効され、そのシリアル番号が証明書失効リスト(CRL)に追加されます。CAは、特定の公開キーが、関連付けられているユーザーIDの確認に使用できなくなると、定期的にCRLを発行してユーザーに警告します。
サーバーまたはクライアントはOracle環境でユーザー証明書を受信すると、その有効期限、署名および失効ステータスをチェックして証明書を検証できます。証明書失効ステータスは、発行されたCRLに照らして検証することでチェックされます。証明書失効ステータス・チェックが有効になっている場合、サーバーはこの機能の構成方法に応じて適切なCRLを検索します。サーバーは、次の場所で(この順番で) CRLを検索します。
-
ローカル・ファイル・システム
-
Oracle Internet Directory
-
CRL配布ポイント(CRL DP)。証明書が発行されたときの、CRL Distribution Point (CRL DP) X.509バージョン3の証明書拡張で指定されている場所。CRL DPは、X.509バージョン3証明書標準で指定されるオプションの拡張子であり、証明書の失効情報が格納される区分CRLの位置を示します。通常、この拡張子の値はURLの形式です。CRL DPによって、1つの認証局ドメイン内の失効情報を複数のCRLにポストできます。CRL DPによって、失効情報はより管理しやすい部分に細分化され、CRLが膨大に増加するのが回避されるため、パフォーマンスが向上します。たとえば、CRL DPを証明書に指定し、その証明書の失効情報をダウンロードできる、Webサーバー上のファイルを指すようにできます。
ノート:
他のOracle製品でCRLを使用するには、その製品のドキュメントを参照してください。CRLによる証明書の検証の実装は、Oracle Database 12cリリース1 (12.1)以降のSSLアダプタでのみ使用できます。
関連トピック
23.4.2.4 ウォレット
ウォレットは、認証および署名資格証明(TLSで必要な秘密キー、証明書、信頼できる証明書など)の格納に使用されるコンテナです。
Oracle環境では、TLS通信を行うどのエンティティにも、X.509バージョン3の証明書、秘密キーおよび信頼できる証明書のリストが必要です。ただし、Diffie-Hellmanは例外です。
セキュリティ管理者は、サーバーのセキュリティ資格証明の管理にOracle Wallet Managerを使用します。ウォレットの所有者は、クライアントのセキュリティ資格証明の管理に使用します。具体的には、Oracle Wallet Managerは次のことを行うために使用します。
-
公開キーと秘密キーのペアの生成および証明書リクエストの作成
-
秘密キーと一致するユーザー証明書の格納
-
信頼できる証明書の構成
関連項目:
-
Oracle Wallet Managerの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
-
Oracleウォレットの新規作成の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
-
Oracleウォレットでの信頼できる証明書の管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
-
23.4.2.5 ハードウェア・セキュリティ・モジュール
SSLのハードウェア・セキュリティ・モジュールには、様々な機能を処理するデバイスや、暗号情報を格納するハードウェア・デバイスなどがあります。
Oracle Databaseでは、これらのデバイスを次の機能に使用します。
-
秘密キーなどの暗号情報の格納
-
他のトランザクションに応答できるようにCPUを解放して、サーバーにおけるRSA操作の負荷を軽減する暗号操作の実行
暗号情報は、次の2つのタイプのハードウェア・デバイスに格納できます。
-
(サーバー側)キーがボックスに格納され、トークンを使用して管理されるハードウェア・ボックス。
-
(クライアント側)トークンへの秘密キーの格納をサポートするスマートカード・リーダー
Oracle環境では、RSA Security社の公開キー暗号規格(PKCS)#11仕様に準拠しているAPIを使用したハードウェア・デバイスがサポートされています。
ノート:
現在、SafeNET、nCipherおよびUtimacoデバイスはOracle Databaseで認定されています。
23.5 Transport Layer Securityと他の認証方式の併用
TLSをデータベースのユーザー名とパスワード、RADIUSおよびKerberosと同時に使用するようにOracle Databaseを構成できます。
- アーキテクチャ: Oracle DatabaseとTransport Layer Security
Oracle DatabaseとTLSとの連携のアーキテクチャを理解することが重要です。 - Transport Layer Securityと他の認証方式の併用
Transport Layer Securityは、Oracle Databaseでサポートされているその他の認証方式との併用が可能です。
23.5.1 アーキテクチャ: Oracle DatabaseとTransport Layer Security
Oracle DatabaseとTLSとの連携のアーキテクチャを理解することが重要です。
Transport Layer SecurityアーキテクチャのOracle Databaseの実装を示す図20-4では、Oracle DatabaseがTLSの上位のセッション・レイヤーで動作し、トランスポート・レイヤーでTCP/IPを使用していることを示しています。セッション・レイヤーは、プレゼンテーション・レイヤー・エンティティが必要とするサービスを提供するネットワーク・レイヤーであり、プレゼンテーション・レイヤー・エンティティがダイアログの編成と同期およびデータ交換の管理を行えるようにします。このレイヤーは、クライアントとサーバー間でネットワーク・セッションを確立、管理および終了する。トランスポート・レイヤーは、データ・フロー制御とエラー・リカバリ方式を通じてエンドツーエンドの信頼性を維持するネットワーキング・レイヤーです。Oracle Net Servicesは、トランスポート・レイヤーにOracleプロトコル・サポートを使用します。
このように機能が分離されているため、TLSを他のサポートされているプロトコルと同時に利用できます。
23.5.2 Transport Layer Securityと他の認証方式の併用
Transport Layer Securityは、Oracle Databaseでサポートされているその他の認証方式との併用が可能です。
図23-1に、Transport Layer Securityが別の認証方式と併用されている構成を示します。
この例では、最初のハンドシェイク(サーバー認証)を確立するためにTransport Layer Securityが使用され、クライアントの認証に別の認証方式が使用されています。このプロセスは、次のとおりです。
-
クライアントがOracleデータベース・サーバーに接続しようとします。
-
Transport Layer Securityによってハンドシェイクが実行され、その間にサーバーがクライアントに対して自己認証を行い、クライアントとサーバーの両方が使用する暗号スイートを設定します。
-
Transport Layer Securityハンドシェイクが正常に完了すると、ユーザーはデータベースにアクセスしようとします。
-
Oracleデータベース・サーバーは、KerberosやRADIUSなどの非TLS認証方式を使用して、認証サーバーでユーザーを認証します。
-
認証サーバーによる検証が完了すると、Oracleデータベース・サーバーによってアクセス権と認可がユーザーに付与され、ユーザーはTLSを使用してデータベースに安全にアクセスできるようになります。
23.6 Transport Layer Securityとファイアウォール
Oracle Databaseは、アプリケーション・プロキシベースのファイアウォールとステートフル・パケット・インスペクション・ファイアウォールの2つをサポートしています。
ファイアウォールは次のとおりです。
-
アプリケーション・プロキシベースのファイアウォール: Network Associates GauntletやAxent Raptorなど。
-
ステートフル・パケット・インスペクション・ファイアウォール: Check Point Firewall-1やCisco PIX Firewallなど。
TLSを有効にした場合、ステートフル・インスペクション・ファイアウォールは暗号化されたパケットを復号化しないため、アプリケーション・プロキシ・ファイアウォールと同じように動作します。
ファイアウォールは暗号化されたトラフィックを検査しません。ファイアウォールは、イントラネット・サーバーのTLSポート宛てのデータを検出すると、アクセス・ルールに基づいてターゲットIPアドレスを確認し、許可されたTLSポートに対してはTLSパケットを通過させ、他のすべてのパケットは拒否します。
23.7 Transport Layer Security使用時の問題
他のOracle製品との通信や、サポート対象の認証方式および暗号化方式のタイプといった、TLSの使用に関する問題に注意する必要があります。
TLSを使用する場合は、次のことを考慮してください。
-
TLSを使用すると、Oracle Internet Directoryなどの他のOracle製品との安全な通信が可能になります。
-
TLSでは認証と暗号化の両方がサポートされているため、クライアント/サーバー接続が標準のOracle Net TCP/IPトランスポート(ネイティブ暗号化を使用)より多少遅くなります。
-
各TLS認証モードには、構成設定が必要となります。
ノート:
TLS暗号化を構成する場合は、非TLS暗号化を無効にする必要があります。
23.8 クライアント・ウォレットを使用しないTransport Layer Security接続
データベース・サーバーに対して共通のルート証明書を使用するTransport Layer Security (TLS)接続には、クライアント・ウォレットは必要ありません。
- クライアント・ウォレットを使用しないTransport Layer Security接続について
環境が特定の要件を満たしている場合、クライアント・ウォレットを使用しないTransport Layer Security (TLS)接続を構成できます。 - クライアント・ウォレットを使用しないTransport Layer Security接続の構成
クライアント・ウォレットを使用しないTransport Layer Security (TLS)を構成する前に、データベースでクライアント認証が必要ないことを確認する必要があります。
23.8.1 クライアント・ウォレットを使用しないTransport Layer Security接続について
環境が特定の要件を満たしている場合、クライアント・ウォレットを使用しないTransport Layer Security (TLS)接続を構成できます。
環境が次の要件を満たしている場合は、クライアント・ウォレットを使用しないTLS接続を使用することを検討してください。
- クライアント証明書は、データベースへのユーザー認証の手段として使用されません。TLS接続を確立するために必要なのはサーバー証明書のみです。
- サーバー証明書は、システムのデフォルトの証明書ストアに使用可能な証明書(共通のルート証明書)を持つ認証局(CA)によって発行されました。
- Oracleデータベース・サーバーは、TLS接続を許可するように構成されています。(
SSL_CLIENT_AUTHENTICATION=FALSE
を設定)。
データベース・サーバーに対するルート証明書がローカルのシステム証明書ストア内にすでに存在していれば、これが最も一般的なタイプの構成になります。この構成は、クラウド・データベースとオンプレミス・データベースの両方に使用できます。この構成により、クライアントで独自のウォレットを構成することなく、サーバー証明書を検証できます。
次のことに注意してください。
- CおよびInstant Clientのデータベース・ドライバ(およびSQL*Plus)の場合、ウォレットレス機能はMicrosoft WindowsおよびLinuxのx64でのみ使用できます。
- JDBCシン・ドライバの場合、ウォレットレス機能はすべてのプラットフォームで使用できます。
23.9 クライアント・ウォレットを使用するTransport Layer Security接続
Transport Layer Securityは、サーバーで構成してから、クライアントで構成する必要があります。
- ステップ1: サーバーでのTransport Layer Securityの構成
インストール中、Oracleデータベース・サーバーとOracleクライアントに、Oracleウォレットの場所を除くTLSパラメータのデフォルトが設定されます。 - ステップ2: クライアントでのTransport Layer Securityの構成
SSLをクライアントで構成する場合、サーバーDNを構成して、TLS付きTCP/IPをクライアントで使用します。 - ステップ3: データベース・インスタンスへのログイン
構成の完了後、データベースにログインします。
23.9.1 ステップ1: サーバーでのTransport Layer Securityの構成
インストール中、Oracleデータベース・サーバーとOracleクライアントに、Oracleウォレットの場所を除くTLSパラメータのデフォルトが設定されます。
- ステップ1A: サーバーでのウォレット作成の確認
次のステップに進む前に、ウォレットが作成されていることと、ウォレットに証明書があることを確認する必要があります。 - ステップ1B: サーバーでのデータベース・ウォレット・ロケーションの指定
次に、ウォレットのサーバー上の場所を指定します。 - ステップ1C: サーバーでのTransport Layer Security暗号スイートの設定(オプション)
オプションで、Transport Layer Security暗号スイートを設定できます。 - ステップ1D: サーバーでの必要なTransport Layer Securityバージョンの設定(オプション)
SSL_VERSION
パラメータでは、サーバーが通信するシステムで実行する必要があるTLSのバージョンを定義します。 - ステップ1E: サーバーでのTransport Layer Securityクライアント認証の設定(オプション)
SSL_CLIENT_AUTHENTICATION
パラメータは、クライアントがTLSを使用して認証されるかどうかを制御します。 - ステップ1F: サーバーでの認証サービスとしてのTransport Layer Securityの設定(オプション)
sqlnet.ora
ファイルのSQLNET.AUTHENTICATION_SERVICES
パラメータでは、TLS認証サービスを設定します。 - ステップ1G: サーバーおよびクライアントでのSSLv3の無効化(オプション)
SSLv3はSecure Sockets Layerバージョン3のことです。 - ステップ1H: Transport Layer Security付きTCP/IPを使用するリスニング・エンドポイントのサーバーでの作成
TLS付きTCP/IPを使用するリスニング・エンドポイントをサーバーで構成できます。 - ステップ1H: データベースの再起動
サーバーでのTransport Layer Securityの構成を完了するには、データベースを再起動する必要があります。
23.9.1.2 ステップ1B: サーバーでのデータベース・ウォレット・ロケーションの指定
次に、ウォレットのサーバー上の場所を指定します。
ノート:
リスナーでは、listener.ora
ファイルに定義されているウォレットを使用します。任意のデータベース・ウォレットを使用できます。Net Managerを使用してサーバーのSSLが構成されている場合、ウォレット・ロケーションはlistener.ora
ファイルとsqlnet.ora
ファイルに入力されています。listener.ora
ファイルは、Oracleクライアントには関係ありません。
リスナーが独自のウォレットを所有するようにリスナーのウォレット・ロケーションを変更するには、listener.ora
を編集して新しい場所を入力します。
23.9.1.3 ステップ1C: サーバーでのTransport Layer Security暗号スイートの設定(オプション)
オプションで、Transport Layer Security暗号スイートを設定できます。
- Transport Layer Security暗号スイートについて
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。 - TLS暗号スイートの認証、暗号化、整合性およびTLSバージョン
Oracle Databaseでは、Oracle Databaseをインストールするとデフォルトで設定される一連の暗号スイートがサポートされています。 - データベース・サーバーのTransport Layer Security暗号スイートの指定
最初に、データベース・サーバーのTransport Layer Security暗号スイートを指定する必要があります。
23.9.1.3.1 Transport Layer Security暗号スイートについて
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。
Transport Layer Securityハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Databaseをインストールすると、Transport Layer Security暗号スイートがデフォルトで設定され、リスト順にネゴシエートされます。デフォルトの順序は、SSL_CIPHER_SUITES
パラメータを設定して上書きできます。SSL_CIPHER_SUITES
パラメータの設定は必ずカッコで囲んでください(例: SSL_CIPHER_SUITES=(tls_rsa_with_aes_128_cbc_sha256)
)。そうしないと、暗号スイート設定が正しく解析されません。
暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。
-
互換性。正常に接続するには、互換性のある暗号スイートを使用するようにサーバーとクライアントを構成する必要があります。
-
暗号の優先順位と強度。最高レベルのセキュリティを確保するために、最も強力なものから最も弱いものの順に暗号スイートの優先順位を設定します。
-
使用するセキュリティ・レベル。
-
パフォーマンスへの影響。
ノート:
Diffie-Hellman 匿名認証について:
-
この暗号スイートを使用するようにサーバーを設定する場合は、同じ暗号スイートをクライアントにも設定する必要があります。設定しない場合、接続に失敗します。
-
Diffie-Hellman匿名を使用する暗号スイートを使用する場合、
SSL_CLIENT_AUTHENTICATION
パラメータをFALSE
に設定して、サーバーでTLSクライアント認証を構成する必要があります。 -
既知の不具合があり、クライアントを認証しないDH_ANONを含む暗号スイートを使用する場合でも、OCIクライアントでウォレットが必要です。
-
23.9.1.3.2 TLS暗号スイートの認証、暗号化、整合性およびTLSバージョン
Oracle Databaseでは、Oracle Databaseをインストールするとデフォルトで設定される一連の暗号スイートがサポートされています。
表23-1に、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプを示します。
表23-1 Transport Layer Security暗号スイート
暗号スイート | 認証 | 暗号化 | データ整合性 | 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のみ |
表23-2に、使用可能な暗号スイートを示しますが、これらは通信者の認証を提供しないため、第三者攻撃に対して無防備になる可能性があることに注意してください。機密データを保護する場合は、これらの暗号スイートを使用しないことをお薦めします。ただし、これらは、通信者が匿名を維持する場合や、相互認証によって発生するオーバーヘッドを望まない場合に有効です。
表23-2 SSL_DH Transport Layer Security暗号スイート
暗号スイート | 認証 | 暗号化 | データ整合性 | TLSの互換性 |
---|---|---|---|---|
|
DH anon |
3DES EDE CBC |
SHA-1 |
TLS 3.0以降 |
23.9.1.4 ステップ1D: サーバーでの必要なTransport Layer Securityバージョンの設定(オプション)
SSL_VERSION
パラメータでは、サーバーが通信するシステムで実行する必要があるTLSのバージョンを定義します。
オプションで、sqlnet.ora
ファイルまたはlistener.ora
ファイルでSSL_VERSION
パラメータを設定できます。
これらのシステムで有効なバージョンを使用するように設定できます。sqlnet.ora
におけるこのパラメータのデフォルト設定はundetermined
で、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。
ノート:
SSL 2.0はサーバー側でサポートされていません。
23.9.1.5 ステップ1E: サーバーでのTransport Layer Securityクライアント認証の設定(オプション)
SSL_CLIENT_AUTHENTICATION
パラメータは、クライアントがTLSを使用して認証されるかどうかを制御します。
このパラメータはサーバーの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
に設定するには:
23.9.1.6 ステップ1F: サーバーでの認証サービスとしてのTransport Layer Securityの設定(オプション)
sqlnet.ora
ファイルのSQLNET.AUTHENTICATION_SERVICES
パラメータでは、TLS認証サービスを設定します。
このパラメータは、TLS認証とOracle Databaseでサポートされている別の認証方式を組み合せて使用する場合に設定します。たとえば、サーバーがTLSを使用してクライアントに対して自己認証を行い、クライアントがKerberosを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。
-
サーバーに
SQLNET.AUTHENTICATION_SERVICES
パラメータを設定するには、テキスト・エディタを使用してsqlnet.ora
ファイルでこのパラメータにTLS付きTCP/IP(TCPS)を追加します。たとえば、SSL認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)
TLS認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。
23.9.1.7 ステップ1G: サーバーおよびクライアントでのSSLv3の無効化(オプション)
SSLv3はSecure Sockets Layerバージョン3のことです。
ADD_SSLV3_TO_DEFAULT
sqlnet.ora
パラメータをFALSE
に設定する必要があります。ADD_SSLV3_TO_DEFAULT
は、SSL_VERSION
パラメータが設定されていない場合にのみ適用されます。(SSLバージョンのデフォルト・リストが使用されることを意味します)。
23.9.1.8 ステップ1H: Transport Layer Security付きTCP/IPを使用するリスニング・エンドポイントのサーバーでの作成
TLS付きTCP/IPを使用するリスニング・エンドポイントをサーバーで構成できます。
listener.ora
ファイルでリスナーを構成します。一般的なOracle Netクライアントには、ポート番号2484を使用することをお薦めします- データベースを再起動します。
23.9.2 ステップ2: クライアントでのTransport Layer Securityの構成
SSLをクライアントで構成する場合、サーバーDNを構成して、TLS付きTCP/IPをクライアントで使用します。
- ステップ2A: クライアント・ウォレット作成の確認
クライアントでウォレットが作成されていることと、クライアントに有効な証明書があることを確認する必要があります。 - ステップ2B: サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用
次に、サーバーDN一致を構成し、クライアントでTransport Layer Security (TLS)付きのTCP/IPを使用します。 - ステップ2C: 必要なクライアントTLS構成の指定(ウォレット・ロケーション)
Oracle Net Managerを使用して、必要なクライアントTLS構成を指定できます。 - ステップ2D: クライアントのTransport Layer Security暗号スイートの設定(オプション)
オプションで、Transport Layer Security暗号スイートを設定できます。Oracle Databaseにはデフォルトの暗号スイート設定が用意されています。 - ステップ2E: 必要なTLSバージョンのクライアントでの設定(オプション)
SSL_VERSION
パラメータでは、クライアントが通信するシステムで実行する必要があるTLSのバージョンを定義します。 - ステップ2F: クライアントにおける認証サービスとしてのTLSの設定(オプション)
sqlnet.ora
ファイルのSQLNET.AUTHENTICATION_SERVICES
パラメータでは、TLS認証サービスを設定します。 - ステップ2G: クライアントでの認証に使用する証明書の指定(オプション)
証明書が複数ある場合は、sqlnet.ora
ファイルのSQLNET.SSL_EXTENDED_KEY_USAGE
パラメータで正しい証明書を指定できます。 - ステップ2H: 接続でTransport Layer Securityが使用されていることの確認
動的ビューV$SESSION
とV$SESSION_CONNECT_INFO
を問い合せると、クライアント接続でTransport Layer Security (TLS)が使用されていることを確認できます。 - ステップ2I: データベースの再起動
クライアントでのTransport Layer Securityの構成を完了するには、データベースを再起動する必要があります。
23.9.2.2 ステップ2B: サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用
次に、サーバーDN一致を構成し、クライアントでTransport Layer Security (TLS)付きのTCP/IPを使用します。
- サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用について
サーバー証明書の証明書チェーンの検証に加えて、サーバーDN一致を使用して追加のチェックを実行できます。 - サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用
サーバーDN一致を構成し、クライアントでTLS付きのTCP/IPを使用するようにtnsnames.ora
ファイルとlistener.ora
ファイルを編集する必要があります。 - SSL_ALLOW_WEAK_DN_MATCHパラメータを使用したSSL_SERVER_DN_MATCHの制御
SSL_ALLOW_WEAK_DN_MATCH
パラメータは、SSL_SERVER_DN_MATCH
パラメータで部分識別名一致にサービス名を使用できるかと、データベース・サーバーの証明書をチェックするかを制御します。
23.9.2.2.1 サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用について
サーバー証明書の証明書チェーンの検証に加えて、サーバーDN一致を使用して追加のチェックを実行できます。
サーバーDN一致を含み、クライアントでTLS付きのTCP/IPを使用するようにOracle Net Service名を構成できます。これを実行するには、クライアント・ネットワーク構成ファイルで、サーバーDNマッチングおよびTCP/IPをTLS接続できるように、プロトコルとしてサーバーの識別名(DN)とTCPS
を指定する必要があります。サーバーDN一致はオプションですが、クライアントにセキュリティのレイヤーが追加されるため、お薦めします。これにより、クライアントはサーバーに対してこのチェックを実行できます。
2022年から組織単位(OU
)フィールドが削除されるCA証明書形式の変更により、SSL_SERVER_DN_MATCH
をTRUE
に設定した場合は、サーバー証明書DNを更新する必要がある場合があります。DNからOUが削除された新しいサーバー証明書を受け取ったら、新しいDNと一致するようにクライアントのSSL_SERVER_CERT_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\
23.9.2.2.2 サーバーDN一致の構成とクライアントでのTLS付きTCP/IPの使用
サーバーDN一致を構成し、クライアントでTLS付きのTCP/IPを使用するようにtnsnames.ora
ファイルとlistener.ora
ファイルを編集する必要があります。
23.9.2.2.3 SSL_ALLOW_WEAK_DN_MATCHパラメータを使用したSSL_SERVER_DN_MATCHの制御
SSL_ALLOW_WEAK_DN_MATCH
パラメータは、SSL_SERVER_DN_MATCH
パラメータで部分識別名一致にサービス名を使用できるかと、データベース・サーバーの証明書をチェックするかを制御します。
Oracle Database 23c以降、SSL_SERVER_DN_MATCH
パラメータの動作が変更されました。以前は、DN一致について、データベース・サーバーの証明書のみがチェックされました。Oracle Database 23cでは、リスナーとサーバーの両方の証明書がチェックされます。また、SERVICE_NAME
設定は、部分DN一致時のチェックに使用されません。HOST
設定は引き続き、リスナーとサーバーの両方の証明書で、証明書DNおよびサブジェクト代替名(SAN)との部分DN一致に使用できます。
SSL_ALLOW_WEAK_DN_MATCH
は次のように設定できます。
TRUE
は、SSL_SERVER_DN_MATCH
でデータベース・サーバーの証明書をチェックし(ただし、リスナーはチェックしません)、サービス名を部分DN一致に使用できるようにします。クライアント側での検索順序は、まずホスト名、次にサブジェクト代替名(SAN)、そしてサービス名です。FALSE
(デフォルト)は、SSL_SERVER_DN_MATCH
でサービス名一致をチェックできないようにします。かわりに、クライアント側での一致は、証明書DNでのHOST
設定の検索に基づき、それが使用できない場合はサブジェクト代替名(SAN)フィールドで行います(ただし、サービス名は使用できません)。DNチェックは、リスナーおよびサーバーで実行されます。
以前に部分DN一致にサービス名を使用した場合は、新しい証明書を取得するか、SSL_ALLOW_WEAK_DN_MATCH
をTRUE
に設定してリリース23cより前の動作に戻す必要があります。ほとんどの場合、データベース・サーバーとリスナーの両方に同じ証明書を使用していますが、そうでない場合は、次のいずれかを実行する必要があります。
- 新しい証明書を取得します(自己署名証明書には
orapki cert create
コマンドを使用します) - DN一致方針を変更または削除します。
SSL_SERVER_DN_MATCH
を古い動作に戻すには、SSL_ALLOW_WEAK_DN_MATCH
パラメータをTRUE
に設定します。
SSL_ALLOW_WEAK_DN_MATCH
をTRUE
に設定する際は、次の点に注意してください。
- クライアントが完全DN一致(
SSL_SERVER_MATCH=TRUE
、SSL_SERVER_CERT_DN="certificate_DN"
)を実行する場合、データベース・サーバーの証明書DNのみがSSL_SERVER_CERT_DN
値と一致する必要があります。 - クライアントが部分DN一致(
SSL_SERVER_MATCH=TRUE
、SSL_SERVER_CERT_DN
が設定されていない)を実行する場合、Oracle Databaseは接続文字列パラメータHOST
をデータベース・サーバー証明書DNの共通名(CN)および証明書のサブジェクト代替名フィールド(SAN)と比較します。部分一致がない場合、Oracle Databaseは引き続き、CNでSERVICE_NAME
パラメータをチェックします。
23.9.2.4 ステップ2D: クライアントのTransport Layer Security暗号スイートの設定(オプション)
オプションで、Transport Layer Security暗号スイートを設定できます。Oracle Databaseにはデフォルトの暗号スイート設定が用意されています。
- クライアントのTransport Layer Security暗号スイートの設定について
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。 - クライアントのTransport Layer Security暗号スイートの設定
Oracle Net Managerを使用して、クライアントTLS暗号スイートを設定できます。
23.9.2.4.1 クライアントのTransport Layer Security暗号スイートの設定について
暗号スイートは、ネットワーク・エンティティ間のメッセージ交換に使用される認証、暗号化およびデータ整合性アルゴリズムのセットです。
SSLハンドシェイク時に、2つのエンティティがネゴシエートし、メッセージを送受信するときに使用する暗号スイートを確認します。
Oracle Databaseをインストールすると、TLS暗号スイートがデフォルトで設定されます。2つのエンティティが接続をネゴシエートするときに、この表のリスト順で暗号スイートが試行されます。デフォルトは、SSL_CIPHER_SUITES
パラメータを設定して上書きできます。たとえば、Oracle Net Managerを使用して暗号スイートSSL_RSA_WITH_RC4_128_SHA
を追加する場合、デフォルト設定の他のすべての暗号スイートは無視されます。
暗号スイートの優先順位を設定できます。クライアントが使用する暗号スイートに関してサーバーとネゴシエートする場合、設定されている優先順位に従います。暗号スイートの優先順位を設定する場合は、次の点を考慮してください。
-
使用するセキュリティ・レベル。たとえば、AES暗号化はDESよりも強力です。
-
パフォーマンスへの影響。たとえば、Triple-DES暗号化は、DESよりも低速です。
-
管理要件。クライアントに対して選択された暗号スイートは、サーバーに必要な暗号スイートと互換性がある必要があります。たとえば、Oracle Call Interface (OCI)ユーザーの場合、サーバーはクライアントに自己認証を求めます。この場合、証明書の交換を許可しないDiffie-Hellman匿名認証を利用する暗号スイートは使用できません。
通常、暗号スイートは最も強力なものから弱いものの順に優先順位を設定します。
現在サポートされているTransport Layer Security暗号スイートは、Oracle Databaseのインストール時にデフォルトで設定されます。表では、各暗号スイートで使用される認証、暗号化およびデータ整合性のタイプも示されています。
ノート:
sqlnet.ora
ファイルでSSL_CLIENT_AUTHENTICATION
パラメータをtrue
に設定する場合は、Diffie-Hellman匿名認証を使用するすべての暗号スイートを無効にします。設定しない場合、接続に失敗します。
23.9.2.5 ステップ2E: 必要なTLSバージョンのクライアントでの設定(オプション)
SSL_VERSION
パラメータでは、クライアントが通信するシステムで実行する必要があるTLSのバージョンを定義します。
sqlnet.ora
ファイルでSSL_VERSION
パラメータを設定する必要があります。これらのシステムで有効なバージョンを使用するように設定できます。
sqlnet.ora
におけるこのパラメータのデフォルト設定はundetermined
で、これは、「ネットワーク・セキュリティ」ウィンドウの「SSL」タブのリストから「任意」を選択すると設定されます。「任意」を選択すると、TLS 1.0が最初に試行され、その後、TLS 3.0、TLS 2.0の順に試行されます。クライアントのTLSバージョンがサーバーで使用されているバージョンと互換性があることを確認します。
23.9.2.6 ステップ2F: クライアントにおける認証サービスとしてのTLSの設定(オプション)
sqlnet.ora
ファイルのSQLNET.AUTHENTICATION_SERVICES
パラメータでは、TLS認証サービスを設定します。
- SQLNET.AUTHENTICATION_SERVICESパラメータについて
SQLNET.AUTHENTICATION_SERVICES
パラメータは、TLS認証とOracle Databaseでサポートされている別の認証方式の併用を可能にします。 - SQLNET.AUTHENTICATION_SERVICESパラメータの設定
sqlnet.ora
ファイルでSQLNET.AUTHENTICATION_SERVICES
パラメータを設定できます。
23.9.2.6.1 SQLNET.AUTHENTICATION_SERVICESパラメータについて
SQLNET.AUTHENTICATION_SERVICES
パラメータは、TLS認証とOracle Databaseでサポートされている別の認証方式の併用を可能にします。
たとえば、サーバーがTLSを使用してクライアントに対して自己認証を行い、クライアントがRADIUSを使用してサーバーに対して自己認証を行う場合に、このパラメータを使用します。
SQLNET.AUTHENTICATION_SERVICES
パラメータを設定するには、sqlnet.ora
ファイル(他のネットワーク構成ファイルと同じディレクトリにあります)を編集する必要があります。
プラットフォームに応じて、sqlnet.ora
ファイルは次のディレクトリにあります。
-
(UNIXの場合)
$ORACLE_HOME
/network/admin
-
(Windowsの場合)
ORACLE_BASE
\
ORACLE_HOME
\network\admin\
23.9.2.6.2 SQLNET.AUTHENTICATION_SERVICESパラメータの設定
sqlnet.ora
ファイルでSQLNET.AUTHENTICATION_SERVICES
パラメータを設定できます。
-
クライアントの
SQLNET.AUTHENTICATION_SERVICES
パラメータを設定するには、テキスト・エディタを使用して、sqlnet.ora
ファイルのこのパラメータにTLS付きTCP/IP (TCPS
)を追加します。たとえば、TLS認証とRADIUS認証を組み合せて使用する場合は、このパラメータを次のように設定します。
SQLNET.AUTHENTICATION_SERVICES = (TCPS, radius)
TLS認証と別の認証方式を組み合せて使用しない場合は、このパラメータを設定しません。
23.9.2.7 ステップ2G: クライアントでの認証に使用する証明書の指定(オプション)
証明書が複数ある場合は、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
を設定して、クライアント認証を設定できます。
23.9.2.7.1 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
が自動的に、サーバーへのクライアントのTransport Layer Security認証に使用されます。
23.9.2.7.2 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
パラメータ設定を削除します。
23.9.2.8 ステップ2H: 接続でTransport Layer Securityが使用されていることの確認
動的ビューのV$SESSION
とV$SESSION_CONNECT_INFO
を問い合せると、クライアント接続がTransport Layer Security (TLS)を使用していることを確認できます。
23.9.3 ステップ3: データベース・インスタンスへのログイン
構成の完了後、データベースにログインします。
-
SQL*Plusを起動して、次のいずれかの接続コマンドを入力します。
-
クライアントにTransport Layer Security認証を使用する場合は(
sqlnet.ora
ファイルでSSL_CLIENT_AUTHENTICATION=true
を設定)、次のように入力します。CONNECT/@net_service_name
-
Transport Layer Security認証を使用しない場合は(
sqlnet.ora
ファイルでSSL_CLIENT_AUTHENTICATION=false
を設定)、次のように入力します。CONNECT username@net_service_name Enter password: password
-
関連トピック
23.10 Transport Layer SecurityのOracleウォレット検索順序
Oracle Databaseは、Transport Layer Security (TLS)環境でサーバーのウォレットを検索するための複数のルートを用意しています。
Oracle Databaseサーバーは、次の場所を次の順序で検索して、ウォレットを取得します。
init.ora
ファイルのWALLET_ROOT
sqlnet.ora
ファイルのWALLET_LOCATION
- デフォルトのウォレット・ロケーション:
- Linux:
/etc/ORACLE/WALLETS/user_name
- Windows:
C:\Users\user_name\\ORACLE\WALLETS
- Linux:
TNSリスナーは、次の順序でこれらの場所を検索してウォレット・ロケーションを取得します。
listener.ora
ファイルのWALLET_LOCATION
- デフォルトのウォレット・ロケーション:
- Linux:
/etc/ORACLE/WALLETS/user_name
- Windows:
C:\Users\user_name\\ORACLE\WALLETS
- Linux:
Oracle Databaseクライアントは、次の場所を次の順序で検索して、ウォレットを取得します。
- 接続文字列
sqlnet.ora
ファイルのWALLET_LOCATION
- デフォルトのウォレット・ロケーション:
- Linux:
/etc/ORACLE/WALLETS/user_name
- Windows:
C:\Users\user_name\\ORACLE\WALLETS
- Linux:
- 証明書ストアの場所にあるシステム・ウォレット。デフォルトの証明書ストアの場所は、次のようにプラットフォームによって異なります:
- Linux: RHEL/Oracle Linux:
/etc/pki/tls/cert.pem
- Microsoft Windows: Microsoft証明書ストア
- Linux: RHEL/Oracle Linux:
23.11 Oracle Real Application Clusters環境でのTransport Layer Security接続
Oracle RACツールを使用してOracle Database構成ファイルを変更することで、Oracle Real Application Clusters (Oracle RAC)環境でTransport Layer Security (TLS)接続を構成できます。
- ステップ1: TCPSプロトコル・エンドポイントの構成
Oracle Real Application Clusters (Oracle RAC)では、クライアントは3つのスキャン・リスナーのいずれかにアクセスし、その後、データベース・リスナーにルーティングされます。Transport Layer Security (TLS)をサポートするには、これらのリスナーすべてにTCPSプロトコル・エンドポイントが必要です。 - ステップ2: 各ノードでLOCAL_LISTENERパラメータが正しく設定されていることの確認
Oracle Agentは、各ノードでLOCAL_LISTENER
パラメータを自動的に設定しますが、正しいことを再確認する必要があります。 - ステップ3: Transport Layer Securityウォレットおよび証明書の作成
クラスタ用、およびTLS経由でクラスタに接続するクライアント用のTransport Layer Security (TLS)ウォレットおよび証明書を作成する必要があります。 - ステップ4: Oracle RACクラスタの各ノードでのウォレットの作成
クラスタ・ウォレットの作成後、Oracle Real Applications (Oracle RAC)クラスタの各ノードにコピーできます。 - ステップ5: listener.oraおよびsqlnet.oraファイルでのウォレットの場所の定義
データベース・サーバーおよびリスナーがウォレットにアクセスできるようにするには、listener.ora
およびsqlnet.ora
ファイルでウォレットの場所を定義する必要があります。 - ステップ6: データベース・インスタンスおよびリスナーの再起動
ウォレットが配置され、*.ora
ファイルが編集された状態で、データベース・サーバーおよびリスナー・プロセスを再起動して、新しい設定を取得する必要があります。 - ステップ7: クラスタ・ノード構成のテスト
クラスタ・ノード構成をテストするには、ノードの接続記述子を作成し、このノードへの接続を試行します。 - ステップ8: リモート・クライアント構成のテスト
Oracle Real Applications (Oracle RAC)クラスタ・ノードでウォレットをテストした後、リモート・クライアント構成をテストする準備ができます。
23.11.1 ステップ1: TCPSプロトコル・エンドポイントの構成
Oracle Real Application Clusters (Oracle RAC)では、クライアントは3つのSCANリスナーのいずれかにアクセスし、それからデータベース・リスナーにルーティングされます。Transport Layer Security (TLS)をサポートするには、これらのリスナーすべてにTCPSプロトコル・エンドポイントが必要です。
23.11.2 ステップ2: 各ノードでLOCAL_LISTENERパラメータが正しく設定されていることの確認
Oracle Agentは、各ノードでLOCAL_LISTENER
パラメータを自動的に設定しますが、正しいことを再確認する必要があります。
23.11.3 ステップ3: Transport Layer Securityウォレットおよび証明書の作成
クラスタ用、およびTLS経由でクラスタに接続するクライアント用のTransport Layer Security (TLS)ウォレットおよび証明書を作成する必要があります。
- 証明書が必要なOracle Real Application Clustersコンポーネント
Transport Layer Security (TLS)接続を構成する場合、Oracle Real Application Clusters (Oracle RAC)の特定のコンポーネントに証明書が必要です。 - Transport Layer Securityウォレットおよび証明書の作成
Transport Layer Securityウォレットおよび証明書を作成するには、最初にルートCA証明書を作成し、次にクラスタ・ウォレットおよびクライアント・ウォレットを作成します。
23.11.3.1 証明書が必要なOracle Real Application Clustersコンポーネント
Oracle Real Application Clusters (Oracle RAC)の特定のコンポーネントでは、Transport Layer Security (TLS)接続を構成するときに証明書が必要です。
- 各クラスタ・ノード(サーバー)およびリスナーには、ユーザー証明書およびCA証明書を含むウォレットが必要です。
- 一方向のTLSが構成されている場合、クライアントはリスナーおよびサーバーのCA証明書(ウォレットまたはシステムの証明書ストア内)のみを必要とします。
- mTLSが構成されている場合、クライアントには、ユーザー証明書とリスナーおよびサーバーのCA証明書を含むウォレットが必要です。
23.11.4 ステップ4: Oracle RACクラスタの各ノードでのウォレットの作成
クラスタ・ウォレットを作成した後、それをOracle Real Applications (Oracle RAC)クラスタの各ノードにコピーできます。
23.11.5 ステップ5: listener.oraおよびsqlnet.oraファイルへのウォレットの場所の定義
データベース・サーバーおよびリスナーがウォレットにアクセスできるようにするには、listener.ora
およびsqlnet.ora
ファイルにウォレットの場所を定義する必要があります。
23.11.6 ステップ6: データベース・インスタンスおよびリスナーの再起動
ウォレットを配置して*.ora
ファイルを編集した後、データベース・サーバーおよびリスナー・プロセスを再起動して新しい設定を取得する必要があります。
LOCAL_LISTENER
パラメータを設定したOracle Real Application Clusters (Oracle RAC)インスタンスも有効になります。
23.12 Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成
この構成をMicrosoft Certificate Store (MCS)で実行するには、orapki
コマンドライン・ツールを使用して証明書を生成し、Oracleウォレットを操作します。
- Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成について
このタイプの構成は、Common Access CardおよびPIVカード認証の基盤です。 - ステップ1: サーバー・ウォレットの作成および構成
orapki
を使用して、サーバー・ウォレットおよびサーバーの自己署名証明書を作成する必要があります。 - ステップ2: クライアント・ウォレットの作成および構成
orapki
を使用して、クライアント・ウォレットおよび証明書リクエストを作成する必要があります。 - ステップ3: Oracle Databaseでの外部ユーザーの作成
クライアントおよびサーバー接続で使用する外部ユーザーを作成する必要があります。 - ステップ4: サーバーのlistener.oraファイルの構成
次に、サーバーのlistener.ora
ファイルを確認してから再起動する必要があります。 - ステップ5: サーバーのsqlnet.oraファイルの構成
sqlnet.ora
ファイルが、前に作成したサーバー・ウォレットを指していることを確認する必要があります。 - ステップ6: Microsoft証明書ストアへのクライアント・ウォレットのインポート
このインポート操作を実行するには、Microsoft管理コンソール(MMC)を使用する必要があります。 - ステップ7: クライアントのsqlnet.oraファイルの構成
クライアント・ウォレットにMicrosoft証明書ストアを使用するようにクライアントのsqlnet.ora
ファイルを構成する必要があります。 - ステップ8: Oracle Databaseの構成
Oracleデータベースで、OS_AUTHENT_PRE
およびREMOTE_OS_AUTH
パラメータを構成します。 - ステップ9: クライアントおよびサーバー接続のテスト
Microsoft証明書ストア構成を完了したら、サーバー接続をテストする必要があります。
23.12.1 Microsoft証明書ストアを使用したクライアント認証および暗号化のためのトランスポート・レイヤー・セキュリティの構成について
このタイプの構成は、Common Access CardおよびPIVカード認証の基盤です。
Common Access CardおよびPIVカードとともに提供されるソフトウェア・ライブラリが、必要な証明書を透過的にMicrosoft証明書ストアにロードできるかぎり、構成するTransport Layer Security (TLS)認証は透過的に実行されます。
PIVカードにロードされるユーザー証明書のすべての署名証明書は、サーバー・レベルのTLS構成の一部としてサーバーのウォレットに手動でロードする必要があることに注意してください。
23.12.7 ステップ6: Microsoft証明書ストアへのクライアント・ウォレットのインポート
このインポート操作を実行するには、Microsoft管理コンソール(MMC)を使用する必要があります。
- MMC (
mmc.exe
)を起動します。 - 「ファイル」、「スナップインの追加と削除」の順に選択します。
- 「証明書」、「追加」の順に選択します。
- 「ユーザー アカウント」、「完了」、「OK」の順に選択します。
- 「コンソール ルート」、「証明書 - 現在のユーザー」、「個人」、「証明書」の順に移動します。
- 「すべてのタスク」を右クリックし、「インポート」、「次へ」、「参照」の順に選択します。
- 接続に必要な証明書が含まれている証明書ファイル(
ewallet.p12
など)を選択します。 - 「開く」、「次へ」の順に選択します。
- ウォレットのパスワードを入力します。
- 「このキーをエクスポート可能としてマークする」チェック・ボックスを選択します。
- 「すべての拡張プロパティを含める」チェック・ボックスを選択します。
- 「すべての証明書を次のストアに配置する: 個人」を選択します。
- 「次へ」、「完了」の順に選択します。
- 「コンソール ルート」に移動してから、「証明書 - 現在のユーザー」、「個人」、「証明書」の順に選択して、クライアントの証明書がMYストアに追加されていることを確認します。
- 「コンソール ルート」に移動してから、「証明書 - 現在のユーザー」、「信頼されたルート証明機関」、「証明書」の順に選択して、CA証明書がROOTストアに追加されていることを確認します。
23.12.8 ステップ7: クライアントのsqlnet.oraファイルの構成
クライアント・ウォレットにMicrosoft証明書ストアを使用するようにクライアントのsqlnet.ora
ファイルを構成する必要があります。
23.13 Transport Layer Security構成のトラブルシューティング
Oracle Database SSLアダプタの使用中に一般的なエラーが発生する場合があります。
Oracle Netトレースを有効にして、エラーの原因を特定することが必要になる場合があります。トレース・パラメータを設定してOracle Netトレースを有効にする方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
- ORA-28759: ファイルのオープンに失敗しました
-
原因: 指定されたファイルをオープンできませんでした。通常、このエラーはウォレットが見つからないために発生します。
- ORA-28786: 暗号化された秘密キーの復号化に失敗しました
-
原因: 暗号化された秘密キーの復号化に不正なパスワードが使用されました。このことは、多くの場合、自動ログイン・ウォレットが使用されていないために発生します。
- ORA-28858: SSLプロトコル・エラーが発生しました
-
原因: これは、2つのプロセス間のTLSハンドシェイク・ネゴシエーション中に発生する可能性がある一般的なエラーです。
- ORA-28859 SSLでネゴシエーションに失敗しました
-
原因: TLSプロトコルの一部である2つのプロセス間のネゴシエーション中にエラーが発生しました。このエラーは、両プロセスの接続で同じ暗号スイートがサポートされていない場合に発生する可能性があります。
- ORA-28862: SSL接続に失敗しました。
-
原因: このエラーは、ピアが接続をクローズしたために発生しました。
- ORA-28865: SSL接続はクローズしました。
-
原因: 基礎となるトランスポート層でエラーが発生したか、ピア・プロセスが突然停止したため、TLS接続がクローズしました。
- ORA-28868: ピア証明連鎖のチェックに失敗しました。
-
原因: ピアが証明連鎖を提示したときに、その証明連鎖のチェックに失敗しました。この失敗の原因として、いくつかの問題が考えられます。
-
連鎖内のいずれかの証明書が期限切れになっています。
-
連鎖内のいずれかの証明書の認証局がトラスト・ポイントとして認識されていません。
-
いずれかの証明書の署名を検証できません。
-
- ORA-28885: 必須のキー使用方法のある証明書が見つかりません。
-
原因: 証明書は、適切なX.509バージョン3のキー使用方法の拡張機能を使用して作成されていません。
- ORA-29024: 証明書の検証に失敗しました
-
原因: 反対側から送信された証明書の妥当性チェックに失敗しました。このエラーは、証明書が期限切れか、失効済か、または他の理由で無効になっている場合に発生する可能性があります。
- ORA-29223: 証明連鎖を作成できませんでした
-
原因: インストールする証明書の既存のトラスト・ポイントを使用して証明書チェーンを作成できません。通常、このエラーは、ピアによって完全な連鎖が提供されず、連鎖を完了するのに適切なトラスト・ポイントがない場合に戻されます。
23.14 証明書失効リストによる証明書の検証
オラクル社では、証明書失効リストを使用して証明書を検証できるツールを提供しています。
- 証明書失効リストによる証明書検証について
指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。 - 使用するCRLの選択方法
使用するトラスト・ポイントすべてについてCRLが必要です。 - CRLチェックの動作の仕組み
Oracle Databaseでは証明書の失効状態をCRLに照らして確認します。 - 証明書失効リストによる証明書検証の構成
sqlnet.ora
ファイルを編集して、証明書失効リストによる証明書検証を構成できます。 - 証明書失効リストの管理
証明書失効リストの管理では、証明書失効チェックを有効にする前に、CRLが正しい書式であることを確認する必要があります。 - CRL証明書検証のトラブルシューティング
CRLに対して証明書を検証するかどうかを判断するには、Oracle Netトレースを有効にできます。 - 証明書検証に関連するOracle Netトレース・ファイルのエラー・メッセージ
証明書検証に関連するトレース・メッセージが生成されます。
23.14.1 証明書失効リストによる証明書検証について
指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。
証明書の検証には、次が該当するかどうかの判定が含まれます。
-
信頼できる認証局(CA)にデジタル署名された証明書があるかどうか。
-
証明書のデジタル署名が、証明書自体の別個に計算されたハッシュ値および証明書の署名者の(CAの)公開キーに対応しているかどうか。
-
証明書が期限切れになっていないかどうか。
-
証明書が失効していないかどうか。
Transport Layer Securityネットワーク・レイヤーは、自動的に最初の3つの検証チェックを実行しますが、証明書が失効していないことを確認するには、証明書失効リスト(CRL)のチェックを構成する必要があります。CRLは、失効した証明書のリストを含む署名付きデータ構造体です。これは通常、元の証明書を発行したエンティティと同じエンティティによって発行され署名されます。
親トピック: 証明書失効リストによる証明書の検証
23.14.2 使用するCRLの選択方法
使用するトラスト・ポイントすべてについてCRLが必要です。
トラスト・ポイントは、一定の信頼レベルで資格を与えられたサード・パーティ・アイデンティティからの信頼できる証明書です。
通常、信頼する認証局はトラスト・ポイントと呼ばれます。
親トピック: 証明書失効リストによる証明書の検証
23.14.3 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を定期的に更新する必要があることに注意してください。 -
CRL DP
CAが、証明書が発行されたときのCRL DP X.509、バージョン3、証明書拡張子内の位置を指定すると、その証明書用の失効情報を含む適切なCRLがダウンロードされます。現在、Oracle Databaseは、LDAPを介したCRLのダウンロードをサポートしています。
次のことに注意してください。
-
パフォーマンス上の理由から、ユーザー証明書のみがチェックされます。
-
CRLをローカル・ファイル・システムではなくディレクトリに格納することをお薦めします。
-
23.14.4 証明書失効リストによる証明書検証の構成
sqlnet.ora
ファイルを編集して、証明書失効リストによる証明書検証を構成できます。
- 証明書失効リストによる証明書検証の構成について
証明書失効ステータス・チェックを有効にするには、sqlnet.ora
ファイルでSSL_CERT_REVOCATION
パラメータをREQUIRED
またはREQUESTED
に設定する必要があります。 - クライアントまたはサーバー用の証明書失効ステータス・チェックの有効化
クライアントまたはサーバー用の証明書失効ステータス・チェックを有効にできます。 - 証明書失効ステータス・チェックの無効化
証明書失効ステータス・チェックを無効にできます。
親トピック: 証明書失効リストによる証明書の検証
23.14.4.1 証明書失効リストによる証明書検証の構成について
証明書失効ステータス・チェックを有効にするには、sqlnet.ora
ファイルでSSL_CERT_REVOCATION
パラメータをREQUIRED
またはREQUESTED
に設定する必要があります。
証明書失効ステータス・チェックを有効にするには、sqlnet.ora
ファイルでSSL_CERT_REVOCATION
パラメータをREQUIRED
またはREQUESTED
に設定する必要があります。
デフォルトでは、このパラメータはNONE
に設定され、証明書失効ステータス・チェックはオフになっています。
ノート:
CRLをローカル・ファイル・システムまたはOracle Internet Directoryに格納する場合は、コマンドライン・ユーティリティorapki
を使用して、ファイル・システム内のCRLの名前を変更するか、CRLをディレクトリにアップロードします。
関連トピック
親トピック: 証明書失効リストによる証明書検証の構成
23.14.4.2 クライアントまたはサーバー用の証明書失効ステータス・チェックの有効化
クライアントまたはサーバー用の証明書失効ステータス・チェックを有効にできます。
関連トピック
親トピック: 証明書失効リストによる証明書検証の構成
23.14.5 証明書失効リストの管理
証明書失効リストの管理では、証明書失効チェックを有効にする前に、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
のメンバーである必要があります。
親トピック: 証明書失効リストによる証明書の検証
23.14.5.1 証明書失効リストの管理について
Oracle Databaseには、証明書の管理を実行するために使用できるコマンドライン・ユーティリティorapki
があります。
証明書失効ステータス・チェックを有効にするには、まず、使用するCAから受信したCRLがコンピュータで使用できるフォームである(ハッシュ値で名前変更されている)こと、またはコンピュータで使用できる場所にある(ディレクトリにアップロードされている)ことを確認してください。
LDAPコマンド行ツールを使用して、Oracle Internet DirectoryでCRLを管理することもできます。
ノート:
CRLは、正常な検証を行うために、(期限切れになる前に)定期的に更新する必要があります。このタスクは、スクリプトでorapki
コマンドを使用して自動化できます。
親トピック: 証明書失効リストの管理
23.14.5.2 CRLを管理するコマンドのorapkiヘルプの表示
CRLの管理に使用可能なorapki
コマンドをすべて表示できます。
-
CRLの管理に使用可能な
orapki
コマンドとそのオプションをすべての表示するには、コマンドラインに次のように入力します。orapki crl help
ノート:
-summary
、-complete
または-wallet
コマンド・オプションの使用は、常にオプションです。これらのコマンド・オプションが指定されていなくても、コマンドは実行されます。
親トピック: 証明書失効リストの管理
23.14.5.3 証明書検証用ハッシュ値による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発行者名が表示されます。
親トピック: 証明書失効リストの管理
23.14.5.4 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
(認証なしのTLSポート)はディレクトリがインストールされているシステムに対するもの、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ベースのTLSサーバーが実行されているディレクトリのSSLポートを指定していることを確認してください。これは、認証を実行しないTLSポートです。サーバー認証も相互認証TLSポートも、
orapki
ユーティリティではサポートされていません。
親トピック: 証明書失効リストの管理
23.14.5.5 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ポートであることに注意してください。
親トピック: 証明書失効リストの管理
23.14.5.6 Oracle Internet DirectoryでのCRLの表示
Oracle Internet Directory CRLは要約された形式で表示できるほか、CRLの失効した証明書のリストを要求することもできます。
親トピック: 証明書失効リストの管理
23.14.5.7 Oracle Internet DirectoryからのCRLの削除
orapki
を使用してディレクトリからCRLを削除するユーザーは、ディレクトリ・グループCRLAdmins
のメンバーである必要があります。
親トピック: 証明書失効リストの管理
23.14.6 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: 証明書の検証に失敗しました」
というメッセージが表示されます。
23.14.7 証明書検証に関連する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が正しくない場合に発生します。
親トピック: 証明書失効リストによる証明書の検証
23.15 ハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
Oracle Databaseでは、RSA Security社のPKCS #11仕様に準拠したAPIを使用するハードウェア・セキュリティ・モジュールがサポートされています。
通常、これらのハードウェア・デバイスは、トークンまたはスマートカードの秘密キーを安全に格納および管理するため、または暗号処理を高速化するために使用されます。
- TLSでハードウェア・セキュリティ・モジュールを使用するための一般的なガイドライン
Oracle Databaseでハードウェア・セキュリティ・モジュールを使用する場合は、次のガイドラインに従ってください。 - nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
暗号化処理でnCipherハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。 - SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
暗号化処理でSafeNETハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。 - ハードウェア・セキュリティ・モジュールの使用時のトラブルシューティング
ハードウェア・セキュリティ・モジュールに関するトラブルシューティングのアドバイスを提供します。
23.15.1 TLSでハードウェア・セキュリティ・モジュールを使用するための一般的なガイドライン
Oracle Databaseでハードウェア・セキュリティ・モジュールを使用する場合は、次のガイドラインに従ってください。
-
必要なハードウェア、ソフトウェアおよびPKCS #11ライブラリを取得するには、ハードウェア・デバイス・ベンダーにお問い合せください。
-
使用しているハードウェア・セキュリティ・モジュールに適したハードウェア、ソフトウェアおよびライブラリをインストールします。
-
ハードウェア・セキュリティ・モジュールのインストールをテストして、正常に動作することを確認します。詳細は、使用するデバイスのドキュメントを参照してください。
-
秘密キーをトークンに格納する場合は、Oracle Wallet Managerを使用して
PKCS11
タイプのウォレットを作成し、PKCS #11ライブラリへの絶対パス(ライブラリ名を含む)を指定します。OraclePKCS11
ウォレットには、秘密キーにアクセスするためのトークンを指す情報が格納されます。
PKCS #11情報が格納されたウォレットは、任意のOracleウォレットを使用する場合と同様に使用できます。ただし、秘密キーをハードウェア・デバイスに格納し、暗号操作もそのデバイスで実行する場合を除きます。
23.15.2 nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
暗号化処理でnCipherハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。
- nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について
nCipher社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。 - nCipherハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント
nCipherハードウェア・セキュリティ・モジュールを使用するには、特別なコンポーネントのセットが必要です。 - nCipherハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件
nCipherハードウェア・セキュリティ・モジュールはnCipher PKCS #11ライブラリを使用します。
23.15.2.1 nCipherハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について
nCipher社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。
これらのモジュールでは、キーを安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。
-
暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。
-
デバイス上の秘密キーの記憶領域が保護されます。
-
スマートカードを使用してキーを管理できます。
ノート:
Oracle Databaseで使用する認定済のハードウェアおよびソフトウェアを入手するには、nCipherの代理店にお問い合せください。
23.15.2.2 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ハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。
23.15.2.3 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ライブラリを使用します。
23.15.3 SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成
暗号化処理でSafeNETハードウェア・セキュリティ・モジュールを使用するようにシステムを構成できます。
- SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について
SafeNET社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。 - SafeNET Luna SAハードウェア・セキュリティ・モジュールに必要なOracleコンポーネント
SafeNET Luna SAハードウェア・セキュリティ・モジュールを使用するには、特別なコンポーネントのセットが必要です。 - SafeNETハードウェア・セキュリティ・モジュールをインストールするためのディレクトリ・パス要件
SafeNETハードウェア・セキュリティ・モジュールはSafeNET PKCS #11ライブラリを使用します。
23.15.3.1 SafeNETハードウェア・セキュリティ・モジュールを使用するためのシステムの構成について
SafeNET社製のハードウェア・セキュリティ・モジュールは、Oracle Databaseで動作することが証明されています。
これらのモジュールでは、キーを安全に格納し、暗号処理の負荷を軽減できます。これらのデバイスには、主に次の利点があります。
-
暗号処理の負荷が軽減され、サーバーが他の要求に応答できるようになります。
-
デバイス上の秘密キーの記憶領域が保護されます。
ノート:
Oracle Databaseで使用する認定済のハードウェアおよびソフトウェアを入手するには、SafeNETの代理店にお問い合せください。
23.15.3.2 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ハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。
23.15.3.3 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の場合)
23.15.4 ハードウェア・セキュリティ・モジュールの使用時のトラブルシューティング
ハードウェア・セキュリティ・モジュールに関するトラブルシューティングのアドバイスを提供します。
- Oracle Netトレース・ファイルのエラー
使用されているモジュールを検出するには、Oracle Netトレースをオンにします。 - ハードウェア・セキュリティ・モジュールの使用に関連するエラー・メッセージ
PKCS #11ハードウェア・セキュリティ・モジュールの使用に関連するエラーが表示される場合があります。
23.15.4.1 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管理者ガイド』を参照してください。
23.15.4.2 ハードウェア・セキュリティ・モジュールの使用に関連するエラー・メッセージ
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のドキュメントを参照してください。