參與專家有：京東數(shù)科數(shù)據(jù)庫團(tuán)隊(duì)負(fù)責(zé)人-高新剛、交通行業(yè)運(yùn)維經(jīng)理-Jan、廣州維他奶技術(shù)總監(jiān)-葉熙昌、安徽天元技術(shù)總監(jiān)-徐傳貴、DBA-秦世黎、DBA-蔡鵬。

[[322953]]

這兩天，“鄭大一附院系統(tǒng)癱瘓2小時(shí)，違規(guī)操作的運(yùn)維被判5年半”的事件刷了屏。據(jù)目前公開資料顯示，北京中科某某科技有限公司的夏某某在未經(jīng)授權(quán)或許可的情況下，私自編寫了“數(shù)據(jù)庫性能觀測程序”和鎖表語句，并利用私自記錄的賬號密碼將該程序私自連接鄭大一附院“HIS數(shù)據(jù)庫”，導(dǎo)致該鎖表語句在“HIS數(shù)據(jù)庫”運(yùn)行并鎖定，造成鄭大一附院三個(gè)院區(qū)所有門診、臨床計(jì)算機(jī)業(yè)務(wù)受惡意語句攻擊，多個(gè)門診業(yè)務(wù)系統(tǒng)無法正常操作，所有門診相關(guān)業(yè)務(wù)停滯近2個(gè)小時(shí)，嚴(yán)重影響醫(yī)院的正常醫(yī)療工作。

[[322954]]

事件引發(fā)了持續(xù)的熱議，其中也不乏爭議，針對關(guān)注度較高的問題，包括防止運(yùn)維人員的騷操作、如何兼顧運(yùn)維效率與安全、事件中的甲乙兩方存有哪些不足、企業(yè)等保工作如何開展和有效落地等，dbaplus社群整理并歸總觀點(diǎn)如下，希望能給大家今后相關(guān)工作的展開和處理提供參考：

1、如何防止運(yùn)維人員在生產(chǎn)環(huán)境搞測試、自己編寫程序連生產(chǎn)庫等騷操作?

• 權(quán)限控制+日常審計(jì)。對核心生產(chǎn)環(huán)境進(jìn)行白名單機(jī)制，明確每一個(gè)終端每一個(gè)賬號的連接以及進(jìn)程，對異常情況進(jìn)行阻斷或監(jiān)控。
• 除了grant權(quán)限以外，給予開發(fā)運(yùn)維人員slave或dev環(huán)境。
• 通過運(yùn)維系統(tǒng)和堡壘機(jī)隔離運(yùn)維人員和服務(wù)器。程序要納入代碼管控，嚴(yán)禁文件上傳下載。

2、運(yùn)維人員應(yīng)不應(yīng)該為了工作之便在客戶系統(tǒng)上使用自己編寫的工具?

• 要有授權(quán)，要經(jīng)過測試，要經(jīng)過許可。據(jù)我了解電力行業(yè)的一些規(guī)范，要推行軟件、工具，甚至要去電科院進(jìn)行測試，獲得證書才可部署試行。所以如果甲方要求不太嚴(yán)格，可以把自己的工具拿出來一起評審，沒問題的話搞就行，切忌私自運(yùn)行。
• 運(yùn)維人員不應(yīng)該有權(quán)限在客戶的系統(tǒng)上運(yùn)行自己編寫的程序，所有程序必須是公對公的行為。包括各種腳本，都是需要進(jìn)行代碼review的，實(shí)驗(yàn)過沒問題才可以上。

3、流程一旦復(fù)雜，勢必會影響運(yùn)維的效率，應(yīng)該怎么設(shè)置運(yùn)維人員的工作流程、權(quán)限劃分才能兼顧到效率與安全?

• 甲方自身沒有對系統(tǒng)的管控能力，還應(yīng)用于核心系統(tǒng)，等于把命脈交在別人手里。所以甲方應(yīng)該把日常工作流程化，有明確的操作流程，并對乙方的權(quán)限劃分遵循最小化賦權(quán)，最好由堡壘機(jī)錄屏，定期審計(jì)外包操作內(nèi)容。
• 這個(gè)還是得看業(yè)務(wù)的重要性和核心生產(chǎn)環(huán)境的操作，一定要有確認(rèn)、復(fù)審的流程，然后才能執(zhí)行，這一塊一定要嚴(yán)格。實(shí)際上有些方法是可以在技術(shù)方面杜絕一些高危操作的，比如細(xì)化權(quán)限分配和明示高危操作，不同的賬號做不同的事情，精細(xì)化分工;阻斷drop，rm-rf等高危操作。在核心問題方面，質(zhì)量可以大于效率。
• 關(guān)于流程跟標(biāo)注化或者規(guī)范化的實(shí)施及操作，長期以來我只奉行一個(gè)觀點(diǎn)：凡是不能通過代碼來表達(dá)的流程、規(guī)范/標(biāo)準(zhǔn)化都是在扯淡。公司項(xiàng)目多了，人也多了之后不可能每一個(gè)人都會嚴(yán)格遵循流程來的，一旦有一個(gè)人失誤就會造成事故，因此現(xiàn)在很多公司都在推行DevOps不是沒有道理的。
• 流程復(fù)雜盡量使用腳本操作，或者類似Python Ansible的工作。

