《DBA在傳統企業數據庫安全建設上能做些什么？》要點：
本文介紹了DBA在傳統企業數據庫安全建設上能做些什么？，希望對您有用。如果有疑問，可以聯系我們。

本文根據代海鵬老師在〖4月8日DBAplus社群上海數據庫技術沙龍〗現場演講內容整理而成.

講師介紹

代海鵬

新炬網絡資深數據庫工程師

• 擅長數據庫性能優化、故障診斷,曾為中國人壽、中國移動、國家電網、太平洋保險等大型企業提供數據庫技術支持服務.

分享大綱：

1面對數據泄密,DBA能做什么?

2面對數據丟失,DBA能做什么?

3數據庫備份及演練

我把數據的安全事件簡單分為兩類,第一類是泄密事件,第二類是數據丟失事件.

先說說近年來影響比較大的數據泄密事件：

1. 洲際酒店在內的10大酒店泄密大量客人開房的信息包括姓名、身份證被泄密,直接導致客人量下降；
2. 下一個是韓國2000萬信用卡信息泄露,引發“銷戶潮”；
3. 某網數據泄漏,全國各地有39名用戶被騙,詐騙金額高達140多萬.像這類數據泄露,如果你的親屬朋友是被騙人之一,我相信感受一定與光看數字的感觸不同；
4. 某貸寶被脫褲,導致10G裸條泄露.

再說說近期影響較大的數據丟失事件：

1. Gitlab99%數據丟失：1月份時,某外國工程師對自認為是空文件夾的文件夾做了一個刪除,過了兩秒他反應過來了,我是不是搞錯服務器了,后果是幾百G的數據文件被刪得就剩下3個G；
2. 爐石傳說30%數據丟失：有4人在1月份提議把1月份作為數據安全月,也不至于.這是怎么回事呢?爐石傳說的數據庫哥們帶病運行了兩天以后又回滾到故障以前,導致幾天的數據全部丟失.這里我們不去深究到底什么技術原因導致竟然無法修復.

對此,我想說的是：我們的運維團隊并沒有我們想象中那么牛逼,所以我們要對生產抱有敬畏之心.

一、面對數據泄密,DBA能做什么?

1、用戶管理

清理和鎖定無用的數據庫帳號.進了一個新環境,核心庫賬戶是必查項.

• 將未被鎖定的帳號列出來和開發進行確認,每個用戶都找到具體作用和應用.
• 如賬戶無人認領,則通過DBA_HIST_ACTIVE_SESS_HISTORY 配合dba_users 把這個用戶的語句抓出來,繼續確認,語句如下：

• 如果無法抓出相關信息,這時候就進行匯報,然后申請鎖定用戶.
• 11G有非常多的用戶,附件word 有其中最常見的31個用戶的詳細信息,包括用戶名字以及這個用戶是哪個Oracle默認組件會使用到的.

(點擊此鏈接查看) ?

2、用戶Profile

除了用戶本身以外,還有用戶的profile要進行檢查,首先就是密碼的驗證算法,11G默認是沒有算法的,我們要用腳本@?/rdbms/admin/utlpwdmg.sql創建名叫VERIFY_FUNCTION_11G的驗證函數.

VERIFY_FUNCTION_11G函數驗證項如下：

• 密碼不能小于8位
• 密碼和用戶名不能一樣
• 也不能是反過來的用戶名
• 不能和數據庫的服務名一樣
• 檢查是不是簡單的字典用于,比如password之類的
• 不能是Oracle
• 必須包含1個數字,一個字母,在檢查的時候順便檢查與之前的密碼最少有3個字母不同

profile中有兩類屬性：

• 第一類是資源控制,控制邏輯讀、SGA、空閑會話存活時長等等.這一類需要將參數resource_limit設置為TRUE才能生效；
• 第二類是密碼策略,包括 錯誤幾次、密碼失效、密碼可重用周期、最多可重用次數、驗證函數、密碼鎖定時間、到期后緩期執行等,該類型無需resource_limit參數配置.

3、權限管理

權限管理很簡單,就是最小化原則.

最小化應用賬戶,在工作中我個人經驗為默認給開發及應用賬戶的權限,就connect、resource、創建視圖的權限即可.

reousrce的權限是有很多,可以創建視圖,我只給這么多,如果你還想要別的,可以向DBA團隊申請,DBA團隊來給你審批.然后是數據庫字典,普通用戶禁止訪問.為了禁止普通用戶的訪問可以用下面的07-DICTIONARY-ACCESSIBILTY進行限制.安全和便利總是相對的,越安全,那么操作起來就越復雜,所以說這里是否進行限制就見仁見智.我們可以把權限匯集成Role,一類應用所需的權限可以歸類為一個單獨的role,以后只要是類似應用上線不要再管理.而應用下線也可以通過Role快速回收對應權限.通過Role賦權是我的建議之一.

