29 監査の概要

特権ユーザーは、他の特権ユーザーを含むすべてのユーザーがデータベースで行った変更を追跡するポリシーを作成できます。

関連トピック

29.1 監査とは

監査とは、データベース・アクティビティ(データベース・ユーザーと非データベース・ユーザー両方のアクティビティ)を監視して記録することです。

非データベース・ユーザーとは、CLIENT_IDENTIFIER属性を使用してデータベースで認識されるアプリケーション・ユーザーのことです。ユーザーのこの対応を監査する場合は、統合監査ポリシー条件、ファイングレイン監査ポリシー、またはOracle Database Real Application Securityを使用できます。

通常、Oracle Database監査は、次のアクティビティの実行に使用されます。

  • 特権データベース管理者のアクティビティの監視
  • 機密資産の不正アクティビティを検出
  • データ漏洩などの疑わしいアクティビティの調査を支援
  • 重要な資産を監視する証拠を監査者に提供
  • データベース環境の変更に関するレポートを監査者に提供

このガイドでは、ファイングレイン監査やOracle Database Vaultなどの様々なOracle Databaseコンポーネントの監査証跡を、統合監査を使用して1つの統合監査証跡にまとめるポリシーを作成する方法について説明します。この監査証跡は、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューで表示できます。(AUDIT_UNIFIED_POLICIESなどの、その他の統合監査証跡ビューを使用できます。)統合監査データ証跡によって、分析を実行する前にまず監査データを1つの場所に集めることなく、1つの操作で監査データ全体の分析レポートを実行できます。Oracle Audit Vaultなどの監査マイニング・ツールは、監査レコードを収集するために複数の場所ではなく1つの場所を参照できます。統合監査証跡は、監査情報が一貫してフォーマットされ、一貫したフィールドが含まれていることを確認します。

ノート:

Oracle Database 23cでは、従来の監査はサポートされなくなりました。かわりに統合監査を使用することをお薦めします。

監査は、実行されたSQL文のタイプなどの個々のアクションに基づいて、またはユーザー名、アプリケーション、時間などを含めることができるセッション・メタデータの組合せに基づいて実行できます。

成功したアクティビティと失敗したアクティビティの両方の監査が可能で、特定のユーザーを監査対象に含めたり、除外したりできます。プラガブル・データベース(PDB)の個々のアクション、またはマルチテナント・コンテナ・データベース(CDB)全体の個々のアクションを監査できます。データベースで提供される標準アクティビティの監査に加え、監査には、Oracle Database Real Application Security、Oracle Recovery Manager、Oracle Data Pump、Oracle Machine Learning for SQL、Oracle Database Vault、Oracle Label SecurityおよびOracle SQL*Loaderダイレクト・パス・イベントからのアクティビティを含めることができます。

監査はデフォルトで有効です。すべての監査レコードは、同一の形式で統合監査証跡に書き込まれ、UNIFIED_AUDIT_TRAILビューから使用できます。これらのレコードはAUDSYSスキーマにあります。監査レコードは、デフォルトでSYSAUX表領域に格納されます。統合監査証跡用に異なる表領域を構成することをお薦めします。これを行うには、DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONプロシージャを使用します。Oracle Database Standard EditionおよびExpress Edition (Enterprise Editionは除く)では、統合監査の表領域の関連付けは1回のみであることに注意してください。この関連付けは、統合監査証跡の監査レコードを生成する前に行う必要があります。表領域を関連付けると、Enterprise Editionではパーティション化のみがサポートされるため、表領域を変更できません。

次のいずれかの方法を使用して監査を構成できます。

  • 監査設定を1つの統合監査ポリシーにグループ化する。データベースで必要なすべての監査設定を定義する統合監査ポリシーを1つ以上作成できます。

  • 事前定義の統合監査ポリシーのいずれかを使用する。Oracle Databaseには、ほとんどの規制機関で必要とされる標準の監査設定を網羅した事前定義の統合監査ポリシーが提供されています。

  • ファイングレイン監査ポリシーを作成する。アクションの発生時刻などの特定のアクティビティを取得するファイングレイン監査ポリシーを作成できます。

  • Oracle Data Safeで提供される推奨監査ポリシーのいずれかを有効にする。

