參與專家有：京東數科數據庫團隊負責人-高新剛、交通行業運維經理-Jan、廣州維他奶技術總監-葉熙昌、安徽天元技術總監-徐傳貴、DBA-秦世黎、DBA-蔡鵬。

[[322953]]

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

[[322954]]

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

1、如何防止運維人員在生產環境搞測試、自己編寫程序連生產庫等騷操作?

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

2、運維人員應不應該為了工作之便在客戶系統上使用自己編寫的工具?

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

3、流程一旦復雜，勢必會影響運維的效率，應該怎么設置運維人員的工作流程、權限劃分才能兼顧到效率與安全?

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

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

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

5、甲方對外包人員應該做到怎樣的權限管理?

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

6、甲方自身應該做好怎樣的應急預案?

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

7、企業的等保工作如何開展并落實到位?

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

8、運維人員應該嚴守哪些工作準則、具備哪些安全意識?

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

9、運維真如多數人吐槽的那樣，是份“高危”職業嗎?這個職業的上崗標準和保障條例是否應該進一步優化?

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

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

1. 如何制定生產運行管理規范，明確權責，提高生產環境安全、責任意識?
2. 生產操作怎么做到有授權、有記錄、有跟蹤、有監控?
3. 未經充分測試的程序、未經充分確認的操作命令、未經充分討論確認的方案，如何嚴格規定不得在生產執行?
4. 賬號權限如何管理?
5. 工作職責如何管理?

本文轉載自微信公眾號「DBAplus社群」，可以通過以下二維碼關注。轉載本文請聯系DBAplus社群公眾號。