前回の記事では、データベースファイルそのものを暗号化し、万が一のディスク盗難やOSレベルでの閲覧からデータを保護する方法として、 透過的データ暗号化、通称TDE (Transparent Data Encryption) をご紹介しました。

しかし、セキュリティは保存データ（at rest）だけを守れば十分というわけではありません。データベースとクライアント間でやり取りされる通信の盗聴や改ざんのリスクも考慮し、「通信中のデータ（in transit）」にも目を向ける必要があります。

例えば、通信に対するリスクとしては以下のようなものが考えられます。

  • ネットワーク盗聴（パケットキャプチャによるデータ漏洩）
  • 中間者攻撃
  • 認証情報の漏洩（ID・パスワードの解読）

これらのリスクに対処するため、Oracle Database ではデータベースとアプリケーション間の通信（SQL*Net）を暗号化する仕組みが提供されています。

そこで本記事では、Oracleがもつ、この通信暗号化機能についてご紹介していきたいと思います。

 

DB通信を暗号化する選択肢

Oracle Databaseでは、ネットワーク上でやり取りされるSQLクエリやその結果、認証情報などの機密情報を安全に保護することを目的として、SQL*Net経由の通信を暗号化し、さらに整合性を検証する機能が用意されています。

この機能の方式は、大きく次の2つに分けられます。

ネイティブ・ネットワーク暗号化（Native Network Encryption: NNE）

  • Oracle独自のプロトコルを使用。暗号化、改ざん防止機能を備える

TLS（Transport Layer Security）

  • 業界標準のプロトコル。暗号化と改ざん防止に加えて認証機能もサポート

 

これら2つはもともと Advanced Security Option(ASO)の一部だったのですが、11gR2からはすべてのエディションでご利用いただけるようになりました。

それでは、それぞれの方式について詳しく見ていきましょう。

 

ネイティブ・ネットワーク暗号化

ネイティブ・ネットワーク暗号化（Native Network Encryption: NNE）では、Oracle独自のプロトコルを使用して通信を暗号化します。また、暗号化機能の他に、ハッシュを用いた整合性チェックの機能も備えており、データの改ざん対策としても利用することができます。

構成もシンプルで、クライアントまたはサーバー側の設定ファイル（sqlnet.ora）にパラメータを追記するだけで有効化が可能です。リスナーも暗号化の有無にかかわらず共通で利用できるため、暗号化用に新しいリスナーを用意する必要はありません。

使用可能な暗号化アルゴリズムは代表的なものとして、AES128、AES192、AES256があり、鍵交換にはDiffie-Hellman鍵共有が使用されています。 整合性チェック用のアルゴリズムは SHA-1、SHA-256、SHA-384、SHA-512を指定することが可能です。

 

・設定方法

設定内容について見ていきましょう。 先述した通り、サーバーまたはクライアントの sqlnet.ora に以下の２行を追記するだけで、暗号機能を有効化できます。 サーバー側にはSERVERを、クライアント側にはCLIENTのパラメータを追記します。

SQLNET.ENCRYPTION_[SERVER | CLIENT] = {REQUIRED, REQUESTED, ACCEPTED, REJECTED}
SQLNET.ENCRYPTION_TYPES_[SERVER | CLIENT] = (AES256, AES192, AES128)

 

NNE接続の構成

 

クライアントとサーバーはこれらの設定をもとに暗号化の有無とアルゴリズムのネゴシエーションを行います。そして、暗号化の有無は以下の表のように、SQLNET.ENCRYPTION_SERVER と SQLNET.ENCRYPTION_CLIENT の組み合わせによって決まります。

NNEの設定組み合わせ

 

※ 暗号化設定が一致しない場合は、接続は失敗しORA-12650エラーが発生します。

デフォルトではACCEPTEDとみなされるため、暗号化機能はオフになっていますが、クライアントまたはサーバーのどちらかの設定をREQUESTED以上にしていただくだけで暗号化を有効にすることができます。なお、使用される暗号化アルゴリズムは設定リストの先頭から優先して選択されます。

一方、整合性検証の設定についても、暗号機能と同様の設定に以下のパラメータを追加します。

SQLNET.CRYPTO_CHECKSUM_[SERVER | CLIENT]={REQUIRED, REQUESTED, ACCEPTED, REJECTED}
SQLNET.CRYPTO_CHECKSUM_TYPES_[SERVER | CLIENT]=(SHA256,SHA384,SHA512,SHA1)

 

適用のフローは暗号化と同様で、クライアントとサーバーの設定により整合性検証の有無が決定されます。

 

・OCI（Oracle Cloud Infrastructure）での初期設定

Oracle Cloud Infrastructure（以下OCI）の Database Cloud Service では、このネイティブ・ネットワーク暗号化機能の暗号化と整合性検証がデフォルトで有効化設定されています。

以下は、Base Base Database Service 23ai を作成した際の初期設定です。構成時の参考にしてください。
※ 整理のため一部省略、および並び替えを行っています。

# 暗号化設定
SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256, AES192, AES128)
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256, AES192, AES128)

# 整合性検証設定
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA256, SHA384, SHA512, SHA1)
SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(SHA256, SHA384, SHA512, SHA1)

# 接続確認（接続がアクティブであることを確認する間隔：分）
SQLNET.EXPIRE_TIME=10

 

・クライアント要件

この機能を利用するには基本的にOracle Net Servicesが必要となります。そのため、利用するクライアントによっては設定方法や対応可否が異なりますのでご注意ください。

