資料庫審計

資料庫審計（簡稱DBAudit）能夠實時記錄網路上的資料庫活動，對資料庫操作進行細粒度審計的合規性管理，對資料庫遭受到的風險行為進行告警，對攻擊行為進行阻斷。它通過對使用者訪問資料庫行為的記錄、分析和彙報，用來幫助使用者事後生成合規報告、事故追根溯源，同時加強內外部資料庫網路行為記錄，提高資料資產安全。

資料庫審計是資料庫安全技術之一，資料庫安全技術主要包括：資料庫漏掃、資料庫加密、資料庫防火牆、資料脫敏、資料庫安全審計系統。

資料庫是任何商業和公共安全中最具有戰略性的資產，通常都儲存著重要的商業夥伴和客戶資訊，這些資訊需要被保護起來，以防止競爭者和其他非法者獲取。網際網路的急速發展使得企業資料庫資訊的價值及可訪問性得到了提升，同時，也致使資料庫資訊資產面臨嚴峻的安全挑戰，概括起來主要表現在以下三個層面：

1. 管理風險：主要表現為人員的職責、流程有待完善，內部員工的日常操作有待規範，第三方維護人員的操作監控失效等等，離職員工的後門，致使安全事件發生時，無法追溯並定位真實的操作者。

2. 技術風險：Oracle, SQL Server是一個龐大而複雜的系統，安全漏洞如溢位， 注入層出不窮，每一次的CPU（Critical Patch Update）都疲於奔命， 而企業和政府處於穩定性考慮，往往對補丁的跟進非常延後，更何況通過應用層的注入攻擊使得資料庫處於一個無辜受害的狀態。

3. 審計層面：現有的依賴於資料庫日誌檔案的審計方法，存在諸多的弊端,比如:資料庫審計功能的開啟會影響資料庫本身的效能、資料庫日誌檔案本身存在被篡改的風險，難於體現審計資訊的有效性和公正性。此外，對於海量資料的挖掘和迅速定位也是任何審計系統必須面對和解決的一個核心問題之一。

伴隨著資料庫資訊價值以及可訪問性提升，使得資料庫面對來自內部和外部的安全風險大大增加，如違規越權操作、惡意入侵導致機密資訊竊取洩漏，但事後卻無法有效追溯和審計。

審計專案

通過應用層訪問和資料庫操作請求進行多層業務關聯審計，實現訪問者資訊的完全追溯，包括：操作發生的URL、客戶端的IP、請求報文等資訊，通過多層業務關聯審計更精確地定位事件發生前後所有層面的訪問及操作請求，使管理人員對使用者的行為一目瞭然，真正做到資料庫操作行為可監控,違規操作可追溯。

通過對不同資料庫的SQL語義分析，提取出SQL中相關的要素（使用者、SQL操作、表、欄位、檢視、索引、過程、函式、包…） 實時監控來自各個層面的所有資料庫活動，包括來自應用系統發起的資料庫操作請求、來自資料庫客戶端工具的操作請求以及通過遠端登入伺服器後的操作請求等 通過遠端命令列執行的SQL命令也能夠被審計與分析，並對違規的操作進行阻斷 系統不僅對資料庫操作請求進行實時審計，而且還可對資料庫返回結果進行完整的還原和審計，同時可以根據返回結果設定審計規則。

靈活的策略定製：根據登入使用者、源IP地址、資料庫物件（分為資料庫使用者、表、欄位）、操作時間、SQL操作命令、返回的記錄數或受影響的行數、關聯表數量、SQL執行結果、SQL執行時長、報文內容的靈活組合來定義客戶所關心的重要事件和風險事件 多形式的實時告警：當檢測到可疑操作或違反審計規則的操作時，系統可以通過監控中心告警、簡訊告警、郵件告警、Syslog告警等方式通知資料庫管理員。

一般包括以下幾方面內容：

1、登入和登出

2、資料庫源頭（ip和操作命令）

3、職權分離（角色和許可權）

4、日誌分析

5、審計資料庫錯誤

審計系統特點

完整性：獨一無二的多層業務關聯審計，可針對WEB層、應用中間層、資料層各層次進行關聯審計

細粒度：細粒度的審計規則、精準化的行為檢索及回溯、全方位的風險控制。

有效性：獨有專利技術實現對資料庫安全的各類攻擊風險和管理風險的有效控制；靈活的、可自定義的審計規則滿足了各類內控和外審的需求（有效控制誤操作、越權操作、惡意操作等違規行為）

公正性：基於獨立審計的工作模式，實現了資料庫管理與審計的分離，保證了審計結果的真實性、完整性、公正性

零風險：無需對現有資料庫進行任何更改或增加配置，即可實現零風險部署

高可靠：提供多層次的物理保護、掉電保護、自我監測及冗餘部署，提升裝置整體可靠性

