3、接口安全概述：常见安全威胁与加密必要性
我一直觉得，做接口开发的人，最怕的不是需求变，而是接口上线后被人“黑”了还浑然不觉。
我自己早年接手过一个支付回调项目。上线第二天，总金额就莫名其妙对不上。查了两天，才发现是攻击者把回调参数里的金额字段给改了。从那时起，我才真正意识到：接口安全绝不是“可以后期再补”的东西。
3.1 接口面临的三大核心威胁
接口暴露在外网，说白了就是把自己家的门敞开了。你想想看，谁会来敲这扇门？正常用户会来，小偷也会来。
常见的恶意行为，可以归纳为三类：
- 数据泄露 — 接口在传输过程中被监听，敏感信息（身份证号、手机号、支付金额）被中间人截获。
- 数据篡改 — 攻击者截获请求数据包后，修改其中的字段再转发给服务端。
- 重放攻击 — 攻击者记录一次合法请求，然后反复发送同样的请求，让服务端重复处理。
| 威胁类型 | 攻击本质 | 典型场景 | 后果 |
|---|---|---|---|
| 数据泄露 | 被动拦截，读取明文 | Web API 未使用 HTTPS | 用户隐私暴露，违反合规要求 |
| 数据篡改 | 主动修改传输内容 | 修改转账金额、修改商品折扣 | 资金损失、订单异常 |
| 重放攻击 | 重复发送合法请求 | 重复调用下单接口、重复抢红包 | 业务被刷、库存超卖 |
核心观点：这三大威胁独立存在，也可能组合出现。篡改攻击常与重放攻击配合使用，防护时必须一并考虑。
3.2 安全三要素：CIA 铁三角
聊接口安全，绕不开一个经典模型：CIA 三要素。分别是机密性、完整性和可用性。
- 机密性（Confidentiality） — 确保数据在传输和存储过程中不被未授权方读取。对应的是加密技术。
- 完整性（Integrity） — 确保数据在传输过程中未被篡改。对应的是签名、哈希校验。
- 可用性（Availability） — 确保接口在正常使用条件下能被合法用户访问。对应的是限流、熔断等手段。
| 要素 | 含义 | 对应防护手段 |
|---|---|---|
| 机密性 | 别人看不懂你的数据 | 对称加密、非对称加密、HTTPS |
| 完整性 | 别人改不了你的数据 | 数字签名、HMAC、消息摘要 |
| 可用性 | 别人打不垮你的服务 | 限流、防重放、熔断降级 |
我在项目中最深的体会是：机密性和完整性不能二选一，必须同时做。只加密不签名，攻击者虽然看不到明文，但可以替换密文。只签名不加密，中间人可以完整看到你的业务数据。
3.3 为什么要加密？非做不可的三个理由
你可能觉得，内部系统或者私有 API 不需要加密。我当年也这么想过，直到……
嗯，我在一次内网渗透测试中发现，即使在内网环境中，Wireshark 抓包也能直接看到明文请求。内部人员、跳板机、VPN 网关……攻击面比你以为的要多得多。
加密的必要性，可以归结为三点：
- 合规要求 — 等保 2.0、GDPR、金融行业标准，都明确要求敏感数据在传输和存储时必须加密。
- 业务安全底线 — 不加密的接口，相当于把数据库暴露在公网上。一次中间人攻击就能让你背上全部责任。
- 防御纵深的第一道墙 — 加密不是万能的，但它能挡住大多数低级攻击。攻击者拿到密文后，需要花费额外精力去破解。
注意：很多开发者认为“用了 HTTPS 就不用再加密了”。这个说法不完全正确。HTTPS 只保证传输过程中的加密，但在反代、网关、负载均衡器等节点上，TLS 会被终止，数据会以明文形式暴露在内网。
3.4 理解两种加密方式：对称 vs 非对称
既然要加密，我们得先搞明白两种流派。
- 对称加密：加密和解密用同一个密钥。优势是速度快。缺点是密钥分发困难。常见算法：AES、DES、3DES。
- 非对称加密：加密用公钥，解密用私钥。优势是密钥分发方便。缺点是速度慢。常见算法：RSA、ECC。
| 对比维度 | 对称加密（AES 为例） | 非对称加密（RSA 为例） |
|---|---|---|
| 密钥数量 | 1 个 | 2 个（公钥/私钥） |
| 加密速度 | 快（硬件加速支持好） | 慢（比对称慢 100-1000 倍） |
| 安全性前提 | 密钥不外泄 | 私钥不外泄 |
| 主要问题 | 密钥分发困难 | 运算开销大 |
| 典型用途 | 大数据量加密 | 密钥交换、数字签名 |
我个人的习惯是：用非对称加密来交换对称密钥，用对称密钥来加密实际业务数据。这个模式叫做“混合加密”，HTTPS 就是用的这种套路。
面试/实战小贴士：如果面试官问“RSA 加密速度太慢怎么办”，标准答案就是“用对称加密加密数据，用 RSA 加密这个对称密钥”。上一行提到的混合加密，就是标准打法。
为什么不能只用非对称？举个例子。假设你要加密一个 1MB 的支付订单报文。用 RSA 跑一次，服务器 CPU 会直接拉满，响应时间甚至可能超过 1 秒。但用 AES 加密同样的数据，耗时只有几毫秒。
3.5 本课程中的加密方案总览
在这个课程里，我们不会只用一种加密方式。你会看到这样一套组合：
- 用 AES-256-GCM 加密业务数据的 body。
- 用 RSA 或 ECC 来加密这个 AES 密钥。
- 用 HMAC-SHA256 做签名保证完整性。
- 用 时间戳 + nonce 防重放。
当然，后面每一章都会手把手带着你做代码实现。今天我们先把这些概念搞清楚。
3.6 接口安全威胁与加密体系结构
下面这张图，把本章讲到的核心概念串了起来。你可以把它当成一张“思维导图”来用。
怎么看这张图：从顶层的 CIA 目标出发，向下展开到具体的威胁，再到对应的防护手段。最底部是本课程准备使用的技术栈。这个结构会贯穿后续 27 章。你也可以把它当作自己设计接口安全方案时的检查清单。
3.7 小结：你至少应该带走这三点
- 接口安全要防的是三件事：泄露、篡改、重放。一件都不能漏。
- CIA 三要素是理论基础。加密解决机密性，签名解决完整性，防重放保护可用性。
- 对称加密和非对称加密各有所长。实际工程中，混合加密是主流方案。
嗯，概念就到这里。从下一节开始，我们会真正动手写代码。第一个要解决的问题就是：如何用 Python 实现一个高可用的脱敏加密工具函数。
—— 一位踩过坑才来讲课的老工程师