某金融科技公司因核心交易系统存在 SQL 注入漏洞，被黑客窃取 3 万条用户银行卡信息，不仅因未满足等保 2.0 “计算环境安全” 要求被罚 80 万元，还被迫暂停业务 —— 此类安全编码缺失导致的合规风险屡见不鲜。等保 2.0（GB/T 22239-2019）将 “代码安全” 纳入核心合规维度，要求从编码规范、漏洞防控到部署验证构建全流程防线。本文结合等保关键条款，拆解从编码到部署的安全实践，为开发团队提供合规方案。

一、写代码前：先明确等保要求，划好安全底线

安全不是写代码时临时想的，得提前把等保的要求理清楚，让开发团队知道 “哪些安全点必须做到”，避免后期返工。

1. 先搞懂：等保里哪些要求和代码有关？

等保里和代码安全直接相关的要求，主要集中在三类，不用记专业名词，理解核心目的就行：

系统使用安全：要保证别人不能随便登录、访问数据，比如登录时密码要够复杂，代码里得有防 “别人钻空子访问” 的逻辑；

数据安全：用户的敏感信息（比如身份证、银行卡号）不能明文存、明文传，开发时得考虑 “怎么把这些信息加密，或者隐藏关键部分”；

运维追溯安全：谁改了代码、改了什么，都得有记录；发现代码有漏洞，修复过程也要记下来，方便后续核查。

举个例子：等保三级要求 “核心系统登录得有双重验证”，那写代码前就得明确 “登录模块必须加验证码或动态令牌”，不能等代码写完了才想起要加。

2. 定好规则：哪些代码不能写，哪些必须做？

开发团队得一起定个《安全编码规则》，明确 “哪些事绝对不能做，哪些事必须做到”，比如：

不能做的：比如代码里不能直接写密码、密钥（避免代码泄露后，别人直接拿到关键信息）；不能随便相信用户输入的内容（防止黑客搞破坏）；

必须做的：所有用户输入的内容都要检查格式（比如 “订单号只能是数字”）；敏感信息要处理（比如手机号中间几位用 * 代替）；操作日志里得有 “谁操作、什么时候、做了什么”。

再做一个简单的《安全检查清单》，列 20 条左右关键项（比如 “有没有直接写密码”“用户输入有没有检查”），开发人员写代码时对着查，就不容易漏。

二、写代码时：盯着等保核心要求，把安全嵌进去

写代码的过程中，要重点防住那些容易让黑客钻空子的地方，这些也是等保常查的点，用通俗的话讲清楚怎么防：

1. 防 “黑客乱输入搞破坏”：用户输入要把关

黑客常通过 “输入特殊内容” 骗系统出问题，比如在搜索框里输一串奇怪的字符，就能看到所有用户数据。要避免这种情况，写代码时得做好两件事：

先检查用户输入：明确 “什么格式的输入是允许的”，比如 “手机号只能是 11 位数字”“订单号只能是数字和字母”，不符合的就拒绝；

显示内容要处理：用户输入的内容在页面上显示前，要先 “过滤”—— 比如有人输入带特殊符号的内容，系统要自动转成安全的格式，防止页面出问题或泄露信息。

比如某电商的商品搜索功能，因为没检查用户输入，黑客输了一串特殊字符，就看到了所有商品的后台数据，这就是没做好输入把关的后果，也不符合等保 “数据不能随便被访问” 的要求。

2. 防 “敏感信息泄露”：加密、隐藏要到位

用户的身份证、银行卡号这些敏感信息，是等保重点保护的对象，写代码时要做好 “加密” 和 “隐藏”：

传的时候、存的时候要加密：这些信息在系统间传输（比如从 APP 传到服务器）、存在数据库里时，都要变成 “乱码”，只有授权的人能解开；

开发测试时要隐藏：开发或测试的时候，不能用真实的用户信息，比如把手机号改成 “138****5678”，身份证号隐藏中间几位，避免测试数据泄露。

