oracle 審計

一、  審計分類：
ORACLE中審計總體上可分為“標準審計”和“細粒度審計”後者也稱為“基於政策的審計”，在Oracle10G之後功能得到很大增強。其中標準審計可分為使用者級審計和系統級審計。使用者級審計是任何Oracle使用者可設定的審計，主要是使用者針對自己建立的資料庫表或檢視進行審計，記錄所有使用者對這些表或檢視的一切成功和(或)不成功的訪問要求以及各種型別的SQL操作。系統級審計只能由DBA設定，用以監測成功或失敗的登入要求、監測GRANT和REVOKE操作以及其他資料庫級許可權下的操作。

二、    標準審計：

 2.1分類：

在ORACLE中分別支援以下三種標準審計型別：

u         語句審計，對某種型別的SQL語句審計，不指定結構或物件。

u         特權審計，對執行相應動作的系統特權的使用審計。

u         物件審計，對一特殊模式物件上的指定語句的審計。

這三種標準審計型別分別對如下3方面進行審計：

u         審計語句的成功執行、不成功執行，或者其兩者。

u         對每一使用者會話審計語句執行一次或者對語句每次執行審計一次。

u         對全部使用者或指定使用者的活動的審計。

    當資料庫的審計功能開啟後，在語句執行階段產生審計記錄。審計記錄包含有審計的操作、使用者執行的操作、操作的日期和時間等資訊。審計記錄可存在資料字典表（稱為審計記錄）或作業系統審計記錄中。資料庫審計記錄是在SYS模式的AUD$表中。

2.2設定ORACLE標準審計：

下列步驟可以設定ORACLE的標準審計功能：

1.   修改初始化引數檔案（init.ora）

如果使用伺服器引數檔案使用alter system set= scope=spfile|both，詳情參照1.1節中關於引數檔案的介紹），設定AUDIT_TRAIL引數，並且重啟資料庫。AUDIT_TRAIL的取值如下：

l        DB/TRUE：啟動審計功能，並且把審計結果存放在資料庫的SYS.AUD$表中

l        OS：啟動審計功能，並把審計結果存放在作業系統的審計資訊中  

l        DB_EXTENDED：具有DB/TRUE的功能，另外填寫AUD$的SQLBIND和SQLTEXT欄位

l        NONE/FALSE：關閉審計功能 

2.設定AUDIT_TRAIL引數：

如果設定AUDIT_TRAIL = OS,還需要修改引數AUDIT_FILE_DEST。

   如果作業系統支援設定AUDIT_TRAIL=OS，檔案會自動存放在AUDIT_FILE

