28 監査の概要

Oracle Databaseは、業界で最も包括的な監査機能を備えており、誰が何のアクションをいつ実行したかについて、および監査レコードを生成したアクティビティに関連するコンテキストに関する詳細情報を取得できます。

  • 監査とは
    データベース監査とは、データベース・アクティビティの最も正確な記録です。監査では、権限の使用、高い権限を持つユーザーのアクティビティ、機密データへのアクセス、データベース・オブジェクトに対して実行されるアクション、およびデータベース設定に対する変更を追跡します。
  • 監査を使用する理由
    通常は、監査を使用してユーザー・アクティビティを監視します。
  • 監査のベスト・プラクティス
    監査のベスト・プラクティスに関するガイドラインに従ってください。
  • 統合監査とその利点
    統合監査は、Oracle Database 12cで導入され、監査機能が大幅に拡張されました。
  • 監査の実行者
    Oracleでは監査を実行するユーザー用にAUDIT_ADMINとAUDIT_VIEWERという2つのロールが用意されており、業務の分離が可能です。
  • 従来の監査のサポート終了への対応
    Oracle Database 23ai以降では、従来の監査はサポートされなくなりました。かわりに統合監査を使用することをお薦めします。
  • マルチテナント環境での統合監査
    ポリシーのタイプに応じて、個々のPDBに、またはCDBに監査設定を適用できます。
  • 分散データベースでの監査
    データベース・インスタンスでは直接接続しているユーザーによって発行された文のみが監査されるため、監査はサイトで自律的に実行されるといえます。

関連トピック

親トピック: 監査を使用したデータベース・アクティビティの監視

28.1 監査とは

データベース監査とは、データベース・アクティビティの最も正確な記録です。監査では、権限の使用、高い権限を持つユーザーのアクティビティ、機密データへのアクセス、データベース・オブジェクトに対して実行されるアクション、およびデータベース設定に対する変更を追跡します。

データベース監査は、過去10年間で機能性と評価の高さの両方で着実に進化しており、現在はほとんどの組織で必須です。不正使用を検出するだけでなく、一般データ保護規則(GDPR)、Payment Card Industry(PCI)、California Consumer Privacty Act(CCPA)、世界中のその他のプライバシ規制など、様々な規制に準拠していることを確認するためにも、監査が必要とされています。

データベース監査は通常、次のユースケースで使用されます:

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

データベース監査は、ネットワーク上で行われる接続だけでなく、直接ローカル・ログイン、再帰的SQL、動的SQLおよびストアド・プロシージャを介しても、データベース・アクティビティの最も正確なレコードを提供します

監査レコードによって、操作の詳細、実行されたSQL文のタイプ、強力なシステム権限の使用、実行された操作、操作に関連するデータベース・オブジェクト、フォレンジック分析に役立つその他のセッション詳細など、完全な実行コンテキストが提供されます。

成功した操作と失敗した操作の両方に対して監査を構成できますが、解析エラーまたは構文エラーは監査されません。また、特定のユーザーを監査に含めることも除外することもできます。監査は、ネットワーク暗号化、アクセス・パス、ユーザーなどの外部接続ファクタとは無関係であり、発生した実際のイベントの信頼できるソースとして常に使用できます。

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

Oracle Database監査は、データベースの後続のリリースごとに拡張されています。従来の監査は、Oracle Database 12cより前のリリースでの、データベース監査の以前のアプローチでした。統合監査は、その後Oracle Database 12cで導入されました。このOracle Database 12cでは、特定のセキュリティ要件に対応するために微調整できる、堅牢であり、高度にカスタマイズ可能なフレームワークを実現するために、監査機能が大幅に拡張されました。従来の監査はOracle Database 23aiではサポートされなくなり、Oracleでは統合監査の使用をお薦めします。

