Oracle Databaseのセキュリティにおいて、Oracle 監査設定（オラクル 監査）は「いつ、誰が、何をしたか」を記録する生命線です。本記事では、19cでの推奨設定や、標準監査と統合監査の違い、実務で監視すべき項目について技術的な視点で解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
監査設定の最短チェックリスト
実務でまず確認・実施すべき「やることリスト」です。
- 統合監査（Unified Auditing）の有効化: 19c以降の推奨方式であることを確認する。
- 特権ユーザーの監視:
SYSDBA等の強力な権限を持つユーザーの全操作を記録対象にする。 - ログイン失敗の記録: ブルートフォース攻撃（総当たり）対策として失敗ログを重視する。
- 監査ログの外部保存: 改ざん対策としてOS上のSYSLOGや専用サーバーへ転送する。
- 定期パージの自動化:
DBMS_AUDIT_MGMTを使用し、ディスク枯渇を防ぐ。
監査の仕組みと標準・統合の差異
Oracleの監査には「標準監査（従来型）」と「統合監査（12c以降）」の2種類があります。19cを運用する上で、この2つの違いを理解することは必須です。
| 比較項目 | 標準監査 (Traditional) | 統合監査 (Unified Auditing) |
| 記録先 | AUD$ (DB内) や OSファイル | 単一のリードオンリービュー (UNIFIED_AUDIT_TRAIL) |
| 性能 | 同期書き込みのため負荷が高い | メモリ内バッファへの書込により高速 |
| 管理 | パラメータ変更・再起動が必要な場合あり | 監査ポリシー（SQL）で動的に管理可能 |
| 19cでの位置付け | 非推奨 (Deprecated) | 推奨 (Recommended) |
初心者向け一口メモ
「標準監査」は昔からある機能で、設定がバラバラになりがちでした。「統合監査」はそれらを1箇所にまとめ、かつ動作を軽くした最新の仕組みです。
監査設定を行うメリットと監視可能な情報
監査を適切に設定することで、単なる「記録」以上の価値をシステムにもたらします。
監査設定の主なメリット
- 抑止力: ログが残ることを明示することで、内部不正や安易な特権操作を抑制します。
- 証跡管理（コンプライアンス）: 外部監査や法規制（SOX法など）への対応が可能になります。
- トラブルシューティング: 「いつデータが消えたか」「誰が設定を変えたか」の追跡を容易にします。
- セキュリティ侵害の検知: 不自然なログイン失敗の連続などを検知し、攻撃を早期発見できます。
監視できる情報の例
監査ポリシーを構成することで、以下の情報を詳細に記録できます。
- 認証情報: ユーザー名、接続元IPアドレス、OSユーザー名、ターミナル名、ログイン/ログアウト日時。
- DDL操作:
CREATE、ALTER、DROPなどのスキーマ定義変更。 - DML操作:
INSERT、UPDATE、DELETEなどのデータ操作（※特定テーブルに限定するのが一般的）。 - 権限操作:
GRANTやREVOKEによる権限の付与・剥奪。 - システム操作: インスタンスの起動・停止、初期化パラメータの変更。
監査設定で検討すべき重要ポイント
1. 統合監査への切り替え（推奨）
19cでは「混合モード（Mixed Mode）」がデフォルトですが、パフォーマンスと管理性を最大化するには統合監査へ完全に移行することが推奨されます。
2. 特権ユーザー操作の確実な記録
SYS や SYSTEM などの特権ユーザーは監査ログ自体を操作できるため、最も厳重な監視が必要です。
- ポイント: OSレベルの監査ログ（
audit_sys_operations）を有効にし、DB内部だけでなくOS側のログファイルにも記録を残します。
3. 「ログイン失敗」の重点監視
正常な操作をすべて記録するとログが膨大になります。まずは「認証エラー」や「権限不足エラー」などの「失敗した操作」に絞って監査ポリシーを作成するのが実務的です。
4. ログの保存期間とパージ（削除）運用
監査を有効にしただけで満足し、数ヶ月後にディスクがいっぱいになってDBが停止するトラブルが後を絶ちません。
- 対策:
DBMS_AUDIT_MGMTパッケージを使用し、古いログを定期的に削除するジョブを必ず構成してください。
運用・セキュリティ上の注意点
- パフォーマンスへの影響:大規模なバッチ処理で数百万回の
INSERTを行うテーブルに対し、1行ずつのアクセス監査を設定すると性能が著しく劣化します。 - リスクと戻し方:監査設定後に性能劣化が見られた場合は、即座に
NOAUDITコマンドでポリシーを無効化してください。検証環境での「負荷テスト」は必須です。 - セキュリティの限界:DB内監査はDBA権限を持つ攻撃者には回避される可能性があります。より高度な要件では、Oracle Audit Vault などの外部製品を検討してください。
FAQ（よくある質問）
Q：監査を有効にする「やり方」として、DBの再起動は必要ですか？
A： 統合監査のポリシー作成・適用はオンラインで可能（再起動不要）です。ただし、統合監査自体を完全に有効化（バイナリのリンク設定）する場合は再起動が必要です。
Q：標準監査と統合監査を同時に使ってもいいですか？
A： 可能です（混合モード）。移行期間中はこの状態で運用し、徐々に統合監査へ移行するのが一般的です。
Q：監査ログがディスクを圧迫してログインできなくなりました。
A： OS上のログファイルを退避させるか、DBA権限でログインし DBMS_AUDIT_MGMT でパージを実行してください。緊急時は一時的に監査を無効化する判断も必要です。
まとめ
- Oracle 監査設定は、19c以降なら統合監査をメインに構成する。
- 特権ユーザーの監視とログイン失敗の記録は、セキュリティの最低ライン。
- 監査ログの肥大化対策（パージ設定）を忘れると、DB停止のリスクがある。
- パフォーマンス劣化を防ぐため、監査対象は必要最小限に絞り込む。
本記事は Oracle Database 19c を対象に解説します（他バージョンは画面や既定値が異なる場合があります）。
[参考]
監査の概要
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント