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

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

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

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

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

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

disp_201506_1_img_1.png

図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のデータ生成機能を使用

検証環境

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

マシン OS Windows7
CPU Intel Core i5-2430M 2.40GHz
メモリ 4GB
その他 特に無し
DB 対象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のデータ生成機能を使って準備します。(第1回参照)

カラム名 データ生成方法
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回

監査 1回目 2回目 3回目 4回目 5回目 平均
監査なし 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

※単位:秒

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

disp_201506_1_img_2.png

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

追加検証

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

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

監査 1回目 2回目 3回目 4回目 5回目 平均
監査なし 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

※単位:秒

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

disp_201506_1_img_3.png

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

結論

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

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

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

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

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

新規CTA

RECENT POST「DBlab」の最新記事


この記事が気に入ったらいいねしよう!
OBトライアル
ブログ購読のお申込み

RANKING人気資料ランキング

RANKING人気記事ランキング

RECENT POST 最新記事