Oracle Databaseの監査（Audit）機能とは？ユーザーの操作履歴を記録するUnified Auditingを解説

Oracle Databaseには監査（Audit）の仕組みがあり、データベースで実行されたユーザーの操作を監査レコードとして記録できます。例えば特定の表へのSELECT・INSERT・UPDATE・DELETE、特定のシステム権限を使用した操作などを監査対象として設定できます。

ただし、「監査を有効にすればユーザーが行ったすべての操作内容が自動的に完全保存される」という理解は正確ではありません。Oracle Databaseでは監査ポリシーによって、何を監査するのか、誰を対象にするのか、成功・失敗のどちらを記録するのかなどを設計します。

現在のOracle Databaseで特に重要なのがUnified Auditing（統合監査）です。Oracle Database 12cから導入された仕組みで、現在の監査設計ではUnified Auditingを中心に理解しておくとよいでしょう。[参照] Oracle公式 Unified Auditingの監査ポリシー

Oracle Databaseでは監査機能で操作履歴を記録できる

Oracle Databaseの監査では、セキュリティ上確認したい操作を監査対象として設定し、その条件に該当する操作が実行されたときに監査レコードを生成できます。

例えば「重要な表に対して誰がアクセスしたのか」「特定の権限を使用した操作が行われたか」「監査対象の操作が成功したのか失敗したのか」といった情報を後から調査する用途があります。

Unified Auditingでは、監査ポリシーを有効化するAUDIT文によって、すべてのユーザーまたは指定したユーザーなどを対象にできます。また、成功した操作だけ、失敗した操作だけ、あるいは両方を監査する設定が可能です。[参照] Oracle公式 AUDIT（Unified Auditing）

Unified Auditingでは監査ポリシーを作成して有効化する

現在のOracle Databaseの監査を理解するときは、「監査ポリシーを定義する」「そのポリシーを有効にする」「生成された監査レコードを確認する」という流れで考えると分かりやすくなります。

独自のUnified Audit Policyを作成する場合には、例えばCREATE AUDIT POLICYを使用して監査対象となるアクションなどを定義します。そしてAUDIT POLICY ポリシー名によって、そのポリシーを有効にします。

Oracleの公式ドキュメントでも、カスタム監査では監査ポリシーを作成し、AUDIT文で有効化したうえで、生成されたレコードをUNIFIED_AUDIT_TRAILから確認する流れが案内されています。[参照] Oracle公式 監査ポリシーの構成

どのような操作を監査できるのか

監査対象は用途に応じて設定できます。代表的には、SQL文による操作、オブジェクトへの操作、システム権限の使用などがあります。

例えば業務上重要な表について、SELECTによる参照、INSERTによる追加、UPDATEによる更新、DELETEによる削除などを監査対象として検討できます。また、ユーザーや権限管理に関係する重要操作を監査することもできます。

ただし、監査対象を無制限に増やすのが最適とは限りません。必要なセキュリティ要件やコンプライアンス要件を整理し、調査に必要なイベントを選ぶことが重要です。

監査結果はUNIFIED_AUDIT_TRAILで確認できる

Unified Auditingによって生成された監査レコードを確認するときに重要なのがUNIFIED_AUDIT_TRAILビューです。OracleのSecurity Guideでは、このビューが監査レコードを表示するものとして案内されています。

例えば監査設定後に「いつ」「どのユーザーが」「どのようなアクションを行ったか」などを監査レコードから調査します。実際に利用できる列や取得条件はOracle Databaseのバージョンや監査対象なども踏まえて確認します。

また、マルチテナント環境ではCDB_UNIFIED_AUDIT_TRAILも重要です。Oracleのドキュメントでは、CDBルートから全PDBの監査レコードを確認するためのビューとして説明されています。[参照] Oracle公式 監査データ・ディクショナリ・ビュー

「操作履歴」と「変更前後のデータ」は分けて考える

監査機能について特に誤解しやすいのが、「UPDATEを監査したら変更前と変更後のすべてのデータが自動的に保存される」と考えてしまうことです。監査はデータベース上で行われたアクションを追跡するための仕組みであり、業務データそのものの完全な変更履歴管理とは目的が異なります。

例えば「USER_Aが顧客表に対してUPDATEを実行した」という事実を監査することと、「住所が東京都から大阪府へ変更された」という業務データの新旧値を保存することは別の要件です。

