InsightTechnology 旧ブログ

DB監査製品シェアNo.1

＜RACにAuditを実装する -Oracle新人奮闘記-＞
ペンネーム： world famous beagle

みなさん、こんにちは。
印旛くんのRACインストールはお楽しみいただけたでしょうか？
ようやくインストールを終えた印旛くんが次の課題に進みます。

よろしくお願いします。
———————————————————————-
「印旛くん、ちょっと」
「はい、なんでしょう」
「君がインストールしたRACにauditを実装して欲しいんだけど」
「オウディットって、監査のauditですよね？」
「うん、じゃあよろしく。
過去のメルマガにauditの検証があるから参考にしてもいいよ」
「はい。わかりました」

＊Audit Trailについての検証１～８
https://old.insight-tec.com/mailmagazine/ora3/vol163.html

新しい仕事だ！やったー。
さすがにちょっとRACのインストールはお腹一杯だったんだよね。
次は、auditか。
セキュリティ関係だよね。なんだか時代に乗ってる感じがするなぁ。
早速調べよう。

Oracleが提供している監査機能は、大きく分けて3つ。
・標準監査(audit文を使用)
・ファイングレイン監査

標準監査には、3つの監査オプションがある。
・文監査
・権限監査
・オブジェクト監査

標準監査機能を使うには、
audit_trail初期化パラメータの値をtrueにする必要があるのか。
(デフォルトはfalse)
そして、DBを再起動しないといけない。
これは、もしサービス起動中のDBに実装するとしたら大変だな。

ファイングレイン監査って名前がかっこいいよね。
ちょっとメルマガを読んでみよう。

うーーーん。
標準監査の3つに比べて複雑だな。
標準監査よりも細かい設定ができたり、メール通知機能があったり、
便利そうだな。
何よりも、audit_trailっていう初期化パラメータを設定する必要がないらしい。
ってことは、DBの再起動も必要ないってことか。
これは、サービス起動中のDBに実装する時にはよさそうだな。
今回の監査の実装はファイングレイン監査にしようかな。

「岸田さん、ファイングレイン監査を実装しようと思うんですけど、
どうでしょう？」
「は？」
「auditを使った標準監査よりも細かい設定ができるようなので・・・。
あとは、DBを再起動する必要がないです」
「ファイングレインはOracleがEnterprise Editionじゃないと使えないけど」
「え？」
「君がインストールしたのは、SERACだよね？」
「はい、Standard Editionでした・・・」
「それで？」
「じゃあ、オブジェクト監査を実装します！」
「あ、そう。早くして」
「はい・・・」
「何を監査すればいいのかはわかってる？」
「えーーっと。とりあえずは、
scottスキーマのemp表の監査の設定をしてみようかと思ってるんですけど」
「なんで？」
「監査をする必要があるのは、
基本的には個人情報とかの情報漏えいのリスクが高いものですよね？
ということで、従業員表や顧客情報が入っている表が対象になるかと
思ったんですけど」
「うん、じゃあよろしく」

よし、オブジェクト監査だ！細かい失敗は気にしない気にしない。
まずは、初期化パラメータの設定だ。
audit_trailを確認すると現在の値は、FALSE。
これを変えればいいんだけど・・・、色々変えられるみたいだな。
—–NONE,FALSE,OS,DB,DB_EXTEND,XML,XML_EXTEND——
さてどれ？

‘_EXTEND’となっているのは、ログと一緒に実行されたSQL文を出力するかどうか。
あとは、OSファイルに書き出すか、
AUD$表にデータファイルとして書き出すかの違いかな。

うーーん。何を考えて決めればいいんだろうか。
お客さんに実装するなら、DBのサービスへのインパクトが
低いものを選ぶべきだよね。
そもそも、auditを設定すると再起動が必要だし、
メルマガ”Audit Trailについての検証”にもあったように
パフォーマンスに影響がある場合があるんだよな。
あとは、今回はRACだからシングルインスタンスの時と何か違いはないのかな。

うーーーん。うーーん。
やっぱりOSにファイル出力した方がいいんじゃないかな・・・。
理由は・・・

１．audit_trail=DBにした場合、
→SYSTEM表領域内のAUD$表にauditの情報が書き込まれる
→この表が膨らんでいって、SYSTEM表領域を圧迫
→RACのサービス全てが停止する危険がある

２．RAC環境で、’audit_trail=DB’にした場合
→複数インスタンスがAUD$表に同時に書き込みを行う可能性がある
→シングルインスタンスよりもパフォーマンスへの影響が大

ということで、audit_trail=OSすれば、
DBのサービスへの影響は小さくできるはずだな。
今回のRACは、Oracleのデータファイル、アーカイブログは全て
共有ディスク上だからAuditを実装してI/O問題が起きることはないでしょう。

では、早速初期化パラメータの設定を。

user: SYS
SQL> alter system set audit_trail=OS scope=spfile;
System altered.

SQL> alter system set
  2  audit_file_dest='/home/oracle/audit_inba' scope=spfile;
System altered.

よし、一応auditのログの出力先を自分で作ったディレクトリにしておこう。
これで、DBを再起動すれば設定完了！

初期化パラメータを確認しよう。

SQL> show parameter audit
NAME                     TYPE      VALUE
------------------------ --------- ------------
audit_file_dest          string    /home/oracle/audit_inba
audit_sys_operations     boolean   FALSE
audit_syslog_level       string
audit_trail              string    OS

よし、完璧。
次は、audit文を使ってauditを設定しよう。
scottユーザのemp表が検索された場合にログを出力することを想定すると・・・

$ sqlplus scott/tiger

SQL> audit select on scott.emp;
監査が成功しました。

これで、別のセッションからemp表に対してselect文を発行すると、
audit_file_destに設定したディレクトリにログが出力されるはずなんだけど・・・

***auditが実行されるのは、auditを設定した次のセッションからです***

$ cd /home/oracle/audit_inba
$ ls
ora_10137.aud

お、あるある。中身を見てみよう。

$ view ora_10137.aud
Audit file /home/oracle/audit_inba/ora_10137.aud
Oracle Database 10g Release 10.2.0.1.0 - 64bit Production
With the Real Application Clusters option
ORACLE_HOME = /opt/app/oracle/product/10.2.0/db
System name:    Linux
Node name:      ******
Release:        2.6.9-34.ELsmp
Version:        #1 SMP Fri Feb 24 16:56:28 EST 2006
Machine:        x86_64
Instance name: inba1
Redo thread mounted by this instance: 1
Oracle process number: 28
Unix process pid: 10137, image: oracle@***** (TNS V1-V3)

Tue Oct 10 22:34:10 2006
SESSIONID: "10765597" ENTRYID: "1" STATEMENT: "8" USERID: "SCOTT"
USERHOST: "*****" TERMINAL: "pts/3" ACTION: "103" RETURNCODE: "0"
OBJ$CREATOR: "SCOTT" OBJ$NAME: "EMP" SES$ACTIONS: "---------S------"
SES$TID: "72760" OS$USERID: "oracle"

おーーー。ちゃんとログが出てる！
けど、なんだか見にくい気がするなぁ。
データのサイズは、729バイト。あまり大きくはないね。

この情報から何ができるか、どうやって運用するかを考えないと！
それでは、また来週。