Oracle Database 23cから従来型監査がサポートされなくなり、統合監査を使用しなければいけなくなりました。
従来型監査では監査レコードの出力先をOSファイルかDB内にするか選べたのですが、統合監査ではDB内にしか出力できなくなりました。ここで1つの疑問が。
DataGuardのフィジカルスタンバイデータベース側で、
統合監査の監査レコード出力ってどうなるの？？？
ということで、色々気になることをちょっと調べてみました。
※残念ながら実機確認までは手を出していません。時間ができたらやりたいと思います。。
フィジカルスタンバイを使うときは監査ができない？
結論から言うと、そんなことはないようです。
フィジカルスタンバイの様にRead Only状態のデータベースだけでなく、データベースがマウント状態など、データベースに書き込みできない場合、監査レコードはスピルオーバー監査ファイル(拡張子.bin)というOSファイルに出力されます。
スピルオーバー監査ファイルのデフォルトの出力先は、「$ORACLE_BASE/audit/$ORACLE_SID」ディレクトリになります。
スピルオーバー監査ファイルに出力された監査レコードは、データベースが書き込み可能な状態になったら、DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを実行することで、データベースにロードすることができ、ロード完了後にファイルは消える様です。
スピルオーバー監査ファイルについては、マニュアルのセキュリティ・ガイドに記載がありました。19cであれば下記から参照できます。ただ、「フィジカルスタンバイデータベースでは…」みたいに直接的な記載はされていないので、気づくのは難しいと思います…
Oracleのサポート契約がある方は、My Oracle Supportで下記のドキュメント(英語)を参照して頂いた方がわかりやすいかと思います。
Doc ID: 2021747.1
12c Unified Auditing used with Data Guard
フィジカルスタンバイの監査レコードの参照は遅いのでは？
上記のMy Oracle Supportに記載されている情報から、監査レコードを取得したいときに参照するUNIFIED_AUDIT_TRAILビューにアクセスすると、データベース内とOS上のスピルオーバー監査ファイルの両方から監査レコードを取得する旨の記載がありました。
The UNIFIED_AUDIT_TRAIL (based on V$UNIFIED_AUDIT_TRAIL) view gets you the audit records from both database store and the OS .bin files.
スピルオーバー監査ファイルは複数ファイルできる模様で、ファイル数またはファイル内の監査レコード数が多くなると、UNIFIED_AUDIT_TRAILビューへアクセスした際のレスポンスが悪くなる予感がします(データベース内だけのアクセスよりアクセス効率悪いはず)。
この性能劣化を抑えるためには、DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを用いて、スピルオーバー監査ファイルをデータベースに取り込めばよいと思うのですが、フィジカルスタンバイなので、データベースが書き込み可能になるタイミングは永遠にやってきません。。。
なので、フィジカルスタンバイで監査レコードを参照するのは、運用期間が長くなるほど遅くなるのでは？と懸念しております。
もしかしたら、プライマリ側にスピルオーバー監査ファイルをコピーして、データベースに取り込むという解があるのかもしれませんが、現時点で調べた限りではその様な情報に辿り着くことができていません。機会があったら調査したいと思います。
スピルオーバー監査ファイルの出力先は変更できない？
もし大量のスピルオーバー監査ファイルが出力されるなら、高速で大容量なストレージに出力したくなると思うので調べてみましたが、残念ながら変更方法を見つけられず。。。変更方法がわかったら、記載をアップデートします。
ただ、もし変更できないとしても、高速で大容量なストレージ領域を、デフォルトの出力先にマウントすればいいだけかなとは思います。
スピルオーバー監査ファイルの削除はDBインスタンスを停止しなくてもできる？
前述のMy Oracle Supportのドキュメントにも、監査が不要なら安全に削除できます、程度の記載しかなく、監査は必要だけど古くなったファイルを、DBインスタンスの停止などせず、無邪気に削除できるのかまでは判断できませんでした。
なんとなくですが、UNIFIED_AUDIT_TRAILビューの様な監査レコードにアクセスする処理が実行されない時間帯に、既に新しい監査レコードが追記されなくなったスピルオーバー監査ファイルであれば(そもそも「追記されなくなる」という状態が存在してくれるか不明ですが)、DBインスタンスの停止などせずに削除できるのではないかと思いますが、今後も要調査といったところです。
プライマリとスタンバイの監査レコードを区別できる？
統合監査における監査レコードの中身は、UNIFIED_AUDIT_TRAILビューを介して確認するのですが、スタンバイデータベース側でこのビューにアクセスすると、プライマリで格納された監査レコードをデータベース内から、スタンバイで生成された監査レコードをスピルオーバー監査ファイルから取得した結果が表示される気がします。つまり、プライマリとスタンバイの監査レコードが混在して表示されるのでは？という疑念が湧いてきます。
UNIFIED_AUDIT_TRAILビューに、プライマリとスタンバイを区別できるような列があればよいのですが、下記の19cマニュアルを見た限りでは、それっぽい列は存在しないようにみえるので、容易に区別できない可能性があります。
スタンバイではそもそもUNIFIED_AUDIT_TRAILビューにアクセスした際に、スピルオーバー監査ファイルしか参照しない動きをしてくれるとか、こうやれば区別つけられるという方法がないかは、今後わかり次第更新したいと思います。 ★参照。
もし、スタンバイデータベースにアクセスできるクライアントが、プライマリデータベースにアクセスできるクライアントと完全に分離されている環境であれば、userhost列で区別できるかとは思います。
【★区別方法について追記】
プライマリとスタンバイの監査レコードの見分け方について、My Oracle Supportの下記ドキュメントに記載がありました。
Doc ID: 2714585.1
How to Identify if Unified Audit Entries were Generated on Primary or Standby Database?
UNIFIED_AUDIT_TRAILビューのxs_sessionid列に格納されている値で判別できるとのことです。マニュアル上ではReal Application Securityセッションの識別子に関する情報が格納されるカラムとのことですが、スタンバイデータベースの監査レコードでは、このカラムに"000…00"が格納(ゼロ埋め)されるので、「WHERE xs_sessionid LIKE '0%'」といった条件句を付与すれば区別できそうです。
次の記事：テーブル結合時のテーブルアクセスについて調べてみた