易操作：充分考慮國內使用者的使用和維護習慣，提供Web-based全中文操作介面及線上操作提示

軟體產品舉例：資料庫審計TopAudit-DB_天融信 http://www.topsec.com.cn/aqcp/sjjk1/sjksjtopauditdb/

好了理論就扯淡這麼多，最主要的是結合實際情況進行方案操作。

2017年6月1日《中華人民共和國網路安全發》的正式施行，極大促進了資訊保安等級保護工作的建設。而由於資訊保安等級保護三級對內控與審計方面的要求，市面上的各種審計產品如雨後春筍般湧現，使用者難免會被市面上眾說紛紜的解說所誤導，對產品的認識可能產生偏差。（其實最好的審計就是每天的運維檢查和研發資料庫監控系統）

背景：

假設這麼一個情況，你是某公司mysql-DBA，某日突然公司資料庫中的所有被人為刪了。

儘管有資料備份，但是因服務停止而造成的損失上千萬，現在公司需要查出那個做刪除操作的人。

但是擁有資料庫操作許可權的人很多，如何排查，證據又在哪？

是不是覺得無能為力？

mysql本身並沒有操作審計的功能，那是不是意味著遇到這種情況只能自認倒黴呢？

本文就將討論一種簡單易行的，用於mysql訪問審計的思路。

概述：

其實mysql本身已經提供了詳細的sql執行記錄–general log（詳見上篇blog） ，但是開啟它有以下幾個缺點

無論sql有無語法錯誤，只要執行了就會記錄，導致記錄大量無用資訊，後期的篩選有難度。

sql併發量很大時，log的記錄會對io造成一定的印象，是資料庫效率降低。

日誌檔案很容易快速膨脹，不妥善處理會對磁碟空間造成一定影響。

實話實說吧，那麼筆者根據以往的工作經驗和經歷總結出以下幾種方案供讀者參考。

一、Mysql5.6（及其以後版本）的審計功能

mysql5.6以後的版本自帶的安全審計功能，個人感覺是一個累贅的設計沒有什麼意義的，但有總比沒有的好，期待以後的mysql版本功能越來越強大（不過Oracle甲骨文收購了mysql別抱有太大的期望，還是用MariaDB吧社群解決方案更多）

具體設定方法請參考：Mysql5.6審計功能 - 紅黑聯盟 https://www.2cto.com/database/201507/422910.html

二、使用init-connect + binlog的方法進行mysql的操作審計（此方法還是比較管用）

mysql伺服器自身沒有提供審計功能,但是我們可以使用init-connect + binlog的方法進行mysql的操作審計。

由於mysql binlog記錄了所有對資料庫長生實際修改的sql語句，及其執行時間，和connection_id但是卻沒有記錄connection_id對應的詳細使用者資訊。

在後期審計進行行為追蹤時，根據binlog記錄的行為及對應的connection-id 結合 之前連線日誌記錄 進行分析，得出最後的結論。

1. 設定init-connect
1.1 建立用於存放連線日誌的資料庫和表
create database accesslog;
CREATE TABLE accesslog.accesslog (`id` int(11) primary key auto_increment, `time` timestamp, `localname` varchar(30), `matchname` varchar(30))

1.2 建立使用者許可權
可用現成的root使用者用於資訊的讀取
grant select on accesslog.* to root;
如果存在具有to *.* 許可權的使用者需要進行限制。

這裡還需要注意使用者必須對accesslog表具有insert許可權
grant select on accesslog.* to user@’%’;

1.3 設定init-connect
在[mysqld]下新增以下設定：
init-connect=’insertinto accesslog.accesslog(id, time, localname, matchname)
values(connection_id(),now(),user(),current_user());’
------注意user()和current_user()的區別
log-bin=xxx
這裡必須開啟binlog

1.4 重啟資料庫生效
shell> /etc/init.d/mysql restart

2. 記錄追蹤
2.1 thread_id確認

可以用以下語句定位語句執行人

Tencent:~ # mysqlbinlog --start-datetime='2011-01-26 16:00:00'
--stop-datetime='2011-01-26 17:00:00' /var/lib/mysql/mysql-bin.000010
| grep -B 5 'wsj'

COMMIT/*!*/;
# at 767
#110126 16:16:43 server id 1 end_log_pos 872 Query thread_id=19 exec_time=0 error_code=0
use test/*!*/;
SET TIMESTAMP=1296029803/*!*/;
create table wsj(id int unsigned not null)
--
BEGIN
/*!*/;
# at 940
#110126 16:16:57 server id 1 end_log_pos 1033 Query thread_id=19 exec_time=0 error_code=0
SET TIMESTAMP=1296029817/*!*/;
insert into wsj(id) values (1)
--
BEGIN
/*!*/;
# at 1128
#110126 16:16:58 server id 1 end_log_pos 1221 Query thread_id=19 exec_time=0 error_code=0
SET TIMESTAMP=1296029818/*!*/;
insert into wsj(id) values (2)

