多くのRDBMSでは、それぞれ監査証跡を記録する機能を備えている*1*2*3。一方で、RDBMSの監査証跡機能を利用せず、ビジネスロジックとして証跡を取得する(監査証跡を機能要件として定める)ケースもある。そこで、RDBMSの監査証跡機能を利用しない・できない理由として考えられるものを列挙してみた。
- 必要な監査機能のない古いRDBMS(Oracle 8とか)を使っていた頃に監査証跡機能を実装するため、監査証跡用のデータを記録する処理がビジネスロジックに埋め込まれており、その処理がそのまま受け継がれている。また、監査証跡の取得方法をRDBMS標準の機能に変更した際に、監査ログ用のディスク領域設計等を行える人がプロジェクト内に育っていない。
- 監査証跡の保存方法や保存形式がRDBMSごとに異なる*4。そのため、RDBMSを変更した際に監査証跡のデータを移行できず、これがベンダロックインとみなされる。「システム更改時にOracleをやめてPostgreSQLやMySQLへRDBMSを変更したい」という場合、DBA_AUDIT_TRAILやDBA_FGA_AUDIT_TRAILビューをPostgreSQLやMySQLの監査機能のデータ形式へ移行する方法が見当たらない。
- 監査証跡にはユーザIDが記録されるが、これが意味をなさない。監査ログには、DataSource経由での接続ユーザIDと、OSのユーザIDしか記録されない*5。そのため、DBを更新するアプリケーションへログインしたユーザIDを記録する処理はアプリケーション側で実装する必要がある。
- 性能の問題。古いけどOracle 10gで監査証跡を有効にした場合の性能低下として、ファイングレイン監査で3割減となるというデータがある*6。
- 必要な監査の内容がRDBMS標準の監査証跡と異なる。J-SOXのIT業務処理統制ではユーザがアクセスしたレコードの情報の記録は規定されていないみたい*7なのでOracleのデフォルト監査設定でカバーできそう。一方、不正閲覧の調査が必要なシステムでは、データの閲覧履歴を記録する必要がある。PostgreSQLではpgAuditを使うことでPCI DSSに必要なレベルまでは証跡を取得できる*8。
- 監査証跡をSQLで検索できない。たとえばPostgreSQLは監査証跡ログがDBでなくファイルに出力される。運用担当者が、システム運用の一環で本番環境のDBに対しSQLを叩く作業プロセスがすでに作りあげられている場合、そこへファイルを使った確認手順を追加するのが難しい。また運用担当者がSQLには慣れているが正規表現には慣れていない。
*1:https://www.scsk.jp/lib/product/oss/pdf/oss_7.pdf
*2:SQL ServerについてはSQL Server 徹底検証シリーズ「コンプライアンス実現のためのガイドライン」に記述があったようなのだが、MicrosoftのサイトからPDFが消えてしまっていて、WayBack Machineでも取れないようだ。 https://web.archive.org/web/20081222125204/http://www.microsoft.com/japan/sqlserver/2008/bible/cqi.mspx
*3:https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_9.7.0/com.ibm.db2.luw.admin.sec.doc/doc/c0005483.html
*4:https://www.scsk.jp/lib/product/oss/pdf/oss_7.pdf
*5:https://docs.oracle.com/cd/E16338_01/network.112/b56285/auditing.htm
*6:https://www.atmarkit.co.jp/fdb/single/09_orasec2/09_orasec2_02.html
*7:https://xtech.nikkei.com/it/article/MAG/20070313/264706/
*8:https://www.pgecons.org/wp-content/uploads/PGECons/2015/WG3/PGECons_2015_WG3_Security.pdf#page=21