現實中的細粒度審計(1)
2024-07-21 02:08:26
供稿：網友
現實中的細粒度審計(1)
作者：arup nanda
了解如何使用 oracle 數據庫的細粒度審計特性來跟蹤對表中特定行的只讀訪問 — 以及更多信息
傳統的 oracle 數據庫審計選件允許您在宏觀級別上跟蹤用戶在對象上所執行的操作 — 例如，如果您審計對某個表的 select 語句，則可以跟蹤是誰從表中選擇了數據。但是，您不知道他們選擇了什么。利用數據操縱語句 — 如 insert、update 或 delete — 您可以通過使用觸發器或使用 oracle logminer 實用程序來分析歸檔日志，從而捕獲任何的更改。因為簡單的 select 語句是不操縱數據的，它們既不啟動觸發器，也不記入到那些以后可以進行挖掘的歸檔日志中，所以這兩種技術在涉及到 select 語句的地方無法滿足要求。
oracle9i database 推出了一種稱為細粒度審計 (fga) 的新特性，它改變了這種局面。該特性允許您將單個的 select 語句聯同用戶提交的確切語句一起進行審計。除了簡單地跟蹤語句之外，fga 還通過在每次用戶選擇特定的數據集時執行一段代碼，提供了一種方法來模擬用于 select 語句的觸發器。在分為三部分的這一系列文章中，我將說明如何使用 fga 解決實際問題。這第一部分的主要內容是構建基本的 fga 系統。
示例安裝
我們的示例基于一個銀行系統，已經通過應用程序級的審計按照傳統提供了用戶訪問特定數據的審計線索。但是，只要用戶使用諸如 sql*plus 等工具從應用程序以外的地方訪問數據，該系統就不能滿足要求。在本文中，我將說明作為 dba 的您能夠如何使用 fga 來完成捕獲用戶對特定行的 select 訪問的任務，無論訪問的工具或機制是什么。
在我們的示例中，數據庫有一個名為 accounts 的表，由模式 bank 擁有，其結構如下：
name null? type ---------------- -------- ------------acct_no not null numbercust_id not null numberbalance number(15,2)
為了構造一個能夠對任何在此表中選擇的用戶進行審計的系統，您需要定義對該表的 fga 策略如下：
begindbms_fga.add_policy (object_schema=>'bank',object_name=>'accounts',policy_name=>'accounts_access' );end;
這段代碼必須由具有執行程序包 dbms_fga 權限的用戶來執行。但是，為了提高安全性，建議不要對用戶 bank（將要被審計的表的所有者）授予執行權限；而應該將權限授予一個安全的用戶（比如 secman），此用戶應該執行添加策略的過程。
在定義了策略以后，當用戶以通常的方式對表進行查詢時，如下所示：
select * from bank.accounts;
審計線索記錄此操作。您可以使用以下語句查看線索：
select timestamp, db_user,os_user,object_schema,object_name,sql_textfrom dba_fga_audit_trail;timestamp db_user os_user object_ object_n sql_text--------- ------- ------- ------- -------- ----------------------22-sep-03 bank ananda bank accounts select * from accounts
注意名為 dba_fga_audit_trail 的新視圖，它記錄細粒度的訪問信息。其中顯示了審計事件的時間標記、查詢者的數據庫用戶 id、操作系統用戶 id、查詢中所使用表的名稱和所有者，最后還有確切的查詢語句。在 oracle9i database 之前不可能得到這種信息，但隨著 fga 的推出，獲得此信息變得輕而易舉。
在 oracle9i database 中，fga 只能捕獲 select 語句。利用 oracle database 10g，fga 還可以處理 dml 語句 — insert、update 和 delete — 使其成為完整的審計特性。在本系列的第 3 部分，我將詳細說明這些新的功能。
審計列和審計條件
讓我們更詳細地檢查前面的示例。我們要求審計對該表所使用的任何 select 語句。但是在現實中，可能不必要這樣做，并且這樣可能會使存儲線索的審計表承受不起。當用戶選擇含有敏感信息的余額列時，銀行可能需要進行審計，但當用戶選擇特定客戶的帳號時，可能不需要進行審計。列 balance（選擇它可觸發審計）稱為審計列，在此情況下，dbms_fga.add_policy 過程的參數指定該列如下：
audit_column => 'balance'
如果每次用戶從表中選擇時都記錄審計線索，則線索的大小將增長，導致空間和管理問題，因此您可能希望只有在滿足特定條件時進行審計，而不是每次都進行審計。也許只有當用戶訪問極為富有的戶主帳號時，銀行需要審計 — 例如，只有當用戶選擇了余額為 11,000 美元或更多的帳號時需要審計。這種類型的條件稱為審計條件，并作為一項參數傳遞到 dbms_fga.add_policy 過程，如下所示：
audit_condition => 'balance >= 11000'
讓我們來看這兩個參數如何起作用。現在策略定義的形式類似于：
begindbms_fga.add_policy (object_schema=>'bank',object_name=>'accounts',policy_name=>'accounts_access',audit_column => 'balance',audit_condition => 'balance >= 11000' );end;
在此情況下，只有當用戶選擇列 balance 并且檢索的行包含大于或等于 $11,000 的余額時，才會審計該操作。如果這兩個條件中有一個不為真，則該操作不會被寫入到審計線索中。表 1 中的示例演示了何時審計操作和何時不審計操作的各種情況。
優化器模式
fga 需要基于開銷的優化 (cbo)，以便正確地工作。在基于規則的優化時，只要用戶從表中進行選擇，無論是否選擇了相關的列，都始終生成審計線索，增加了誤導項目出現的可能性。為使 fga 正確地工作，除了在實例級啟用 cbo 之外，在 sql 語句中應該沒有規則暗示，并且必須至少使用評估選項對查詢中的所有表進行分析。
