近日，云頭條發布的“一個違規操作、損失 800 萬、被判五年半：運維夏某某致鄭大一附院智慧醫院系統癱瘓 2 個小時，判破壞計算機信息系統罪”一文引發了技術圈的熱議。

[[323346]]

圖片來自 Pexels

事件經過

夏某某任職北京中科某某科技有限公司，負責該公司為鄭大一附院開發的“軟件信息系統”的維護工作。

[[323347]]

2017 年 10 月 31 日 20 時許，夏某某參與并直接操作了鄭大一附院“HIS 數據庫”的賬號密碼修改儀式，夏某某在未經授權或許可的情況下，私自記錄了該賬號密碼。

后夏某某在未經授權或許可的情況下，私自編寫了“數據庫性能觀測程序”和鎖表語句，并利用私自記錄的賬號密碼將該程序私自連接鄭大一附院“HIS 數據庫”，導致該鎖表語句在“HIS 數據庫”運行。

2018 年 12 月 24 日 8 時 13 分至 9 時 47 分期間，夏某某先后六次利用“數據庫性能觀測程序”連接“平臺數據庫”的“鎖定平臺掛號表”功能，將數據庫執行鎖表命令。

該命令執行后鎖定 fin_opr_register 表，使其不能進行其它活動，并導致“HIS 數據庫”鎖定。造成鄭大一附院鄭東院區、惠濟院區、醫學院院區所有門診、臨床計算機業務受到惡意語句攻擊，門急診掛號、門急診叫號、門急診支付、門急診藥房、門急診檢查、門急診檢驗等業務系統均無法正常操作，所有門診相關業務停止服務，造成該醫院三個院區門診業務停滯近兩個小時，造成大量患者積壓在門診無法就診，嚴重影響醫院的正常醫療工作。

案發后，夏某某對其工作數據日志、辦公電腦進行了清理。2019 年 5 月 22 日，經民警電話通知后被告人夏某某到鄭州市公安局鄭東分局投案。

經鄭大一附院出具證明：由于惡意鎖表行為遭受損失等相關情況，包括：

• 從當日收入來測算。當日收入損失約為 800 萬元。
• 鄭東院區門診樓有 380 臺電腦無法進入醫生工作站正常工作，72 臺自助掛號機和 49 臺報到機無法正常工作;河醫院區門診樓有 1027 臺電腦無法正常進入系統，86 臺自助掛號機和 55 臺報到機無法工作;惠濟院區門診部有 82 臺電腦無法正常進入系統，11 臺自助掛號機和 4 臺報到機無法工作。
• 對該院智慧醫院項目造成巨大影響。

被害單位委托代理人楊某的陳述：

2018 年 12 月 24 日 8 點 17 分，我在鄭大一附院河醫院區辦公，我看到微信上三個院區的服務群里說門診業務系統卡住了，無法進行其他任何業務。

我和同事以及東區的技術人員一起通過工作電腦查詢門診業務系統卡機的原因和查詢數據庫。在查到 82 號和 89 號這兩個接口服務器時，發現數據包擁塞嚴重。

在 9 點的時候，我在我們的 PL/SQL 里面發現了一條鎖表語句(LOCKTABLE+表名字，也是掛號業務表)，然后我們就執行了終止語句(KILL)。

我們一共執行了 6 次終止語句，門診業務才恢復正常，這個時候時間是 10 點左右。

后來我們將服務器工作日志導出發到東軟公司總部進行分析，分析的結果是發現那個鎖表語句是非程序中的運行語句，懷疑是人為操作，操控門診業務系統。

我們又請了鄭州市信大天瑞信息技術有限公司的技術人員進行了日志分析，分析的結果與東軟一致。

這 6 次鎖表語句的總共執行時間是 1 小時 34 分，從 2018 年 12 月 24 日上午 8 點 13 分開始到 9 點 47 分結束。

這個鎖表語句影響了鄭大一附院的三個院區，分別是鄭東院區、河醫院區和惠濟院區門診的所有業務。

在這 1 小時 34 分的時間內三個院區的 15300 多個門診業務量無法工作，24 號當天的業務量是 25528 個。這次的惡意鎖表現象嚴重影響了我們的日常門診工作。

據當事人解釋：

2018 年 12 月 24 日 8 點左右，我在北京家中用公司給我配備的聯想電腦，遠程登錄到鄭大一附院的數據庫和小型機的數據庫，查看數據庫的運行情況。

大概 8 點 30 分，我看到微信群里河醫的門診系統卡頓，我擔心公司的綜合信息運用平臺也會出問題，就啟動了我自己編程的一個程序(程序名稱：數據庫性能觀測軟件)對我們公司的系統進行查看。

在我運行系統的時候發現我運行的這個程序在報錯，我就更改了幾次數據參數，一直沒有運行成功我就主動放棄了，整個操作過程大概 20 分鐘。大概在 10 點多的時候微信群說河醫系統運行正常，我就去公司上班了。

