データベース・セキュリティの実装　第2回　ログの取得と監査設計のポイント

更新日: 2012/02/10
公開日: 2011/11/02

通知

LogMiner

　Oracle Databaseでは、REDOログ(オンラインREDOログ、アーカイブREDOログ)にデータベースに対するすべての変更履歴を格納している。LogMinerはこのREDOログを分析し、発行されたSQL文と同じ変更が適用されるSQL文(SQL_REDO)と、適用した変更をロールバックするためのSQL文(SQL_UNDO)を取得する機能だ。LogMinerは既存のREDOログの仕組みを利用しているため、変更データの保存に別の領域を確保する必要がない。通常、本番システムのデータベースはリカバリのためアーカイブログモードで運用されるので、バックアップ要件に従ってある程度過去までのアーカイブログファイルが保存されているが、アーカイブログが保存されている限り、過去の変更を確認できる非常に便利な機能だ。

LogMinerを利用した変更履歴の確認

　ただし、デフォルトの状態ではLogMiner機能は利用できず、事前にサプリメンタルロギングを有効化する必要がある。サプリメンタルロギングを有効化すると生成されるREDOログ量が多少増えるが、性能や物理容量に大きな影響はないため、アーカイブログを長期間保存しているシステムでは、LogMinerを利用するためにサプリメンタルロギングをあらかじめ有効にしておくことを考慮いただきたい。

　LogMinerの設定方法は「ユーティリティ」マニュアルのREDOログ・ファイル分析のためのLogMinerの使用を参照してほしい。

Total Recall

　Oracle Databaseでは、フラッシュバック問合せという過去のある時点のデータに対して検索する機能がある。これはUNDO表領域に格納された履歴データを利用して過去の表データを再現する機能で、簡単に過去のデータを確認することができる。また、特定のレコードの変更履歴を確認するフラッシュバック・バージョン問合せという機能もある。ただし、どちらもUNDO表領域にUNDOデータが残っていることが前提条件であり、UNDOデタの保持期間はUNDO_RETENTION初期化パラメータで調整できるものの、デフォルトでは900秒と長期間データを残しておくことは考慮されていない。

　Total Recallでは、指定した表のみのUNDOデータを別領域に書き出すことで、このフラッシュバック問合せを数年間という単位で実現する機能だ。

Total Recallを利用した過去データの検索

　たとえば情報流出事故が発生した場合、監査を取得していればいつどんなSQL文によって流出が起こったかは分かるが、実際に流出したデータは分からない。Total Recallのフラッシュバック問合せを利用すればSQLが発行された時点でのデータでのSQL実行を再現できるので、データの流出範囲を特定できる。

　変更履歴はパーティション化され圧縮されてデータベース内に格納される。そのため管理の手間がなく、また内部的に自動管理されているため、変更履歴を改ざんできない。

　フラッシュバック問合せとTotal Recallの利用方法は「アドバンスト・アプリケーション開発者ガイド」マニュアルのOracle Flashback Technologyの使用を参照してほしい。

監査設計のポイント

　監査を実施すると性能が出ない、という話をよく聞く。片やいかに処理を速くするかと必死にチューニングする一方で、処理性能に影響を与える監査は必要と思っていても実施できないこともあるだろう。だたし、これは監査の目的を考えず「とりあえず何かあった時のためにすべてのアクセスログを残しておこう」と漠然としか監査について考慮されていないだけであって、通常の業務処理と同様、監査についても適切に設計がなされていれば性能への影響は無視できるレベルにできる。

　監査設計の肝は、「監査対象の設計」と「監査証跡の設計」だ。

監査対象の設計

　監査対象の設計では、とりあえずすべてのアクセスを監査したい、という過ちが多い。本当に必要な監査は何なのかを理解する必要がある。一般的にアプリケーションが発行するSQL文に関しては監査の必要性は低い。アプリケーションが発行するSQL文のうち監査の必要がある可能性があるのは、個人情報、会計情報などの個人情報保護法、J-SOX法などのコンプライアンス対応に必要な情報と機密情報に対するアクセスだ。すべてのSQL文に監査を設定することは、無駄な監査証跡が増え、後からの解析が煩雑になるという欠点もある。

　逆に管理操作などの非定形SQL文は監査の必要性が高い。ユーザーやオブジェクト定義の変更、権限設定などデータベースやアプリケーション管理者の操作は構成変更管理の観点からも監査すべきだ。Oracle Database 11gR1以降のデフォルト監査設定は、この構成変更操作に対しての監査が有効化されているのが確認できる。

監査証跡の設定

　監査の性能は監査証跡の出力先でも変わる。具体的には監査証跡の出力先をOSファイル(OS、XMLとも)にしたほうが、データベース内の監査証跡表を利用するよりも性能への影響は少ない。また、管理の容易性を優先して出力先を監査証跡表にする場合には、11gR2以降ではDBMS_AUDIT_MGMTパッケージを利用して、監査証跡表(SYS.AUD$およびSYS.FGA_LOG$)表の出力先をSYSTEM以外の表領域に移動してほしい。データブロックの空き領域管理がフリーリスト管理であるSYSTEM表領域から、自動セグメント領域管理である他の領域に移動することで同時実行性が向上し、とくにRAC環境では監査証跡レコードの同じブロックに対する同時挿入によるキャッシュフュージョンが起こりにくくなる。

　DBMS_AUDIT_MGMTパッケージにはほかにも古い監査証跡の自動削除やOS監査証跡ファイル分割サイズの指定などができるため、監査証跡の管理のために有効活用してほしい。

　このほかにも監査に利用できる製品として、Oracle Net通信をモニタリング、さらにはブロッキングできるOracle Database Firewallがあるが、これは最終回に紹介する。その前に次回はデータの暗号化とハードウェアを利用したその高速化を取り上げるのでご期待いただきたい。