Oracleサーバに対する通信経路の暗号化：データベースセキュリティの基礎のキソ（6）

» 2004年05月21日 00時00分公開

[篠田道明，インターネット総合研究所]

　「第5回内部犯行を抑制するデータベース監査」では、Oracle9iのデータベース監査機能を利用した保存データの監査方法について説明した。この対策を行ったうえで、適正な運用（ログの保存なども含めて）が行われているのであれば、最近数カ月の間に頻繁に公表されている顧客情報の流出に対して、限定的ではあるが、抑止力という意味で、かなり有効なソリューションであると筆者は考える。Yahoo!BBをはじめとする一連の顧客情報流出事件は、セキュリティという視点からデータベースプラットフォームを見つめ直すよいきっかけになると思う。今回は、さらに一歩進めてOracle9iデータベースの通信部分における暗号化について触れてみたいと思う。

※通信機能の暗号化機能および符号化機能を利用する場合は、Oracle9i Enterprise Editionに加えて、Oracle Security Optionの購入が必要になる。ライセンスなども含めて詳しくは、Oracleソウトウェアベンダにお問い合わせください。

通信経路の暗号化の必要性

　Oracle9iデータベースの通信における暗号化がなぜ必要なのだろうか？例えば、図1のような場合を考えていただきたい。悪意を持ったユーザーが、ネットワーク経路上に設置されている機器に対して物理的にアクセスできる場合、通信内容が盗聴されてしまう可能性がある（例えば、オフィススペースにネットワークスイッチが設置されている場合など）。

図1 クライアント−Oracle9iサーバ接続の場合

　さらに、図2のようなWebシステムにおいても、WebサーバとOracle9iサーバが接続された同一ネットワーク上にプロミスキャスモードで設定されているネットワーク機器が存在する場合、そこから悪意を持ったユーザーが通信内容を盗聴することができる（例えば、施錠されていないマシンルームにネットワークスイッチが設置されている場合など）。

※プロミスキャスモードについては、「5分で絶対に分かるIDS」を参照。プロミスキャスモードとは、通常は受信せずに捨てられてしまうパケットを受け取ることができるようにしたネットワークインターフェイスカード設定のことを指す。

図2 Webサーバ−Oracle9iサーバ接続の場合

　ISPの情報漏えい事件の原因として指摘されているが、社内にこそ悪意を持ったユーザーが常に存在するという性悪説的な考えを持って、顧客情報を取り扱う必要がある。今後、顧客情報の取り扱いが厳重になった場合に、現状で一般的に想定されているようなメディアなどの持ち出しといった被害パターンがより複雑になる可能性もあるだろう。物理的にOracle9iデータベースがしっかりと守られた状態では、こういった作業は非常に労力と時間がかかる。社内での情報管理が厳しくなると、情報へのアクセスもより巧妙となり、上記のようなネットワーク傍受の手法を利用した顧客情報の抜き取り行為の可能性も出てくる。

　攻撃は、常にシステムの弱い部分が狙われるものだ。例えば、オペレータとWebサーバの通信はすべて128ビットSSLで暗号化をされているが、Oracle Net Serviceを利用した通信を行っているWebサーバとOracle9iサーバの間で何ら対策が行われていない場合には、後者が狙われやすい。管理者も人間なので、完全なものを作り出すことはできないが、想定されるリスクはできるだけ低く抑える必要がある。それが企業におけるセキュリティ対策のあるべき姿であると筆者は考えている。

Oracle Net Servicesだけではダメ

　デフォルトでインストールされたOracle9iデータベースでは、Oracle Net Servicesを利用してSQL Plusでクライアントから通信した場合、データは基本的に平文で流れる。この場合、前述したように、悪意のあるユーザーに対して無力である。図1や図2のように通信経路上で傍受が可能な場合は、SQL文や出力結果が盗聴されてしまう可能性がある。もちろん、そのような環境がすべて危険という意味ではなく、リスクが存在するという認識を持っていただければ幸いだ。

図3 SQL Plusによる通信（暗号化前）

