openGauss資料庫原始碼決議系列文章—

在前面文章中介紹過“9.4 物件權限管理”，本篇我們介紹第9章安全管理原始碼決議中“9.5 審計與追蹤”的相關精彩內容介紹，
審計機制和審計追蹤機制能夠對用戶的日常行為進行記錄和分析，實作規避風險、提高安全性，

9.5.1 審計日志設計

審計內容的記錄方式通常有兩種：記錄到資料庫的表中、記錄到OS檔案中，openGauss采用記錄到OS檔案中（即審計日志）的方式來保存審計結果，審計日志檔案夾受作業系統權限保護，默認只有初始化用戶可以讀寫，從資料庫安全角度出發，保證了審計結果的可靠性，日志檔案的存盤目錄由audit_directory引數指定，
openGauss審計日志每條記錄包括time、type、result、userid、username、database、client_conninfo、object_name、detail_info、node_name、thread_id、local_port、remote_port共13個欄位，圖9-23為審計日志的單條記錄示例，
在這里插入圖片描述

圖9-23 審計記錄示例

對審計日志檔案進行讀寫的函式的代碼主要位于“pgaudit.cpp”檔案中，其中主要包括兩類函式：審計檔案的讀、寫、更新函式；審計記錄的增、刪、查介面，
首先介紹審計檔案的資料結構，如圖9-24所示，
openGauss的審計日志采用檔案的方式存盤在指定目錄中，通過查看目錄，可以發現日志主要包括兩類檔案：形如0_adt的審計檔案以及名為index_table索引檔案，
在這里插入圖片描述

圖9-24 審計檔案結構

以adt結尾的審計檔案中，每一條審計記錄對應一個AuditData結構體，資料結構AuditData代碼如下：

typedef struct AuditData {
    AuditMsgHdr header;    /*  記錄檔案頭，存盤記錄的標識、大小等資訊   */
    AuditType type;        /*  審計型別   */
    AuditResult result;      /*  執行結果   */
    char varstr[1];         /*  二進制格式存盤的具體審計資訊   */
} AuditData;

其中AuditMsgHdr記錄著審計記錄的標識資訊，資料結構AuditMsgHdr的代碼如下：

typedef struct AuditMsgHdr {
    char signature[2];   /*  審計記錄標識，目前固定為AUDIT前兩個字符’A’和’U’  */
    uint16 version;      /*  版本資訊，目前固定為0   */
    uint16 fields;       /*  審計記錄欄位數，目前為13   */
    uint16 flags;        /*  記錄有效性標識，如果被洗掉則標記為DEAD   */
    pg_time_t time;     /*  審計記錄創建時間   */
    uint32 size;         /*  審計資訊占位元組長度   */
} AuditMsgHdr;

AuditData的其他結構存盤著審計記錄的審計資訊，AuditType為審計型別，目前有38種型別，AuditResult為執行的結果，有AUDIT_UNKNOWN、AUDIT_OK、AUDIT_FAILED三種結果，其余的各項資訊，均通過二進制的方式寫入到varstr中，
審計日志有關的另一個檔案為索引檔案index_table，其中記錄著審計檔案的數量、審計日志檔案編號、審計檔案修改日期等資訊，其資料結構AuditIndexTable代碼如下：

typedef struct AuditIndexTable {
    uint32 maxnum;             /*  審計目錄下審計檔案個數的最大值   */
    uint32 begidx;               /*  審計檔案開始編號   */
    uint32 curidx;                /*  當前使用的審計檔案編號   */
    uint32 count;                 /*  當前審計檔案的總數   */
    pg_time_t last_audit_time;      /*  最后一次寫入審計記錄的時間   */
    AuditIndexItem data[1];        /*  審計檔案指標   */
} AuditIndexTable;

索引檔案中每一個AuditIndexItem對應一個審計檔案，其資料結構AuditIndexItem的代碼如下：

typedef struct AuditIndexItem {
    pg_time_t ctime;             /*  審計檔案創建時間   */
    uint32 filenum;              /*  審計檔案編號   */
    uint32 filesize;               /*  審計檔案占空間大小   */
} AuditIndexItem;

審計檔案的讀、寫類函式如auditfile_open、auditfile_rotate等函式實作較簡單，讀者可以直接閱讀原始碼，
下面主要介紹日志檔案的結構和日志記錄的增、刪、查介面，
審計記錄的寫入介面為audit_report函式，該函式的原型為：

void audit_report(AuditType type, AuditResult result, const char* object_name, const char* detail_info)；

其中入參type、result、object_name、detail_info分別對應審計日志記錄中的相應欄位，審計日志中的其余9個欄位均為函式在執行時從全域變數中獲取，
audit_report函式的執行主要分為3個部分，首先會檢查審計的各項開關，判斷是否需要審計該操作；然后根據傳入的引數、全域變數中的引數以及當前時間，生成審計日志所需的資訊并拼接成字串；最后呼叫審計日志檔案讀寫介面，將審計日志寫入檔案中，
審計記錄查詢介面為pg_query_audit函式，該函式為資料庫內置函式，可供用戶直接呼叫，呼叫形式為：

