一轉(zhuǎn)眼，已經(jīng)是雞年的第一個工作日了，祝各位看官開年大吉。

就在兩天前，《Gitlab誤刪300GB數(shù)據(jù)，備份失效后直播搶救》、《Gitlab不小心刪除了數(shù)據(jù)庫導(dǎo)致網(wǎng)站下線》霸屏了科技新聞的頭條。

整個事件的回顧，Gitlab 第一時間放到了 Google Doc 上，并在 Twitter 上對事件的處置狀態(tài)進行實時更新，后來索性在 Youtube上 開了頻道直播恢復(fù)進程，目前網(wǎng)站已經(jīng)恢復(fù)了正常。

對于事件的前因后果，Gitlab 在 Google Doc 上面已經(jīng)進行了詳細(xì)說明，簡單來說：

Gitlab 遭受了惡意郵件發(fā)送者的 DDoS 攻擊，導(dǎo)致數(shù)據(jù)庫寫入鎖定，網(wǎng)站出現(xiàn)不穩(wěn)定和宕機，在阻止了惡意郵件發(fā)送者之后，運維人員開始修復(fù)數(shù)據(jù)庫不同步的問題，在修復(fù)過程中，錯誤的在生產(chǎn)環(huán)境上執(zhí)行了數(shù)據(jù)庫目錄刪除命令，導(dǎo)致300GB數(shù)據(jù)被刪除，Gitlab 被迫下線。在試圖進行數(shù)據(jù)恢復(fù)時，發(fā)現(xiàn)只有 db1.staging 的數(shù)據(jù)庫可以用于恢復(fù)，其它五種備份機制均無效。db1.staging 是6小時前的數(shù)據(jù)，而且傳輸速率有限，導(dǎo)致恢復(fù)進程緩慢。

作為一個信息系統(tǒng)審計師和信息安全顧問，筆者曾經(jīng)對數(shù)十家企業(yè)的信息系統(tǒng)運維工作進行過審計，類似的事件屢見不鮮，其中也不乏國際知名的IT巨頭和國內(nèi)頂尖的科技公司，只是傳播范圍、影響力、事件透明度都沒有這個事件這么大。這次事件，其實是一個非常典型的信息安全風(fēng)險爆發(fā)、信息安全控制措施失效的案例，筆者將從 IT 審計的角度，進行一些簡單分析和分享。

1、IT審計的邏輯是什么

IT 審計是一種針對信息系統(tǒng)的審計方式，不同于財務(wù)審計對財務(wù)報告真實性、有效性、準(zhǔn)確性的驗證，IT 審計關(guān)注于對信息系統(tǒng)本身的穩(wěn)定性、準(zhǔn)確性、安全性的檢查以及圍繞信息系統(tǒng)運維管理活動有效性的檢查。直白一點來說，除了要檢查信息系統(tǒng)本身能否正確、穩(wěn)定的進行信息處理，IT 審計還關(guān)注是否針對信息系統(tǒng)運維風(fēng)險的設(shè)計了有效的控制措施，并有效執(zhí)行。

在 IT 審計中，審計的出發(fā)點叫做 WCGW (What Could Go Wrong)，說白了就是要識別出哪些場景可以導(dǎo)致信息系統(tǒng)的不穩(wěn)定、不準(zhǔn)確的情況發(fā)生。這是一個基于過程的分析方式，用 Gitlab 事件舉個例子，其中的一個 WCGW 就可以是『錯誤的將對備庫操作在生產(chǎn)庫上執(zhí)行』。在大量的IT風(fēng)險事件基礎(chǔ)上，IT審計服務(wù)機構(gòu)識別出了很多的WCGW，并進行歸類和分析，并據(jù)此設(shè)計出一套方法論和控制措施檢查清單。IT審計服務(wù)機構(gòu)根據(jù)這一方法論和檢查清單對企業(yè)執(zhí)行IT審計，以判斷是否有能力應(yīng)對潛在的IT風(fēng)險。

審計執(zhí)行過程一般分為兩個階段：

制度、流程、控制措施的設(shè)計有效性檢查階段

制度、流程、控制措施的執(zhí)行有效性檢查階段

首先，控制設(shè)計的有效性主要是檢查企業(yè)是否建立了制度、流程，以對風(fēng)險進行控制。

筆者在實際檢查過程中，經(jīng)常發(fā)現(xiàn)不完善的企業(yè)的IT規(guī)則嚴(yán)重依賴信息系統(tǒng)管理、維護人員的個人能力和意識，信息系統(tǒng)的維護活動、操作執(zhí)行對企業(yè)管理者來說是完全的黑盒。而正規(guī)一些的IT組織，則會建立完整的規(guī)則，且不論這些規(guī)則是否執(zhí)行有效，至少在紙面上可以做到『有法可依』。在審計的邏輯里面，有法可依是第一步，如果連基本的管理要求都不存在，也就談不上執(zhí)行的有效性了。