クライアント 対応

 python(python-oracledb) 

 ・thin mode: 不可
 ・thick mode: sqlnet.ora にて設定

 Java(JDBC) 

 ・thin Driver: Javaプロパティオブジェクトより設定
 ・OCI Driver: sqlnet.ora にて設定

 node.js(node-oracledb) 

 ・thin mode: 不可
 ・thick mode: sqlnet.ora にて設定

 .NET(ODP.NET) 

 ・Core: sqlnet.ora または 構成APIの OracleConfiguration にて指定          
 ・Managed Driver: 構成ファイルの setting セクションにて設定 
 ・Unmanaged Driver: sqlnet.ora にて設定

 

TLS（Transport Layer Security）

TLS（Transport Layer Security）は、業界標準のセキュリティプロトコルを用いた通信暗号化方式です。 Oracle Databaseでは TLS 1.2 に対応しており、23ai からは TLS 1.3 もサポートされるようになりました。

Oracle Databaseでは用途に応じてTLSにてサポートされる以下３つの認証方式を選択できます。

  • サーバー認証のみ：
    • 最も一般的な構成で、クライアントがサーバー証明書を検証します。
  • 相互認証（mTLS）：
    • クライアントもサーバーも証明書を提示し合い、相互に認証します。
  • 認証なし：
    • 証明書は使用せず暗号化機能だけを使用します。通信内容の盗聴は防げますが、相手の正当性は検証しないため、中間者攻撃などには注意が必要です。
    • 23ai よりサポートされなくなりました。

サーバー認証や相互認証を利用する場合は、証明書の取得・配置・更新といった管理作業が必要となるため、システム運用において適切な証明書管理が必要となります。

 

TLS接続の構成

 

TLSを使用する場合は、TLS接続専用のリスナーポートを新たに作成する必要があります。そのため、通常のリスナーは業務アプリケーション向けに利用し、TLS接続はDBAや管理ツールからのアクセス用途に使用するなど、用途に応じた通信の使い分けを行うことも可能です。

 

・Autonomous Database（ADB）での TLS 接続

OCI のマネージド・データベース・サービスである Autonomous Database（以下ADB）では、セキュリティが非常に重要視されており、接続にはTLSの使用が必須となっています。

mTLSを使用する場合、クライアント側では「ウォレット」と呼ばれるファイルを用意する必要があります。このウォレットには証明書や接続情報が含まれており、ADBへのセキュアな接続を確立するために使用されます。ウォレットは定期的な更新が求められますが、ADBでは複数のウォレットを同時に保持することが可能なため、証明書のローテーション時にもサービスを停止せずに安全に切り替えることができます。

環境に応じてウォレットを使わないTLS接続を構成することも可能です。アクセス制御リスト（ACL）が定義されている場合やプライベートエンドポイントを利用している場合には、サーバー認証のみのTLS接続を行うことができます。これにより、セキュリティを保ちつつ、運用負荷の軽減やシステム構成の簡素化が図られます。

参考として以下ドキュメントもご覧ください。
・Autonomous DatabaseでTLSまたは相互TLS (mTLS)認証のみを許可するためのネットワーク・オプションの更新 Autonomous Databaseのウォレットのローテーション

 

・クライアント要件

ADBにおいてTLS を利用する場合、認証方式によって対応しているクライアントが異なります。

その他、各言語のクライアント設定については以下を参照ください。
・クライアント・アプリケーションを使用したAutonomous Databaseへの接続

 

NNE vs TLS

２つの暗号化方式の違いについて整理してみます。

項目  ネイティブ・ネットワーク暗号化（NNE）  TLS（Transport Layer Security）

 プロトコル 

  非標準のOracle独自プロトコル  業界標準プロトコル

 認証機能 

  なし（証明書不要）  あり（サーバー証明書必須）

 設定のしやすさ 

  簡単（sqlnet.ora で完結）  クライアント／サーバーの設定変更と証明書管理が必要      

 接続ポート 

  既存リスナーのポートを利用可能  専用ポートが必要

 対策 

  盗聴・改ざん  盗聴・改ざん防止・認証

 運用負荷 

  低め（証明書不要）  中〜高（証明書管理が必要）

 

どちらの方式にもそれぞれの利点と適用シーンがあります。システムの要件や運用方針に応じて最適な暗号化方式を選択してみてください。

 

まとめ

Oracle Database では、SQL*Net 通信を暗号化してネットワーク経由でやり取りされるデータを保護する仕組みとして、ネイティブ・ネットワーク暗号化（以下NNE）とTLSの2つの選択肢が用意されています。

19cからは、異なるユーザーに対してNNEとTLSを同時にサポートし、併用することも可能になりました。

NNEは構成がシンプルで導入しやすく、既存のリスナーをそのまま利用できる点が魅力です。一方、TLSは証明書を用いた認証機能を備えており、中間者攻撃などのリスクにも対応できる高いセキュリティ対策が行えます。

また、シーン別に分けると、以下のような選び方が考えられます。

  • まずは手軽に暗号化を導入したい場合や、既存システムへの影響を最小限に抑えたい場合はNNE
  • 高度なセキュリティ対策が求められる環境や、厳格な認証要件がある場合はTLS

それぞれにメリットがありますが、選択はシステムの要件や運用体制次第にも依るかと思います。なお使用にあたり、通信を暗号化する場合は必ず暗号処理によるオーバーヘッドが発生します。 AES-NI などのハードウェア支援による高速化も活用できますが、事前にパフォーマンスへの影響を十分に検証することが重要です。場合によってはルーターやネットワーク機器の設定の対策を利用するなど、総合的にご検討ください。

昨今では外部との連携やセキュリティ基準の厳格化により、通信の暗号化が求められるケースも増えているかと思います。ぜひ本記事の内容を参考に、自社システムに適したセキュリティ強化を進めてみてください。