_DEST所指定的目錄下，並且檔名包含程式的PID。

  比如： 

   AUDIT_FILE_DEST = $ORACLE_HOME/rdbms/audit  

   $ ls -l $ORACLE_HOME/rdbms/audit  

  -rw-rw---- 1 ora92   dba       881 Mar 17 09:57 ora_13264.aud

   $ ps -ef|grep 13264

   ora92 13264 13235 0 09:56:43 ? 0:00 oracleV92 (DESCRIPTION=(LOCAL=Y)

   SQL> select spid, program, username from v$process;

   SPID PROGRAM                                USERNAME

  ------ -------------------------------------------- -------------

  ...

  13264       oracle@frhp11 (TNS V1-V3)                   ora92

3.確認審計相關的表是否已經安裝

  SQLPLUS> connect / AS SYSDBA 

  SQLPLUS> select * from sys.aud$; --沒有記錄返回  

  SQLPLUS> select * from dba_audit_trail;--沒有記錄返回 

 如果做上述查詢的時候發現表不存在，說明審計相關的表還沒有安裝，需要安裝。

  SQLPLUS> connect / as sysdba 

  SQLPLUS> @$ORACLE_HOME/rdbms/admin/cataudit.sql 

 審計表安裝在SYSTEM表空間。所以要確保SYSTEM表空間又足夠的空間存放審計資訊。

4.關閉並重啟資料庫 

5.設定所需要的審計資訊

 下面是一個例子

  SQL> connect system/manager

  SQL> grant audit system to scott;     

  SQL> connect scott/tiger

  SQL> audit session;

 停止審計：

  SQL> noaudit session; 

通常設定了標準審計後都是透過Audit語句開啟審計，使用noaudit語句收回審計。如下所示：

對修改SC表結構或資料的操作進行審計可使用如下語句：

AUDIE ALTER，UPDATE ON SC;

取消對SC表的一切審計可使用如下語句：

NOAUDIT ALL ON SC;

2.3設定審計的例項（對試圖嘗試口令的訪問的審計）：

以下是一個審計的例項，用於記錄嘗試透過野蠻嘗試法破譯ORACLE帳號口令的例子：

1.修改審計相關引數（參照上面介紹的方法）

2.重啟資料庫

3.設定審計資訊

   SQL>AUDIT ALL BY ACCESS WHENEVER NOT SUCCESSFUL

 

4.查詢AUD$

  SQL> select returncode, action#, userid, userhost, terminal,timestamp

from aud$

 

  RETURNCODE   ACTION# USERID  USERHOST TERMINAL

  ---------- ---------- -------- -------------------- --------------------

   1017       100     SCOTT   WPRATA-BR

   1017       100     SCOTT   WPRATA-BR

   1017       100     SCOTT   WPRATA-BR

 

 ORA-1017的含義為錯誤的使用者名稱口令。透過檢視AUD$表可以清楚地看到WPRATA-BR嘗試破譯SCOTT的口令。可以透過下面一個儲存過程來分析AUD$表，找出可疑的資訊：

create or replace procedure AuditLogin(Since Varchar2,Times PLS_Integer)

is

USER_ID VARCHAR2(20);

cursor c1 is select userid,count(*) from sys.aud$ where returncode='1017' and timestamp#>=to_date(Since,'yyyy-mm-dd')

 group by userid;

cursor C2 IS Select userhost, terminal,TO_CHAR(timestamp#,'YYYY-MM-DD:HH24:MI:SS')

 from sys.aud$ WHERE returncode='1017' and timestamp#>=to_date(Since,'yyyy-mm-dd') AND USERID=USER_ID;

ct PLS_INTEGER;

V_USERHOST VARCHAR2(40);

V_TERMINAL VARCHAR(40);

V_DATE VARCHAR2(40);

BEGIN

   OPEN C1;

   dbms_output.enable(1024000);

   LOOP

     FETCH C1 INTO USER_ID,CT;

     EXIT WHEN C1%NOTFOUND;

     IF(CT>=TIMES) THEN

       DBMS_OUTPUT.PUT_LINE('USER BROKEN ALARM:'||USER_ID);

       OPEN C2;

       LOOP

         FETCH C2 INTO V_USERhOST,V_TERMINAL,V_DATE;

         DBMS_OUTPUT.PUT_LINE(CHR(9)||'HOST:'||V_USERHOST||',TERM:'||V_TERMINAL||',TIME:'||V_DATE);

         EXIT WHEN C2%NOTFOUND;

       END LOOP;

       close c2;

     END IF;

   END LOOP;

   close c1;

END;

/

一下是執行結果：

SQL>set serveroutput on;

SQL> execute auditlogin('2004-01-01',2);

USER BROKEN ALARM:SYS

       HOST:,TERM:XUJI,TIME:2004-09-22:11:08:00

       HOST:,TERM:XUJI,TIME:2004-09-22:11:08:01

       HOST:,TERM:XUJI,TIME:2004-09-22:11:09:29

       HOST:,TERM:XUJI,TIME:2004-09-22:11:09:29

 

PL/SQL過程已成功完成。

2.4將審計相關的表移動到其他表空間：

由於AUD$表等審計相關的表存放在SYSTEM表空間，因此為了不影響系統的效能，保護SYSTEM表空間，最好把AUD$移動到其他的表空間上。可以使用下面的語句來進行移動：

sql>connect / as sysdba;

sql>alter table aud$ move tablespace ;

sql>alter index I_aud1 rebuild online tablespace ;

SQL> alter table audit$ move tablespace ;

SQL> alter index i_audit rebuild online tablespace ;

SQL> alter table audit_actions move tablespace ;

SQL> alter index i_audit_actions rebuild online tablespace ;

三、     三 細粒度審計：

   細粒度審計(FGA)（透過Oracle9i引入）可以理解為“基於政策的審計”。與標準的審計功能相反，FGA可用於指定生成審計記錄必需的條件：

FGA政策透過使用“dbms_fga”程式包以程式設計方式繫結到物件（表、檢視）。類似於用於透過VPD ("dbms_rls")進行訪問控制的程式包，它允許您建立任何需要的條件，例如：僅當以下條件為真時審計事件：

• 在早上九點到下午六點之間或在星期六和星期日對某個表進行了訪問。
• 使用了公司網路外部的某個IP地址。
• 選定或更新了特定列。
• 使用了該列的特定值。

這將建立更有意義的審計線索，因為無需記錄每一個人對錶的每一次訪問。從Oracle資料庫10g開始，FGA支援在一個策略中使用“選擇”、“插入”、“更新”和“刪除”語句的任意組合。事實上，繫結到表的FGA政策簡化了審計政策的管理，因為這將只需在資料庫中對其更改一次，不用在每個應用程式中一次次進行。此外。無論使用者透過何種方式連線至資料庫（透過應用程式、Web介面或透過SQL*Plus），其操作都會記錄下來。

3.1使用細粒度審計：

  1、建立測試表：

  createtableACCOUNT

(AACT_NOnumbernotnull,

    CUST_IDnumbernotnull,

    BALANCEnumber(15,2)

);

  2、新增審計策略：

  begin

   DBMS_FGA.DROP_POLICY(object_schema => 'TEST',

                      object_name  => 'ACCOUNT',

                      policy_name  => 'ACCOUNT_ACCESS');

end;

這段程式碼必須由具有執行程式包dbms_fga許可權的使用者來執行。建議應該建立一個專門的使用者來專門負責新增審計策略。該過程有許多引數，具體含義如下：

3、在定義了策略以後，當使用者以通常的方式對錶進行查詢時，如下所示：

select * from bank.accounts;

審計線索記錄此操作。可以使用以下語句檢視線索：

select timestamp,

db_user,

os_user,

object_schema,

object_name,

sql_text

from dba_fga_audit_trail;

 

TIMESTAMP DB_USER OS_USER OBJECT_ OBJECT_N SQL_TEXT

--------- ------- ------- ------- -------- ----------------------

26-MAR-10 TEST   ananda TEST   ACCOUNT select * from account

注意名為DBA_FGA_AUDIT_TRAIL的新檢視，它記錄細粒度的訪問資訊。其中顯示了審計事件的時間標記、查詢者的資料庫使用者ID、作業系統使用者ID、查詢中所使用表的名稱和所有者，最後還有確切的查詢語句。

3.2審計列和審計條件：

預設情況下會對被審計物件的所有列開啟審計，當任何一列被訪問時都會紀錄一條審計資訊，這在現實情況下不太常見，因為這樣會使審計資訊表增長過快造成儲存空間的壓力，因此通常都會設定審計條件，當條件觸發時再發起審計。例如我們可以對Account表的Balance列設定審計條件，當訪問該列並觸發審計條件時才進行審計。如下所示：

begin

dbms_fga.add_policy (

object_schema=>'TEST',

object_name=>'ACCOUNT',

policy_name=>'ACCOUNT_ACCESS',

audit_column => 'BALANCE',

audit_condition => 'BALANCE >= 11000'

 );

end;

該策略將在訪問BALANCE列並且只有訪問列值大於等於11000時才發起審計。因此根據該條件戶有如下不同審計狀態：

 

3.3最佳化器模式：

FGA需要基於成本的最佳化(CBO)，以便正確地工作。在基於規則的最佳化時，只要使用者從表中進行選擇，無論是否選擇了相關的列，都始終生成審計線索，增加了誤導專案出現的可能性。為使FGA正確地工作，除了在例項級啟用CBO之外，在SQL語句中應該沒有規則暗示（hint），並且必須至少使用評估選項對查詢中的所有表進行分析。

3.4管理FGA策略:

 要刪除策略，您可以使用以下語句：

begin

dbms_fga.drop_policy (

object_schema => 'TEST',

object_name => 'ACCOUNT',

policy_name => 'ACCOUNT_ACCESS'

  );

end;

對於更改策略而言，沒有隨取隨用的解決方案。要更改策略中的任何引數，必須刪除策略，再使用更改後的引數新增策略。但是可以暫時禁用已有策略，如下所示：

begin

dbms_fga.enable_policy (

object_schema => 'TEST',

object_name => 'ACCOUNT',

policy_name => 'ACCOUNT_ACCESS',

enable => FALSE

  );

end;

若要重新啟用它，可使用同一函式，只需將引數enable設定為TRUE。

3.5FGA資料字典檢視：

FGA策略的定義位於資料字典檢視DBA_AUDIT_POLICIES中。該市途中各列含義如下：

3.6檢視和FGA：

假定在ACCOUNTS表上定義檢視VW_ACCOUNT如下：

create view vw_account as select * from account;

現在，如果使用者從檢視中而不是從表中進行選擇：

select * from vw_account;

您將看到以下審計線索：

select object_name, sql_text from dba_fga_audit_trail;

 

OBJECT_NAME SQL_TEXT

----------- -------------------------------------------------

ACCOUNT   select * from vw_account

注意，是基表名稱而不是檢視名稱出現在OBJECT_NAME列中，因為檢視中的選擇是從基表中進行選擇。但是，SQL_TEXT列記錄了使用者提交的實際語句。

如果只希望審計對檢視的查詢而不是對錶的查詢，可以對檢視本身建立策略。透過將檢視名稱而不是表的名稱傳遞給打包的過程dbms_fga.add_policy中的引數object_name，可以完成這項工作。隨後DBA_FGA_AUDIT_TRAIL中的OBJECT_NAME列將顯示檢視的名稱，並且不會出現有關表訪問的附加記錄。

3.7其它用途：

除了記錄對錶的選擇訪問，FGA還可用於某些其它情況：

• 可以對資料倉儲使用FGA，以捕獲特定的表、檢視或物化檢視上發生的所有語句，這有助於計劃索引。不需要到V$SQL檢視去獲取這些資訊。即使SQL語句已經超出了V$SQL的期限，在FGA審計線索中將會始終提供它。
• 由於FGA捕獲繫結變數，它可以幫助瞭解繫結變數值的模式，這有助於設計直方圖集合等。
• 可以向審計者或DBA傳送警告，這有助於跟蹤惡意應用程式。

由於FGA可以作為SELECT語句的觸發器，可以在需要這種功能的任何時候使用它。

3.8       FGA在10G中的增強：

3.8.1對所有DML的審計：

  在9i中FGA只能對Select語句進行審計，而不能對其他DML語句（Update、Delete、Insert）進行審計，如果想對其他DML語句進行審計那麼只能採取資料庫處發起的形式來實現。在10G中實現了對所有DML語句的審計，如下所示：

begin  dbms_fga.add_policy (     object_schema  => 'TEST',     object_name    => 'ACCOUNT',     policy_name    => 'ACCOUNT_ACCESS',     audit_column   => 'BALANCE',     audit_condition => 'BALANCE >= 3000'，     statement_types => 'INSERT, UPDATE, DELETE, SELECT' );end;

透過statement_types => 'INSERT, UPDATE, DELETE, SELECT'引數制定了新的策略，該策略可以對Select之外的所有DML操作進行審計。因此根據新的審計條件和審計策略會有如下不同情況：

第1種情況

之前：BALANCE = 1000

使用者發出：

update account set balance = 1200 where ACCOUNT_NO = ....

舊的和新的balance都小於3,000，審計條件不滿足；因此這條語句將不會被審計。

第2種情況

之前：BALANCE = 1000

使用者發出：

update account set balance = 3200 where ACCOUNT_NO = ....

新的balance大於3,000，審計條件滿足；因此這條語句將 會被審計。

第3種情況

之前：BALANCE = 3200

使用者發出：

update account set balance = 1200 where ACCOUNT_NO = ....

新的balance小於3,000，但舊的balance大於3,000。因此審計條件滿足，這條語句將被審計。

第4種情況

使用者插入一行，其中有BALANCE < 3000。

insert into account values (9999,1200,'X');

因為balance 1,200不滿足審計條件，所以這條語句不被審計。如果balance列大於或等於3,000，它將被審計。

第5種情況

使用者插入一行，其中balance的值為空。

insert into account (account_no, status) values (9997, 'X');

因為balance為空，該列沒有任何預設值，所以審計條件不滿足（比較NULL >= 3000結果為FALSE），這條語句不會被審計。重要注意事項：假設該列有一個大於3,000的預設值時，這條語句仍然不會被審計，即使插入行的balance列值大於3000。 注意對於DML語句的審計是由一個自動事務插入的；即使回滾DML語句的操作，審計記錄也將存在不會跟著回滾。

3.8.2制定相關的列策略：

在表ACCOUNT上定義的一個策略，如下：

begin

  dbms_fga.add_policy (

     object_schema  => 'TEST',

     object_name    => 'ACCOUNT',

     policy_name    => 'ACCOUNT_SEL',

     audit_column   => 'ACCOUNT_NO, BALANCE',

     audit_condition => 'BALANCE >= 3000',

     statement_types => 'SELECT'

 );

end;

在某些情況下，列的組合可能很重要，而不是某個特定的列。以上策略是在ACCOUNT_NO和BALANCE上定義的。那麼如果使用者發出以下語句：

select balance from accounts where account_no = 9995;

這條語句將被審計，因為balance列被選中，且餘額為3,200，大於3,000，滿足審計條件。

如果一個使用者想查出在銀行的總餘額，他發出：

select sum(balance) from account;

這條查詢幾乎沒什麼害處；它不明確指出帳戶所有者和帳戶餘額。因此安全策略可能不會要求審計這條查詢。不過，這條查詢

select balance from account where account_no = 9995

必須被審計；因為它明確地指定了一個帳戶。預設地，所有語句都被審計（無論使用了什麼樣的列組合）。這將建立大量不需要的審計線索專案，並可能帶來一些空間限制問題。為了限制它們，您可以指定僅當在查詢中使用了希望的列組合時才開始審計。當定義策略時，您可以使用一個新的引數：

audit_column_opts => DBMS_FGA.ALL_COLUMNS

這個引數將使策略僅當列ACCOUNT_NO和BALANCE在查詢中都被訪問時才建立審計線索專案。例如，以下查詢將產生一個審計線索專案。

select account_no, balance from account;

但這條查詢不會產生審計線索專案。

select account_no from account;

使用這個引數將把審計的數量限制在一個更易管理的大小。如果希望採用預設的行為—即任意列被選中時都進行審計，那麼您可以對同一引數的使用不同值。

audit_column_opts => DBMS_FGA.ANY_COLUMNS

3.8.3與標準審計的結合：

  透過制定如下審計策略實現標準審計與細粒度審計的結合

begin  dbms_fga.add_policy (     object_schema    => 'TEST',     object_name      => 'ACCOUNT',     policy_name      => 'ACCOUNT_SEL',     audit_column     => 'ACCOUNT_NO, BALANCE',     audit_condition  => 'BALANCE >= 3000',     statement_types  => 'SELECT',     audit_column_opts => DBMS_FGA.ALL_COLUMNS,     audit_trail      => DB );end;

透過指定audit_trail => DB引數實現在細粒度審計時開啟標準審計。在Oracle Database 10g中，標準審計也得到了巨大的改進。透過AUDIT命令執行標準審計，它現在能夠捕獲大量其它有用的資訊。在內容和功能方面，標準審計類似於細粒度審計。然而，作為一個資料庫管理員，有興趣知道所有的審計專案，而不只是一個審計專案。一個新的檢視，DBA_COMMON_AUDIT_TRAIL，結合了標準審計線索和FGA審計線索。用以下查詢來檢查它們二者如：

select * from dba_common_audit_trail;透過這條查詢可以同時檢視兩種審計收集的資訊。

四、FGA審計和標準審計的差異 ：

• 標準審計必須用引數AUDIT_TRAIL在資料庫級啟用。這個引數不是動態的；您必須重啟資料庫來使其生效。相比而言，FGA不需要任何引數修改。
• 一旦被設定在一個物件上，標準審計將保持在那裡。要解除它，必須用NOAUDIT命令刪除審計選項。這可能很不方便，因為在一個表上丟棄審計選項也將丟棄後設資料資訊。然而，FGA可以臨時禁用和啟用，不丟失任何後設資料資訊。
• FGA只能夠處理四種型別的語句：SELECT、INSERT、UPDATE和DELETE。相比而言，常規審計可以處理其它許多語句和許可權，甚至會話連線和斷開。
• 標準審計每次會話只建立一條記錄（按會話）或每次訪問物件建立一條記錄（按訪問）這種佔用資源很少的方式對於控制審計線索表中的空間非常重要。FGA並不是同樣節省資源；它每次訪問執行一次—使得線索更大。
• 透過記錄線索，標準審計可以用來檢測任何中斷企圖，如果企圖沒有成功，則將產生錯誤程式碼。而FGA不能。
• 標準審計可以寫資料庫表或OS檔案。後者在審計員（不是資料庫管理員）能夠訪問線索時非常有用。在Windows下，非資料庫審計線索記錄在事件日誌中，並且可以用不同的方式對其進行訪問。這個選項保護了審計線索的完整性。然而，FGA日誌僅寫到資料庫表FGA_LOG$中。可以在FGA中建立使用者自定義的審計處理程式來寫OS檔案，但它們的完整性不能保證。
• 標準審計可以設定用於預設物件。當表是在執行期建立時，這個功能變得極為有用：預設的審計選項允許沒有資料庫管理員干預的審計。這在FGA中是不可能的，使用者必須在一個現有的表上建立策略，上述的情況只能在表已建立之後才可能發生。
• 在FGA中，審計更加靈活—僅當訪問某些列，當某個特定的條件為真時等等。這種多功能性在您需要控制線索的增長時非常方便。
• 在FGA中，SQL賦值變數預設被捕獲。在標準審計中，必須把初始化引數audit_trail設為db_extended，以啟用這一功能。
• 許可權差異：標準審計需要審計系統或語句許可權；FGA只需要dbms_fga程式包上的執行許可權。

 

 

---

2014.09.16 13:20
share you knowledge with the world.