12 月 25 日我們公司將小型機的數據庫的性能報告導出來，同事張某 2 將報告發給我一份，讓我幫忙分析問題出現的原因。

26 日我分析的時候發現小型機分析報告中第 9 條語句看著有點眼熟，拿出來跟我自己做的編程進行了比對，結果和我運行程序的語句一樣。

我自己推斷可能是我運行的程序和性能報告第九條重疊，這個運行語句會造成鎖表。

接下來我就對我自己做的程序進行分析，發現自己寫的程序是有問題可能會將鎖表語句執行到 HIS 數據庫中。

附錄要點如下：

①編寫的“his.exe”軟件(數據庫性能觀測軟件)沒有得到中科弘睿公司或者鄭大一附院的授權。

②從鄭大一附院授權角度講，我是沒權利使用上述賬號和密碼的。2017 年 10 月 31 日，鄭大一附院網絡安全加密實施儀式我在場，修改的 zdhis 的密碼由 3 個院領導分別掌握各自的部分，我當時寫了個修改密碼的語句。這個語句在我電腦里有保存，我當時存到一個 txt 文檔里。我存這個密碼的時候是我私下偷偷存的。

法院裁定

鄭州高新技術產業開發區人民法院認為：夏某某違反國家規定，擅自對計算機信息系統功能進行刪除、修改、增加、干擾，造成計算機信息系統不能正常運行，后果特別嚴重，其行為已構成破壞計算機信息系統罪。

關于被告人夏某某及辯護人辯稱其沒有破壞計算機信息系統的主觀故意的意見，經查，根據被告人夏某某供述、證人張某 1、張某 2、周某的證言可知，夏某某并無知曉使用鄭大一附院東軟 his 數據庫“zdhis”賬號和密碼的權限，其工作內容并不需要登錄上述帳號。

[[323348]]

夏某某在未經授權的情況下，趁被害單位修改密碼之機私自記錄上述賬號和密碼，并私自開發應用“數據庫性能觀測軟件”，私自使用該賬號密碼連接被害單位 his 數據庫，使其編寫的鎖表語句在 his 數據庫運行，導致被害單位的門診業務系統癱瘓，造成重大損失。

2018 年 12 月 24 日，夏某某在運行自編軟件報錯的情況下多次修改參數繼續運行，導致被害單位計算機信息系統 6 次執行鎖表操作，系統近兩個小時無法正常工作，嚴重影響醫院正常工作。

夏某某作為專業技術人員，應明知其違規操作可能造成被害單位計算機系統不能正常運行，而放任該結果的發生，屬于間接故意，應對危害后果承擔法律責任，符合本罪的主觀構成要件。

被告人夏某某破壞醫療領域提供公共服務的計算機信息系統，致使生產生活受到嚴重影響，造成五十臺以上的計算機不能正常運行，造成經濟損失超過五萬元以上，符合破壞計算機信息系統罪“后果特別嚴重”的規定，應處五年以上有期徒刑。

辯護人辯稱不構成本罪的意見不能成立。夏某某雖系主動到案，但未能如實供述犯罪事實，不能認定為自首。

裁判結果

被告人夏某某犯破壞計算機信息系統罪，判處有期徒刑五年零六個月。(刑期從判決執行之日起計算。判決執行以前先行羈押的，羈押一日折抵刑期一日，即自 2019 年 5 月 23 日起至 2024 年 11 月 22 日止。)

[[323349]]

這里給大家普及一下破壞計算機信息系統罪，它是 IT 從業人員必須了解的安全守則：

《中華人民共和國刑法》第二百八十六條第一款：

【破壞計算機信息系統罪】違反國家規定，對計算機信息系統功能進行刪除、修改、增加、干擾，造成計算機信息系統不能正常運行，后果嚴重的，處五年以下有期徒刑或者拘役;后果特別嚴重的，處五年以上有期徒刑。

違反國家規定，對計算機信息系統中存儲、處理或者傳輸的數據和應用程序進行刪除、修改、增加的操作，后果嚴重的，依照前款的規定處罰。

故意制作、傳播計算機病毒等破壞性程序，影響計算機系統正常運行，后果嚴重的，依照第一款的規定處罰。

單位犯前三款罪的，對單位判處罰金，并對其直接負責的主管人員和其他直接責任人員，依照第一款的規定處罰。

如何看待“鄭大一附院”系統違規操作損失 800 萬，肇事者被判五年半?我們先看看網友的評論：

下面，我們再來看看知乎網友對此事的深入分析，他表示夏同學確實沒說實話，這里聊兩點質疑：

①默認連接了 HIS 數據庫，不知情?

相信寫過代碼的都會感同身受，尤其是夏同學這樣的運維界老鳥。如果連接的是客戶生產庫，那么“用戶名、密碼、url”等信息的配置和啟用，都會是在“蹦一根神經、確認再確認”的狀況下完成，豈會兒戲?

