Oracle Database Security：データベース監査

この記事では、Oracle Database Securityを継続し、Oracleの標準データベース監査、監査トリガー、および監査ポリシーに関するいくつかの重要な事実を示します。データベース監査には、確立されたデータベースアクティビティセットとイベントの監視と永続的な登録の2つのコンポーネントがあります。データベース監査の目的は、否認防止、疑わしいアクティビティの調査、承認（リソースアクセス）に関する構成によって生成された問題の検出、実際の法律と管理の遵守です。

標準監査

どのような活動を監査しますか？データベースの開始と停止、およびデータベース管理者によって行われた接続は、Oracleによって暗黙的に監査され、データはオペレーティングシステムに自動的に保存されます。次の表は、監視できるその他のアクティビティを示しています。

監査された活動はどこに保管しますか？

• データベース内 、データベース監査証跡を使用します。2つの可能性があります。
• • audit_trail =DB
    これは、次のコードで実行できます：

    alter system set audit_trail=db scope=spfile;

• • audit_trail =DB、EXTENDED
    次のコードを使用：

    alter system set audit_trail= db, extended scope=spfile;

  DBとDB、EXTENDEDの違いは、2番目がSYS.AUD$テーブルのSQLBIND列とSQLTEXTCLOB列に入力されることです。

• 外部 、オペレーティングシステムの監査証跡を使用します。次の可能性があります。
  • audit_trail =OS
    使用されるコードは次のとおりです：

    alter system set audit_trail=os scope=spfile;

  • audit_trail =XMLおよびAUDIT_FILE_DEST=ファイルパス（暗黙的に$ ORACLE_BASE / admin / $ ORACLE_SID / adump）
    コード：

    alter system set audit_trail=xml scope=spfile;

保存された監査済みアクティビティの現在の構成を見つけるために、小文字で記述された次のクエリを実行できます。

select value from v$parameter where name='audit_trail';

より便利なコマンド：

[テーブルID=43 /]

それでは、データベース監査の例をいくつか見てみましょう。

データベースに保存されている監査情報を使用した標準監査の例を次に示します。

監査される情報は、データベーステーブルで実行されるSELECTステートメントで構成されます。

SQL Developerで、次のスクリプトを実行します。

alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

次に、データベースを再起動する必要があります。これを行うには、SQLPlusターミナルで、ユーザー名sysをsysdba / passwordとして接続し、次のステートメントを実行します。

SHUTDOWN IMMEDIATE
STARTUP

上記のサイズはシステムごとに異なることに注意してください。

監査証跡が正しく設定されているかどうかを確認するには、次のクエリを実行します。

select value from v$parameter where name='audit_trail';

または：

show parameter audit_trail;

監査を停止する場合は、次を実行します。

NOAUDIT SELECT TABLE;

監査によって記録されたステートメントを表示するには、次を使用できます。

select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

または

select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);

もう1つの例は、標準パスのXMLファイルに保存された監査済みデータを使用した標準監査の場合です。

alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

もう一度、データベースを再起動します。sysdba/passwordとしてusernamesysを使用してSQLPlusターミナルに接続し、SHUTDOWNIMMEDIATEおよびSTARTUPコマンドを実行します。

その後、employeesテーブルでクエリの選択、挿入、更新、削除が失敗するたびに、XMLファイルに記録する必要があります。

監査を停止する場合は、データベース開発環境で次のコマンドを実行します。

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

そして、デフォルトの監査証跡を復元します：

alter system set audit_trail=db scope=spfile;

以下は、XML監査ファイルの一部の例です。

監査された情報を削除するにはどうすればよいですか？

監査対象のデータの量は、監査対象のアクティビティの数とその頻度によって非常に大きくなる可能性があります。そのため、監査済みデータを定期的にアーカイブして、本番システムから削除することをお勧めします。

監査されたデータがデータベースに保存されている場合（データベース監査証跡）、deleteステートメントを使用できます（ただし、データをアーカイブした後でのみ！）：

DELETE FROM SYS.AUD$;

特定のデータベースオブジェクトの監査情報を削除することを選択できます。たとえば、products：

DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

監査トリガー

トリガは、イベントが発生するたびに自動的に実行されるPL/SQLプロシージャのPL/SQLブロックまたはCALL文です。トリガーには、データベースレベル（データベースステートメント）とアプリケーションレベル（たとえば、Oracleフォームのボタンを押す）の2種類があります。監査に使用されるトリガーは、データベースレベルのトリガーです。それらは次のカテゴリに分類されます：