最小化DBA權限用戶,一種是操作系統上面DBA組,其中操縱系統帳號最好就Oracle一個,因為DBA組所屬用戶可以通過操作系統驗證直接以sysdba的權限登錄到庫里.另外一種,數據庫里面有DBA角色,或者有大權限的帳號也一定要審查一下,如果有可疑的賬戶雖然沒有DBA角色,但相關的權限卻全部擁有的,更是一定要進行檢查核對.

4、日志管理

日志管理主要是說審計,在后面發現問題時可以快速知道是之前誰做的操作.我們可以把審計配置好以后關閉審計,如果某天系統已經上生產后老板說你給我把這個庫審計一下,我們只需一條命令就可以審計了,不需要再做一系列配置及資源申請.

審計涉及的參數：

• AUDIT_TRAIL,有幾種配置選項,將審計數據放在數據庫中 或者放在文件系統中,是普通模式 還是 extend模式.詳細的進reference一看便知,這個可自己調配
• AUDIT_SYS_OPERATIONS參數建議打開,畢竟sysdba的威力其實是最大的

有幾點注意事項：

• 將aud$表挪出SYSTEM表空間
• AUDIT_FILE_DEST審計文件存放位置設置一個單獨的lv,嚴禁與根目錄,ORACLE_HOME目錄放在一起
• 默認使用命令noaudit create session 先停止審計,在需要的時候再開啟

11G新參數ENABLE_DDL_LOGGING,開這個參數可以在alert日志中記錄所有的DDL語句,不過記錄的內容相對簡單,只有時間和語句.

在11.2.0.4之前,這個功能是有bug的,rename操作是不做記錄的.

到12C 這個參數更加完善了,如圖右,除了語句以外 還有IP 、機器名等信息,在我們不開審計的情況下,也能獲取DDL執行信息.

5、漏洞管理

及時的升級對應的PSU,尤其是修復的重要安全bug的PSU.

關于漏洞,我簡單地貼了一個文章,1454618.1.

上面有很多數據都可以通過MOS文章一把拉出來.講這個的主要原因是強調我們要緊跟著自身版本的PSU,這個不代表說本月發布的PSU,我們必須本月升級,而是應該有計劃進行升級.比如以延遲半年為計劃,或者延遲一個季度為計劃.除了這方面,還有業內會經常爆出一些嚴重BUG,如像DBAplus這樣的社群是會第一時間發出聲明及處理方案,我們一定要時刻關注,不能等問題真的到我們頭上了才知道,那樣公司請你就沒有價值了.

以上所述都是應對數據泄密的措施.簡單來說,我認為數據泄密方面DBA和運維人員只是做了輔助作用,因為很多公司會有自己的安全團隊,會從外面請一些公司去做整體的掃描,會給出一系列建議、配置性的更改,我們只需要針對數據庫這方面調整,就夠了.

前面說那么多東西是為什么呢?大家都知道了,去年下半年有比特幣勒索,大家在網上了下載了一些破解工具,如PLSQL DEV、SCRT等,有一部分工具被放置惡意的腳本,然后當你通過很大的權限(如SYSDBA)連接到數據庫,這些工具會自己創建一個存儲過程,存過名字起跟真的一樣,里面還給你加密.一定時期以后(如三年)這個函數會自己執行,把你的數據全部搞亂搞廢掉,然后會在報錯信息里面提供包含比特幣鏈接的勒索信息,大致意思是你給我錢,我就給你把數據庫恢復.

那么我們前面做的,收用戶、收權限,就是保證,當我們DBA自身使用的工具是安全的情況下就能保證數據庫不受勒索.如果你大的權限在下面飄著,就不能保證研發、應用的哥們究竟安全意識如何,到時候連防都不好防.

如果面對數據泄密是DBA是輔助類工作的話,面對數據丟失,DBA有無法推卸的責任,這個“鍋”你是甩不出去的.

二、面對數據丟失,DBA能做什么?

在平時運行維護時,總會有種種情況導致業務數據丟失或者損壞,無論丟失是多是少,我們DBA都應該盡量避免發生.

下列是我們平時遇到的4種可能會造成數據丟失的類型：

• 系統故障： CPU、內存、主板、等主機層面的故障
• 存儲故障：UPS掉電、控制器損壞、物理硬盤損壞等
• 數據庫BUG：因觸發數據庫BUG導致刷入存儲的數據塊邏輯損壞
• 人為操作故障,錯誤執行刪除數據命令

就Oracle本身來講,它有自己的高可用體系產品及功能.

1、應對主機層面的故障

這種故障正常來說是丟失未提交的數據,大部分情況我們是無需在意這些丟失數據的.這時候主要以恢復業務為目的來設計數據.我們通過使用主機層面高可用技術RAC,來解決這個問題,主機層面高可用指,兩套內存、CPU等運算資源,但是使用同一套數據文件.當RAC中某主機損壞時,業務可以在下次連接的時候連入另外的節點.