其次，控制執(zhí)行有效性檢查，是基于『控制設(shè)計是有效的』這一結(jié)論。

一般來說，如果設(shè)計有效性評價為無效，是不會進行執(zhí)行有效性檢查的，因為那意味著『無法可依』或者『法律無效』。在Gitlab這個事件中，有評論分析說，管理員之所以執(zhí)行了誤操作，是因為『迷失在了N多個終端窗口當(dāng)中』。這樣的場景很常見，很多企業(yè)都制定了生產(chǎn)環(huán)境操作的規(guī)則以防止類似的事情發(fā)生，可實際上由于這些控制措施未被執(zhí)行，還是會導(dǎo)致生產(chǎn)事故的發(fā)生。筆者曾聽聞了多起類似的由于多窗口不同環(huán)境同時操作導(dǎo)致的生產(chǎn)事故，這種情況被稱為控制措施執(zhí)行的失效。

2、IT審計的三大重點

如前所述，各家IT審計服務(wù)機構(gòu)都有一套控制檢查清單，其中，最為基礎(chǔ)的被稱為『一般性IT控制措施』，這當(dāng)中包括了三大審計重點。就筆者實際服務(wù)經(jīng)驗來看，這三大重點往往涵蓋了絕大多數(shù)的生產(chǎn)故障發(fā)生的原因。

重點一：變更管理

在Gitlab事件中，最為令人驚訝的（其實也沒那么驚訝）是運維人員在事件處置過程中，可以不經(jīng)任何授權(quán)、評估、測試，直接在生產(chǎn)環(huán)境上進行實驗性的操作，而且執(zhí)行的是刪除目錄這樣高危的操作。在ITIL所描述的變更發(fā)布管理優(yōu)秀實踐中，變更管理往往會經(jīng)過多個控制環(huán)節(jié)，以確保變更的成功，這些環(huán)節(jié)包括了變更申請、授權(quán)、評估（業(yè)務(wù)影響、風(fēng)險、可行性）、測試（單元、集成、用戶驗收）、審批、發(fā)布執(zhí)行、回滾計劃、上線驗證等等。之所以變更流程的優(yōu)秀實踐如此之復(fù)雜，是因為生產(chǎn)環(huán)境的變更實際上是信息系統(tǒng)安全性最大的隱憂。

在IT審計中，變更管理的有效性，也是關(guān)注的第一大重點。作為審計師，我們會關(guān)注變更流程中是否有有效的審批授權(quán)（以確認(rèn)變更操作不是個人的、非授權(quán)的行為）、是否進行了合理而充分的測試（以確認(rèn)變更在上線前是否得到質(zhì)量驗證）、是否遵循了不相容職責(zé)分離的原則（申請與審批、開發(fā)與測試、開發(fā)與上線部署等）。在Gitlab事件中，我們明顯的看到管理員對生產(chǎn)環(huán)境執(zhí)行的變更操作未能遵循上述基本要求。

雖然Gitlab作為一家創(chuàng)業(yè)型的科技企業(yè)，實際上無需遵守什么樣特定的運維流程，但一些通用風(fēng)險控制的管理方式也是可以借鑒的，畢竟這些控制點和實踐是從大量的教訓(xùn)當(dāng)中積累出來的。從審計的角度來說，所有的形式、文檔、記錄都是為了『證明我們確實這么做了』，但從目的來說，更重要的是『即使我們不需要證明什么，我們也會遵循一些要求來提高我們系統(tǒng)的安全性和穩(wěn)定性』。

重點二：訪問控制

在IT審計中的第二個重點是訪問控制，訪問控制一般會關(guān)注兩大問題：

賬號合理性的問題

權(quán)限合理性的問題

直白一點來講，第一個問題關(guān)注哪些人能開哪些門，第二個問題關(guān)注這些人進到屋子里面之后能干些什么。

Gitlab事件當(dāng)中，我們注意到了很多有趣、有價值的建議，例如生產(chǎn)運維賬號權(quán)限限制以及自動化運維，這些建議其實都可以看作是訪問控制的一種延伸。在對生產(chǎn)運維賬號權(quán)限進行限制時，運維人員將無法直接對一些敏感、高危的操作直接執(zhí)行，而必須額外的獲得更高的權(quán)限執(zhí)行操作，這些特異性的操作方式由于有別于開發(fā)、測試環(huán)境，將有利于運維人員獲得操作危險性提示，這當(dāng)然是對『人肉運維』的一種改良性的嘗試。而自動化運維，則是更加徹底可以降低這一風(fēng)險的運維技術(shù)發(fā)展趨勢。除了應(yīng)急情況下備用的管理員賬號，信息系統(tǒng)當(dāng)中只存在自動化運維工具的賬號，這些運維工具被配置特定的權(quán)限、執(zhí)行特定的操作，這將大大的降低『人肉運維』可能帶來的風(fēng)險。

