Oracle 監査ログ保存はパフォーマンスにどれくらい影響するか

2015.06.01 株式会社システムインテグレータ

マイナンバー導入に向けてセキュリティ面に注目が集まっているが

今年導入が予定されているマイナンバーですが、その導入に伴いデータのセキュリティ面も、今後は更に注意しなければいけません。セキュリティ面に注目が集まる中、データの運用で大事な点の一つが「監査」の実施です。

監査の方法は様々ですが、有効な監査方法を実施しなければ意味がありません。アプリケーション側から制御をかけることも有効ですが、それではデータベースへ直接アクセスするのを防げません。そのため、データベースが提供する監査方法を利用する方法が考えられますが、データベースの更新などパフォーマンスの低下を懸念する方も多いことでしょう。

今回はOracleを例に挙げ、Oracleから提供されているいくつかの監査方法を用いて、各監査方法でどれくらいのパフォーマンスの違いが出るのかを検証していきます。

Oracle 監査ログ保存はパフォーマンスにどれくらい影響するか 1

図１：検証イメージ

Oracleが提供する監査について

Oracle提供してる代表的な方法と、それぞれの特徴は以下の通りです。

監査	標準監査	ファイングレイン監査	値ベース監査
説明	AUDIT_TRAIL初期化パラメータと、AUDITコマンドによる監査オプションの設定を行い、各監査証跡に書き込みを行います。	DBMS_FGAパッケージを使用して、任意の監査方針を設定します。	データベーストリガーを使用。データの変更を任意のテーブルに監査証跡として格納します。
特徴	指定した操作が行われると証跡を出力します。テーブルアクセス以外にも、様々なデータベース操作に対して監査を設定することが可能です。初期化パラメータの変更が伴うため、データベースの再起動が必要です。	指定条件のデータにアクセスがあると証跡を出力します。 SELECT・INSERT・UPDATE・DELETEに対してのみ設定可能です。監査対象としてテーブル名だけではなく、列や条件の指定ができます。	トリガーの起動きっかけになったDML文が実行されると証跡を出力します。トリガーの仕様上、INSERT・UPDATE・DELETEに対してのみ設定可能です。
取得情報 (抜粋)	・DBﾕｰｻﾞｰ名・OSﾕｰｻﾞｰ名・ｸﾗｲｱﾝﾄのﾏｼﾝ名・ﾀｲﾑｽﾀﾝﾌﾟ・影響を受けたｵﾌﾞｼﾞｪｸﾄ作成者・影響を受けたｵﾌﾞｼﾞｪｸﾄ名前・問合せのSQLﾃｷｽﾄなど・・・	・DBﾕｰｻﾞｰ名・OSﾕｰｻﾞｰ名・ｸﾗｲｱﾝﾄのﾏｼﾝ名・ﾀｲﾑｽﾀﾝﾌﾟ・表/ﾋﾞｭｰの所有者・表/ﾋﾞｭｰの名前・問合せのSQLﾃｷｽﾄ・ﾌｧｲﾝｸﾞﾚｲﾝ監査ﾎﾟﾘｼｰ名など・・・	・DBﾕｰｻﾞｰ名・ﾀｲﾑｽﾀﾝﾌﾟ・(DDL)対象ｵﾌﾞｼﾞｪｸﾄ所有者・(DDL)対象ｵﾌﾞｼﾞｪｸﾄ名・ﾄﾘｶﾞｰ起動ｲﾍﾞﾝﾄ・ﾄﾘｶﾞｰ起動SQLﾃｷｽﾄなど・・・

それぞれの監査方法で特徴が異なるため、目的に沿った監査を行うことが重要となります。
注意点としては、監査方法によっては取得可能な操作に制限がある点です。
例えば、テーブルなどのオブジェクトの構成変更や、権限管理の実施など、テーブルへのアクセス以外も監査を行う場合は、標準監査が適しているということになります。

また、標準監査では監査証跡の取得方法として下記が提供されています。
・os
→監査レコードをOS監査証跡に取得します。(Windowsの場合はイベントビューア)
・db、db,extended
→監査レコードをデータベース監査証跡（AUD$テーブル）に取得します。
・xml、xml,extended
→監査レコードをOS監査証跡（XML形式）に取得します。