SELECT * FROM pg_query_audit (timestamptz startime,timestamptz endtime, audit_log)；

入參為需要查詢審計記錄的起始時間和終止時間以及審計日志檔案所在的物理路徑，當不指定audit_log時，默認查看連接當前實體的審計日志資訊，
審計記錄的洗掉介面為pg_delete_audit函式，該函式為資料庫內置函式，可供用戶直接呼叫，呼叫形式為：

SELECT * FROM pg_delete_audit (timestamptz startime,timestamptz endtime)；

入參為需要被洗掉審計記錄的起始時間和終止時間，該函式通過呼叫pgaudit_delete_file函式來將審計日志檔案中，startime與endtime之間的審計記錄標記為AUDIT_TUPLE_DEAD，達到洗掉審計日志的效果，而不實際洗掉審計記錄的物理資料，帶來的效果是執行該函式審計日志檔案大小不會減小，

9.5.2 審計執行

1. 執行原理

審計機制是openGauss的內置安全能力之一，openGauss提供對用戶發起的SQL行為審計和追蹤能力，支持針對DDL、DML陳述句和關鍵行為（登錄、退出、系統啟動、恢復）的審計，在每個作業執行緒初始化階段把審計模塊加載至執行緒中，其審計的執行原理是把審計函式賦給SQL生命周期不同階段的Hook（鉤子），當執行緒執行至SQL處理流程的特定階段后會進行審計執行判定邏輯，審計模塊加載關鍵代碼如下：

void pgaudit_agent_init(void) {
…
    /* DDL、DML陳述句審計Hook賦值, 賦值結束后標識審計模塊已在此執行緒加載 */
    prev_ExecutorEnd = ExecutorEnd_hook;
    ExecutorEnd_hook = pgaudit_ExecutorEnd;
    prev_ProcessUtility = ProcessUtility_hook;
    ProcessUtility_hook = (ProcessUtility_hook_type)pgaudit_ProcessUtility;
    u_sess->exec_cxt.g_pgaudit_agent_attached = true;
}

SQL陳述句在執行到ProcessUtility_hook和ExecutorEnd_hook函式指標時，會分別進入到已預置好的審計流程中，這兩個函式指標的位置在SQL進入執行器執行之前，具體關系如圖9-25所示，
在這里插入圖片描述

圖9-25 審計執行關系圖

如圖9-25所示，在執行緒初始化階段審計模塊已加載完畢，SQL經過優化器得到計劃樹，此時審計模塊的pgaudit_ExecutorEnd函式和pgaudit_ProcessUtility函式分別進行DML和DDL陳述句的分析，如果和已設定審計策略相匹配，則會呼叫審計日志介面，生成對應的審計日志，對于系統變更類的審計直接內置于相應行為的內核代碼中，

2. 關鍵執行流程

系統變更類審計執行

pgaudit_system_recovery_ok
pgaudit_system_start_ok
pgaudit_system_stop_ok
pgaudit_user_login
pgaudit_user_logout
pgaudit_system_switchover_ok
pgaudit_user_no_privileges
pgaudit_lock_or_unlock_user

以上為openGauss支持系統變更類的審計執行函式，對于此類審計函式均嵌入內核相應呼叫流程中，下面以審計用戶登入退出pgaudit_user_login函式為例說明其主體流程，

在這里插入圖片描述

圖9-26 登入審計執行流程

圖9-26為服務端校驗客戶端登入時的主要流程，以登錄失敗場景為例，首先根據組態檔和客戶端IP和用戶資訊確認采用的認證方式(包括sha256和SSL認證等)；然后根據不同的認證方式采用不同的認證流程和客戶端進行互動完成認證身份流程；如果認證失敗，則執行緒進入退出流程上報客戶端，此時呼叫pgaudit_user_login獲取當前訪問資料庫名稱和詳細資訊，并記錄登錄失敗相關的審計日志，關鍵代碼如下：

/* 拼接登錄失敗時候的詳細資訊，包括資料庫名稱和用戶名 */
rc = snprintf_s(details,
PGAUDIT_MAXLENGTH,
    PGAUDIT_MAXLENGTH - 1,
    "login db(%s)failed,authentication for user(%s)failed",
    port->database_name,
    port->user_name); 
securec_check_ss(rc, "\0", "\0");
/* 呼叫登入審計函式，記錄審計日志 */
pgaudit_user_login(FALSE, port->database_name, details);
/* 退出當前執行緒 */
ereport(FATAL, (errcode(errcode_return), errmsg(errstr, port->user_name)))

登入審計日志介面pgaudit_user_login則主要完成審計日志記錄介面需要引數的拼接，相關代碼如下：