データベースを監査することをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは規制コンプライアンス要件を満たすことができます。これを使用すると、ビジネス操作をモニターでき、企業ポリシーから逸脱する可能性があるアクティビティを検出できます。有効な監査ポリシーを作成することで、監査および個人のコンプライアンスに関する監査レコードを生成できます。選択的に監査を行い、ビジネス・コンプライアンスのニーズを満たしていることを確認してください。

29.2 監査を使用する理由

通常は、監査を使用してユーザー・アクティビティを監視します。

監査を使用すると、次の内容が可能になります。

  • アクションに対するアカウンタビリティの有効化。特定のスキーマ、表または行に対して実行されるアクション、あるいは特定の内容に影響を与えるアクションなどがあります。

  • それぞれのアカウンタビリティに基づいた、ユーザー(または侵入者などの他者)による不適切なアクションの防止。

  • 疑わしいアクティビティの調査。たとえば、ユーザーが表からデータを削除しようとした場合、セキュリティ管理者は、そのデータベースへのすべての接続と、そのデータベースにあるすべての表からの行の削除(成功および失敗)をすべて監査できます。

  • 認可されていないユーザーのアクションを監査人に通知します。たとえば、認可されていないユーザーがデータを変更または削除を実行できるなど、予期した以上の権限を持っている場合に、ユーザー認可を再評価できます。

  • インシデント発生後の調査をサポートします。

  • 特定のデータベース・アクティビティに関するデータの監視と収集。たとえば、データベース管理者は、更新された表、実行された論理I/Oの回数、またはピーク時に接続していた同時実行ユーザーの数などに関する統計を収集できます。

  • 認可またはアクセス制御の実装に関する問題の検出。たとえば、データは他の方法で保護されているため、監査レコードは生成されないと予測される監査ポリシーを作成できます。しかし、これらのポリシーで監査レコードが生成された場合は、他のセキュリティ制御が正しく実装されていないことがわかります。

  • コンプライアンスのための監査要件への対処。次のような法規に、監査に関連する一般的な要件が含まれています。

    • 米国サーベンス・オクスリー法

    • 米国の医療保険の相互運用性と説明責任に関する法律(Health Insurance Portability and Accountability Act、HIPAA)

    • 自己資本の測定と基準に関する国際的統一化: 改訂された枠組(バーゼルII)(International Convergence of Capital Measurement and Capital Standards: a Revised Framework、Basel II)

    • 日本の個人情報保護法

    • 欧州連合のプライバシと電子通信に関する指令(European Union Directive on Privacy and Electronic Communications)

29.3 監査のベスト・プラクティス

ベスト・プラクティスに関するガイドラインに従ってください。

  • 原則として、法令順守要件を満たすために必要な量の情報を収集するように監査方針を策定しますが、大きなセキュリティ問題の原因となるアクティビティに焦点を合せてください。たとえば、データベース内のすべての表を監査するのではなく、給与など機密性の高いデータが入った表列を監査するのが実用的です。統合監査とファイングレイン監査の両方により、監査対象の特定のアクティビティに焦点を合せた監査ポリシーの策定に使用できるメカニズムがあります。

  • 監査証跡データを定期的にアーカイブして削除します。DBMS_AUDIT_MGMTパッケージを使用して、複数の方法で監査レコードを削除できます。収集された監査レコードを定期的に確認し、サイトの保存ポリシーに基づいて監査レコードの収集および保存体系を確立する必要があります。DBMS_AUDIT_MGMTに加えて、Oracle Data SafeおよびOracle Audit Vault and Database Firewallには、監査証跡データのアーカイブおよび削除を管理するための機能が用意されています。

29.4 統合監査とは

