编辑：陶家龙 出处：云头条，知乎综合整理

近日，云头条发布的“一个违规操作、损失 800 万、被判五年半：运维夏某某致郑大一附院智慧医院系统瘫痪 2 个小时，判破坏计算机信息系统罪”一文引发了技术圈的热议。

图片来自 Pexels

事件经过

夏某某任职北京中科某某科技有限公司，负责该公司为郑大一附院开发的“软件信息系统”的维护工作。

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 分，我在郑大一附院河医院区办公，我看到微信上三个院区的服务群里说门诊业务系统卡住了，无法进行其他任何业务。

在 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 点多的时候微信群说河医系统运行正常，我就去公司上班了。

26 日我分析的时候发现小型机分析报告中第 9 条语句看着有点眼熟，拿出来跟我自己做的编程进行了比对，结果和我运行程序的语句一样。

我自己推断可能是我运行的程序和性能报告第九条重叠，这个运行语句会造成锁表。

接下来我就对我自己做的程序进行分析，发现自己写的程序是有问题可能会将锁表语句执行到 HIS 数据库中。

①编写的“his.exe”软件（数据库性能观测软件）没有得到中科弘睿公司或者郑大一附院的授权。

②从郑大一附院授权角度讲，我是没权利使用上述账号和密码的。2017 年 10 月 31 日，郑大一附院网络安全加密实施仪式我在场，修改的 zdhis 的密码由 3 个院领导分别掌握各自的部分，我当时写了个修改密码的语句。这个语句在我电脑里有保存，我当时存到一个 txt 文档里。我存这个密码的时候是我私下偷偷存的。

法院裁定

郑州高新技术产业开发区人民法院认为：夏某某违反国家规定，擅自对计算机信息系统功能进行删除、修改、增加、干扰，造成计算机信息系统不能正常运行，后果特别严重，其行为已构成破坏计算机信息系统罪。

关于被告人夏某某及辩护人辩称其没有破坏计算机信息系统的主观故意的意见，经查，根据被告人夏某某供述、证人张某 1、张某 2、周某的证言可知，夏某某并无知晓使用郑大一附院东软 his 数据库“zdhis”账号和密码的权限，其工作内容并不需要登录上述帐号。

夏某某在未经授权的情况下，趁被害单位修改密码之机私自记录上述账号和密码，并私自开发应用“数据库性能观测软件”，私自使用该账号密码连接被害单位 his 数据库，使其编写的锁表语句在 his 数据库运行，导致被害单位的门诊业务系统瘫痪，造成重大损失。

2018 年 12 月 24 日，夏某某在运行自编软件报错的情况下多次修改参数继续运行，导致被害单位计算机信息系统 6 次执行锁表操作，系统近两个小时无法正常工作，严重影响医院正常工作。

夏某某作为专业技术人员，应明知其违规操作可能造成被害单位计算机系统不能正常运行，而放任该结果的发生，属于间接故意，应对危害后果承担法律责任，符合本罪的主观构成要件。

被告人夏某某破坏医疗领域提供公共服务的计算机信息系统，致使生产生活受到严重影响，造成五十台以上的计算机不能正常运行，造成经济损失超过五万元以上，符合破坏计算机信息系统罪“后果特别严重”的规定，应处五年以上有期徒刑。

辩护人辩称不构成本罪的意见不能成立。夏某某虽系主动到案，但未能如实供述犯罪事实，不能认定为自首。

裁判结果

被告人夏某某犯破坏计算机信息系统罪，判处有期徒刑五年零六个月。（刑期从判决执行之日起计算。判决执行以前先行羁押的，羁押一日折抵刑期一日，即自 2019 年 5 月 23 日起至 2024 年 11 月 22 日止。）

这里给大家普及一下破坏计算机信息系统罪，它是 IT 从业人员必须了解的安全守则：

《中华人民共和国刑法》第二百八十六条第一款：

如何看待“郑大一附院”系统违规操作损失 800 万，肇事者被判五年半？我们先看看网友的评论：

下面，我们再来看看知乎网友对此事的深入分析，他表示夏同学确实没说实话，这里聊两点质疑：

①默认连接了 HIS 数据库，不知情？

相信写过代码的都会感同身受，尤其是夏同学这样的运维界老鸟。如果连接的是客户生产库，那么“用户名、密码、url”等信息的配置和启用，都会是在“蹦一根神经、确认再确认”的状况下完成，岂会儿戏？

夏同学的“数据库性能检测”软件，事发前已经私下验证过，并跑了一年多时间（自述是 2017 年 7、8 月份写的），而且是一个人写的全部代码。

按理说功能点和配置项再熟悉不过了，况且事发前 20 多天早就已经将连接配置新增上去了，并不是当天临时的忙中出错导致，怎么可能对“启动后默认连接上 HIS 的数据库”并不知情？当初配置的时候是睡着了吗？

②“数据库性能检测”，真的需要如此锁表？

我写的程序当中造成锁表执行程序的语句是 lock table fin_opr_register in exclusive mode。

这个语句的功能是用来锁综合信息平台 fin_opr_register 这个表的。锁表的目的是为了模拟一下在高并发情况下的死锁情况，测试一下我们公司综合信息运用平台的性能。

在重要客户（郑大一附院的门诊量全国排名第一）早已上线多年的门诊生产库上，在早上的业务高峰期，用偷来的账号私下连接，不仅玩模拟性能压测，执行的还是最高级别的排他死锁？！！

这操作，如果智商正常，恐怕是想黄了公司吧？

这里普及下 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 万块钱赔偿的事情，而是以很多人已不可挽回的健康痛楚为代价。

这已经不是一个低智商的事故个例，很明显是公司层面的整体意识问题，是安全意识和安全规范远低于及格线的企业能力问题。

只可惜当事的运维人员夏某某一个人扛下了所有，项目监理方、东软 HIS 系统架构师、甲方聘请的专家评审组等等都或多或少有责任缺失。

对于此事，大家怎么看？运维如何避免面向监狱编程？欢迎大家底部留言讨论。

链接：