夏同學的“數據庫性能檢測”軟件，事發前已經私下驗證過，并跑了一年多時間(自述是 2017 年 7、8 月份寫的)，而且是一個人寫的全部代碼。

按理說功能點和配置項再熟悉不過了，況且事發前 20 多天早就已經將連接配置新增上去了，并不是當天臨時的忙中出錯導致，怎么可能對“啟動后默認連接上 HIS 的數據庫”并不知情?當初配置的時候是睡著了嗎?

②“數據庫性能檢測”，真的需要如此鎖表?

我寫的程序當中造成鎖表執行程序的語句是 lock table fin_opr_register in exclusive mode。

這個語句的功能是用來鎖綜合信息平臺 fin_opr_register 這個表的。鎖表的目的是為了模擬一下在高并發情況下的死鎖情況，測試一下我們公司綜合信息運用平臺的性能。

在重要客戶(鄭大一附院的門診量全國排名第一)早已上線多年的門診生產庫上，在早上的業務高峰期，用偷來的賬號私下連接，不僅玩模擬性能壓測，執行的還是最高級別的排他死鎖?!!

這操作，如果智商正常，恐怕是想黃了公司吧?

[[323350]]

這里普及下 Oracle 的鎖類型：

Oracle 的幾種鎖類型

PS：以上的數字越大，鎖的級別越高，影響的范圍和操作就越多。

in exclusive mode，意味著其他的更新事務只能被掛起，阻塞所有的更新操作會話。

在業務系統中，我確實極少見到主動排他鎖表的，一般在生產庫上使用 select for update 就已經需如履薄冰了，夏同學這樣的 SQL 使用可以說是罕見的存在。

這樣的寫法會讓事務串行執行，對于有并發的系統尤其是大型生產庫，還是業務高峰期，簡直是災難性的“自殺式襲擊”，一旦執行，故障的結局早已經注定無可避免。

相信懂點 DB 的都明白鎖表的后果，何況是一個專業公司的專業運維人員。

另外，數據庫性能檢測，居然不是檢測數據庫及所在服務器的各項性能指標和日志反饋，也不是利用 Oracle 自帶的完善性能分析工具。

而是選擇在高峰期鎖死業務表來搞垮系統性能，理由是“測試一下性能”，這一波操作如果是正常思考，那么心大的境界實在可怕。

退一步說，不要忘了可是偷偷摸摸連的數據庫，即便真要性能壓測，在凌晨的夜里搞一搞，也不至于輕易被發現，但無論如何也不需要鎖死表才能測到性能呀，再說 HIS 級的業務系統難不成真沒有報錯、告警的日志反饋?

這可是在中國醫院綜合指數科研實力排全國第 10 位的鄭大一附院，也是中國醫院信息化建設的先進單位呀!

感受有如下三點：

①安全規范和安全策略的設定缺失

生產庫即便沒有 VPN，也沒有設置遠程跳板機，至少也得做好白名單或可訪問的 ip list 設置吧?clientinfo 也需要有記錄 ip 的功能吧?

很明顯，這些都不到位，跳板機也缺失了，安全防范形同虛設。甚至都偷偷遠程訪問了一年多，連異地遠程訪問的 IP 記錄也沒有，心真是太大了，當初項目數據安全方案和上線評估是怎么通過驗收的?監理方是失責的。

②監控告警功能不到位，問題排查能力滯后

都兩個小時了才發現問題所在?二天后當事人才確認可能自己搞的?

數據庫一旦死鎖，服務器 CPU 占用和 DB 內的 SQL 排隊會迅速飆升，業務系統大量報錯 SQL 超時，這樣的特征太明顯了。

在控制臺輸入一條百度到的排查命令也能很快定位到源頭 SQL，但 SQL 雖然被救火的技術人員 Kill 干掉過，但重現了幾次，最終還是放棄了，說明還是問題定位不自信，進而不敢再繼續 Kill 掉問題 SQL，白白浪費了寶貴時間。

一旦發現這樣的異常且非業務內置的 SQL，Linux 直接啟用防火墻，拒絕掉此 IP 的 TCP 鏈接，先恢復業務再慢慢排查，都是及時的應對手段呀!

③對于類似安全意識淡薄，沒有安全規范和執行能力的 IT 公司，應該趁早剔除出圈

影響了兩個小時的門診，耽誤了多少有急癥的門診患者?這并不是 800 萬塊錢賠償的事情，而是以很多人已不可挽回的健康痛楚為代價。

這已經不是一個低智商的事故個例，很明顯是公司層面的整體意識問題，是安全意識和安全規范遠低于及格線的企業能力問題。

[[323351]]

只可惜當事的運維人員夏某某一個人扛下了所有，項目監理方、東軟 HIS 系統架構師、甲方聘請的專家評審組等等都或多或少有責任缺失。

 

對于此事，大家怎么看?運維如何避免面向監獄編程?歡迎大家底部留言討論。

編輯：陶家龍

出處：云頭條，知乎綜合整理

鏈接：https://www.zhihu.com/question/389167387/answer/1170852426