138      阿裏雲  技術社區[雲棲]

DBA在傳統企業數據庫安全建設上能做些什麼？

代海鵬

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

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

分享大綱：

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 把這個用戶的語句抓出來，繼續確認，語句如下：

select  b.username,a.sql_id ,count(*)from

DBA_HIST_ACTIVE_SESS_HISTORY a,dba_users b where a.user_id=b.user_id

group by b.username,a.sql_id

order by count(*);

• 如果無法抓出相關信息，這時候就進行匯報，然後申請鎖定用戶。

• 11G有非常多的用戶，附件word 有其中最常見的31個用戶的詳細信息，包括用戶名字以及這個用戶是哪個Oracle默認組件會使用到的。

  

  （點擊文末鏈接下載查看）                           

2、用戶Profile

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

VERIFY_FUNCTION_11G函數驗證項如下：

• 密碼不能小於8位

• 密碼和用戶名不能一樣

• 也不能是反過來的用戶名

• 不能和數據庫的服務名一樣

• 檢查是不是簡單的字典用於，比如password之類的

• 不能是Oracle

• 必須包含1個數字，一個字母，在檢查的時候順便檢查與之前的密碼最少有3個字母不同

profile中有兩類屬性：

1. 第一類是資源控製，控製邏輯讀、SGA、空閑會話存活時長等等。這一類需要將參數resource_limit設置為TRUE才能生效；

2. 第二類是密碼策略，包括 錯誤幾次、密碼失效、密碼可重用周期、最多可重用次數、驗證函數、密碼鎖定時間、到期後緩期執行等，該類型無需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空間並沒有想象中貴，這點投入是完全值得的。

今天分享就到這兒了，希望大家的係統平安，做好防範。謝謝！

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

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

（接上問）

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

A2：到期了。

Q3：到期的時間不是沒有限製嗎？

A3：資源是沒有限製的。

Q4：資源參數沒打。

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

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

A5：默認180天。

Q6：PPT一開始rf刪掉以後，我去年做過暴力測試，是可以恢複備份的。國外的那個沒有嗎？

A6：國外哥們的庫是不一樣的。他那邊有三到四重的備份方案，各種各樣的容災，全部都沒有用。最後恢複不是采用正常手段恢複的，是用其它係統的數據傳回來的，非常佩服他們把恢複進度在推特上麵進行公布，以每小時5%的進度慢慢恢複。當時這篇文章也炒得很火了。

原文發布時間為：2017-04-25

本文來自雲棲社區合作夥伴DBAplus

最後更新：2017-05-17 12:32:26

  上一篇：  iText操作PDF問題總結

  下一篇：  單元測試，測試什麼？