安全隐患漏洞

2023年秋天，安全某三甲医院信息科在例行巡检时发现，隐患一台内网服务器上跑着三年前离职员工留下的漏洞测试脚本。脚本里硬编码了数据库账号和密码，安全而那个账号至今仍有写入权限。隐患没人知道这脚本在跑什么，漏洞也没人敢直接关掉——万一是安全某个业务系统在调用呢？这事最后捅到了院长办公会，处理方式是隐患把服务器网线拔了，等业务科室自己找上门再说。漏洞

这就是安全典型的安全隐患漏洞：不是被黑客攻破的那种，而是隐患自己人留下的、没人说得清、漏洞没人敢碰的安全烂摊子。

我见过太多这样的隐患案例。某制造企业的漏洞ERP系统里，财务模块和库存模块共用一个数据库账户，密码是Admin@123。问IT主管为什么不改，回答是“改了怕产线那边出问题”。产线那边用的是同一个账户跑MES系统。一个账户串起财务、库存、生产三条线，权限大到能删库，密码简单到用手机备忘录就能记住。这种设计在中小企业里遍地都是，不是技术不行，是当初上线时图省事，后来就没人愿意动。

漏洞的可怕之处不在于它有多复杂，而在于它太简单。简单到所有人都觉得“这不算问题”。

去年有个做电商的朋友找我帮忙看服务器。我扫了一眼，发现他们的订单查询接口没有做频率限制，用浏览器按着F5就能把数据库连接池打满。他听完愣了一下，说“这接口上线两年了，没人提过”。两个月后，有人用脚本刷了这个接口，数据库CPU飙到100%，订单系统瘫了四个小时。事后复盘，技术团队说“没想到会有人这么干”。可做安全的都知道，这不是“会不会有人干”的问题，是“什么时候有人干”的问题。

很多团队把安全当成一个开关：买了防火墙、装了杀毒软件、做了等保测评，就觉得安全了。但真正的隐患往往藏在那些“正常运转”的角落里。比如日志里反复出现的登录失败记录，运维觉得是用户记错密码，实际上是有人在暴力破解。比如某个内部API返回了超出预期的字段，开发觉得“反正内网用”，实际上数据已经在往外漏了。这些信号每天都在产生，只是没人看。

我自己的习惯是每周翻一次服务器日志，不看告警，就看那些“正常”的请求。有一次发现某个IP每天凌晨三点准时请求用户列表接口，每次只取一条记录。频率不高，但太规律了。查下去发现是个离职员工写的爬虫，还在跑，目的是同步客户联系方式到自己邮箱。这事没触发任何告警，因为从流量上看，它太“正常”了。

安全隐患漏洞不是技术问题，是人的问题。是“先上线再说”的侥幸，是“一直这样也没出事”的惯性，是“这不是我的活”的推诿。技术手段能堵住已知的洞，但堵不住那些没人愿意承认存在的洞。

真要解决，办法也简单：把“安全”从检查表里拿出来，变成日常动作。每次改代码时多问一句“这个接口谁能访问”，每次加账户时多想一下“这个权限是不是给大了”，每次看到异常日志时多查一步“这到底是不是误报”。不用搞什么零信任架构，先把那些明摆着的、没人管的、觉得“无所谓”的口子堵上。大部分出事的系统，不是被攻破的，是自己敞着门。