系统上线前的最后一轮安全检查，往往比开发阶段任何一次代码评审更能决定事故的概率。我们做过不少企业级系统的交付与运维，一个反复出现的规律是：真正导致线上事故的，很少是某个复杂算法出错，而是账号没回收、接口没鉴权、日志查不到这几件「看起来很小」的事。下面这份清单不追求大而全，而是按上线前一周的实际节奏组织，逐项给出可执行的查法。
- 账号与权限：默认账号是否已改密、离职/临时账号是否已回收、权限是否遵循最小化原则。
- 接口鉴权：所有对外接口是否强制鉴权、越权访问是否被拦截、签名与时效是否校验。
- 敏感数据：传输是否加密、日志与导出中是否残留身份证、手机号、密钥等明文。
- 日志与审计：关键操作是否留痕、日志能否按人按时间检索、留存周期是否达标。
- 备份与回滚：备份是否可恢复、回滚路径是否演练过、故障时的责任人是否明确。
账号与权限：先把「谁能进」理清楚
上线前最容易踩的坑，是开发阶段为了方便留下的共享账号和测试账号。检查时应逐个核对：是否存在默认密码、是否有人仍在使用 admin/admin 这类弱口令、开发与运维账号是否与个人身份绑定。我们通常建议做一次账号基线盘点，把长期未登录的账号直接禁用，把临时外包账号设置明确的失效时间。
权限侧的核心是「最小可用」。很多系统上线时给业务管理员开了全量菜单，理由是「省得以后再来加」。这在审计时几乎必然被点名。更稳妥的做法是按角色划分权限包，默认只给到岗位必需的功能，新增权限走审批。要特别检查数据权限——同一个接口，A 部门用户能否通过改 URL 参数读到 B 部门的数据，这是最常见的越权入口。
接口鉴权：不要让「内部接口」成为后门
企业系统常见的一个疏漏，是前台页面调用的接口做了鉴权，而一些「内部使用」的接口默认没有校验身份。攻击者拿到前端代码后，很容易拼出这些接口地址。上线前应把接口清单拉出来，逐条确认：是否要求登录态、是否校验资源归属、是否有频率限制。对于开放给第三方的接口，还要检查签名算法、时间戳有效期与重放保护。
另一类问题是鉴权逻辑写在 Controller 里，新增接口时容易漏。我们更推荐把鉴权做成统一入口的拦截规则，再对少数白名单接口显式放行。这样遗漏的可能性会小很多——漏一个白名单是显式错误，漏一个鉴权则是静默风险，而静默风险往往在事故时才被发现。
敏感数据：传输、存储与日志三条线
敏感数据要分别检查传输、存储和日志三个环节。传输上确认全站 HTTPS 且没有混合内容，内部服务间调用也不能走明文。存储上确认密码用不可逆哈希加盐，不要把可解密的对称加密当作密码保护。日志上则要格外警惕：很多系统在调试时把完整请求体打进日志，里面可能包含身份证号、银行卡、令牌。上线前应抽几条真实日志人工过一遍，确认没有明文敏感字段。
数据导出是另一个高发区。报表导出、批量下载功能通常不受页面权限约束，却能把大量数据一次性带走。检查时应确认导出操作有独立权限、有数量上限、有审计记录。
日志与审计：出事时能还原现场
日志的价值不在「有没有」，而在「出事时能不能查到」。上线前至少要验证三件事：关键操作（登录、权限变更、数据删除、资金相关操作）是否留下了操作人、时间、IP 与操作对象；日志能否按用户和时间范围快速检索；日志留存周期是否满足公司制度与合规要求。审计日志还应与业务日志分开存储，避免被普通运维随手清理。
备份与回滚：把「万一」变成可执行步骤
备份最忌讳「有备份但没验过」。上线前应实际做一次恢复演练，从备份文件恢复到独立环境，确认数据完整、应用能起来。同时明确回滚条件与决策人：什么情况下回滚、由谁拍板、回滚预计多久。发布时保留上一个可用版本，数据库变更要有对应的回退脚本。
把以上五类检查项固化成上线检查表并指定负责人逐项签字，比临上线前临时拉群确认要可靠得多。检查表本身也应随每次事故复盘更新——它记录的不只是流程，更是团队踩过的坑。安全不是上线前的一次动作，而是持续迭代的习惯。