Oracle Databaseの監査(統合監査)は、デフォルトで有効になっています。次の一連のガイドラインに従って、データベース監査要件が最も一般的なセキュリティおよびコンプライアンスのニーズを満たしていることを確認します:

  1. 常時オンの必須監査を最大限に活用します。セキュリティが重視される特定のデータベース・アクティビティは、Oracle Databaseで強制的に監査され、無効化できません。複製しないでください。
  2. 事前定義の統合監視ポリシーを使用します。Oracle Databaseには、ほとんどの規制機関で必要とされる標準の監査設定を網羅した事前定義の統合監査ポリシーが提供されています。
    1. 事前定義されたORA_SECURECONFIGおよびORA_LOGIN_LOGOUT統合監査ポリシーは、ほとんどのデプロイメントで自動的に有効になります。まだ有効にしていない場合は、必ず有効にしてください。
    2. 自律型データベースには、デフォルトで有効になっている多数の事前定義済の監査ポリシーが用意されています。
    3. Oracle Data SafeまたはOracle Audit Vault and Database Firewall (AVDF)を使用して企業全体のデータベース・アクティビティを監視している場合、これらの製品には、1回のクリックでプロビジョニングするための事前定義済の監査ポリシーが多数用意されています。
  3. 特殊なユース・ケースには、カスタム監査ポリシーを作成します。Oracle Databaseでは、特定のニーズに応じてカスタム監査ポリシーを柔軟に作成および有効化できます。特殊なニーズに対しては、統合監査ポリシーまたはファイングレイン監査ポリシーを定義できます。

データベース監査は、アラートの生成、分析およびレポートのために監査データを収集および格納するデータベース・アクティビティ・モニタリング(DAM)ソリューションによって頻繁に拡張されます。DAMソリューションを提供するOracle Databaseセキュリティ製品には、Oracle Data SafeとOracle Audit Vault and Database Firewall (AVDF)が含まれます。

関連トピック

親トピック: 監査の概要

28.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)

データベースを監査することをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは規制コンプライアンス要件を満たすことができます。これにより、業務を監視し、異常なアクセス・パターンを検出できます。

監査では、データベース・ユーザーだけでなく、非データベース・ユーザーのデータベース・アクティビティも監視できます。非データベース・ユーザーとは、標準的なアプリケーション・サービス・アカウントであり、CLIENT_IDENTIFIER属性を使用してデータベースで認識されます。このタイプのユーザーを監査する場合は、統合監査またはファイングレイン監査ポリシー、あるいはOracle Database Real Application Securityを使用できます。

親トピック: 監査の概要

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

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

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

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

  • 統合監査証跡のために別の表領域を構成することをお薦めします。DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATIONプロシージャを使用できます。Oracle Database Standard EditionおよびExpress Editionでは、統合監査の表領域の関連付けは1回のみ可能であることに注意してください。この関連付けは、統合監査証跡の監査レコードを生成する前に行う必要があります。表領域を関連付けると、表領域を変更できなくなりますが、これはパーティション化がOracle Database Enterprise Editionでのみサポートされるためです。この制限は、Enterprise Editionには存在しません。

関連トピック

親トピック: 監査の概要

28.4 統合監査とその利点

統合監査は、Oracle Database 12cで導入され、監査機能が大幅に拡張されました。

統合監査では、次のソースから監査レコードを取得し、その監査レコードを単一の統合監査証跡に書き込むことができます:

  • 統合監査ポリシーおよび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の両方の環境で使用できます。統合監査証跡では、すべての監査ソースで標準化された列名およびデータ型を使用して、監査レコード形式も正規化されます。統合され、正規化された統合監査証跡により、様々な監査ソースで生成された監査レコードの収集、分析および管理が簡素化されます。一貫した書式設定により、監査データのレポートおよび分析が簡素化されます。

統合監査では、ユーザーが監査証跡を改ざんできないため、高度な監査証跡の整合性が提供されます。統合監査証跡はAUDSYSスキーマに格納され、誰もデータベース内のそのスキーマにはログインできません。AUD$UNIFIEDは、INSERTアクティビティのみを許可する特殊な表です。AUD$UNIFIED表の内容を直接切捨て、削除または更新しようとすると失敗し、監査レコードが生成されます。組込みの監査データ管理DBMS_AUDIT_MGMTパッケージを使用して、監査データを管理できます。また、透過的データ暗号化(TDE)を使用して監査表領域を暗号化できます。統合監査表は、Oracle Database Vaultレルムで保護できます。