4、事件中可以看出乙方存有哪些不足?

• 其實(shí)這個(gè)事故本來可以快速定位并解決的，結(jié)果耗時(shí)這么久!從解決該問題的運(yùn)維人員的操作復(fù)盤來看，第一時(shí)間居然是通過plsql看問題，這顯然是存在問題的。我想象的處理場景應(yīng)該是外包公司有一套可靠的監(jiān)控系統(tǒng)(通過員工復(fù)盤過程可以看出監(jiān)控系統(tǒng)應(yīng)該還是有的，但為何監(jiān)控沒有第一時(shí)間預(yù)警，這里也存在問題)，當(dāng)發(fā)現(xiàn)異常后運(yùn)維/DBA應(yīng)該能通過平臺去定位問題甚至解決問題，顯然該乙方在平臺化方面做的有所欠缺。

5、甲方對外包人員應(yīng)該做到怎樣的權(quán)限管理?

• 一是區(qū)分外包人員管理范圍，明確外包人員工作職責(zé);二是甲方應(yīng)該管理核心權(quán)限。對外包人員要有適度權(quán)限管控;三是用系統(tǒng)或者運(yùn)維平臺替代外包人員手動操作。減少人、機(jī)直接接觸。四是根據(jù)等保要求定期進(jìn)行安全巡檢和變更密碼;五是對外包人員進(jìn)行能力考核，防止能力不過硬的運(yùn)維人員接觸核心系統(tǒng)。
• 主要從三方面來考慮和管控，一是要明確規(guī)章制度和管理規(guī)范，明確外包人員的職責(zé)范圍;二是在技術(shù)方面要做好隔離，杜絕某一項(xiàng)目的外包人員擁有其他項(xiàng)目的權(quán)限，這一塊主要是從技術(shù)上實(shí)現(xiàn);三是做好審計(jì)，定時(shí)審計(jì)和控制。
• 我們這邊的做法是，供應(yīng)商不準(zhǔn)有VPN，所有操作必須通過堡壘機(jī)，后臺錄像。然后后面有一套安全的大數(shù)據(jù)平臺，會分析他們的行為，如果有不正常的話，直接報(bào)警。
• 一是不要給外包root administator之類過高的權(quán)限;二是盡量不要給外包人員登錄生產(chǎn)環(huán)境;三是給予slave和測試環(huán)境給開發(fā)人員使用。
• 核心功能權(quán)限不可以給外包人員，得做好分權(quán)分域，并做好安全培訓(xùn)，簽訂安全協(xié)議。

6、甲方自身應(yīng)該做好怎樣的應(yīng)急預(yù)案?

• 一是加強(qiáng)系統(tǒng)化建設(shè)，通過運(yùn)維管控系統(tǒng)實(shí)現(xiàn)自動化管理;二是加強(qiáng)制度管理，提高運(yùn)維人員安全意識和操作規(guī)范度;三是成立技術(shù)評委會，對產(chǎn)品、性能和安全進(jìn)行定期評估。制定應(yīng)急方案。
• 從這個(gè)事件上來講，其實(shí)技術(shù)性不是很強(qiáng)，系統(tǒng)卡頓，數(shù)據(jù)庫排查，查到鎖表，監(jiān)控到鎖表的賬戶和語句，進(jìn)行kill，應(yīng)該快速恢復(fù)。如果要就該事件討論應(yīng)急預(yù)案的話，建議以時(shí)間調(diào)查和溯源為切入點(diǎn)，即出現(xiàn)可以操作到時(shí)系統(tǒng)中斷，應(yīng)該從網(wǎng)絡(luò)、硬件、存儲、客戶端、數(shù)據(jù)庫、應(yīng)用等方面進(jìn)行排查，從問題的排查方法策略、日志、操作審計(jì)溯源等方面，進(jìn)行應(yīng)急預(yù)案，同時(shí)強(qiáng)化備份以及備份驗(yàn)證的頻次。實(shí)際上結(jié)合我的經(jīng)驗(yàn)，數(shù)據(jù)庫有哪些賬號，那些客戶端在鏈接應(yīng)該有臺賬并建立白名單信息的。
• 安全架構(gòu)落實(shí)到位，堡壘機(jī)、監(jiān)控、代碼審計(jì)、賬號權(quán)限、密碼修改策略等等;服務(wù)器方面HA的方案很多很多。白天可以做限制鎖表等危險(xiǎn)性操作，寫好監(jiān)控程序比如觸發(fā)器，禁止該系列危險(xiǎn)操作并發(fā)出警告，除非收到最高權(quán)限授權(quán)。
• 備份和高可用方案要做好。