在Oracle 9i之前,RAC的名稱叫做OPS,而9i之前每次傳輸塊的時候,需要先將數據刷入硬盤,然后另外的節點從硬盤上讀取.

RAC進化的最重要的一點,就是有了CACHE-FUSION的特性,最新的當前塊數據可以通過私網進行傳輸了.

使用RAC的注意點：

• 盡量減少cache-fusion,通過應用切割的模式；
• 第二個注意點,CPU、內存這些計算資源,最好不要上60,相對內存來說,CPU更是.如果平時跑每個節點的CPU就飆上60%,那么當發生故障的時候,存活節點是不是能抗住是要打問號的；
• 如果資源吃緊,提前對業務進行提前梳理這套庫上面哪些業務是重要的,哪些業務是較為不重要的,哪些最不重要.便于緊急時刻可停止非關鍵業務釋放資源供給核心業務.

2、應對存儲層面發生故障或損壞

這個層面的故障和損壞RAC是無法保護的,因此Oracle提供了DG進行存儲保護.

當存儲出現故障的時候,丟失多少數據都是有可能的,這時候如果DG存在,我們可以激活備庫,將應用的IP調整為備庫及時的恢復應用,并且可以做到盡量不丟失數據,這里可以給大家分享的經驗是,建立內網域名服務器,將IP都設置為對應的域名,以后發生容災切換的時候 只需要調整域名服務器的映射即可,無需每個應用單獨調整.

在11G以后DG的standby端可以以readonly的模式進行打開,并對外提供只讀服務.這也是盡量將物理資源利用起來.

3、應對BUG導致的數據丟失

兩種情況,一種是歸檔好著,只是刷塊的時候有問題,導致刷壞了.這種普通DG就可以搞定,另外一種歸檔被寫壞,而傳到standby 應用也會導致備庫數據塊壞掉.

這時候我們就需要講DG進行延時應用,注意這里只是延時應用,日志還是會自動傳輸的.哪怕生產壞掉了,除了需要追一定時間的歸檔外,不會有數據丟失,延時語句如下：

alter database recover managed standby database delay 120 disconnect from session;

120的單位是分.

這里2小時只是代表standby 和生產端真實時間差距,并不代表生產發生down機, standby 必須兩個小時才能追平歸檔.

4、應對誤操作

說實話靠個人是很難避免的,誰都有個精神不好的時候,犯迷糊的時候.這時候就需要通過規范和制度來保證這種事情不發生.

經驗分享：

• 一定要有變更方案,詳細列出每條要執行的命令,并且多人評審；
• 具體實施過程中,除非排障,否則命令一律不得手敲；
• 執行危險命令時,一定要ifconfig 查看一下IP,以防萬一；
• 生產和測試環境的窗口不要同時打開,如果非要打開,命名對應窗口,并使用不同的文字背景；
• 變更方案要有對應的回退方案,如果執行變更的時候出現了問題,當時如狀態并不好,建議直接回退,不要勉強自己排錯.

三、數據庫備份及演練

作為一個DBA,如果想要睡得踏實,那么備份一定要有.

當前數據庫中數據越來越大,幾十T的庫屢見不鮮,有時候可能真的沒那么大空間做演練 .經驗小分享：調整備份手段,將業務表空間分散開,每份單獨與system sysaux等組成一個備份集.分批采用進行全備.

最后驗證時可以只驗證一份,這樣數據量就小很多了.不過很多地方為了保證安全,兩地三中心都搞出來了,幾十T空間并沒有想象中貴,這點投入是完全值得的.

今天分享就到這兒了,希望大家的系統平安,做好防范.謝謝!

Q&A

Q1：有一次客戶那邊的賬戶突然鎖了,我查了其它的信息表空間,發現并沒有因為多次密碼登陸錯,排除這個情況外還有什么原因?

A1：你說的是資源,profile分口令規則和資源限制,資源限制是需要和resource_limit參數進行配合的.有兩種情況,第一種情況是有人直接進行手工鎖定,第二種情況是密碼試錯過多導致被鎖定的.

(接上問)

Q2：我的意思是排除密碼輸錯,也不是人為鎖的.

A2：到期了.

Q3：到期的時間不是沒有限制嗎?

A3：資源是沒有限制的.

Q4：資源參數沒打.

A4：資源參數部分是不生效,跟口令參數是無關的.

Q5：可以告訴我多長時間嗎?

A5：默認180天.

Q6：PPT一開始rf刪掉以后,我去年做過暴力測試,是可以恢復備份的.國外的那個沒有嗎?

A6：國外哥們的庫是不一樣的.他那邊有三到四重的備份方案,各種各樣的容災,全部都沒有用.最后恢復不是采用正常手段恢復的,是用其它系統的數據傳回來的,非常佩服他們把恢復進度在推特上面進行公布,以每小時5%的進度慢慢恢復.當時這篇文章也炒得很火了.詳情可了解社群文章《99%數據被誤刪,5類備份全部失效,怎么破?》

文章來自微信公眾號：DBAplus社群

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4223.html