統合監査では、統合監査証跡により、次の各種ソースから監査情報が取得されます。

統合監査では、次のソースから監査レコードを取得できます。

  • 統合監査ポリシーおよびAUDIT設定による監査レコード(SYS監査レコードを含む)

  • DBMS_FGA PL/SQLパッケージによるファイングレイン監査レコード

  • Oracle Database Real Application Security監査レコード

  • Oracle Recovery Manager監査レコード

  • Oracle Database Vault監査レコード

  • Oracle Label Security監査レコード

  • Oracle Machine Learning for SQLレコード

  • Oracle Data Pump

  • Oracle SQL*Loaderダイレクト・ロード

  • Oracle XML DB HTTPおよびFTPプロトコル・メッセージ

統合監査証跡は、SYSAUX表領域のAUDSYSスキーマの読取り専用の表にあり、この情報をUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューで同一の形式で使用できるようにし、単一インスタンスおよびOracle Database Real Application Clustersの両方の環境で使用できます。ユーザーSYSに加えて、AUDIT_ADMINおよびAUDIT_VIEWERロールが付与されているユーザーもこれらのビューを問い合せることができます。ユーザーが監査ポリシーの作成ではなく、ビューの問合せのみを必要としている場合は、AUDIT_VIEWERロールを付与します。

データベースが書込み可能な場合、監査レコードは統合監査証跡に書き込まれます。データベースが書込み可能でない場合、監査レコードは$ORACLE_BASE/audit/$ORACLE_SIDディレクトリの新しい形式のオペレーティング・システム・ファイルに書き込まれます。

29.5 統合監査証跡の利点

統合監査証跡には、次のように多くの利点があります。

たとえば:

  • 統合監査の有効化後、以前のリリースで使用されていた初期化パラメータには依存しません。これらの初期化パラメータのリストは、表D-1を参照してください。

  • SYS監査証跡のレコードを含む、Oracle Databaseインストールのすべての監査コンポーネントの監査レコードは、1つの場所に1つの形式で配置されるため、様々な場所を参照して各種形式の監査証跡を探す必要はありません。この統合ビューにより、監査者は様々なコンポーネントから監査情報を相互に関連付けることができます。たとえば、INSERT文の実行中にエラーが発生した場合は、標準の監査でエラー番号と実行されたSQLを示すことができます。Oracle Database Vault固有の情報では、このエラーがコマンド・ルール違反またはレルム違反のどちらの原因で発生したかを示すことができます。別のAUDIT_TYPEの監査レコードが2つあります。この統合を適切に設定すると、AUDIT_TYPEStandard Auditに設定されたSYS監査レコードが表示されます。

  • 監査証跡の管理とセキュリティは、監査証跡を単一にすることでも改善されます。

  • 監査の全体的なパフォーマンスが大幅に向上します。デフォルトでは、監査レコードはAUDSYSスキーマの内部リレーショナル表に自動的に書き込まれます。

  • SYS管理ユーザーだけでなく、サポートされているコンポーネント(この項の最初に記載)を各自で監査できる名前付きの監査ポリシーを作成できます。さらに、条件と除外を各自のポリシーに作成することもできます。

  • Oracle Audit Vault and Database Firewall環境を使用している場合は、このデータがすべて1つの場所から取得されるため、統合監査証跡により、監査データの収集がかなり容易になります。

29.6 従来の監査のサポート終了への対応

Oracle Database 23c以降では、従来の監査はサポートされなくなりました。かわりに統合監査を使用することをお薦めします。

以前のリリースで従来の監査を使用していた場合は、Oracle Database 23cにアップグレードしても、既存の従来の監査設定が引き続き適用され、監査レコードはそれぞれの監査証跡に引き続き生成されます。ただし、新しく従来の監査設定を作成することや、既存の従来の監査設定を更新することはできません。既存の従来の監査設定を削除することのみ可能です。

