「第4回Oracleデータベースで活用したい『データの保護』と『暗号化』」では、Oracleデータベースの暗号化機能を利用した保存データの暗号化について説明した。今回は、データベース監査つまり保存データを監視するための機能について紹介する。
データベース監査の効果とは
なぜ、データベース監査を行うのだろうか？ 昨今、顧客情報保護の重要性が叫ばれており、社内のユーザーからの不正行為が顧客情報流出の原因の大部分を占めているという報告もあり、データベース監査は社内向け侵入検知システム（IDS）のような位置付けとなり得るということがあるためだ。
また、データベース監査の利用効果として、悪意を持った社内ユーザーなどのデータベースへの不正な動作を監視（記録・統計）するとともに、データベース監査しているということを社内的にアナウンスするだけで、ある程度の抑止効果も同時に生むことが考えられる。≪
●Oracleデータベースによる監査の対象
Oracleデータベースでは、データベースに対するアクセスや更新などのさまざまなアクションを記録する監査機能が提供されている。その監査対象として、以下のような分類で行うことができる。
- 文監査（特定のSQL文の監査を個別に設定）
- システム権限監査（90種類以上のシステム権限を個別に設定）
- オブジェクト監査（特定のオブジェクトに対するSQL文の実行を監査）
さらに、これらの対象ごとに以下のような設定も併せて行うこともできるため、用途に合った監査を行うことができる。
- 監査する対象として特定のユーザーを設定する、またはすべてのユーザーを設定する
- 同じSQL文が実行された場合、セッション単位で1度のみ監査を行う、またはSQL文ごとに監査する
- 監査を行う場合、成功時のみに管理者へ通知する、または失敗時のみ、あるいは両方の場合通知することも可能
また、Oracleデータベース監査機能には、Oracle8i以前から提供されている「データベース監査」とOracle9iから導入された「ファイングレイン監査」があるため、後ほど詳しく紹介することにする。
| 機能 | 概要 |
|---|---|
| データベース監査 | オブジェクトレベル（表・ビューなど）監査を行う。 |
| ファイングレイン監査 | Oracle9i Database Enterprise Editionでのみ利用できる機能。オブジェクトに登録されているデータの値を基に監査を行うことができる。 |
| 表1 データベース監査とファイングレイン監査の違い | |
では、基本的なデータベース監査について説明しよう。
データベース監査の進め方
まず、データベース監査を進めるに当たって決めなければいけないのが、何のためにデータベース監査を実施するのか、という監査の目的になる。では、以下のフローに従いその進め方を説明していく。
●データベース監査の目的を明確化する
むやみやたらにデータベース監査を行っても結局は意味のないものになってしまうため、目的を明確にすることで不必要なデータベース監査を行わずに済むことになる。結果として作業全体の時間とコストを短縮できる。
では、必要なものだけを監査するにはどんな点に注目すればよいのだろうか。例えば、Webサーバのログを見るときには、成功したものではなく、エラーが起きたものを調査することで不正アクセスの有無を確認できる。データベース監査についても同様のことがいえるだろう。
まず初めに、扱っている情報の重要性やデータの性質によって何を監査（監視）するかを決定する必要がある。例えば、顧客情報などの管理システムなどについては、詳細なデータベース監査を行う必要があるが、システム全体のログをデータベースに延々と書き込んでいるログテーブル（オブジェクト）については、事細かに確認する必要はないなどのように、監査する目的として重要なことは何かをしっかりと見極めておく必要がある。
●データベース監査対象の決定
データベース監査の目的が決定できたら、次はデータベース監査を行う対象を決定する。ここでは、管理ユーザーの設定方法と各オブジェクトに対するデータベース監査方法について説明する。
・管理ユーザーのための設定
データベース管理者は、データベースに関するさまざまな操作を行うことができる。そのため、一般ユーザーとは別に管理ユーザーの監査を行うことができる。
例えば、通常、データベースの起動・停止などの情報については、$ORACLE_HOME/admin/ORALCE_SID.logに書き込まれる。
※注意
$ORACLE_HOMEについては、Oracle9iのインストール環境ごとに異なるので、環境ごとに読み替えていただきたい。
また、Oracle9iデータベースではデフォルトであるSYSユーザーとして接続したセッションは、AUDIT_SYS_OPERATIONS初期化パラメータを利用することで、OSに書き込むことができる。
AUDIT_SYS_OPERATIONS = TURE
※注意
デフォルトは、FALSEになっている。
・各オブジェクトに対するデータベース監査設定方法
データベース監査を行う場合、まず監査が可能な状態にデータベースを設定しなければならない。そのうえで、監査に必要なSQL文を発行することで監査ログの取得が可能となるため、以下の手順で設定する必要がある。
まず、各オブジェクトに対するデータベース監査のためのパラメータについて説明する。Oracle9iデータベースのデータベース監査には、特定のオブジェクトに対する監査と権限やSQL文に関する権限がある。以下はその利用権限に関するパラメータである（表2）。
| 初期化パラメータ | 詳細 |
|---|---|
| AUDIT_TRAIL | データベース監査を使用可能・禁止にする。 |
| AUDIT_FILE_DEST | AUDIT_TRAIL=OSが設定されている場合、データベース監査が保存されるディレクトリを指定する。 |
| 表2 利用権限に関するパラメータ（初期化パラメータ） | |
※注意
初期化パラメータAUDIT_SYS_OPERATIONS、AUDIT_TRAIL、AUDIT_FILE_DESTは、静的パラメータのため、データベースの再起動が必要である。
例えば、監査ログを/var/oracle/logディレクトリ以下に書き込む場合は、以下のようにする。
AUDIT_FILE_DEST=/var/oracle/log
・監査の使用可能および使用禁止
AUDIT_TRAILパラメータは、データベース監査の使用可能および使用禁止の設定を行うことができる。この設定を行わないとデータベース監査を行うことができない。
また、このパラメータは、監査内容の書き込み先を指定する場合にも利用される。例えば、その設定値がDBになっている場合は、データベースの監査証跡表（スキームSYS.AUD$表）に監査レコードが格納される。
| 設定値 | 詳細 |
|---|---|
| DB | データベース監査を使用可能にする。データベース監査は、データベース内に保存される。 |
| OS | データベース監査を使用可能にする。データベース監査は、 オペレーティングシステムのファイルとして保存される。 |
| NONE | データベース監査を使用禁止にする。 |
| 表3 AUDIT_TRAILパラメータ | |
※注意
監査をするにはAUDIT SYSTEM権限が必要である。
例えば、OSファイルシステム上に監査ログを書き込む場合は、以下のようにする。
AUDIT_TRAIL=OS
・そのほかのオプション
データベース監査を行うに当たって、いくつかのオプションを指定することができる。代表的なものは、監査ログの取得タイミングと取得単位がある。なお、これらパラメータについては、監査オプション設定時に利用するオプションとなる。
（1）監査ログ取得タイミング
成功時に監査ログを取得するか、失敗時に監査ログを取得するかを設定するパラメータがある。WHENEVER SUCCESSFULを指定するとSQL文が成功した場合のみをデータベース監査対象とする。
WHENEVER NOT SUCCESSFULを指定すると、SQL文が失敗またはエラーが発生した場合のみデータベース監査の対象となる。
例えば、成功時のみ監査ログを取得する場合は、以下のようにする。
AUDIT SELECT ON CUSTOMER.CUSTOMER_MAIN WHENEVER SUCCESSFUL;
（2）監査ログ取得単位
監査ログの取得単位を設定できるパラメータがある。BY SESSIONは、同一セッション内のすべてのSQL文が単一レコードに書き込まれる。BY ACCESSを指定すると、アクセスごとにレコードが書き込まれる。
例えば、アクセスごと（SQL文が投げられるごとに）に監査ログをまとめる場合は、以下のようにする。
AUDIT SELECT ON CUSTOMER.CUSTOMER_MAIN BY ACCESS
データベース監査の実際の設定
先ほど説明したようにデータベース監査を可能な状態にするには、AUDIT_TRAILパラメータによって監査可能にした後で、AUDITコマンドを利用して監査を開始する必要がある。ここでは、実際の設定方法について、代表的な例を挙げながら説明しよう。
●ユーザーによる問い合わせ
まず、特定のユーザーの問い合わせについてデータベース監査を行う方法を説明しよう。この場合の特定のユーザーとは、Oracle9iデータベース内でのユーザーになるため、データベースにアクセス権限のあるユーザーやアプリケーションサーバ経由などでアクセスを行うユーザーを指定することで、特定のユーザーの問い合わせ内容を確認することができる。
例えば、ユーザーSCOTTがデータベースに新しい表が追加されたことを監査するには、以下のようにする。
AUDIT CREATE TABLE BY SCOTT;
BY SCOTTについては、ほかのユーザー名に置き換えることができる。さらに、複数のユーザーの設定が必要な場合は、以下のように「BY ユーザー名,ユーザー名」と記述する。
AUDIT CREATE TABLE BY SCOTT,BOB;
●オブジェクト（表）に対する問い合わせ
非常に重要な顧客情報テーブルなどのある特定のオブジェクト（表およびビュー）へのアクセスを監査するような場合は、監査の対象にオブジェクト（表）を指定する必要がある。
例えば、スキーマCUSTOMERのCUSTOMER_MAIN内のすべての問い合わせのSQL文についてデータベース監査を行う。
AUDIT SELECT ON CUSTOMER.CUSTOMER_MAIN
スキーマCUSTOMER内のCUSTOMER_MAIN内のすべての問い合わせが正常に終了したすべての問い合わせのSQL文についてデータベース監査を行う。
AUDIT SELECT ON CUSTOMER.CUSTOMER_MAIN WHENEVER SUCCESSFUL;
●デフォルト監査オプション
とにかく、いちいちオブジェクトやユーザーなど気にせずデータベース上のアクションに対してデータベース監査を行いたい場合は、監査デフォルトオプションを指定する。ただし、データベース監査は、先ほども説明したように、必ず監査ログの書き込みをOSファイルまたはデータベース上で行うため、サーバに対して負荷が掛かる。そのため設定時には設定内容をよく吟味する必要があるだろう。
例えば、表を作成した場合、ALTER文、INSERT文、UPDATE文が自動的にデータベースの監査対象になる。
AUDIT ALTER,INSERT,UPDATE,DELETE ON DEFAULT;
●監査コマンドの有効化および無効化
一度設定した監査コマンドを変更する必要があるかもしれない。例えば、対象とするオブジェクトの追加や削除がそれに当たる。その場合、NOAUDITコマンドを利用して監査を停止する（監査の開始には、AUDITコマンドを利用する）。
例えば、スキーマCUSTOMERのCUSTOMER_MAIN表の更新に対してデータベース監査を行う。
AUDIT UPDATE ON CUSTOMER.CUSTOMER_MAIN
このデータベース監査オプションを無効にするためには、以下のような設定を行う。
NOAUDIT UPDATE ON CUSTOMER.CUSTOMER_MAIN
※注意
NOAUDIT文を実行しても監査オプションの設定が解除されるだけで、監査機能自体が使用禁止になるわけではない。データベース監査機能自体を完全に停止するには、初期パラメータAUDIT_TRAILの設定を変更する必要がある。
すべての監査を使用禁止にするには、以下のような設定を行う。このコマンドにより、すべての監査コマンドが無効になる。
NOAUDIT ALL;
監査内容の確認
データベースに監査内容が書き込まれる場合は、SYS.AUD$に書き込まれる。ここには、さまざまな情報が書き込まれるため、具体的な表示を行うためのいくつかのビューを作成する必要がある。このビューは、CATALOG.SQLおよびCATAUDIT.SQLスクリプトから作成することができる。
| ビュー | 詳細 |
|---|---|
| AUDIT_ACTIONS | 監査のアクション・タイプ・コードが記述される。 |
| DBA_AUDIT_TRAIL | 監査が指定されているすべてのエントリーが表示される。 |
| DBA_STMT_AUDIT_OPTS | すべてのシステム監査オプションが表示される。 |
| DBA_PRIV_AUDIT_OPTS | すべてのオブジェクトの監査オプションが表示される。 |
| DBA_AUDIT_OBJECT | すべての監査レコードが表示される。 |
| 表4 監査内容確認用ビュー | |
例えば、以下に記したように、監査結果をOSファイルに書き出したものになる。初期化パラメータAUDIT_TRAIL=OSで設定した場合の結果となり、ここでは、SYSスキーマのDBA_USERSのSELECT操作に対して監査を設定し、SYSTEMユーザーが当該オブジェクトに対してSQL文を実行した場合の結果になる。
select * from dba_users; ======================================================================== [ora920@localhost oracle]$ cat ora_13484.aud Audit file /var/oracle/ora_13484.aud Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.1.0 - Production ORACLE_HOME = /usr/oracle/product/9.2.0 System name: Linux Node name: localhost.localdomain Release: 2.4.9-e.9.30ml Version: #1 Mon Jan 20 19:24:39 JST 2003 Machine: i686 Instance name: home1920 Redo thread mounted by this instance: 1 Oracle process number: 14 Unix process pid: 13484, image: oracle@localhost.localdomain (TNS V1-V3) Mon Feb 23 01:39:29 2004 SESSIONID: "112" ENTRYID: "1" STATEMENT: "7" USERID: "SYSTEM" TERMINAL: "pts/1" ACTION: "103" RETURNCODE: "0" OBJ$CREATOR: "SYS" OBJ$NAME: "DBA_USERS" SES$ACTIONS: "---------S------" SES$TID: "1874" OS$USERID: "ora920"
ファイルグレイン監査
いままで説明してきたOracle8iデータベースまでのデータベース監査機能は、オブジェクト単位（ユーザー単位）でしかデータベース監査対象を設定することができなかった。Oracle9iデータベースから新しくファイングレイン監査が実装されたことで列単位およびデータ値によるハンドリングを含め、データベース監査の対象とすることができるようになった。
※注意
ただし、ファイングレイン監査は、Oracle9i Enterprise Editionのみで利用できる機能である。
コラム データベーストリガを利用した監査機能
Oracle9iデータベース以前でもデータベーストリガを利用したログ取得はよく利用されていた。格納されている値に変更があった場合に、ログを書き込むトリガなどは筆者実際にOracleに触り始めのころ作ったことがある。
例えば、以下のデータベーストリガは、顧客氏名の変更があった場合のみ、特定の表にデータを書き込むトリガになっている。余談ではあるが、デバッグにかなりのクセのあるPL/SQLであるが、データベースのパフォーマンスを有効に使うという意味では、非常にいいツールである。Java系のアプリケーションでもPL/SQLプロシージャをキックするような使い方をしているサイトもある。
CREATE TRIGGER AUDIT_CUSTOMER_MAIN AFTER INSERT OR DELETE OR UPDATE ON CUSTOMER_MAIN FOR EACH ROW BEGIN IF (:NEW.CUSTOMER_NAME != OLD.CUSTOMER_NAME) THEN INSERT INTO AUDIT_CUSTOMER VALUES (:CUSTOMER_ID,:OLD.CUSTOMER_NAME,:NEW.CUSTOMER_NAME); ENDIF; END;
ファイングレイン監査の利用については、以下の図のような流れになる。
●ファイングレイン監査の設定
ファイルグレイン監査の設定の流れについては、図4をご覧いただければ大体流れをつかむことができると思う。概念は非常にシンプルだが、単純なSQL文ではなくPL/SQLパッケージを使うため、ちょっととっつきにくい部分があると思う。以下に記したファイングレイン監査の設定には、DBMS_FGAパッケージを利用する。たった4種類しかないのか？ という方もいるかもしれないが、パラメータが多いため悩むこともあるかもしれない。4つのプロシージャはそれぞれ先ほどのデータベース監査と突き合わせて見るとよいだろう（ほぼ1対1の関係になっている）。
| プロシージャ名 | 詳細 |
|---|---|
| DBMS_FGA.ADD_POLICYプロシージャ | 監査ポリシーを追加する。 |
| DBMS_FGA.DROP_POLOCYプロシージャ | 監査ポリシーを削除する。 |
| DBMS_FGA.ENABLE_POCLCYプロシージャ | 監査ポリシーを有効化する。 |
| DBMS_FGA.DISABLE_POLICYプロシージャ | 監査ポリシーを無効化する。 |
| 表5 DBMS_FGAパッケージ | |
●ファイングレイン監査の追加
ここでは、ファイングレイン監査の追加方法について説明しよう。初めにDBMS_FGA.ADD_POLICYプロシージャを用いて監査ポリシーを設定することで利用できる。以下の例では、「PEFR_CODE=12（東京都）」の地域だけを監査の対象とする場合の指定方法を表す。この場合、「PERF_CODE=12」以外の地域は監査の対象から除外される。
DBMS_FGA.ADD_POLICY( OBJECT_SCHEMA => 'CUSTOMER', OBJECT_NAME => 'CUSTOMER_MAIN', POLICY_NAME => 'AUDIT_CUSTOMER_MAIN', AUDIT_CONDITION => 'PREF_CODE = '12' AUDIT_COLUMN => 'CUSTOMER_ID');
※注意
AUDIT_COLUMNについては、SELECT句の条件によって、監査対象になる場合とならない場合がある。
【参考】監査対象となるSQL文と対象とならないSQL文
●監査対象となるSQL文
AUDIT_COLUMNに指定してあるCUSTOMER_IDとSELECT句の指定文字列*（すべてのカラム）が一致するため、監査対象となるSQL文。
SELECT * FROM CUSTOMER_CUSTOMER_MAIN WHERE PREF_CODE = 12
●監査対象とならないSQL文
先ほどの例とは異なり、AUDIT_COLUMNに指定してあるCUSTOMER_IDとSELECT句が一致しないため、監査対象から除外されるSQL文。
SELECT CUSTOMER_NAME FROM CUSTOMER_CUSTOMER_MAIN WHERE PREF_CODE = 12
この場合、カラムがCUSTOMER_IDであれば、監査対象となる。
●ファイングレイン監査ログの確認
通常のデータベース監査と同様にファイルグレイン監査によるログもOracle9iデータベース上に保存される。ファイングレイン監査の場合は、SYS.DBA_FGA_AUDIT_TRAILビューに保存され、そのビューを確認することで監査記録を確認することができる。
Oracle9iデータベースのデータベース監査機能の大枠が理解できただろうか。データベース監査機能は、データベースの大小に関係なく、保存されているデータの重要性によっては、大きな効果を発揮するものになるかもしれない（ただし、ファイングレイン監査は、Enterprise Editionライセンスユーザーが対象となることと、通常のデータベース監査で事足りることが多いので、利用される機会は非常に少ないだろう）。
小規模サーバの場合でも顧客情報を何十万人分も扱っている場合は、導入を検討してもよいかもしれない。さらに、詳しい情報については、「Oracle Technology Network Japan」上でOracleデータベースのオンラインマニュアルなどを見ることで、詳細情報を得られるだろう。Oracle9iの幅広いセキュリティ機能の中で今回紹介したデータベース監査についても理解しておくことで、システム構築の際により効率的にOracle9iデータベースを活用いただけるものと考えている。
次回は、Oracle9iデータベースの通信部分の暗号化機能を紹介したい。
Copyright © ITmedia, Inc. All Rights Reserved.