25 監査の概要
監査では、ユーザーがデータベースで行う変更を追跡します。
ノート:
特に断りのないかぎり、この章では、すべての監査レコードが一元管理される完全な統合監査の使用方法について説明します。
- 監査とは
監査とは、構成済のデータベース・アクション(データベース・ユーザーと非データベース・ユーザーの両方からのアクション)を監視して記録することです。 - 監査を使用する理由
通常は、監査を使用してユーザー・アクティビティを監視します。 - 監査のベスト・プラクティス
監査のベスト・プラクティスに関するガイドラインに従ってください。 - 統合監査とは
統合監査では、統合監査証跡により、次の各種ソースから監査情報が取得されます。 - 統合監査証跡の利点
統合監査証跡には、次のように多くの利点があります。 - データベースが統合監査に移行したかどうかの確認
V$OPTION
動的ビューは、データベースが統合監査に移行されたかどうかを示します。 - 混合モードの監査
混合モードの監査は、新しくインストールしたデータベースでのデフォルトの監査です。 - 監査の実行者
Oracleでは監査を実行するユーザー用にAUDIT_ADMIN
とAUDIT_VIEWER
という2つのロールが用意されています。 - マルチテナント環境での統合監査
ポリシーのタイプに応じて、個々のPDBに、またはCDBに監査設定を適用できます。 - 分散データベースでの監査
データベース・インスタンスでは直接接続しているユーザーによって発行された文のみが監査されるため、監査はサイトで自律的に実行されるといえます。
関連トピック
親トピック: 監査を使用したデータベース・アクティビティの監視
監査とは
監査とは、構成済のデータベース・アクション(データベース・ユーザーと非データベース・ユーザーの両方からのアクション)を監視して記録することです。
非データベース・ユーザーとは、CLIENT_IDENTIFIER
属性を使用してデータベースで認識されるアプリケーション・ユーザーのことです。ユーザーのこの対応を監査する場合は、統合監査ポリシー条件、ファイングレイン監査ポリシー、またはOracle Database Real Application Securityを使用できます。
実行された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
表領域に格納されます。統合監査証跡のために別の表領域を構成することをお薦めします。Enterprise Editionを除くほとんどのOracle Databaseエディションでは、統合監査の表領域の関連付けは1回のみになります。この関連付けは、統合監査証跡の監査レコードを生成する前に行う必要があります。表領域を関連付けると、Enterprise Editionではパーティション化のみがサポートされるため、表領域を変更できません。
次のいずれかの方法を使用して監査を構成できます。
-
監査設定を1つの統合監査ポリシーにグループ化する。データベースで必要なすべての監査設定を定義する統合監査ポリシーを1つ以上作成できます。これを実行する方法は、統合監査ポリシーおよびAUDIT文を使用したアクティビティの監査に説明されています。
-
デフォルトの統合監査ポリシーのいずれかを使用する。Oracle Databaseには、ほとんどの規制機関で必要とされる標準の監査設定を網羅した事前定義の統合監査ポリシーが提供されています。事前定義の統合監査ポリシーを使用したアクティビティの監査を参照してください。
-
ファイングレイン監査ポリシーを作成する。アクションの発生時刻などのデータを取得するファイングレイン監査ポリシーを作成できます。ファイングレイン監査を使用した特定のアクティビティの監査を参照してください。
データベースを監査することをお薦めします。監査は、強固な内部制御を規定する有効な方法であるため、サイトでは米国サーベンス・オクスリー法(Sarbanes-Oxley Act)に定義されている法令順守要件を満たすことができます。監査を使用すると、ビジネス操作を監視でき、企業ポリシーから逸脱する可能性があるアクティビティを検出できます。この結果、データベースおよびアプリケーション・ソフトウェアへのアクセスが厳密に制御されるようになり、パッチが予定どおりに適用され、非定型の変更が防止されます。有効な監査ポリシーを作成することで、監査および個人のコンプライアンスに関する監査レコードを生成できます。選択的に監査を行い、ビジネス・コンプライアンスのニーズを満たしていることを確認してください。
親トピック: 監査の概要
監査を使用する理由
通常は、監査を使用してユーザー・アクティビティを監視します。
監査を使用すると、次の内容が可能になります。
-
アクションに対するアカウンタビリティの有効化。特定のスキーマ、表または行に対して実行されるアクション、あるいは特定の内容に影響を与えるアクションなどがあります。
-
それぞれのアカウンタビリティに基づいた、ユーザー(または侵入者などの他者)による不適切なアクションの防止。
-
疑わしいアクティビティの調査。たとえば、ユーザーが表からデータを削除しようとした場合、セキュリティ管理者は、そのデータベースへのすべての接続と、そのデータベースにあるすべての表からの行の削除(成功および失敗)をすべて監査できます。
-
認可されていないユーザーのアクションを監査人に通知します。たとえば、認可されていないユーザーがデータを変更または削除を実行できるなど、予期した以上の権限を持っている場合に、ユーザー認可を再評価できます。
-
特定のデータベース・アクティビティに関するデータの監視と収集。たとえば、データベース管理者は、更新された表、実行された論理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)
-
親トピック: 監査の概要
監査のベスト・プラクティス
ベスト・プラクティスに関するガイドラインに従ってください。
-
原則として、法令順守要件を満たすために必要な量の情報を収集するように監査方針を策定しますが、大きなセキュリティ問題の原因となるアクティビティに焦点を合せてください。たとえば、データベース内のすべての表を監査するのではなく、給与など機密性の高いデータが入った表列を監査するのが実用的です。統合監査とファイングレイン監査の両方により、監査対象の特定のアクティビティに焦点を合せた監査ポリシーの策定に使用できるメカニズムがあります。
-
監査証跡データを定期的にアーカイブして削除します。詳細は、監査証跡レコードの削除を参照してください。
統合監査とは
統合監査では、統合監査証跡により、次の各種ソースから監査情報が取得されます。
統合監査では、次のソースから監査レコードを取得できます。
-
統合監査ポリシーおよび
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
ディレクトリの新しい形式のオペレーティング・システム・ファイルに書き込まれます。
関連トピック
親トピック: 監査の概要
統合監査証跡の利点
統合監査証跡には、次のように多くの利点があります。
例:
-
統合監査の有効化後、以前のリリースで使用されていた初期化パラメータには依存しません。これらの初期化パラメータのリストは、表G-1を参照してください。
-
SYS
監査証跡のレコードを含む、Oracle Databaseインストールのすべての監査コンポーネントの監査レコードは、1つの場所に1つの形式で配置されるため、様々な場所を参照して各種形式の監査証跡を探す必要はありません。この統合ビューにより、監査者は様々なコンポーネントから監査情報を相互に関連付けることができます。たとえば、INSERT
文の実行中にエラーが発生した場合は、標準の監査でエラー番号と実行されたSQLを示すことができます。Oracle Database Vault固有の情報では、このエラーがコマンド・ルール違反またはレルム違反のどちらの原因で発生したかを示すことができます。別のAUDIT_TYPE
の監査レコードが2つあります。この統合を適切に設定すると、AUDIT_TYPE
がStandard Audit
に設定されたSYS
監査レコードが表示されます。 -
監査証跡の管理とセキュリティは、監査証跡を単一にすることでも改善されます。
-
監査の全体的なパフォーマンスが大幅に向上します。デフォルトでは、監査レコードは
AUDSYS
スキーマの内部リレーショナル表に自動的に書き込まれます。 -
SYS
管理ユーザーだけでなく、サポートされているコンポーネント(この項の最初に記載)を各自で監査できる名前付きの監査ポリシーを作成できます。さらに、条件と除外を各自のポリシーに作成することもできます。 -
Oracle Audit Vault and Database Firewall環境を使用している場合は、このデータがすべて1つの場所から取得されるため、統合監査証跡により、監査データの収集がかなり容易になります。
親トピック: 監査の概要
データベースが統合監査に移行したかどうかの確認
V$OPTION
動的ビューは、データベースが統合監査に移行されたかどうかを示します。
-
次に示すように
Unified Auditing
を入力して、V$OPTION
動的ビューのVALUE
列を問い合せます。SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing'; PARAMETER VALUE ---------------- ---------- Unified Auditing TRUE
この出力には、統合監査が有効であることが表示されます。統合監査が有効でない場合、出力はFALSE
になります。
混合モードの監査
混合モードの監査は、新しくインストールしたデータベースでのデフォルトの監査です。
- 混合モードの監査について
混合モード監査では、従来の監査機能(リリース12cより前のリリースの監査機能)と新しい監査機能(統合監査)の両方を使用できます。 - 統合監査の有効化
デフォルトでは、Oracle Databaseは混合モード監査を使用し、統合監査と従来の監査の両方をサポートします。 - 有効にした監査のタイプがデータベースの作成でどのように決定されるか
統合監査では、新しい形式のオペレーティング・システム・ファイルの場所として、$ORACLE_BASE/audit
ディレクトリが使用されます。 - 混合モードの監査の機能
混合モードの監査では、次の機能が提供されます。
親トピック: 監査の概要
混合モードの監査について
混合モード監査では、従来の監査機能(リリース12cより前のリリースの監査機能)と新しい監査機能(統合監査)の両方を使用できます。
新しいデータベースを作成すると、デフォルトで混合モード監査が使用されます。
データベースは2つのモード(混合モード監査または完全な統合監査モード)のいずれでも有効にできます。これらのどちらのモードでも統合監査の機能は有効になりますが、両者に違いがあります。混合モードでは、新しい統合監査機能を従来の監査機能と並行して使用できます。完全な統合監査では、統合監査機能のみ使用します。
ノート:
Oracle Databaseリリース20 c以降では、従来の監査は非推奨です。かわりに統合監査を使用することをお薦めします。
表25-1に、これらの2つのモードの機能とその有効化の方法のサマリーを示します。
表25-1 混合モード監査と完全な統合監査の違い
モード | 機能 | 有効化する方法 |
---|---|---|
混合モードの監査 |
従来の監査と統合監査の両方 |
任意の統合監査ポリシーを有効にします。データベースを再起動する必要はありません。 |
完全な統合監査 |
統合監査のみ |
|
混合モードは統合監査を導入するためのもので、その機能や特徴、利点を知ることができます。混合モードで、統合監査を使用するように既存のアプリケーションおよびスクリプトを移行することができます。完全な統合監査を使用することにしたら、統合監査オプションを有効にしてoracle
バイナリを再リンクし、統合監査をOracleデータベースで実行する唯一の監査機能として有効にします。混合モードに戻す必要がある場合は戻すことができます。
以前のリリース同様、従来の監査機能は、AUDIT_TRAIL
初期化パラメータの影響を受けます。混合モードの監査の場合のみ、このパラメータを対応する従来の監査証跡に設定する必要があります。この従来の監査証跡には、統合監査証跡とともに、監査レコードが移入されます。
データベースを現在のリリースにアップグレードすると、従来の監査が保存され、新規監査レコードが従来の監査証跡に書き込まれます。移行の完了後も、以前のリリースの監査レコードはこれらの監査証跡で使用可能です。企業の保存ポリシーに基づき、DBMS_AUDIT_MGMT
PL/SQLプロシージャを使用して、これらの古い監査証跡をアーカイブして削除できます。
統合監査の有効化
デフォルトでは、Oracle Databaseは混合モード監査を使用し、統合監査と従来の監査の両方をサポートします。
完全な統合監査モード(監査パフォーマンスを向上させる)に移行する準備が整った後は、Oracle Databaseアップグレード・ガイドの説明に従って、oracle
バイナリをuniaud_on
とリンクし、データベースを再起動します。
親トピック: 混合モードの監査
有効にした監査のタイプがデータベースの作成でどのように決定されるか
統合監査では、新しい形式のオペレーティング・システム・ファイルの場所として、$ORACLE_BASE/audit
ディレクトリが使用されます。
新しく作成されたデータベースでは、事前定義のポリシーORA_SECURECONFIG
により、混合モードの監査がデフォルトで有効になります。
統合監査の使用を開始するには、少なくとも1つの統合監査ポリシーを有効にし、その使用を停止するには、すべての統合監査ポリシーを無効にする必要があります。
関連トピック
親トピック: 混合モードの監査
混合モードの監査の機能
混合モードの監査では、次の機能が提供されます。
これらの機能は次のとおりです。
-
既存の監査初期化パラメータの
AUDIT_TRAIL
、AUDIT_FILE_DEST
、AUDIT_SYS_OPERATIONS
およびAUDIT_SYSLOG_LEVEL
をすべて使用できるようにします。 -
従来の監査証跡に必須の監査レコードのみを書き込みます。
-
標準の監査レコードを標準の監査構成に基づくようにし、
AUDIT_TRAIL
初期化パラメータで指定された監査証跡にこれらのレコードを書き込みます。ただし。標準の監査証跡レコードは統合監査ポリシーに基づいても生成され、これらの監査レコードのみが統合監査証跡に書き込まれることに注意してください。統合監査ポリシーの結果として生成された標準の監査レコードは、統合監査ポリシーの有効化のセマンティクスに従います。
-
管理ユーザー・セッションにより、
SYS
監査レコードが生成されます。これらのレコードは、AUDIT_SYS_OPERATIONS
初期化パラメータがTRUE
に設定されている場合に書き込まれます。このプロセスでは、レコードは従来の監査証跡のみに書き込まれます。ただし、統合監査ポリシーが管理ユーザーで有効な場合は、これらの統合監査レコードも統合監査証跡に書き込まれます。 -
従来の監査証跡に書き込まれる監査レコードの形式は、Oracle Database 11gリリース2と同じままです。
-
デフォルトでは、Oracle Databaseで統合監査レコードが
AUDSYS
スキーマの内部リレーショナル表に即座に書き込まれます。詳細は、AUDSYSスキーマへの統合監査証跡レコードの書込みを参照してください。 -
監査レコードの書込みのパフォーマンス・コストは、監査レコードを生成して従来の監査証跡と統合監査証跡に書き込むのに必要な総時間と同等です。
-
混合モードの監査は、統合監査モードの機能の一部です。新しい形式の監査ポリシーと監査証跡に問題ない場合は、統合監査モードに移行することをお薦めします。統合監査に移行するには、『Oracle Databaseアップグレード・ガイド』を参照してください。
親トピック: 混合モードの監査
監査の実行者
Oracleでは監査を実行するユーザー用にAUDIT_ADMIN
とAUDIT_VIEWER
という2つのロールが用意されています。
任意の種類の監査を実行するには、AUDIT_ADMIN
ロールが付与されている必要があります。監査者は、AUDIT_VIEWER
ロールが付与された後に監査データを表示できます。
これらのロールによって提供される権限を次に示します。
-
AUDIT_ADMINロール。このロールでは、統合およびファイングレイン監査ポリシーの作成、
AUDIT
およびNOAUDIT
SQL文の使用、監査データの表示、および監査証跡の管理が可能です。このロールは、信頼できるユーザーにのみ付与します。 -
AUDIT_VIEWERロール。このロールでは、ユーザーによる監査データの表示と分析が可能です。これは、
DBMS_AUDIT_UTIL
PL/SQLパッケージに対するEXECUTE
権限を提供します。このロールが必要なユーザーの種類は、通常は外部監査者です。
ノート:
以前のリリースでは、ユーザーは、追加の権限なしで、各自のスキーマのオブジェクトへの監査構成の追加と削除が許可されていました。この機能は使用できなくなりました。
親トピック: 監査の概要
マルチテナント環境での統合監査
ポリシーのタイプに応じて、各PDBまたはCDBに監査設定を適用できます。
ルートを含め、各PDBには、それ固有の統合監査証跡があります。
-
CREATE AUDIT POLICYおよびAUDIT文で作成された統合監査ポリシー: ルートと個々のPDBの両方のポリシーを作成できます。
-
SYSLOGに書き込まれた監査レコード: UNIXプラットフォームでは、CDBルートで
UNIFIED_AUDIT_COMMON_SYSTEMLOG
初期化パラメータを設定して、特定の統合監査証跡列がSYSLOGに書き込まれるようにできます。WindowsとUNIXの両方で、UNIFIED_AUDIT_SYSTEMLOG
パラメータをルートとPDBレベルの両方で設定できます。 -
ファイングレイン監査ポリシー: ルートではなく、個々のPDBのポリシーのみを作成できます。
-
監査証跡の削除: ルートと個々のPDBの両方に対して、削除操作を実行できます。
分散データベースでの監査
データベース・インスタンスでは直接接続しているユーザーによって発行された文のみが監査されるため、監査はサイトで自律的に実行されるといえます。
ローカルのOracle Databaseノードでは、リモート・データベースで発生するアクションを監査できません。
親トピック: 監査の概要