第1章 等保合规概述与接口安全测试基础
1.1 等保2.0体系概览
等保2.0，全称“网络安全等级保护制度2.0”，2019年12月正式实施。说白了，它把原来只盯着“信息系统”的合规要求，扩展到了云计算、移动互联、物联网和工业控制。我在第一次接触等保2.0项目时，客户问我“接口也要测吗？”我当时就笑了——不测接口，相当于把大门敞开。
这套体系的核心逻辑很清晰：不同安全等级（一级到五级）对应不同强度的管控。大多数企业接触的是二级和三级。二级是“指导保护”，三级是“监督保护”。你想想看，三级如果出了问题，影响面很大，所以测评要求也最细。
等保2.0有两大变化：
- 范围扩大：从传统信息系统扩展到新技术场景。我记得有个做物联网平台的公司，之前按等保1.0过了，结果2.0来了一看，终端设备的接口全没做安全认证，直接开了个高风险。
- 安全要求重新分类：变成“通用要求+扩展要求”。通用要求是所有系统都得过，扩展要求看你的技术环境。
核心要点：等保2.0不是推翻重来，而是在通用安全基础上加了“新技术定语”。接口安全测试，正好卡在通用和扩展的交集上。
下面这张图可以帮你快速理解等保2.0的结构，以及接口安全测试如何嵌入其中：
怎么读这张图？ 从上往下看：等保2.0分为安全通用要求和安全扩展要求。通用要求里的身份鉴别、访问控制、数据完整性，正好是接口安全测试的“基本功”。扩展要求里的云、移、物，则会让接口场景更复杂——比如物联网设备接口的弱口令、移动App API的越权问题。接口安全测试，就是把这两个维度串起来的实践。
1.2 接口安全测试的核心目标
接口安全测试，说白了两件事：一是验证接口“是不是只有该有的人能用”，二是验证接口“传的数据是不是完整的、保密的”。我见过很多项目，接口文档写得漂亮，但一测发现未授权访问、敏感信息明文传输，都是低级错误。
核心目标可以归纳为四条：
- 身份鉴别：确保调用方是合法用户或系统。常见的如、、数字签名。我做过一个金融接口项目，他们只用了简单的AppId，没有签名校验，结果被重放攻击刷了上百万次——教训深刻。
- 访问控制：验证用户只能访问自己有权限的资源。比如一个普通用户能不能通过修改ID查别人的订单？这叫“水平越权”，是我遇到的最高频问题。
- 数据完整性 & 保密性：传输过程中数据不被篡改、不被窃听。至少要用HTTPS，关键接口得做签名。
- 审计：所有接口调用要有日志，能追溯谁、什么时候、做了什么。等保三级明确要求审计记录保留六个月以上。
注意：有些团队把接口安全测试等同于“扫一遍漏洞”。实际上，合规测试更关注“控制措施有没有”——比如有没有认证机制、有没有会话超时。漏洞是附带发现的，不是主要目标。
1.3 接口安全测试的基本原则
基本原则听起来虚，但踩几次坑你就懂了。我按自己的经验总结一下：
| 原则 | 说明 | 我的做法 |
|---|---|---|
| 最小化原则 | 接口只暴露必要的数据和功能，参数最小化 | 我习惯把接口文档和实际代码对照，删除那些“顺手多传”的字段 |
| 纵深防御 | 不依赖单一防护。比如既有网关鉴权，又有接口层校验 | 曾经遇到过网关过了但业务层没校验，结果被直连绕过。现在我会设计多层 |
| 持续评估 | 安全不是一次性测试，每次迭代都要测 | 我建议把接口安全测试集成到CI/CD里，跑自动化用例 |
| 业务优先 | 安全不能过度影响业务可用性和性能 | 比如加密强度要平衡。我记得一个项目用了RSA 2048做每个请求签名，导致接口响应慢了200ms，最终客户投诉 |
一句话总结本章：等保2.0给接口安全测试定了“规矩”，核心是身份、权限、数据、审计四大目标。怎么测？四个原则——最小、纵深、持续、业务优先。后面的章节，我们会逐一拆解每个目标对应的测试方法和实例。