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

　「第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データベースを構築することができる。

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）

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

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

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