従来の監査構成から統合監査ポリシーに早急に移行することをお薦めします。ほとんどの場合、移行は簡単です。Oracle Databaseには、開始に役立つ事前定義された一連の統合監査ポリシーが用意されています。Oracleデータベースのインストールをリリース11gからアップグレードした場合は、少なくとも、最も一般的なセキュリティとコンプライアンスのニーズに対応する次の事前定義済ポリシーを有効にする必要があります。

  • ALTER ANY TABLEシステム権限の監査などのセキュアな構成監査オプション(ORA_SECURECONFIG)
  • ログオン失敗(ORA_LOGIN_LOGOUT)

リリース12.2以降で作成されたすべての新しいOracleデータベースでは、事前定義済の統合監査ポリシーORA_SECURECONFIGORA_LOGIN_LOGOUTが自動的に有効化されます。データベースのアップグレード中には、これらの事前定義済統合監査ポリシーは有効になりません。

従来の監査設定を高度にカスタマイズしていた場合は、統合監査ポリシーに移行するための次の選択肢があります。

  • 統合監査の豊富な機能を使用して、カスタムの統合監査ポリシーを作成することで、監査ポリシーをより条件的、選択的、重点的なものにします。たとえば、表またはデータベースに対するアクションを監査し、アプリケーション・コンテキスト値を監査し、その監査結果をフィルタして最上位レベルのアクティビティのみを表示するポリシーを作成できます。統合監査の結果をさらにフィルタする条件を作成できます。SQLファイアウォール、Oracle Database Vault、Oracle Label Securityなど、他の多くのOracle機能に固有のポリシーを作成することもできます。
  • 統合監査ポリシーの作成に関連する構文に詳しくない場合は、My Oracle Supportノート2909718.1で入手可能な構文コンバータ・スクリプトを使用してください。これにより、現行の従来の監査構成設定を構文的に正しい統合監査ポリシーに変換する.sqlスクリプトを作成できます。この変換の完了後は、ポリシーを検査して、条件の作成やアプリケーション・コンテキスト値の監査などの様々な統合監査の機能を組み込んでからポリシーを有効にするようにお薦めします。

従来の監査設定の統合監査ポリシーへの変換が完了したら、従来の監査設定は削除する必要があります。DBMS_AUDIT_MGMT PL/SQLパッケージで作成していた設定は適切に変更してください。

統合監査のベスト・プラクティスの詳細は、Oracleテクニカル・レポートのOracle Database統合監査: ベスト・プラクティス・ガイドラインを参照してください。

29.7 監査の実行者

Oracleでは監査を実行するユーザー用にAUDIT_ADMINAUDIT_VIEWERという2つのロールが用意されています。

