講師介紹
代海鵬
新炬網絡資深資料庫工程師
擅長資料庫性能優化、故障診斷，曾為中國人壽、中國移動、國家電網、太平洋保險等大型企業提供資料庫技術支援服務。
分享大綱：
面對資料洩密，dba能做什麼？
面對資料丢失，dba能做什麼？
資料庫備份及演練
我把資料的安全事件簡單分為兩類，第一類是洩密事件，第二類是資料丢失事件。
先說說近年來影響比較大的資料洩密事件：
洲際酒店在内的10大酒店洩密大量客人開房的資訊包括姓名、身份證被洩密，直接導緻客人量下降；
下一個是南韓2000萬信用卡資訊洩露，引發“銷戶潮”；
某網資料洩漏，全國各地有39名使用者被騙，詐騙金額高達140多萬。像這類資料洩露，如果你的親屬朋友是被騙人之一，我相信感受一定與光看數字的感觸不同；
某貸寶被脫褲，導緻10g裸條洩露。
再說說近期影響較大的資料丢失事件：
gitlab99%資料丢失：1月份時，某外國工程師對自認為是空檔案夾的檔案夾做了一個删除，過了兩秒他反應過來了，我是不是搞錯伺服器了，後果是幾百g的資料檔案被删得就剩下3個g；
爐石傳說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中有兩類屬性：
第一類是資源控制，控制邏輯讀、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%的進度慢慢恢複。當時這篇文章也炒得很火了。
原文釋出時間為：2017-04-25
本文來自雲栖社群合作夥伴dbaplus