InsightTechnology 旧ブログ

＜Audit Trailについての検証　～その８～＞
ペンネーム　ベロ

いよいよ、AUDIT_TRAIL最終回となりました。

今まで、いくつかの監査を検証してきましたが、最後に監査について押さえて
おくべきポイントをまとめてみたいと思います。

1）監査できる範囲
2）監査におけるレスポンスダウンの把握
3）監査実施後の運用

1)、2）監査の範囲およびレスポンスダウンの把握について

監査について大きく以下の監査手法がオラクルから用意されている。
・文監査
・権限監査
・オブジェクト監査
オラクルへのログイン、ログアウトといったアカウンタビリティの監査は文監査
を実施することで対応可能です。また、パフォーマンスに与える影響もほとんど
無いことが分かった。（Audit_Trail第2回参照）また、アカウンタビリティを監
視することにより、「いつ」「だれが」「どこから」「どのくらい」オラクルに
接続したかを分析することが可能となり、その間発行したSQLもある程度絞ること
が可能となる。
セキュリティを考えれば、アカウンタビリティの監視はセキュリティ対策の第一
歩と言うことができると思います。

また、特定のオブジェクトを対象に監査を実施するためにはオブジェクト監査を
行う。アカウンタビリティといった広範なものではなく、ターゲットを絞り、オ
ブジェクトへのアクションを監査する。この、「ターゲットを絞り」がとても重
要となる。全てのオブジェクトを監査対象にするとレスポンスに大きく影響する。
監査をセッション毎に行った場合、監査を実施しない場合と比べ約18%のレスポ
ンスダウンとなった。また、アクション毎に監査を実施した場合だと約30%のレ
スポンスダウンとなった。（Audit_Trail第3回参照）

さらに、オラクルに標準的に実装されている監査機能に加えユーザ自身がカスタ
マイズできる監査としてファイングレイン監査がオラクル9iから実装されている。
（Audit_Trail第5回参照）

3）監査実施後の運用について

パフォーマンスを考慮して、監査を実施してもその後の運用をしっかり行ってい
かなければ、無用なエラーを引き起こしてデータベース管理者の手を煩わすこと
になる。

今回は初期化パラメータをAUDIT_TRAIL=DBとして運用してみたが、SYSTEM表領域
にAUD$というテーブルを作成し、そこに全ての監査レコードが格納されていく。
また、定期的にテーブルのメンテナンスを行うため、SYSTEM表領域の断片化が予
想される。
また、監査を実施したけれど、その後の運用は行っていないサイトではAUD$表が
一杯になることが予想される。
「監査は付加的なものだから、放っておいても大丈夫」などと考えていると痛い
目に会うかも知れない。

audit session by AAA;

でAAAユーザのログイン/ログアウトの監査を実施している場合を考えてみる。
AUD$表が一杯で拡張不可能な状態にしてみる。

ここで、AAAユーザでログインしてみると・・・

connect aaa/aaa
ERROR:
ORA-04043: 再帰SQL レベルstring でエラーが発生しました

「ORA-0604：再帰SQL レベルstring でエラーが発生しました」といったエラー
でログインできなくなる。ここで、SESSION監査を実施していることすらデータ
ベース管理者が知らなければ、原因究明に無駄な時間が割かれてしまう。

今、データベースにどのような監査が実施され、監査レコードがどの程度なのか
をしっかり把握し、定期的にメンテナンスすることが重要となる。

また、初期化パラメータAUDIT_TRAIL=OSとした場合もAUDIT_FILE_DESTに指定し
たディレクトリにora_.audもしくはsxxx_.oraというファイルが大量
に作成される。

※ ora_.audは専用接続
sxxx_.audはMTS接続

これらのファイルのメンテナンスを定期的に行うことが重要となる。

今回の検証では、パスワードを含むアカウント管理、JOBキューの監視など、広
範なセキュリティについて述べることができませんでしたが、機会があれば、セ
キュリティについて検証してみたいと思います。

スポーツの秋！全身筋肉痛！ 茅ヶ崎より