　ネットワーク経由でのOracle 9iデータベースとの通信については、いくつかのリスクがあることを理解いただけたと思う。それらのリスクを低減するためにOracle9iデータベースでは、Oracle Advanced Securityオプションが用意されている。

※Oracle9i Standard Editionをご利用の場合は、Oracle Advanced Securityオプションを利用できないが、本連載の第1回から第5回までの基本機能を利用することでセキュリティリスクを低減していただきたい。

　Oracle Advanced Securityオプションを利用して暗号化設定を行った場合、SQLクエリを実行しても結果は暗号化されている。このため、パケットキャプチャツールを利用してもパケットを解析できない。

図4 SQL Plusによる通信（暗号化後）

Oracle Advanced Securityオプション

　Oracle9i Enterprise Editionとの通信において、Oracle Advanced Securityオプションを利用することで、通信データの暗号化機能と通信データの符号化機能を利用できる。通信データの暗号化は通信経路での盗聴による機密情報の流出を防ぐものであり、通信データの符号化は通信経路上でのデータの改ざんを防ぐものである。

図5 暗号化と符号化

　まず、暗号化から見ていこう。

●通信データの暗号化

　鍵の暗号化は、共通鍵を用いた暗号方式と公開鍵を利用した暗号方式を利用できるが、ここでは、共通鍵暗号方式を使った暗号化の通信設定について説明したい。共通鍵を利用した暗号化通信では、RC4、DES、3DES、AESの各暗号方式が利用できる。


暗号方式	詳細
RC4	40ビット、56ビット、128ビット、256ビットの鍵を利用できる。
DES	40ビット、56ビットの鍵を利用できる。
3DES	2つの鍵を使うものと3つの鍵を使うものを利用できる。
AES	128ビット、192ビットの鍵を利用できる。
図6 利用可能な暗号化方式

　暗号化の設定方法は、図7の手順で作業を行う。Oracle Net Servicesの設定ファイルは、デフォルトでインストールした場合、サーバ側もクライアント側も$ORACLE_HOME/network/admin配下のsqlnet.oraファイルだ。そして、LISTENERを再起動することで暗号化の設定が完了する。設定自体は非常にシンプルなので、手順をしっかり守れば暗号化の設定に失敗することはない。

図7 暗号化の設定手順

　暗号化通信の動作と使用する暗号鍵について、サーバ側パラメータとクライアント側のパラメータを以下のように設定する。

# SQLNET.ORA Network Configuration File: 
/usr/oracle/product/9.2.0/network/admin/sqlnet.ora
# Generated by Oracle configuration tools. 
SQLNET.ENCRYPTION_TYPES_SERVER= (RC4_256) 
SQLNET.ENCRYPTION_SERVER = requested 
SQLNET.CRYPTO_SEED = asldfkapw85si0mdsfpo8320480t832jas

図8 暗号化sqlnet.ora(サーバ側設定)

# SQLNET.ORA Network Configuration File: 
C:\oracle\ora92\NETWORK\ADMIN\sqlnet.ora
# Generated by Oracle configuration tools. 
SQLNET.ENCRYPTION_TYPES_CLIENT= (RC4_256) 
SQLNET.ENCRYPTION_CLIENT = requested 
SQLNET.CRYPTO_SEED = upoewir79q73423ifa723jijfiu9432

図9 暗号化sqlnet.ora(クライアント側設定)

また、それぞれの暗号化パラメータは以下のとおり。