• DMLトリガー–DMLステートメントがテーブルでトリガーされます。これらのトリガーは、レコード数に関係なくコマンドレベルで1回実行することも（ステートメントレベルでトリガーする）、FOR EVERY ROWで実行することもできます（レコードレベルでトリガーする）。レコードレベルトリガーのタイプ：ステートメント前、ステートメント後、各行の前、各行の後;
• INSTEAD OFトリガー–ビューでDMLステートメントがトリガーされます。
• SYSTEMトリガー–データベースの開始/停止、DDLステートメント、ユーザーのログイン/ログアウトなどのイベントによってトリガーされます。システムトリガーの種類：イベント後、イベント前。

SYS.TRIGGER $のクエリ テーブルまたはALL_TRIGGERS ビューは、すべてのデータベースレベルのトリガーに関する情報を提供します。たとえば、データベースとは異なるトリガータイプは、次のように見つけることができます。

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

DBA_TRIGGERSビューは、インストール時にOracle製品によって自動的に作成されたトリガーに関する情報を提供します。 SYSTEMトリガー（「BEFOREEVENT」および「AFTEREVENT」）に関する情報を検索する場合は、次のステートメントを実行できます。

SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

また、インストール時に、DMLトリガーがHRユーザースキーマに自動的に作成されます。

SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

監査の場合、必要な情報を記録するためにカスタマイズされたトリガーを作成できますが、監査された情報を格納するための特別なテーブルを作成する必要があります。

開発されたトリガーが通常のデータベースアクティビティに影響を与えないようにすることが重要です。監査の目的は、通常の日常のデータベースアクティビティを受動的に監視し、後で分析するために保存することです。したがって、ターゲットテーブルから監査テーブルに結果を返すためにINSTEADOFトリガーを作成することはお勧めしません。

ステートメントレベルのDMLトリガーは、レコードレベルのDMLトリガーと共存できます。呼び出しの順序は次のとおりです。

• ステートメントの前にトリガー
• 影響を受けるレコードごとに
  • 記録前にトリガー
  • 現在のDMLアクション
  • 記録後のトリガー
• AFTERステートメントをトリガーする

ユーザー定義のトリガーは、Oracleによれば、ステートメントが正しく、発生する可能性がある場合にのみ実行されます。間違ったDMLステートメントまたは制約に違反するステートメントの場合、エラーが返され、トリガーは実行されません。したがって、監査には、特にステートメントレベルでLMDトリガーを使用することをお勧めします。

監査トリガーの例：

会社の従業員の20000を超える給与（ここでは通貨は重要ではありません）を確立するDMLステートメントに関する情報を監査テーブル（TAB_AUDIT_EMPと呼ばれる）に記録するトリガーを作成するとします。クエリのシーケンス番号、ユーザー名、セッション、ホスト、日付をTAB_AUDIT_EMPに保存します。

これは、次の方法で実行できます。

CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;

特定の部門の従業員の給与を変更するとします。

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

次に、監視を確認します：

select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;

監査ポリシー

3番目の監査方法は、監査ポリシーを参照します。監査ポリシーの定義には、次のものが含まれます。

• 監視対象のオブジェクト（スキーマ、オブジェクト名、列）の仕様
• オブジェクトに対して監査されるアクションの仕様（SELECT、INSERT、UPDATE、DELETE）：暗黙的にそれはSELECTです
• 監査された情報を記録するために満たす必要のある条件の指定。これはトリガーのWHEN句で行われ、オプションです。
• イベントを追加で処理するイベントハンドラー。これはオプションです。

監査ポリシーは、アクティブ（ENABLEDステータス）または非アクティブ（DISABLEDステータス）になります。監査ポリシーのリストは、ALL_AUDIT_POLICIESビューに問い合わせることで取得できます。

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

監査ポリシー管理用に、DBMS_FGAパッケージがあります。このパッケージを使用するには、PL/SQLコードを作成するユーザーに権限を付与する必要があります。

grant execute on dbms_fga to username;

監査ポリシーの例：

DEPARTMENTSテーブルのマネージャー（MANAGER_ID）を変更するDMLステートメントを記録するための監査ポリシーを作成します。マネージャーに関する変更を通知するproc_audit_alertというポリシーのハンドラーを作成することを選択できます。

CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

そして、ポリシーは次のようになります。

CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

object_schema、object_name、policy_name、audit_column、statement_types、handler_moduleは、作成するポリシーに適合させる必要があることに注意してください。

次に、次の手順を実行します。

EXECUTE proc_audit_manager;

ポリシーが有効になっているかどうかを確認できます：

SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';

次に、更新を実行して、手順とポリシーが正しく機能するかどうかを確認します。

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

結論として、データベースごとに監査が必要であり、上記の方法は、データベースのセキュリティに影響を与える可能性のある疑わしいアクティビティを見つけるのに役立ちます。 Oracleデータベース監査の詳細については、以下の参考文献を参照してください。

参考文献：

• http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
• http://docs.oracle.com/cd/B10501_01/server.920/a96521/audit.htm
• https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000