データベースの設置場所および接続時の勘所：データベースセキュリティの基礎のキソ（2）

» 2003年08月30日 00時00分公開

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

　「第1回データベースセキュリティの基本的な考え方」では、データベースセキュリティの基本的な考え方とセキュリティ要素を階層化した場合のネットワークレイヤー以下の部分、つまり、物理的な設置場所などのセキュリティ要素について説明した。

　今回は、ファイアウォール機能などの実際のネットワーク構築の現場において必要になる、データベースの設置場所およびネットワーク接続時の勘所を説明する。ファイアウォールに関する具体的な設定方法などの詳しい解説などについては、「【連載】ファイアウォール運用の基礎」などを併読されることをお勧めする。

データベースはネットワーク上のどこに置くべきか？

　一言でいうと、データベースは、内部ネットワークに設置し、プライベートアドレスを設定するとセキュリティを高めることができる。データベースへの不特定多数からのアクセスを防ぐことがネットワークにおけるセキュリティ対策の基本。そのうえで、特定のサーバとの通信についてのセキュリティ対策を行うことによって、さらにセキュリティを高めることができる。通信経路でのセキュリティ対策については、次回以降のOracle Advanced Securityの機能の説明の際に紹介することとする。

　一般的に、インターネット上のECサイトなどでOracleなどのデータベースを利用する場合に、多くは図1のようなネットワークになるだろう。ただし、ネットワーク図を見ただけでは、そのネットワークに設置されているデータベースが危険か安全かを詳しく知ることは難しいだろう。

図1 一般的なECサイトのネットワークでは、外部とのインターフェイスにファイアウォールを立てる

　通常、ファイアウォールの内部にデータベースを設置した方がよいということがよくいわれる。これは内部ネットワーク（DMZの内側のネットワーク）にもファイアウォールが設置されている場合にデータベースの保護として意味があるのだ。その理由として、DMZと内部ネットワークの通信においても、ファイアウォールによって守られていることがあるからなのだ。

コラムサーバの要塞化とファイアウォール

Oracleデータベースのサーバの要塞化については、次回（第3回）に詳しく説明する予定だが、ファイアウォールを導入した場合についても、ファイアウォールで許可されたサービスについては、最終的にサーバ側で処理を行わなくてはならないため、サーバの要塞化作業が必要となる。

セキュリティ対策は、ファイアウォールが許可しているサービスだけに施されるものではない。サーバに適切なアクセスコントロールとセキュリティパッチの適用などのセキュリティ対策を行っておくことで、極端にいえばファイアウォールを利用しないでも、ネットワーク上にあるOracleデータベースのセキュリティを保つことができる。

筆者も「サーバの要塞化」を中心としたセキュリティの考え方を先輩に教えていただいたときには、若干ではあるが、衝撃を受けた。バッファオーバーフローを利用した攻撃の多さは、SecurityFocus.comの脆弱性データベースなどを見ていただくと実感できるのではないだろうか。

図2 SecurityFocus.com（http://www.securityfocus.com）のセキュリティ報告一覧例

ファイアウォールの導入は本当に必要か？

　よくコンサルティングの現場などで、顧客から「データベースを導入する場合には、やっぱりファイアウォールを導入しないといけないですかね？」と聞かれることがある。そもそも、ファイアウォールの導入に関しては、3つの選択肢が考えられる（図3-1〜図3-3参照）。これは、システムの規模や予算によって考え方が違ってくるはずだ。ただし、どの選択肢を選んでも間違いではない。予算が許せば、DMZと内部ネットワークそれぞれにファイアウォールを設置することは可能だが、システム構築において常に付きまとうのがコストの制約。セキュリティ要素についても、その制約を逃れることはできない。

図3-1 内部ネットワークにもファイアウォールを設置する場合

図3-2 DMZの外側にファイアウォールを設置する場合

図3-3 ファイアウォールを設置しない場合