検証内容

今回は前述した監査方法の中から、マイナンバーへのアクセスを監査する想定で、SELECT・INSERT・UPDATE・DELETEの監査が可能な「標準監査」と「ファイングレイン監査」を採用します。
検証方法としては、適当なテーブルに大量データを作成した上で、各監査が行われている状況でのDML(SELECT、UPDATE、INSERT、DELETE)の実行時間を計測します。 [RELATED_POSTS]

検証詳細

・サンプルテーブルに10万件のデータを作成
・実施する監査
a.監査なし
b.標準監査(os、db、 db,extended、xml、xml,extended)
c.ファイングレイン監査
・監査するSQL
SELECT、UPDATE、INSERT、DELETE
・実行するSQL(特定の項目(マイナンバー)の指定があるSQLを監査する)

select MY_NUMBER into myNumber from TEST_AUDIT where MY_NUMBER = 1;
update TEST_AUDIT set NAME = 'TEST' where MY_NUMBER = 1;
delete from TEST_AUDIT where MY_NUMBER = 1;
insert into TEST_AUDIT values('1','鈴木一郎','08012345678','埼玉県');

・各SQLを1万回実行するプロシージャを作成、実行する
・それぞれ5回実施し、平均値で比較を行う
・一回の検証ごとに監査ログ(テーブル、XML)、DBバッファキャッシュをクリア
・データ生成には OBのデータ生成機能を使用

検証環境

今回の検証環境は以下の通りです。

マシン

Windows7

CPU

Intel Core i5-2430M 2.40GHz

メモリ

4GB

その他

特に無し

対象RDBMS

Oracle11.0.2.0.1.0

テーブル名

TEST_AUDIT

テーブル項目

MY_NUMBER	NUMBER(10)
NAME	VARCHAR2(50)
TEL_NUMBER	VARCHAR2(20)
ADDRESS	VARCHAR2(100)

※主キー設定なし

検証準備

①データ生成
マイナンバーを取り扱うテーブルを想定して、下記の通り設定しました。
データは10万件、いつものようにObject Browserのデータ生成機能を使って準備します。(第１回参照)

カラム名	データ生成方法
MY_NUMBER	連番。1から開始し1ずつカウントアップ
NAME	テンプレート　苗字 + 名前
TEL_NUMBER	乱数値　電話番号
ADDRESS	テンプレート　住所

②SQL実行を繰り返すプロシージャ用意
指定回数SQLを実行できるプロシージャを用意します。
引数として実行回数を指定できるようにします。

【プロシージャのソース】
CREATE OR REPLACE PROCEDURE PR_TEST_AUDIT(A_COUNT NUMBER)
IS
myNumber TEST_AUDIT.MY_NUMBER%TYPE;
st number; -- 開始時間
t number; -- 経過時間
BEGIN
-- 開始時間を取得
st := dbms_utility.get_time;
--指定回数分を繰り返し
for i in 1..A_COUNT
loop
--各SQLを実行
select MY_NUMBER into myNumber from TEST_AUDIT where MY_NUMBER = 1;
update TEST_AUDIT set NAME = 'TEST' where MY_NUMBER = 1;
delete from TEST_AUDIT where MY_NUMBER = 1;
insert into TEST_AUDIT values('1','SCOTT','08012345678','ADDRESS');
end loop;
-- 終了時間を取得
t := dbms_utility.get_time - st;
--処理時間を表示
dbms_output.put_line(t);
END PR_TEST_AUDIT;
/

あとは監査方法によってそれぞれ変更を行いながらプロシージャを実行します。
・標準監査
→初期化パラメータ(audit_trailを変更 + データベース再起動)
・ファイングレイン監査
→監査オブジェクトを作成

【監査オブジェクト作成用 PL/SQL】
BEGIN
DBMS_FGA.ADD_POLICY(
OBJECT_SCHEMA => 'DBLAB_TEST_1',
OBJECT_NAME => 'TEST_AUDIT',
POLICY_NAME => 'AUDIT_MY_NUMBER',
STATEMENT_TYPES => 'SELECT,INSERT,UPDATE,DELETE',
AUDIT_COLUMN => 'MY_NUMBER'
);
END;