パラメータ名	詳細
SQLNET.ENCRYPTION_SERVER = 要求動作	サーバ側がクライアント側に対して要求する暗号化の動作を指定する。
SQLNET.ENCRYPTION_CLIENT = 要求動作	クライアント側がサーバ側に対して要求する暗号化の動作を設定する。
SQLNET.ENCRYPTION_TYPES_SERVER =暗号化方法	サーバ側で利用する暗号化のアルゴリズムを指定する。暗号化アルゴリズムは複数設定することができ、通信可能な暗号化アルゴリズムが見つかるまで探す。図8では、RC4の256ビットの鍵の利用が指定されている。
SQLNET.ENCRYPTION_TYPES_CLIENT =暗号化方法	クライアント側で利用する暗号化のアルゴリズムを指定する。暗号化アルゴリズムは複数設定することができ、通信可能な暗号化アルゴリズムが見つかるまで探す。図9では、RC4の256ビットの鍵の利用が指定されている。
SQLNET.CRYPTO_SEED = 10〜70文字の乱数	この乱数を利用して暗号鍵が作成される。乱数文字列数は暗号鍵強度に影響する。
図10 暗号化パラメータの説明

　暗号化通信の動作には、通信先となるサーバ側の設定と通信元であるクライアント側の設定が必要である。それぞれの設定によっては、暗号化通信が行われない可能性があるので気を付けたい。図8および図9の場合は、双方ともREQUESTEDが指定されているため、クライアント側から暗号化通信が要求されて通信が行われる。


動作名	詳細
REJECTED	接続先から要求されても暗号化通信を行わない。
ACCEPTED	接続先から要求された場合に、暗号化通信を行う。この場合、接続先での設定がREQUIREDまたはREQUESTEDの場合に、暗号化による通信が行われる。
REQUESTED	接続先に暗号化通信を要求する。接続先の設定がREJECTED以外の場合は、暗号化通信を行う。
REQUIRED	接続先との通信は、必ず暗号化通信を行う。暗号化通信できない場合は通信を行わない。
図11 暗号化動作

●通信データの符号化

　Oracle Advanced Securityオプションでは、MD5とSHA1のハッシュアルゴリズムを利用して通信を符号化できる。符号化機能を利用することで、パケットの改ざんを防ぐことが可能だ。暗号化機能と一緒に利用することでよりセキュリティを高められる。

　共通鍵を利用した符号化通信のロジックを説明しよう。Oracle Advanced Securityオプションでは、MD5とSHA-1の符号化方式を利用することができる。符号化の設定方法は、設定するパラメータが異なっているものの、暗号化設定の作業手順とほぼ同じだ。

図12 符号化の設定手順

　Oracle Net Serviceの設定は、デフォルトでインストールしている場合、サーバ側もクライアント側も$ORACLE_HOME/network/admin配下のsqlnet.oraファイルで行う。暗号化と符号化を同時に行った場合の設定ファイルの例を以下に示す。

# SQLNET.ORA Network Configuration File:
/usr/oracle/product/9.2.0/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
 
SQLNET.ENCRYPTION_TYPES_SERVER= (RC4_256) 
 
SQLNET.ENCRYPTION_SERVER = requested 
 
SQLNET.CRYPTO_CHECKSUM_SERVER = required 
 
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (MD5) 
 
SQLNET.CRYPTO_SEED = asldfkapw85si0mdsfpo8320480t832jas

図13 符号化sqlnet.ora（サーバ側設定）

# SQLNET.ORA Network Configuration File: 
C:\oracle\ora92\NETWORK\ADMIN\sqlnet.ora
# Generated by Oracle configuration tools.  
 
SQLNET.ENCRYPTION_TYPES_CLIENT= (RC4_256) 
 
SQLNET.ENCRYPTION_CLIENT = requested 
 
SQLNET.CRYPTO_CHECKSUM_CLIENT = required 
 
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (MD5) 
 
SQLNET.CRYPTO_SEED = upoewir79q73423ifa723jijfiu9432

図14 符号化sqlnet.ora（クライアント側設定）

　符号化通信の動作と使用する符号化ロジックのパラメータには、サーバ側パラメータとクライアント側パラメータが存在する。