7、企業(yè)的等保工作如何開展并落實(shí)到位?

• 從某種程度上來講，等保工作其實(shí)是表面大于實(shí)際效果，這也是由于企業(yè)甲方不夠重視引起的。做等保不難，難的是根據(jù)等保的要求和規(guī)范來開展和執(zhí)行安全工作。等保的測評機(jī)構(gòu)領(lǐng)企業(yè)進(jìn)安全的門，給指導(dǎo)規(guī)范和標(biāo)準(zhǔn)，剩下大部分的時(shí)間都應(yīng)該是企業(yè)自己進(jìn)行消化、吸收開展和執(zhí)行。實(shí)際上等保2.0非常具有現(xiàn)實(shí)指導(dǎo)意義，很值得企業(yè)結(jié)合自身情況進(jìn)行研究。
• 一是從規(guī)范管理、到標(biāo)準(zhǔn)化，再到流程管理、事件管理、故障復(fù)盤、iso20000認(rèn)證考核;二是定期請相關(guān)專業(yè)審計(jì)機(jī)構(gòu)進(jìn)行風(fēng)險(xiǎn)評估，查漏補(bǔ)缺。
• 企業(yè)等保要求一定的密碼字符復(fù)雜度和定期進(jìn)行密碼修改，以及SSL鏈接加密。

8、運(yùn)維人員應(yīng)該嚴(yán)守哪些工作準(zhǔn)則、具備哪些安全意識?

• 作為運(yùn)維人員一定要小心謹(jǐn)慎，每個(gè)命令發(fā)下去前一定要想好可能帶來的后果，不做沒有把握的事情。每次代碼更新一定要經(jīng)過嚴(yán)格的測試CodeReview(尤其是大批量操作時(shí)哪怕是只執(zhí)行一個(gè)select也要反復(fù)確認(rèn))。操作前最好有人跟你double check，要學(xué)會通過流程辦事，這是對自己的保護(hù)，切不可迷之自信!
• 運(yùn)維人員做任何變更之前都要想好rollback方案，以及回滾時(shí)間，而且必須事先和用戶說清楚。

9、運(yùn)維真如多數(shù)人吐槽的那樣，是份“高危”職業(yè)嗎?這個(gè)職業(yè)的上崗標(biāo)準(zhǔn)和保障條例是否應(yīng)該進(jìn)一步優(yōu)化?

• 規(guī)范操作，規(guī)范流程制度，增加審核審計(jì)，加強(qiáng)應(yīng)急演練。之后運(yùn)維就是安全的。
• 實(shí)際上沒那么夸張，每個(gè)職業(yè)，只要超越了法律底線，都是高危。
• 以后就沒有運(yùn)維，做SRE就可以了，做什么運(yùn)維?以后新世界就不需要傳統(tǒng)運(yùn)維了。
• 我個(gè)人其實(shí)很同情這位運(yùn)維人員，確實(shí)很可惜，處罰也過重了(想想攜程事件吧)。建議有一定能力的技術(shù)人員盡量到互聯(lián)網(wǎng)公司，不管從個(gè)人技術(shù)成長還是未來發(fā)展空間都要靠譜一些。
• 運(yùn)維確實(shí)是高危行業(yè)，經(jīng)常晚上干活，俗話說賺的賣白菜的錢，擔(dān)著賣白粉的風(fēng)險(xiǎn)。

引用大多數(shù)網(wǎng)友總結(jié)的一句話作為結(jié)尾——不該看的不看，不該記的不記，不該說的不說。至于由以上觀點(diǎn)延伸出的更多具體的問題，歡迎大家在評論區(qū)或投稿給我們繼續(xù)探討：

1. 如何制定生產(chǎn)運(yùn)行管理規(guī)范，明確權(quán)責(zé)，提高生產(chǎn)環(huán)境安全、責(zé)任意識?
2. 生產(chǎn)操作怎么做到有授權(quán)、有記錄、有跟蹤、有監(jiān)控?
3. 未經(jīng)充分測試的程序、未經(jīng)充分確認(rèn)的操作命令、未經(jīng)充分討論確認(rèn)的方案，如何嚴(yán)格規(guī)定不得在生產(chǎn)執(zhí)行?
4. 賬號權(quán)限如何管理?
5. 工作職責(zé)如何管理?

本文轉(zhuǎn)載自微信公眾號「DBAplus社群」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系DBAplus社群公眾號。