これらのロールによって提供される権限を次に示します。

  • AUDIT_ADMINロール。このロールでは、統合およびファイングレイン監査ポリシーの作成、AUDITおよびNOAUDIT SQL文の使用、監査データの表示、および監査証跡の管理が可能です。このロールは、信頼できるユーザーにのみ付与します。次の権限のリストが用意されています。

    • NOAUDIT文*
    • AUDIT POLICY
    • NOAUDIT POLICY
    • CREATE AUDIT POLICY
    • ALTER AUDIT POLICY
    • DROP AUDIT POLICY
    • DBMS_FGA PL/SQLパッケージの実行
    • DBMS_AUDIT_MGMT PL/SQLパッケージの実行
    • 次の監査証跡表およびビューの選択:
      • SYS.AUD$表*
      • SYS.USER_AUDIT_TRAILデータ・ディクショナリ・ビュー*
      • SYS.CDB_AUDIT_TRAILデータ・ディクショナリ・ビュー*
      • SYS.FGA_LOG$表*
      • SYS.DBA_FGA_AUDIT_TRAILデータ・ディクショナリ・ビュー*
      • SYS.CDB_FGA_AUDIT_TRAILデータ・ディクショナリ・ビュー*
      • SYS.DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビュー*
      • SYS.CDB_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビュー*
      • SYS.X$UNIFIED_AUDIT_TRAIL動的パフォーマンス・ビュー
      • SYS.V$UNIFIED_AUDIT_TRAIL動的パフォーマンス・ビュー
      • SYS.GV$UNIFIED_AUDIT_TAIL動的パフォーマンス・ビュー
      • AUDSYS.AUD$UNIFIED
      • AUDSYS.UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビュー
      • AUDSYS.CDB_UNFIIED_AUDIT_TRAILデータ・ディクショナリ・ビュー
    • ALTER SYSTEM文を使用して、次のシステム・パラメータを変更可能:
      • AUDIT_FILE_DEST *
      • AUDIT_TRAIL *
      • AUDIT_SYS_OPERATIONS *
      • AUDIT_SYSLOG_LEVEL *
      • UNIFIED_AUDIT_SYSTEMLOG
      • UNIFIED_AUDIT_COMMON_SYSTEMLOG
  • AUDIT_VIEWERロール。このロールでは、ユーザーによる監査データの表示と分析が可能です。これは、DBMS_AUDIT_UTIL PL/SQLパッケージに対するEXECUTE権限を提供します。このロールが必要なユーザーの種類は、通常は外部監査者です。次の権限のリストが用意されています。

    • SYS.AUD$表*
    • SYS.USER_AUDIT_TRAILデータ・ディクショナリ・ビュー*
    • SYS.CDB_AUDIT_TRAILデータ・ディクショナリ・ビュー*
    • SYS.FGA_LOG$表*
    • SYS.DBA_FGA_AUDIT_TRAILデータ・ディクショナリ・ビュー*
    • SYS.CDB_FGA_AUDIT_TRAILデータ・ディクショナリ・ビュー*
    • SYS.DBA_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビュー*
    • SYS.CDB_COMMON_AUDIT_TRAILデータ・ディクショナリ・ビュー*
    • SYS.X$UNIFIED_AUDIT_TRAIL動的パフォーマンス・ビュー
    • SYS.V$UNIFIED_AUDIT_TRAIL動的パフォーマンス・ビュー
    • SYS.GV$UNIFIED_AUDIT_TAIL動的パフォーマンス・ビュー
    • AUDSYS.AUD$UNIFIED
    • AUDSYS.UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビュー
    • AUDSYS.CDB_UNFIIED_AUDIT_TRAILデータ・ディクショナリ・ビュー

監査ポリシーを変更するか、監査証跡を変更する(古い監査データの削除を含む)には、AUDIT_ADMINロールが付与されている必要があります。監査者は、AUDIT_VIEWERロールが付与された後に監査データを表示できます。

*非推奨。従来の監査で使用されます。Oracle Database 23c以降では従来の監査はサポートされませんが、まだ従来の監査設定がある場合はアクセスできます。

29.8 マルチテナント環境での統合監査

ポリシーのタイプに応じて、各PDBまたはCDBに監査設定を適用できます。

ルートを含め、各PDBには、それ固有の統合監査証跡があります。

  • CREATE AUDIT POLICYおよびAUDIT文で作成された統合監査ポリシー: ルートと個々のPDBの両方のポリシーを作成できます。

  • SYSLOGに書き込まれた監査レコード: UNIXプラットフォームでは、CDBルートでUNIFIED_AUDIT_COMMON_SYSTEMLOG初期化パラメータを設定して、特定の統合監査証跡列がSYSLOGに書き込まれるようにできます。WindowsとUNIXの両方で、UNIFIED_AUDIT_SYSTEMLOGパラメータをルートとPDBレベルの両方で設定できます。

  • ファイングレイン監査ポリシー: ルートではなく、個々のPDBのポリシーのみを作成できます。

  • 監査証跡の削除: ルートと個々のPDBの両方に対して、削除操作を実行できます。

29.9 分散データベースでの監査

データベース・インスタンスでは直接接続しているユーザーによって発行された文のみが監査されるため、監査はサイトで自律的に実行されるといえます。

ローカルのOracle Databaseノードでは、リモート・データベースで発生するアクションを監査できません。