　たとえファイアウォールを設置しても、ファイアウォールが通信を許可しているサービスに対するバッファオーバーフロー攻撃までを防ぐことはできない（表1）。ファイアウォールの構築方法はいくつかあるが、Oracleデータベースは、本記事の冒頭でのポリシーに従って内部ネットワークにプライベートアドレスを利用して構築することをお勧めする。そのうえで、Oracleデータベースのネットワーク機能を利用したセキュリティ対策を行うことで、よりセキュアなOracleデータベースを構築することができる。

	ファイアウォールの設置場所
	DMZおよび内部ネットワーク	DMZ	設置なし
DMZへの不正アクセス	○	○	×
DMZからの不正アクセス	○	×	×
バッファオーバーフロー攻撃への対応^＊1	×	×	×

^＊1ここでは、ファイアウォールの有効範囲を表しているが、それがそのままセキュリティ上の危険度につながるものではない。

表1 ファイアウォール導入方法別のファイアウォールの有効範囲

コラム内部ネットワーク用ファイアウォール

DMZセグメントと内部セグメントの間に置かれるファイアウォールを指す。内部ネットワーク用ファイアウォールの設置は、コスト的な負担になるため、積極的に提案されるソリューションではないが、機能としては、DMZセグメントからの通信について、許可されたホストのみの通信を許可するというものだ。

では、許可されないホストから通信が実行された場合はどういう意味になるだろうか？　それは、当該ホストから管理者が間違えてOracleデータベースにアクセスしてしまったケースかそのサーバが不正侵入されてしまった場合などが考えられる。内部ネットワーク用ファイアウォールの設置はこういった行為を防ぐのに有効だ。

さらに、社内ネットワークと接続されている場合などは、社内のほかのネットワークセグメントからの接続について保護を行う場合にも有効なソリューションになる。

ただし、この場合も許可されたホストに対して不正侵入があった場合には、正常なアクセスか不正なアクセスかの区別をファイアウォール自身では行うことができないので、その点については、DMZ上に設置されている各サーバの要塞化を行うなどセキュリティ対策を十分に行う必要がある。

いい換えれば、DMZ上に設置されているサーバについて正しくセキュリティ対策を行っておかないと、そのサーバ経由でOracleデータベースが危険にさらされるということを常に頭に入れておかなければならない。

コラム　Oracleデータベースのメンテナンスライン

インターネットデータセンターなどにOracleデータベースを設置する場合に、そのメンテナンスをどうやって行うかで悩むことが時々ある。社内のサーバルームなどにOracleデータベースが設置されていれば、直接コンソール（ディスプレイ）を叩いて作業を行うことができるが、インターネットデータセンターに設置されているような場合は、設置スペースが限られているラック内にコンソールを設置できない場合がほとんどだ。

Oracle8i以降のOracle管理系ツールは（インストーラも含めて）X Window環境を利用するものが結構多いのが現状だ。Oracleデータベースが、インターネットデータセンターの内部セグメント上に構築されているケースが多く、X Window環境の構築に結構苦労することが多い。

このようなメンテナンスラインの確保についても、ファイアウォールのネットワークデザイン同様にさまざまな対応が可能かと思うが、筆者は、X Windowのセキュリティ対策を行うよりもメンテナンスラインとしてインターネットVPNを利用することで対応することが多い。

Oracleデータベースにおけるネットワーク接続時の対策

　Oracleデータベースのネットワーク上での設置場所が決まれば、あとはネットワークの設置だ。Oracleデータベース（サーバ）とアプリケーションサーバ（クライアント）の通信イメージは、図4のようになる。リスナーとは、ネットワーク経由でOracleクライアントからの接続要求の処理を行う。なお、リスナーでのセキュリティ対策については、基本的には、DMZおよびほかの社内ネットワークなどからの不正侵入などに対する有効な対策になる。

　まず、Oracleネットワーク設定の基本は以下のとおり。

図4 Oracleクライアントからのアクセスイメージ（基本的には、リスナーがネットワーク経由での問い合わせを処理する）