後者が必要なら、アプリケーション側の履歴テーブル、データベースの別機能、Fine-Grained Auditingなどを含め、目的に適した仕組みを検討する必要があります。「誰が何らかの操作をしたのか」と「データが具体的に何から何へ変化したのか」を分けて要件定義することが重要です。

全ユーザーを監査することも特定ユーザーを対象にすることもできる

Unified Auditingでは監査ポリシーを全ユーザーへ適用することも、指定したユーザーなどへ適用することもできます。そのため、システム全体で重要な操作を監査する方法だけでなく、特定の管理者や業務ユーザーを対象とした設計も可能です。

現在有効になっているUnified Audit PolicyはAUDIT_UNIFIED_ENABLED_POLICIESビューで確認できます。このビューではポリシー名のほか、対象となるユーザーまたはロールや、成功・失敗を監査する設定などを確認できます。[参照] Oracle公式 AUDIT_UNIFIED_ENABLED_POLICIES

「監査設定したつもりなのに履歴が取れていない」という場合には、ポリシーを作成しただけなのか、実際に有効化されているのか、対象ユーザーや対象アクションが正しいのかを確認することが重要です。

成功した操作と失敗した操作を監査できる

セキュリティ監査では、成功した操作だけでなく失敗した操作が重要になることがあります。Oracle DatabaseのUnified Auditingでは、監査対象イベントについて成功時・失敗時を指定できます。

例えば重要な操作の成功記録を残して変更状況を追跡する一方、失敗した試行を監査して、不適切な権限で操作しようとした形跡を調査するといった利用が考えられます。

AUDIT文ではWHENEVER SUCCESSFULによって成功したイベント、WHENEVER NOT SUCCESSFULによって失敗したイベントを対象にでき、これらを省略した場合は成功・失敗の両方が監査対象となります。[参照] Oracle公式 AUDIT文

古い解説の「従来型監査」には注意する

Oracle Databaseの監査をインターネットで調べると、AUDIT_TRAIL初期化パラメータやDBA_AUDIT_TRAILなどを中心に説明した古い記事が見つかることがあります。これはTraditional Auditing（従来型監査）を前提としている場合があります。

Oracle AI Database 26aiではTraditional Auditingは非サポートとなっており、OracleはUnified Auditingへの移行を案内しています。また、26aiのAUDIT_TRAIL初期化パラメータについても従来型監査にのみ適用される非推奨のパラメータとされています。[参照] Oracle公式 AUDIT_TRAIL

そのため、新しく監査を学習・設計する場合には、利用しているOracle Databaseのバージョンを確認したうえでUnified Auditingを中心に公式ドキュメントを参照するのが安全です。古いバージョンを運用している場合は、そのバージョンの仕様に合わせて判断します。

監査ログは「取って終わり」ではない

監査機能を有効化すると、対象となる操作に応じて監査レコードが蓄積されます。そのため、本番運用では何を記録するかだけでなく、誰が監査情報を閲覧できるのか、どのくらい保持するのか、どのようにアーカイブ・削除するのかまで設計する必要があります。

Oracleの監査ポリシーに関する公式手順でも、生成されたレコードをUNIFIED_AUDIT_TRAILで確認するだけでなく、監査証跡を定期的にアーカイブしてパージすることが示されています。[参照] Oracle公式 Provisioning Audit Policies

特に大量のSQLを無差別に監査するのではなく、「何を検知・証明するための監査なのか」を決めてからポリシーを設計することが、運用負荷とセキュリティの両面で重要です。

まとめ：Oracle DatabaseではAudit機能でユーザー操作を記録できる

Oracle Databaseには監査機能があり、ユーザーがデータベース上で行った対象操作を監査レコードとして記録できます。現在のOracle Databaseでは、Unified Auditingを中心に監査ポリシーを定義・有効化し、必要な操作を追跡する考え方が重要です。

例えば重要な表へのアクセス、INSERT・UPDATE・DELETEなどの操作、権限を使用した操作などを監査対象として設定できます。また、対象ユーザーを指定したり、成功・失敗に応じて監査したりすることも可能です。

生成された監査レコードは主にUNIFIED_AUDIT_TRAILなどから確認できます。ただし、監査は「すべてのデータの変更前後を自動保存する機能」と同義ではありません。操作監査と業務データの変更履歴は別の要件として考える必要があります。

実際に導入するときは、利用中のOracle Databaseのバージョンを確認し、誰の・どの操作を・成功時か失敗時か・どの期間保存するのかを明確にして監査ポリシーを設計することが重要です。