0x00 MySQL和PostgreSQL安全配置
針對開源數據庫MySQL和PostgreSQL的安全配置主要主要通過身份鑑別、訪問控制、安全審計、入侵防範、資源控制五個方面來實現。
0x01 身份鑑別
MySQL和PostgreSQL均可以實現身份鑑別功能。通過設置數據庫基本上能夠實現能夠滿足《信息系統安全等級保護基本要求》第三級身份鑑別中大部分要求，但是對於“f 項應採用兩種或兩種以上組合的鑑別技術對管理用戶進行身份鑑別”，需要使用第三方的身份鑑別技術，如：口令、數字證書、生物特徵等2。
（一）、MySQL數據庫
MySQL數據庫在安裝後默認存在mysql數據庫，該數據庫爲系統表所在的數據庫，所有用戶記錄在mysql數據庫的user三個權限表的用戶列（包括host、user、password三個字段）。
1）對於身份認證MySQL是通過IP地址和用戶名進行聯合確認的，也就是說“用戶名@IP”用來身份認證的唯一標識；
2）安全配置時儘量避免採用默認的用戶名root，建議對默認用戶名進行重命名，這樣增加鑑別信息被猜測的難度；
mysql> update mysql.user set user =’madman’ where user=’root’; –將root重命名爲madman
3）mysql數據庫默認無法實現密碼更改週期和密碼複雜度要求，需要管理員定期更改口令的複雜度，可以通過如下命令設置密碼；
mysql>update mysql.user set password=password(“12ere@123SWE!@”) where User=”root” and host=”localhost”; –設置密碼複雜度
mysql>FLUSH PRIVILEGES; –刷新權限表
除了密碼認證外，MySQL還支持UNIX域套接字，可以在配置文件中指定套接字文件的路徑，如—socket=/tmp/mysql.sock，當數據庫啓動後可以使用UNIX套接字的方式進行認證。
4）針對MySQL5以後的版本建議禁止使用old_password參數，–old-passwords選項的目的是當服務器生成長密碼哈希值時，允許你維持同4.1之前的客戶端的向後兼容性。在MySQL4.1版本以後建議禁止使用該參數。
5）MySQL數據庫也支持SSL遠程登錄，如果採用本地管理方式則不需要考慮遠程連接安全，如果採用遠程管理則需要SSL支持。
mysql>SHOW VARIABLES LIKE ‘%have_ssl%’； –查看是否支持ssl的連接特性，若爲disabled，說明此功能沒有激活。
6）確保所有的身份鑑別的密碼具有較強的密碼複雜度。
最後，MySQL數據庫本身不支持登錄次數限制，無法實現針對用戶的鎖定，具有登錄的連接超時設置。
（二）、PostgreSQL數據庫
PostgreSQL 支持豐富的認證方法：信任認證、口令認證、PAM認證等多種認證方式。PostgreSQL 默認配置只監聽本地端口，無法通過遠程TCP/IP連接數據庫。需要修改 postgresql.conf 中的 listen_address 字段修改監聽端口，使其支持遠程訪問。例如listen_addresses = ‘*’表示監聽所有端口。
線上重要數據庫禁止使用trust方式進行認證，必須使用md5方式。
重命名數據庫超級管理員賬戶爲pgsqlsuper，此帳號由DBA負責人保管，禁止共用；
配置數據庫客戶端支持SSL連接的配置。客戶端認證是由一個配置文件控制的，存放在數據庫集羣的數據目錄裏[3]。
用openssl生成密鑰對，創建一個自簽名的服務器密匙（server.key）和證書（server.crt）；
數據庫的配置主要通過兩個配置文件pg_hba.conf和postgresql.conf來實現；
開啓TCP/IP連接：將postgresql.conf參數tcpip_socket設置爲true；
開啓SSL：將postgresql.conf參數ssl設置爲true；
強制局域網內的所有主機以任何PostgreSQL中存在的用戶通過TCP+SSL的方式連接到PostgreSQL；
在pg_hba.conf文件中增加記錄：hostssl all all 192.168.54.1/32 md5。
postgresql中還可以通過pg_user系統表的valuntil字段實現用戶口令失效的時間(只用於口令認證)。
0x02 訪問控制
MySQL和PostgreSQL均可以實現訪問控制功能。
（一）、MySQL數據庫
MySQL權限系統通過兩個階段進行權限認證：
對連接的用戶進行身份認證，合法的用戶通過認證，不合法的用戶拒絕連接；
對通過認證的合法用戶賦予相應的權限，用戶可以在這些權限範圍內對數據庫做相應的操作。MySQL中主要權限存儲在MySQL系統庫的user、host、db三個系統表中。這三個表中包括權限列，其中權限列包括普通權限和管理權限。普通權限主要用於數據庫的操作，比如select_priv、create_priv等；而管理權限主要用來對數據庫進行管理的操作，比如process_priv、super_priv等。表1說明了mysql權限系統表
當用戶進行連接的時候，權限表的存取過程有以下兩個階段。
先從user表中的host、user和password這三個字段中判斷連接的IP、用戶名和密碼是否存在於表中，如果存在，則通過身份驗證，否則拒絕連接。
如果通過身份驗證，則按照以權限表的順序得到數據庫權限：userdbtable_privcolumns_priv，即先檢查全局權限表user，如果user中對應的權限爲Y，則此用戶對所有數據庫的權限都爲Y，將不再檢查db, tables_priv,columns_priv；如果爲N，則到db表中檢查此用戶對應的具體數據庫，並得到db中爲Y的權限；如果db中爲N，則檢查tables_priv中此數據庫對應的具體表，取得表中的權限Y，以此類推。這幾個權限表中，權限範圍一次遞減，全局權限覆蓋局部權限。
通過上述介紹，可知在配置權限時需要根據數據庫業務使用的情況配置合理的權限。
1)儘量最小化權限的配置，可以通過如下命令查看權限。
mysql> select * from mysql.user\G –檢查用戶權限列
mysql> select * from mysql.db\G –檢查數據庫權限列
mysql> select * from mysql.tables_priv\G –檢查用戶表權限列
mysql> select * from mysql.columns_priv\G –檢查列權限列
2)業務系統在使用時，也可以通過視圖控制對基礎表的訪問；
3)通過合理的權限配置進行訪問控制外，還需要將DBA管理和應用賬號嚴格分離，不同應用單獨賬號，刪除數據庫相關的歷史操作記錄，避免信息泄露。
4)對於MySQL數據庫自身不具備強制訪問控制（MAC），強制訪問控制（MAC）是系統強制主體服從訪問控制策略。與自主訪問控制（DAC）基於系統實現身份認證及其到系統資源的介入授權方式，共同保證用戶的權限。
a、創建系統表：爲了實現可定製強制訪問控制，需定義用戶的強制訪問權限管理表，系統需要對MySQL原有的數據字典進行改造[3]，增加系統表。
b、修改用戶認證邏輯 在sql_acl.cc中修改用戶驗證邏輯，檢查強制訪問權限管理表，是否符合用戶認證要求。
（二）、PostgreSQL數據庫
PostgreSQL將所有的數據庫對象都存放在系統表空間，所有的系統表都以pg開頭。PostgreSQL採用基於角色的訪問控制機制，通過角色機制，簡化了用戶和權限的關聯性。PostgreSQL系統中的權限分爲兩種：系統權限和對象權限。
系統權限是指系統規定用戶使用數據庫的權限（如連接數據庫、創建數據庫、創建用戶等），系統角色屬性有LOGIN、PASSWORD、SUPERUSER、CREATEDB、CREATEROLE、INHERIT等。
對象權限是指在表、序列、函數等數據庫對象上執行特殊動作的權限，其權限類型有select、insert、update、delete、references、trigger、create、connect、temporary、execute和usage等。
有關角色屬性信息可以在系統表pg_authid中找到。另外pg_roles是系統表pg_authid公開課度部分的視圖。系統表pa_auth_members存儲了角色之間的成員關係
1)根據最小權限要求給用戶配置角色和權限。
postgres=# select * from pg_authid; –查看用戶具有的角色
爲了保護數據安全，當用戶對某個數據庫對象進行操作之前，必須檢查用戶在對象上的操作權限。訪問控制列表（ACL）是對象權限管理和權限檢查的基礎，在PostgreSQL通過操作ACL實現對象的訪問控制管理。所有表的基本定義保存在系統表pg_class中，除了包括表，視圖、序列和索引(與其他許多系統不同，PG的索引也被視作一個類，事實上索引項無論在邏輯組成還是物理結構上都類似一個表的元組。)等對象的基本定義外，它的relacl屬性中爲每個對象維護一個ACL[5]。Relacl是PostgreSQL支持的數組屬性，該數組成員是抽象的數據類型aclitem。這些aclitem作爲對象訪問控制權限的ACE（ACL是存儲控制箱（Access Control Entruy，ACE）的集合，每個ACL實際上是一個由多個aclitem構成的鏈表，ACE由數據庫對象和權限列表構成，記錄着可訪問兌現的用戶或者執行單元（進程、存儲過程等））共同組成對象的ACL。
p1
圖1：ACL權限信息。
2）根據系統提示可以查看對象的ACL列表，已確定用戶對對象的訪問權限。
postgres=# \dp pg_roles; –\dp 後接表名或視圖名查看對象權限
3) 通過合理的權限配置進行訪問控制外，還需要將DBA管理和應用賬號嚴格分離，不同應用單獨賬號，刪除數據庫相關的歷史操作記錄，避免信息泄露。
4)對postgresql進行源代碼修改以實現強制訪問控制（MAC），SQL語句在經過DDL與DML處理時，需要進行MAC檢查，通過檢查的數據才能輸出給用戶，否則只能返回錯誤信息[5]。
0x03 安全審計
商業數據庫均有安全審計功能，通過相關配置，能夠對系統的重要事件進行安全審計目前MySQL數據庫具有基本的日誌功能，通過日誌數據挖掘可以實現安全審計功能，但其實現起來較爲複雜。PostgreSQL具備了良好的審計功能。
（一）、MySQL數據庫
MySQL日誌主要包含：錯誤日誌、查詢日誌、慢查詢日誌、二進制日誌等，日誌主要功能如下：
錯誤日誌：錯誤日誌主要爲了實現數據庫排錯。默認情況下錯誤日誌大概記錄以下幾個方面的信息：服務器啓動和關閉過程中的信息、服務器運行過程中的錯誤信息等跟系統錯誤有關的日誌。
查詢日誌：查詢日誌主要爲了實現數據庫調試。由於查詢日誌會記錄用戶的所有操作，其中還包含增刪查改等信息，在併發操作大的環境下會產生大量的信息從而導致不必要的磁盤IO，會影響mysql的性能的。
慢查詢日誌：慢查詢日誌是用來記錄執行時間超過指定時間的查詢語句。通過慢查詢日誌，可以查找出哪些查詢語句的執行效率很低，以便進行優化。
二進制日誌：二進制日誌也叫更新日誌，主要用於記錄修改數據或有可能引起數據改變的mysql語句，並且記錄了語句發生時間、執行時長、操作的數據等等。
通過上述描述可以看出，對於MySQL來說可以通過日誌分析來實現數據庫審計功能，但是這樣的工作量對DBA來說比較繁瑣，也不利於集中控制數據庫產生的安全審計記錄。MySQL企業級已經實現了針對MySQL的安全審計功能，但開源MySQL數據庫沒有實現安全審計功能。要實現MySQL數據庫的安全審計功能，需要對MySQL源代碼進行修改，目前已經有成熟的插件來實現MySQL數據庫審計功能。
1)MySQL審計插件：MariaDB數據庫管理系統是MySQL的一個分支，其server_audit審計插件能工作在mariadb、mysql和percona server，通過安裝審計插件來實現MySQL的審計功能。
a、安裝審計插件，將server_audit.so 文件拷貝到MySQL/MariaDB 下的 lib/plugin 目錄，並通過如下命令激活該插件：
1
mysql> INSTALL PLUGIN server_audit SONAME ‘server_audit.so’;
b、修改mysql配置文件my.cnf的審計參數
server_audit =FORCE_PLUS_PERMANENT
server_audit_events =’CONNECT,QUERY,TABLE’
server_audit_logging =ON
server_audit_incl_users =root
server_audit_file_rotate_size = 1G
server_audit_file_path = /usr/local/mysql/mysql_logs/auditlog/server_audit.log
c、查看審計配置參數，可以通過下面的命令查詢審計參數配置情況。
1
mysql> SHOW global VARIABLES LIKE ‘%audit%’;
p2
圖1：審計配置參數
表1：PostgreSQL數據庫安全審計配置參數
配置參數 參數說明
server_audit_logging 啓動或關閉審計
server_audit_events 指定記錄事件的類型，可以用逗號分隔的多個值(connect,query,table)，如果開啓了查詢緩存(query cache)，查詢直接從查詢緩存返回數據，將沒有table記錄
server_audit_file_rotate_size 限制日誌文件的大小
server_audit_file_rotations 指定日誌文件的數量，如果爲0日誌將從不輪轉
server_audit_incl_users 指定哪些用戶的活動將記錄，connect將不受此變量影響，該變量比server_audit_excl_users優先級高
2)通過設置嚴格的訪問控制權限確保審計日誌的安全性。
3)通過對審計日誌的格式等進行分析實現審計報表的輸出。
（二）、PostgreSQL數據庫
審計是值記錄用戶的登錄退出以及登錄後在數據庫裏的行爲操作，可以根據安全等級不一樣設置不一樣級別的審計。默認需設置具有如下的安全配置參數：
表2：PostgreSQL數據庫安全審計配置參數
配置參數 參數說明
logging_collector 是否開啓日誌收集開關，默認off，開啓要重啓DB
log_destination 日誌記錄類型，默認是stderr，只記錄錯誤輸出
log_directory 日誌路徑，默認是$PGDATA/pg_log
log_filename 日誌名稱，默認是postgresql-%Y-%m-%d_%H%M%S.log
log_connections 用戶session登陸時是否寫入日誌，默認off
log_disconnections 用戶session退出時是否寫入日誌，默認off
log_rotation_age 保留單個文件的最大時長,默認是1d
log_rotation_size 保留單個文件的最大尺寸，默認是10MB
PostgreSQL日誌裏分成了3類，通過參數pg_statement來控制，默認的pg_statement參數值是none，即不記錄，可以設置ddl(記錄create,drop和alter)、mod(記錄ddl+insert,delete,update和truncate)和all(mod+select)。
1）配置logging_collector、pg_statement、log_connections和 log_disconnections參數，確保登錄連接、退出連接和用戶DDL、DML等行爲能被記錄；
2）配置日誌文件名稱、大小、保留週期等滿足相關要求；
3）確保所有的審計記錄的權限滿足操作系統的權限要求。
0x04 入侵防範
針對數據庫的安全防範主要體現在數據庫補丁更新，特定函數的使用等方面。
（一）、MySQL數據庫
嚴格控制操作系統賬號和權限
鎖定mysql用戶不能登錄；
其他任何用戶都採用獨立的賬號登錄，管理員通過mysql專有用戶管理MySQL，或者通過su到mysql用戶下進行管理。
mysql用戶目錄下，除了數據文件目錄，其他文件和目錄屬主都改爲root。
刪除匿名賬號；
不要把file、process或super權限授予管理員以外的賬號；
進制load data local文件讀取操作的使用，避免讀取操作系統的重要文件到數據庫表中；
在已有的生產庫上建議進制使用safe-user-create參數的使用，避免用戶使用grant語句創建新用戶；
及時更新MySQL安全補丁。
（二）、PostgreSQL數據庫
嚴格控制操作系統的賬號和權限，確保啓動進程具有最小的權限；
嚴格控制數據庫安裝目錄的權限，除了數據文件目錄，其他文件和目錄屬主都改爲root。
及時更新數據庫bug和安全補丁。
0x05 資源控制
資源控制主要保證數據庫的資源不被非法的佔用。
（一）、MySQL數據庫
MySQL中主要權限存儲在MySQL系統庫的user系統表的資源列中可以控制用戶連接數、最大請求數、最大更新數、最大連接等信息。但最大用戶連接數爲較長用的資源控制項，其他選項需更具數據的使用情況進行安全配置。
MAX_QUERIES_PER_HOUR 用來限制用戶每小時運行的查詢數量
MAX_UPDATES_PER_HOUR 用來限制用戶每小時的修改數據庫數據的數量。
MAX_CONNECTIONS_PER_HOUR用來控制用戶每小時打開新連接的數量。
MAX_USER_CONNECTIONS 限制有多少用戶連接MYSQL服務器。
針對每個用戶限制MAX_USER_CONNECTIONS參數，即限制用戶最大連接數。
針對每個用戶限制其來源地址限制，即每個用戶僅允許唯一的IP地址訪問，必要時禁止遠程連接mysql ，設置skip-networking參數。
（二）、PostgreSQL數據庫
PostgreSQL對於資源限制主要體現在用戶最大併發連接數的限制上。具體可以進行如下安全配置。
1）postgresql數據庫可以進行嚴格的地址限制，確保用戶來源可信。
2）配置用戶最大併發連接數量。
postgres=# select * from pg_authid;#查看限制其最大併發連接數量
3）postgresql具有默認的連接超時策略。
0x06 參考文獻
【1】 《關於應用安全可控信息技術加強銀行業網絡安全和信息化建設的指導意見》[ON/EL].http://www.cbrc.gov.cn/govView_EE29BABB27EB4E51A4343517691438F9.html
【2】 邱梓華，宋好好，張笑笑，顧健,主機安全等級保護配置指南[J].信息網絡安全，2011年增刊，112～113
【3】 楊玉傑，韓昧華，王永剛，PostgreSQL的安全數據傳輸[J]，聊城大學學報（自然科學版），第23卷第1期，89～90
【4】 吳飛林，王曉豔，郎波，基於MySQL的可定製強制訪問控制的研究與實現[J].計算機應用研究，第24卷第11期,119
【5】 張孝，PostgreSQL中基於ACL的數據訪問控制技術[J]，計算機應用和軟件，第24卷第9期，68
【6】 劉欣，沈昌祥，基於PostgreSQL的強制訪問控制的實現[J]，計算機工程，第32卷第2期，50