上周帮朋友公司看一个OA系统上线前的等保整改单，对方技术主管直摇头：‘不就是填几张表、买个漏洞扫描服务？怎么还要改登录逻辑、加日志审计、调数据库权限？’
等保不是‘盖章工程’，是实打实的配置活
很多企业以为等保三级=找家测评机构走个流程。实际呢？系统得扛住弱口令爆破、SQL注入、越权访问；管理员操作要留痕，比如谁在凌晨2点删了客户数据，必须能查到IP+账号+时间+操作指令；日志至少存180天，还得防篡改。
举个真实例子：某电商后台用的是Spring Boot，默认错误页会暴露Tomcat版本和堆栈信息。等保检查时被直接判‘高风险’——攻击者一眼就能锁定中间件漏洞版本。改法很简单：
server.error.include-stacktrace = never
server.error.whitelabel.enabled = false常见‘翻车点’就藏在日常习惯里
• 后台管理接口没鉴权：/api/v1/user/delete?id=123 这种URL，只要知道ID就能删用户；
• 日志写在本地磁盘：服务器一崩，半年日志全丢；
• 数据库账号用root：应用出漏洞，攻击者直接拖库；
• 前端JS硬编码密钥：打开F12就能看到调用支付接口的access_token。
这些不是‘高级威胁’，而是每天都在发生的低级失误。等保要求的‘身份鉴别、访问控制、安全审计’，本质就是逼你把平时图省事的操作，换成更啰嗦但更稳的写法。
小动作，大改变
不用推倒重来。给现有系统加个登录失败5次锁账户（别只前端限制），把数据库连接池配置里的username从‘sa’改成专用只读账号，用Nginx把/static/目录的敏感文件返回403——这些改动加起来不到半天，却能让等保测评通过率翻倍。
合规不是给安全团队加活，是让每个开发、运维在写代码、配服务器时，多想半秒：‘如果这是生产环境，我敢这么干吗？’