2.2 使用者確認

thread_id 確認以後，找到元凶就只是一條sql語句的問題了。

mysql> select * from accesslog where id=19;
+----+---------------------+---------------------+-----------+
| id | time | localname | matchname |
+----+---------------------+---------------------+-----------+
| 19 | 2011-01-26 16:15:54 | test@10.163.164.216 | test@% |
+----+---------------------+---------------------+-----------+
1 row in set (0.00 sec)

3. Q
Q：使用init-connect會影響伺服器效能嗎？
A：理論上，只會在使用者每次連線時往資料庫裡插入一條記錄，不會對資料庫產生很大影響。除非連線頻率非常高（當然，這個時候需要注意的就是如何進行連線複用和控制，而非是不是要用這種方法的問題了）---如果採用長連線並且快取的話,可以提高效能

Q：access-log表如何維護?
A: 由於是一個log系統，推薦使用archive儲存引擎，有利於資料厄壓縮存放。如果資料庫連線數量很大的話，建議一定時間做一次資料匯出，然後清表。
Q：表有其他用途麼？
A：有！access-log表當然不只用於審計，當然也可以用於對於資料庫連線的情況進行資料分析，例如每日連線數分佈圖等等，只有想不到沒有做不到。---可以用來測試讀寫分離,驗證負載均衡等

Q：會有遺漏的記錄嗎？
A：會的，init-connect 是不會在super使用者登入時執行的。所以access-log裡不會有資料庫超級使用者的記錄，這也是為什麼我們不主張多個超級使用者，並且多人使用的原因。--這種審計不會記錄root等具有super許可權的賬號對資料庫的訪問

三、MySQL audit—SQL審計外掛or第三方開源審計外掛：libaudit_plugin.so 來完成MySQL的審計工作（外掛很常用審計）

MySQL AUDIT Plugin是一個 MySQL安全審計外掛，由McAfee提供，設計強調安全性和審計能力。

windows和linux參考：MySQL audit—SQL審計外掛 https://www.linuxidc.com/Linux/2017-08/146256.htm

MySQL--audit審計 -  https://blog.csdn.net/dbaxiaosa/article/details/51783214

四、基於360開源資料庫流量審計MySQL Sniffer（別忽視了開源的軟體的力量，對於初創公司可以省不少事）

具體設定：基於360開源資料庫流量審計MySQL Sniffer - 部落格園 https://www.cnblogs.com/qcfeng/p/7390006.html

五、使用ELK處理MySQL資料庫審計日誌（ELK日誌分析功能是很強大的）

拒絕背鍋，使用ELK處理MySQL資料庫審計日誌-ELK-運維人生 http://www.ywadmin.com/?id=86

六、Mysql bin-log日誌進行實時儲存和行為分析 當觸發設定的規則就實現記錄和告警

七、開啟mysql監控，實施監控日誌和使用者命令的操作 ，這類往往是一個平臺或者軟體開發結果集

總之開源的不好用，就二次開發或者自研重寫。。。

這是一項軟體工程，開源的mysql監控系統有很多，彈藥滿足企業自身發展的需求的並不多。所以需要大量的測試和作二次開發

筆者常用的監控系統Prometheus、Mycheckpoint、Zabbix、PMM、doDBA tools、TreeSoft資料庫管理系統和MySQLTOP（lepus）、orztop

監控利器：詳解MySQL 的實時效能監控好工具 http://www.360doc.com/content/16/1224/10/32626470_617243481.shtml

mysql資料庫實時監控工具Mycheckpoint介紹 - 阿里雲 https://yq.aliyun.com/ziliao/72717

開發同學的福利--mysql監控工具sqlprofiler，類似sqlserver的profiler工具 - 布衣人老白 - 部落格園 https://www.cnblogs.com/wucj/p/7152020.html

資料庫監控及指標 - CSDN部落格 https://blog.csdn.net/louishu_hu/article/details/52397134

mysql實時監控工具 - CSDN部落格 https://blog.csdn.net/marko39/article/details/80948659

                                                                                           ——總結——

審計多多少少會影響資料庫的效能，能不開儘量不開。另外開啟審計資料庫使用者要實名制或者一對一，以免幹了壞事兒的人賴賬~由於筆者的水平有限，編寫時間也很倉促，文中難免會出現一些錯誤或者不準確的地方，不妥之處懇請讀者批評指正。

【參考資料】

1、淺析日誌審計與資料庫審計_搜狐科技 https://www.sohu.com/a/207164670_357893

2、一個基於角色的許可權控制系統  https://blog.csdn.net/frankcheng5143/article/details/51725226

3、基於MySQL 資料庫的審計設計方案 -  https://blog.csdn.net/lmocm/article/details/79098678