統合監査では、監査構成がはるかにシンプルで、ニーズにフォーカスしています。名前付き監査ポリシーを一度作成すると、複数の次元(ユーザーやロールなど)で適用できるため、柔軟性とシンプルさが大幅に向上します。統合監査では選択的に監査し、関連するアクティビティを取得できます。監査条件は、アプリケーション・コンテキスト、セッション・コンテキストおよび組込み関数に基づく場合があります。CREATE AUDIT POLICY文でONLY TOPLEVEL句を指定すると、エンド・ユーザーが直接発行するSQL文のみを監査するため、機密表に対してエンド・ユーザーが開始するアクションにのみ焦点を当てるのに役立ちます。このような統合監査の構成の柔軟性は、監査ポリシーを微調整し、ニーズに応じて監査データを収集するのに役立ちます。

統合監査は、監査データ(AUDIT_ADMINおよびAUDIT_VIEWER)を管理し、表示する業務を分離するための様々なロールを提供します。

特権ユーザーの監査や統合監査によるキー・データベース操作の監査の一般的なユースケースでは、パフォーマンスへの影響が非常に低く、その週全体の監査ボリュームが少ないため、測定することもできません。監査ロードが1秒当たり数百の監査イベントに増加すると、パフォーマンスが1%影響することがわかります。ほとんどのユースケースでは、これ以上のオーバーヘッドは見られませんが、組織がアプリケーションの使用状況を監査する場合は、監査ポリシーをチューニングすることをお薦めします。TPC-C混合アプリケーション・ワークロードを使用した内部パフォーマンス・テストでは、統合監査を使用すると、1時間当たり最大360,000の監査レコードを監査するときのCPUオーバーヘッドが1桁台中盤で表示されることがあります。最大監査ロードが1時間当たり最大1,800,000の監査レコードの場合、追加のオーバーヘッドは1桁のままです。

ノート:

1. データベースが書込み可能な場合、監査レコードは統合監査証跡に書き込まれます。データベースが書込み可能でない場合(データベースがクローズされている場合またはOracle Data GuardADGでのように読取り専用の場合など)、Oracle Databaseによって、監査レコードが$ORACLE_BASE/audit/$ORACLE_SIDディレクトリの外部オペレーティング・システムの過剰.BINファイルに書き込まれます。.BINファイルに存在する監査データも、UNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューに表示されます。

関連トピック

親トピック: 監査の概要

28.5 監査の実行者

Oracleでは監査を実行するユーザー用にAUDIT_ADMINとAUDIT_VIEWERという2つのロールが用意されており、業務の分離が可能です。

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

  • AUDIT_ADMINロール。このロールでは、統合およびファイングレイン監査ポリシーの作成、作成された統合監査およびファイングレイン監査ポリシーの有効化、無効化、削除、監査データの表示、監査証跡の管理が可能です。このロールでは、古い監査データの削除を含め、監査ポリシーや監査証跡を変更することもできます。このロールは、信頼できるユーザーにのみ付与します。ユーザーSYSにはこのロールがあります。

    AUDIT_ADMINの権限のリストは次のとおりです:

    • 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権限を提供します。このロールが必要なユーザーの種類は、通常は外部監査者です。監査者は、AUDIT_VIEWERロールが付与された後に監査データを表示できます。ユーザーが監査ポリシーの作成ではなく、ビューの問合せのみを必要としている場合は、AUDIT_VIEWERロールを付与します。ユーザーSYSにはこのロールがあります。

    AUDIT_VIEWERの権限のリストは次のとおりです:

    • 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データ・ディクショナリ・ビュー

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

関連トピック

親トピック: 監査の概要

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

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

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

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

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

リリース12.2以降で作成されたすべての新しいOracleデータベースでは、事前定義の統合監査ポリシーORA_SECURECONFIGがデフォルトで有効になっています。リリース23ai以降では、事前定義の統合監査ポリシーORA_LOGIN_LOGOUTが使用可能になり、デフォルトで有効になっています。データベースのアップグレード中には、これらの事前定義済統合監査ポリシーは有効になりません。

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

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

従来の監査設定の統合監査ポリシーへの変換が完了したら、この生成されたスクリプトを実行する前に慎重に確認して統合監査ポリシーを有効にし、既存の従来の監査構成を削除します。

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

ノート:

統合監査は、従来の監査で使用されていた初期化パラメータには依存しません。これらの初期化パラメータのリストは、従来の監査から統合監査への移行に関する考慮事項の機能列を参照してください。

関連トピック

親トピック: 監査の概要

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

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

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

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

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

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

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

関連トピック

親トピック: 監査の概要

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

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

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

親トピック: 監査の概要