你刚接手公司新上线的OA系统，老板问："这系统过等保了吗？"你一愣——等保是什么？要填表？要买设备？还是得请个安全公司来折腾三个月？
等保不是“考试”，是套动作流程
等保（网络安全等级保护）本质是国家对信息系统分等级、按标准实施保护的一套管理机制。企业级应用——比如内部用的ERP、CRM、HR系统，只要处理员工信息、客户数据、财务流水，基本都属于等保二级或三级范围。别被名字吓住，它不神秘，就是“定级→备案→建设整改→等级测评→监督检查”这五步。
从哪开始？先看你的应用长什么样
打开服务器后台，查查这几个关键点：
• 数据有没有加密存储？比如用户密码是不是明文存MySQL里；
• 登录有没有多因素验证？比如只输密码就算登录成功，那大概率不合规；
• 日志有没有保留6个月以上？操作谁、什么时候、干了什么，得能回溯；
• 系统有没有做过渗透测试？哪怕自己用Burp Suite扫一遍登录接口，也能发现SQL注入漏洞。
一个小例子：一个没做等保的审批系统
某公司用低代码平台搭了个报销审批App，所有审批单据直接存在云数据库里，权限靠前端按钮隐藏控制。结果审计时发现：普通员工能通过改URL参数，看到其他部门的报销明细，连附件PDF都能下载。这不是技术多难，是根本没做访问控制设计。
整改不用全推倒重来
很多企业级应用跑在内网，其实只需补上几块“拼图”：
• 加个统一身份认证（比如对接LDAP或钉钉扫码登录）；
• 把数据库连接字符串从代码里挪到配置中心，加个密；
• 在Nginx层加个简单WAF规则，拦截常见的/..//、union select这类攻击特征；
• 日志接入ELK或直接写入带时间戳的本地文件，每天自动归档。
代码里最容易踩的坑
比如Java项目里常见这种写法：
String sql = "SELECT * FROM user WHERE id = " + request.getParameter("id");这就是典型的SQL注入温床。换成预编译语句就安全多了：
String sql = "SELECT * FROM user WHERE id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, request.getParameter("id"));再比如前端传来的JSON参数，后端不做校验直接反序列化成对象，可能触发Fastjson远程命令执行。换用Jackson，禁用默认类型解析，风险立马降低一大截。
等保合规不是让软件变慢、变复杂，而是逼你把那些“差不多就行”的地方，换成“确实能防住”的做法。它像给门装锁——锁本身不创造价值，但没锁，谁都可能进来翻抽屉。