『人肉運維』仍然是絕大多數(shù)企業(yè)采用的操作方式，很多運維人員甚至認(rèn)為使用root權(quán)限進行生產(chǎn)環(huán)境線上操作處理問題是能力高超的表現(xiàn)。單獨依靠運維人員的個人能力進行運維，風(fēng)險不光有人員能力的天花板，企業(yè)還不得不面對可能的（有些地方甚至是必然的）運維人員流動帶給信息系統(tǒng)的巨大風(fēng)險。

重點三：備份和恢復(fù)測試

筆者在為很多企業(yè)進行IT審計服務(wù)時，最常提出的風(fēng)險發(fā)現(xiàn)之一就是『未執(zhí)行備份的恢復(fù)測試，無法驗證備份數(shù)據(jù)的有效性』，這也被業(yè)內(nèi)人士自嘲式的稱為『最沒有營養(yǎng)的IT審計發(fā)現(xiàn)之一』，因為這一發(fā)現(xiàn)并不會在實質(zhì)上影響審計結(jié)論。然而，在Gitlab事件中，我們看到了令人驚詫的一幕，多重備份機制竟然只有一個可以用于數(shù)據(jù)恢復(fù)。

隨著技術(shù)的飛速發(fā)展，已經(jīng)有了越來越多的技術(shù)手段，幫助企業(yè)提高信息系統(tǒng)的可用性和連續(xù)性。我們看到了集群式高可用架構(gòu)，異地多活數(shù)據(jù)中心，提供數(shù)據(jù)高完整性保障的云服務(wù)。然而在這紛繁繚亂的新技術(shù)中，回歸到信息系統(tǒng)連續(xù)性管理的本源，我們是否對數(shù)據(jù)做了有效的備份，并且能夠在突發(fā)情況下可以實際的實現(xiàn)數(shù)據(jù)的恢復(fù)？我們各種備份機制下，是否設(shè)定了合理的RPO，以滿足我們對數(shù)據(jù)恢復(fù)時可以容忍的數(shù)據(jù)損失？我們是否真正的執(zhí)行過演練，以驗證我們設(shè)定的RTO，真的能夠完成我們的服務(wù)恢復(fù)？

對于備份和恢復(fù)管理，Gitlab事件堪稱絕佳的案例，集中的體現(xiàn)出了備份有效性、RPO和RTO未得到驗證的問題。這也是為什么，越來越多的領(lǐng)軍企業(yè)開始關(guān)注信息系統(tǒng)的連續(xù)性管理和應(yīng)急響應(yīng)，越來越多的企業(yè)開始真刀真槍的開展數(shù)據(jù)中心的切換演練、數(shù)據(jù)恢復(fù)測試演練、應(yīng)急預(yù)案演練。而演練過程中，也確確實實可以發(fā)現(xiàn)大量的不可預(yù)期的問題，例如交通耗時、備用的設(shè)施設(shè)備可用性、各類系統(tǒng)的版本和兼容性問題、讀寫速度和運營商帶寬限制問題、介質(zhì)有效性問題等等，而這些問題在缺少演練的情況下，是很難暴露出來的。

文末小結(jié)

1）前車之鑒，未雨綢繆

就像互聯(lián)網(wǎng)金融行業(yè)里面一直在討論的『投資者教育』的問題，在發(fā)生實質(zhì)性違約事件之前，總是有很多人無法理解『責(zé)任自擔(dān)』的含義。

不論是Gitlab事件，還是當(dāng)年的攜程宕機事件，都應(yīng)當(dāng)作為自我審視和優(yōu)化的一個契機。審視一下自己公司的規(guī)則是否完備，審視一下規(guī)則是否有效的落實，把每一個別人的事故當(dāng)成自我檢查的標(biāo)準(zhǔn)，把每一個預(yù)案場景都實實在在的進行一下演練。安全穩(wěn)定的系統(tǒng)環(huán)境，需要我們以前車之鑒，做未雨綢繆。

2）『有風(fēng)險意識的工程師文化』

筆者在IT風(fēng)險領(lǐng)域從業(yè)多年，盡管在從業(yè)過程中一再的強調(diào)管理導(dǎo)向的重要性，卻也是堅定的工程師文化的追隨者。作為技術(shù)公司，我們應(yīng)當(dāng)更多的相信技術(shù)而不是管理。

安全的運維需要規(guī)則，但規(guī)則的落實要盡可能的依賴技術(shù)的力量，而非紙面上的制度、流程、管理活動。而我也相信，重規(guī)則、輕流程的技術(shù)導(dǎo)向型IT風(fēng)險管理，可以讓企業(yè)走的更高更遠(yuǎn)。

本文作者：馬寅龍（點融黑幫），點融網(wǎng)信息安全合規(guī)專家，2年IT審計和6年信息安全風(fēng)險咨詢服務(wù)經(jīng)驗，擅長信息科技戰(zhàn)略規(guī)劃、信息安全體系建設(shè)、IT風(fēng)險管理與治理，崇尚以務(wù)實的方式踐行企業(yè)的信息安全風(fēng)險管理。