●リスナーポートを変更する（推奨）

　通常、リスナーは、1521番ポートを利用しているが、このデフォルトポートは広く利用されているため、そのポートを変更することで機械的に情報収集を行うようなツールに対して有効な情報が提供されるのを一時的ではあるが防ぐことができる。

図5 リスナー設定例（デフォルトポート番号の変更）

●リスナーにパスワードを設定する

　リスナーはリモートから制御を行うことができるため、リスナーについてパスワードを設定することで、外部からのリスナーに対する攻撃について、セキュリティを高めることができる。

　これにより、リスナーの起動や停止の際には必ずパスワードの入力が必要になる。ただし、リスナーの状況を確認するSTATUSコマンドは、パスワード設定後もパスワード入力なしに確認することができる。パスワード設定LSNRCTLコマンドでリスナー管理メニューを起動後、CHANGE_PASSWORDコマンドを利用すればパスワードを設定することができる。正しくパスワードが設定できると、listener.oraに「PASSWORDS_LISTENER」というパラメータが追加される。パスワードは、暗号化されているため、エディタなどでは確認することはできない。

図6 リスナーへのパスワード設定

　ここでは、パスワードを入力せずにリスナーを停止され、そのときのエラーを表示している。

図7 パスワードを設定したリスナーの管理例（パスワード認証によるエラー）

●IPアドレスによる接続の制限

　基本的に内部ネットワークにファイアウォールを設置していない場合などは、DMZ上のどのサーバからもリスナーへの接続が可能な状態になっている。先ほども説明したが、内部ネットワークを守るためにファイアウォールなどを入れる余裕がない場合は、DMZへの侵入がすなわちリスナーへのアクセスを意味する。

　IPアドレスによる制御を行うことで、DMZ上やほかの社内ネットワークの許可しないサーバやクライアントからの接続を制限することができる。昨年公開された「Oracle Net Listenerに対する潜在的なDoS脆弱性」の対応策としてIPアドレスによる接続の制限が指示されているので、この機能については、概要だけでも知っておく必要がある。

　この設定は、Oracleのバージョンによってファイルが異なっている。Oracle 8.1.7以前については、$ORACLE_HOME^＊2/network/admin/protocol.ora、Oracle 9.0.1以降は$ORACLE_HOME/network/admin/sqlnet.oraになる。この設定を行った場合、必ずリスナーを再起動する必要がある。

図8 IPアドレスによるアクセス先の制御（sqlnet.ora）

^＊2$ORACLE_HOMEは、Oracleインストール時に設定される環境変数になるので、インストール環境ごとに異なるので、それぞれのインストール先ごとに読み替えるよう願いたい。ディレクトリ名をデフォルトから変更することで、攻撃者が情報の解析などを行うための時間を稼ぐこともできるというメリットがある。ささいなことだが、デフォルト設定を変更するということは、セキュリティ対策の中でも有効な対策だと思う。

　いかがだっただろうか、今回の記事を読むことで、効率的にセキュアなOracleデータベースのネットワーク構築の知識と配置方法およびDMZやほかの社内ネットワークからのOracleデータベースへの通信部分についてのセキュリティ設定の必要性を理解することができるかと思う。

　特に、リスナーのIPアドレスによる接続サーバの制限については、Oracleデータベースを社内システム用にのみ利用している環境においても、情報の内部漏えいをコストを掛けずに防ぐことができるものとして理解できると思う。後半部分のOracle Net Serviceのセキュリティ対策については、今回紹介したもの以外にもいくつかの方法があるが、今回は、あえてその中でも必要最低限のものを紹介した。さらに、詳しい情報については、Oracle Technology Network Japan上でOracleデータベースのオンラインマニュアルなどをご覧いただくことで、詳細情報を得ることができるだろう。

　次回は、Oracleデータベースの導入および運用時の基本的なセキュリティ対策について説明する。

「第1回」へ

「第3回」へ