void pgaudit_user_login(bool login_ok, const char* object_name, const char* detaisinfo)
{
    AuditType audit_type;
    AuditResult audit_result;
    Assert(detaisinfo);
    /* 審計型別和審計結果拼裝 */ 
    if (login_ok) {
        audit_type = AUDIT_LOGIN_SUCCESS;
        audit_result = AUDIT_OK;
    } else {
        audit_type = AUDIT_LOGIN_FAILED;
        audit_result = AUDIT_FAILED;
    }
    /* 直接呼叫審計日志記錄介面 */
    audit_report(audit_type, audit_result, object_name, detaisinfo);
}

2） DDL、DML陳述句審計執行

依據“1. 執行原理”節的描述，DDL、DML陳述句的執行分別由于pgaudit_ProcessUtility函式、pgaudit_ExecutorEnd函式來承載，此處首先介紹函式pgaudit_ProcessUtility函式，其主體結構代碼如下：

static void pgaudit_ProcessUtility(Node* parsetree, const char* queryString, ...)
{
/*  適配不同編譯選項  */
...
/*  開始匹配不同的DDL陳述句  */
switch (nodeTag(parsetree)) {
    case T_CreateStmt: {
        /* CREATE table陳述句審計執行 */
        CreateStmt* createtablestmt = (CreateStmt*)(parsetree);
        pgaudit_ddl_table(createtablestmt->relation->relname, queryString);
    } break;
    case T_AlterTableStmt: {
        AlterTableStmt* altertablestmt = (AlterTableStmt*)(parsetree); /* Audit alter table */
        if (altertablestmt->relkind == OBJECT_SEQUENCE) {
            pgaudit_ddl_sequence(altertablestmt->relation->relname, queryString);
        } else {
            pgaudit_ddl_table(altertablestmt->relation->relname, queryString);
        }
    } break;
    /*  匹配其他DDL型別陳述句邏輯  */
    ...
}}

DDL審計執行函式關鍵入參parsetree用于識別審計日志型別(create/drop/alter等操作)，入參queryString保存原始執行SQL陳述句，用于記錄審計日志，略去非關鍵流程，此函式主要根據判斷nodeTag所歸屬的DDL操作型別，進入不同的審計執行邏輯，以T_CreateStmt為例，識別當前陳述句CREATE table則進入pgaudit_ddl_table邏輯進行審計日志執行并最終記錄審計日志，

在這里插入圖片描述

圖9-27 DDL審計執行流程

如圖9-27所示，首先從當前SQL陳述句中獲取執行物件類別校驗其相應的審計開關是否開啟（可以通過GUC引數audit_system_object控制），當前支持開啟的全量物件代碼如下：

typedef enum {
DDL_DATABASE = 0,
DDL_SCHEMA, 
DDL_USER,
DDL_TABLE,
DDL_INDEX,
DDL_VIEW,
DDL_TRIGGER,
DDL_FUNCTION,
DDL_TABLESPACE,
DDL_RESOURCEPOOL,
DDL_WORKLOAD,
DDL_SERVERFORHADOOP,
DDL_DATASOURCE,
DDL_NODEGROUP,
DDL_ROWLEVELSECURITY,
DDL_TYPE,
DDL_TEXTSEARCH,
DDL_DIRECTORY,
DDL_SYNONYM
} DDLType;

如果DDL操作的物件審計已開啟則進行審計日志記錄流程，在呼叫審計日志記錄函式audit_report之前需要對包含密碼的SQL陳述句進行脫敏處理，將包含密碼的陳述句中(CREATE role/user)密碼替換成‘********’用于隱藏敏感資訊，至此針對CREATE DDL陳述句的審計執行完成，其他型別DDL陳述句主體流程一致，不做贅述，
下面介紹針對DML陳述句審計執行邏輯pgaudit_ExecutorEnd函式，整體呼叫流程如圖9-28所示，
在這里插入圖片描述

圖9-28 DML審計執行流程

首先判斷SQL查詢陳述句所歸屬的查詢型別，以CMD_SELECT型別為例，先獲取查詢物件的object_name用于審計日志記錄中訪問物件的記錄，然后呼叫pgaudit_dml_table函式，相關代碼如下：

case CMD_SELECT:
object_name = pgaudit_get_relation_name(queryDesc->estate->es_range_table);
pgaudit_dml_table_select(object_name, queryDesc->sourceText);

和DDL的記錄一樣，同樣會對敏感資訊進行脫敏后呼叫審計日志記錄介面audit_report，至此對DML陳述句的審計日志執行完成，

感謝大家學習第9章安全管理原始碼決議中“9.5 審計與追蹤”的精彩內容，下一篇我們開啟“9.6 資料安全技術”的相關內容的介紹，

敬請期待，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/344297.html

標籤：其他

上一篇：2021年科大訊飛車內貴重物品檢測前三名隊伍分享

下一篇：shell 必知的腳本知識（上篇）

openGauss資料庫原始碼決議系列文章—— 審計與追蹤

9.5.1 審計日志設計

9.5.2 審計執行

1. 執行原理

2. 關鍵執行流程