検証結果

件数：100,000件
実行回数：10,000回

監査	１回目	２回目	３回目	４回目	５回目	平均
監査なし	00:46.570	00:38.160	00:41.170	00:40.400	00:47.310	00:42.722
標準監査 (os)	00:55.410	00:59.280	01:00.800	01:01.470	01:04.790	01:00.350
標準監査 (db)	00:57.940	01:00.450	01:02.520	01:03.710	01:11.700	01:03.264
標準監査 (db,extended)	01:06.260	01:19.420	01:02.090	01:05.660	01:05.910	01:07.868
標準監査 (xml)	03:58.310	03:24.250	03:33.480	04:15.520	03:33.520	03:45.016
標準監査 (xml,extended)	05:38.740	04:52.930	05:34.990	05:06.220	05:30.570	05:20.690
ファイングレイン監査	01:10.310	01:24.960	01:08.240	01:12.260	01:12.430	01:13.640

※単位：秒

平均値での実行時間の対比は以下の通りです。

Oracle 監査ログ保存はパフォーマンスにどれくらい影響するか 2

「監査なし」に比べ、どの監査方法も実行時間が延びています。
その中でも「標準監査(xml)」「標準監査(xml,extended)」の実行時間が長くかかっているようです。

追加検証

今回は検証を追加し、件数を100万件、実行回数を1000回に変更して検証します。
・件数を増加させることで、ひとつのSQLの実行の時間を長くする。
・実行回数を減少させることで、監査証跡の出力回数を少なくする。
といった場合にどうなるか、結果は以下の通りとなりました。

件数：1,000,000件
実行回数：1,000回

監査	１回目	２回目	３回目	４回目	５回目	平均
監査なし	02:20.050	02:04.950	02:13.320	02:32.040	02:41.810	02:22.434
標準監査 (os)	02:31.660	02:50.930	02:34.470	03:01.280	02:25.610	02:40.790
標準監査 (db)	02:27.830	02:19.060	02:13.780	02:45.440	02:12.910	02:23.804
標準監査 (db,extended)	02:13.840	02:23.930	02:10.430	02:22.740	02:45.190	02:23.226
標準監査 (xml)	02:25.110	02:46.980	02:31.480	02:40.680	02:58.680	02:40.586
標準監査 (xml,extended)	02:28.640	02:54.390	03:03.790	02:45.210	03:15.420	02:53.490
ファイングレイン監査	03:02.450	03:10.680	03:19.010	03:01.620	03:38.000	03:14.352

※単位：秒

平均値での実行時間の対比は以下の通りです。

Oracle 監査ログ保存はパフォーマンスにどれくらい影響するか 3

件数を増加させた分、SQL実行に時間がかかっている影響で「監査なし」での実行時間が長くなっています。
また、ファイングレイン監査以外の監査方法に関しては、「監査なし」との差がほとんど見られず、「標準監査(xml)」「標準監査(xml,extended)」の実行時間に関しては、実行回数を減少させた影響か、時間の短縮が見られました。

結論

今回の検証結果では、以下のようになりました。
・標準監査、ファイングレイン監査を行うと、SQL実行のパフォーマンスは低下する
・監査方法によってパフォーマンスの低下率はそれぞれ異なる
・監査対象SQLの実行時間が長くなると、相対的にパフォーマンスの低下は少なくなる

監査の懸念であったパフォーマンスの低下は実際に発生するということと同時に、監査方法によってその低下率は様々で、更に対象テーブルや監査対象のSQL実行速度にも大きく影響することがわかりました。

データの内容や件数などによっては結果が異なるかと思われますが、今回の検証結果からは「監査なし」と実行時間にそれほど差が見られない「標準監査(os)」か、「標準監査(db)」「標準監査(db,extended)」が、パフォーマンスという観点では適しているということになります。

ただし、それぞれ負荷がかかる範囲が異なる(OSかDBか)、監査証跡の出力内容が異なるなど、それぞれの特徴があるため、どの環境でもこの監査方法が適しているとは言えません。
やはり実際に監査を導入する際は、テーブルの件数、アクセス頻度などを考慮し、しっかりとテストを行って適した監査方法を決定する必要があるようです。

今回の検証結果は以上となります。