之前有个企业，把加密用的密钥直接写在代码里，代码泄露后，黑客用这个密钥解开了数据库里的用户信息，就是没做好加密的关键步骤。

3. 防 “越权访问”：谁能做什么要明确

“越权” 就是 “不该你做的事，你却能做”，比如客服能看到所有客户的身份证号，这就不符合等保 “权限最小” 的要求。写代码时要：

登录要够安全：密码不能太简单（至少 12 位，要有大写、小写、数字），长时间不换要提醒更换；重要账号（比如管理员）登录，除了密码还得要验证码；

权限要分清楚：客服只能看自己负责的客户订单，财务只能看自己负责的账单，不能让一个人看到所有数据；而且不管前端页面有没有隐藏功能，后端代码里都要再检查一次权限，防止黑客绕开页面直接操作。

4. 防 “代码本身有漏洞”：避开高危操作

有些写代码的习惯容易留下漏洞，等保也会查这些，比如：

不要用有风险的工具或功能：有些代码工具本身不安全，开发时要避开；

用别人的组件要小心：开发时会用到别人写的 “零件”（比如某个功能模块），要先检查这些 “零件” 有没有安全问题，有漏洞的要及时更新；

日志要记清楚：谁操作了什么、操作结果怎么样，都要记在日志里，至少存 6 个月，方便出问题后追溯，这也是等保要求的 “可追溯”。

三、代码写完后：测试 + 部署，把好最后一关

代码写完不代表安全了，还得通过测试找问题，上线时也要注意环境安全，这才能符合等保的 “运维安全” 要求。

1. 测试：模拟黑客找问题

不能只测试 “功能能不能用”，还要测试 “安全不安全”：

用工具扫代码：用专门的工具检查代码里有没有明显的漏洞，比如 “有没有直接写密码”“有没有没检查的用户输入”，发现高危问题必须改完；

模拟黑客攻击：找专业人员试着像黑客一样操作，比如用普通用户账号能不能看到别人的数据，能不能通过输入特殊内容搞破坏，验证代码的防护效果；

再查一次组件漏洞：确认之前用的别人的 “零件”，都已经更新到安全版本，没有漏洞。

2. 上线部署：环境要隔离，配置要安全

上线时的环境和配置如果不安全，之前的努力可能白费，要注意：

开发、测试、正式系统要分开：不能把测试用的数据或配置，用到正式系统上，避免测试数据泄露或影响正式业务；

服务器要关 “无用功能”：正式用的服务器，要关掉用不到的端口或功能，比如远程登录的旧功能，防止黑客通过这些入口进来；

上线记录要完整：谁负责上线、什么时候上线、改了哪些内容，都要记下来；代码版本要管理好，不能随便改了代码就直接传到正式系统。

四、常见误区：这些认知偏差要避开

觉得 “安全编码只是开发的事”有些企业让开发写完代码直接上线，测试和安全团队都没参与，结果代码里的漏洞没发现，等保测评时出了问题。其实安全编码需要开发、测试、安全团队一起配合，安全团队给规则，测试团队找问题，才能做好。

觉得 “用工具扫一遍就够了”工具只能找到明显的技术漏洞，像 “客服能看到别人的客户数据” 这种业务逻辑上的问题，工具查不出来。得结合人工检查和模拟攻击，才能全面找问题。

觉得 “等保过了就不用管了”等保测评通过不代表代码永远安全，新的漏洞会不断出现。要定期检查核心代码的安全情况，更新安全规则，不能掉以轻心。

结语

等保要求下的安全编码，不是 “额外的麻烦”，而是避免企业被罚款、业务停摆的必要措施。不管是开发团队还是企业管理者，都要跳出 “先做功能、再补安全” 的思维，把安全融入写代码的每一步。

如果在实际操作中，不知道 “加密该用什么方式”“权限该怎么分”，可以结合等保的具体要求和自己的业务场景来定，重点是让安全真正落地，而不是只停留在表面。