支付系统架构安全：三层架构与API网关设计
支付系统的架构安全，说白了就是要把钱袋子看住。我做了这么多年支付安全，见过太多因为架构设计不合理导致的漏洞。今天咱们聊聊三层架构、API网关和微服务认证这几个核心点。
一、三层架构：前端、业务、清算
支付系统为什么非要分成三层？你想想看，如果把所有逻辑都揉在一起，出问题的时候排查起来有多痛苦。我在项目中遇到过一家公司，前端直接连数据库，结果一次SQL注入把整个用户表都拖走了...
1. 前端层（展示层）
- 只负责页面渲染和用户交互
- 绝对不能包含业务逻辑
- 敏感数据（如卡号）要做脱敏处理
我的习惯：前端只展示后4位卡号，完整卡号永远不落地到浏览器。曾经有个项目因为前端缓存了完整卡号，被XSS攻击全量泄露，教训深刻。
2. 业务层（核心处理层）
- 处理订单、支付、退款等核心逻辑
- 做参数校验、权限检查
- 调用清算层接口
业务层是攻击者的主要目标。我记得有一次渗透测试，发现业务层没有做金额校验，攻击者把0.01元的订单改成10000元提交...嗯，这种低级错误其实很常见。
3. 清算层（资金结算层）
- 负责资金划拨、对账、记账
- 必须保证事务一致性
- 操作日志要完整可追溯
避坑指南：我曾经见过清算层直接暴露内网接口，没有任何鉴权。攻击者通过SSRF漏洞直接调用清算接口转账。记住：清算层必须做双向认证，且只能被业务层调用。
二、API网关安全设计
API网关是支付系统的第一道防线。我习惯把它比作机场的安检口——所有请求都得过一遍。
核心安全功能
| 功能 | 说明 | 我的建议 |
|---|---|---|
| 身份认证 | 校验API Key、Token | 使用JWT，设置短有效期 |
| 限流熔断 | 防止DDoS和暴力破解 | 按用户+IP双重限流 |
| 参数校验 | 过滤恶意输入 | 白名单策略，拒绝未知参数 |
| 日志审计 | 记录所有请求和响应 | 敏感字段脱敏后存储 |
关键点：API网关不要做业务逻辑判断！它只负责安全检查和路由转发。我见过有人把支付金额校验写在网关里，结果改个规则还得重启网关，太蠢了。
网关安全配置示例
# API网关安全配置（伪代码）
gateway:
auth:
type: jwt
secret: ${JWT_SECRET}
expire: 15m # 15分钟过期
rate_limit:
per_user: 100/min
per_ip: 1000/min
whitelist:
- /api/v1/health
- /api/v1/callback
blacklist:
- /api/v1/admin # 内部接口不对外暴露三、微服务间认证与鉴权
微服务架构下，服务之间的调用不能裸奔。我刚开始做微服务时，觉得内网环境安全，服务间直接HTTP调用...直到有一次内网被横向渗透，所有服务都被扫了一遍。
认证方式对比
| 方式 | 安全性 | 性能 | 适用场景 |
|---|---|---|---|
| JWT | 中 | 高 | 服务间轻量级调用 |
| mTLS | 高 | 中 | 敏感数据传输 |
| API Key | 低 | 高 | 内部非敏感服务 |
我的推荐：核心支付链路用mTLS，非核心服务用JWT。曾经有个项目全部用API Key，结果Key泄露后攻击者直接调用了所有服务接口。
微服务鉴权流程
// 服务间调用鉴权示例
public class ServiceAuthFilter {
public boolean authenticate(Request request) {
// 1. 校验JWT签名
if (!jwtService.verify(request.getToken())) {
return false;
}
// 2. 检查服务权限
if (!permissionService.hasAccess(
request.getSourceService(),
request.getTargetService()
)) {
return false;
}
// 3. 记录审计日志
auditLogService.log(request);
return true;
}
}四、架构安全知识体系
下面这张图是我总结的支付系统架构安全核心逻辑，你可以对照着检查自己的系统。
最后提醒：架构安全不是配几个参数就完事了。我每年都会做一次架构安全评审，检查各层之间的隔离是否到位、网关规则是否过时、微服务间的认证是否被绕过。安全是动态的，别想着一次配置终身无忧。
公众号:蓝海资料掘金营，微信deep3321