パラメータ名	詳細
SQLNET.CRYPTO_CHECKSUM_SERVER = 要求動作	サーバ側がクライアント側に対して要求する符号化の動作を指定する。
SQLNET.CRYPTO_CHECKSUM_CLIENT = 要求動作	クライアント側がサーバ側に対して要求する符号化の動作を設定する。
SQLNET.CRYPO_CHECKSUM_TYPES_SERVER =符号化方法	サーバ側で利用する符号化のアルゴリズムを指定する。符号化アルゴリズムは複数設定することができ、通信可能な符号化アルゴリズムが見つかるまで探す。図13では、MD5での符号化が指定されている。
SQLNET.CRYPO_CHECKSUM_TYPES_CLIENT =符号化方法	クライアント側で利用する符号化のアルゴリズムを指定する。符号化アルゴリズムは複数設定することができ、通信可能な符号化アルゴリズムが見つかるまで探す。図14では、MD5での符号化が指定されている。
SQLNET.CRYPTO_SEED = 10〜70文字の乱数	この乱数を利用して暗号鍵が作成される。乱数文字列数は暗号鍵強度に影響する。
図15 符号化パラメータの説明

　符号化通信の動作には、通信先となるサーバ側の設定と通信元であるクライアント側の設定が必要である。それぞれの設定によっては、符号化通信が行われない可能性があるので気を付けたい。


動作名	詳細
REJECTED	接続先から要求されても符号化通信を行わない。
ACCEPTED	接続先から要求された場合に、符号化通信を行う。この場合、接続先での設定がREQUIREDまたはREQUESTEDの場合に、符号化による通信が行う。
REQUESTED	接続先に符号化通信を要求する。接続先の設定がREJECTED以外の場合は、符号化通信を行う。
REQUIRED	接続先との通信は、必ず符号化通信を行う。符号化通信できない場合は通信を行わない。
図16 符号化動作

Oracle9iセキュリティ対策とは

　連載のまとめとして、過去5回の各回のセキュリティの勘所をまとめたいと思う。　「第1回データベースセキュリティの基本的な考え方」でも説明したように、セキュリティ対策については、より下のレベルでの対策を行うことで、より大きな対策を取ることができ、コスト自体を抑えることができる。また、「第2回データベースの設置場所および接続時の勘所」では、Oracle9iデータベースのネットワーク上でのセキュリティ対策やネットワーク設計時のポイントを説明した。物理的にOracle9iデータベースを守ることがセキュリティ確保の近道だ。また、「第3回 Oracleデータベース導入時のセキュリティ対策の基本」では、実際のOracle9iデータベースのインストール作業を参考にしながら、初期設定時に行うユーザーアカウントやデータベースオブジェクトにおけるセキュリティ対策を説明した。

　そして、「第4回 Oracleデータベースで活用したい『データの保護』と『暗号化』」では、Oracle9iデータベースに保存されているデータの暗号化やVPD（Virtual Private Database）機能を利用したデータ保護の方法について説明した。さらに、「第5回内部犯行を抑制するデータベース監査」では、Oracle9iデータベース利用におけるデータベース監査の重要性と監査ログの取得方法について説明した。今回も含めて6回の連載で、Oracle9iデータベースのセキュリティ対策の範囲について、ほぼ網羅したと筆者は考える。2004年4月5日に発売されたOracle10gデータベースなどの新しいバージョンがリリースされたとしてもセキュリティに対する基本となる考え方はほとんど変わらないので、この機会に各回を再読いただきたい。

図17 Oracle9iデータベースセキュリティ

　データベースの分野もオープンソース化の流れは確実に進んでいる。PostgreSQLやMySQLなどフリーのデータベースが、Webシステムに限らず業務システムにおいても、以前にも増して重要な役割を果たしつつある。このような流れの中で、「なぜOracle9iデータベースなのか」という問いに対して、「Oracle9iデータベースならばオープンソースのデータベースに実装されていない多くのセキュリティ機能を利用できるから」と答えたい。昨今の顧客情報流出に関する事後のコストからみれば、セキュリティという観点でOracle9iデータベースを導入することは、そんなに高価なものでもないだろう。ただし、Oracle9iデータベースを導入したからといって、決して安全だともいえない。正しいセキュリティ対策と運用がどんなデータベースプラットフォームでも必要なことを忘れないでいただきたい。

（今回で最終回となります。ご愛読ありがとうございました。）