Back to Article

Security

04. 安全、DevSecOps 与 AI 辅助开发

Dsage / / 7 min read
04. 安全、DevSecOps 与 AI 辅助开发

微服务数量增加后，安全边界也会增加。金融领域不能把安全当作上线前扫描一次。本章把 OWASP、NIST、CISA/NCSC、Semgrep、GitHub Copilot、DORA 和 Google SAIF 串成一套开发流程。

1. 微服务安全威胁模型

一个金融微服务系统至少包含这些攻击面：

  • API 网关。
  • 内部 RPC/HTTP 接口。
  • 消息队列。
  • 配置中心。
  • 注册中心。
  • 数据库。
  • 对象存储。
  • CI/CD 流水线。
  • 镜像仓库。
  • Kubernetes API。
  • 日志和监控系统。
  • AI 编码工具和提示词上下文。

NIST SP 800-204 在微服务安全策略中关注认证授权、服务发现、安全通信、监控、弹性、负载均衡、限流、完整性和 API 网关/服务网格等能力。把它翻译成开发团队行动，就是：每个服务都要有身份、权限、通信保护、配置基线、监控和恢复策略。

2. OWASP API Top 10 到金融 API 检查清单

API1 Broken Object Level Authorization

风险：用户能通过改 accountNo、orderNo、paymentId 访问别人的资源。

错误示例：

@GetMapping("/accounts/{accountNo}")
public AccountView get(@PathVariable String accountNo) {
    return accountService.get(accountNo);
}

问题：只按路径参数查，没有验证当前登录用户是否拥有该账户。

改进：

@GetMapping("/accounts/{accountNo}")
public AccountView get(@AuthenticationPrincipal UserPrincipal user,
                       @PathVariable String accountNo) {
    accountPermission.checkReadable(user.userId(), accountNo);
    return accountService.get(accountNo);
}

检查项：

  • 每个对象级资源都有授权检查。
  • 授权检查在服务端，不依赖前端隐藏按钮。
  • 批量查询也做逐项或条件级授权。
  • 管理员接口有独立权限和审计。

API2 Broken Authentication

检查项：

  • token 有过期时间。
  • refresh token 可撤销。
  • 密码、短信验证码、MFA 不写入日志。
  • 内部服务调用也有身份，不使用裸内网信任。

API3 Broken Object Property Level Authorization

风险：响应返回了用户不该看到的字段，或请求允许用户改不该改的字段。

建议：

  • 使用 DTO，不直接暴露 Entity。
  • 输入 DTO 和输出 DTO 分开。
  • 管理端 DTO 和用户端 DTO 分开。
  • 对敏感字段做脱敏。

API4 Unrestricted Resource Consumption

检查项：

  • 分页上限。
  • 文件大小限制。
  • 请求体大小限制。
  • 导出任务异步化。
  • 下游调用超时和并发限制。

API8 Security Misconfiguration

检查项：

  • Actuator 不公网暴露。
  • Swagger/OpenAPI 生产环境有访问控制。
  • 默认密码禁用。
  • 错误响应不泄露堆栈。
  • CORS 不使用无脑 *。

3. 微服务内部安全

3.1 服务身份

内部服务不应只靠“在内网”判断可信。可选方式：

  • mTLS。
  • 服务网格身份。
  • JWT client credentials。
  • 网关签名。
  • RPC 框架内置认证扩展。

3.2 最小权限

每个服务只拿自己的数据库账号、消息 topic 权限、对象存储路径权限。不要所有服务共用 root 或 DBA 账号。

3.3 日志脱敏

禁止明文日志：

  • 身份证。
  • 银行卡。
  • 手机号完整值。
  • token。
  • 密码。
  • 短信验证码。
  • 私钥。

建议保留：

  • hash 后的用户标识。
  • 脱敏手机号。
  • 订单号。
  • traceId。
  • 错误码。

4. NIST SSDF 与 CISA/NCSC：把安全前移

NIST SSDF 关注安全软件开发实践。CISA Secure-by-Design 强调软件制造者要对客户安全结果负责、透明并由高层推动。NCSC 的安全开发部署指南强调保护代码仓库、构建部署流水线、持续测试安全和规划安全缺陷处理。

对团队的具体要求：

  • 需求阶段写安全需求。
  • 设计阶段做威胁建模。
  • 开发阶段使用安全编码清单。
  • PR 阶段做人工 review 和自动扫描。
  • 构建阶段做 SAST/SCA/secret scan。
  • 发布阶段做镜像扫描、IaC 检查、配置基线检查。
  • 运行阶段做告警、漏洞响应、补丁管理。

5. Semgrep 在 Java/Spring 项目中的使用方式

Semgrep 官方提供多语言 cheat sheet 和 Java 支持说明。它适合做轻量静态检查，例如：

  • SQL 注入。
  • 命令注入。
  • SSRF。
  • 路径穿越。
  • 不安全反序列化。
  • 硬编码密钥。
  • 危险日志输出。

建议流水线：

security:
  stage: test
  script:
    - semgrep ci

团队规则示例：

  • 禁止 Controller 直接返回 Entity。
  • 禁止日志输出 password|token|idCard|bankCard 字段。
  • 禁止 RestTemplate 调用用户可控 URL。
  • 禁止 @RequestMapping 管理接口缺少权限注解。

Semgrep 不是替代人工 review。它适合发现重复模式，业务授权漏洞仍需要开发者理解业务对象和权限模型。

6. GitHub Copilot/AI 编码工具的纪律

GitHub 官方 prompt engineering 建议包括：从宽泛目标开始再具体化、给示例、拆复杂任务、避免歧义、指出相关代码、迭代、保持上下文相关、遵循良好编码实践。Copilot code review 官方文档也提醒需要仔细验证反馈，并用人工 review 补充。

金融微服务中建议这样用 AI：

6.1 适合 AI 的任务

  • 生成 DTO、Mapper、测试样例。
  • 解释陌生代码。
  • 根据接口生成 OpenAPI 草稿。
  • 生成单元测试初稿。
  • 重构重复样板代码。
  • 写文档初稿。
  • 生成 Semgrep 规则草案。

6.2 不应直接信任 AI 的任务

  • 支付扣款逻辑。
  • 风控决策逻辑。
  • 加密签名实现。
  • 权限判断。
  • 分布式事务补偿。
  • 数据库迁移脚本。
  • 生产故障处理命令。

6.3 提示词模板

你正在修改一个金融支付微服务。请只生成单元测试，不修改生产代码。
背景：
- createPayment 使用 merchantId + merchantOrderNo 做幂等。
- 参数相同重复请求应返回同一 paymentId。
- 参数不同重复请求应返回 IDEMPOTENCY_CONFLICT。
请为 PaymentApplicationService 生成 JUnit 5 + Mockito 测试，覆盖成功、重复成功、重复冲突、Repository 异常四类场景。

6.4 AI 输出验收清单

  • 是否通过编译和测试。
  • 是否符合业务状态机。
  • 是否破坏幂等。
  • 是否泄露敏感信息。
  • 是否新增未评估依赖。
  • 是否改变事务边界。
  • 是否缺少失败路径。
  • 是否有可观测性。

Reddit、Hacker News 等社区对 AI 编码工具的讨论经常集中在信任、审查和安全。把这些讨论转成工程规则，就是：AI 可以加速草稿，不替代责任人。

7. DORA 视角：AI 是放大器

DORA 2025 报告强调 AI 的收益不只来自工具，而来自底层组织系统。对微服务团队来说：

  • 没有测试，AI 会更快地产生未验证代码。
  • 没有平台规范，AI 会生成更多不一致实现。
  • 没有监控，AI 生成代码上线后的问题更难定位。
  • 没有清晰需求，AI 会放大需求歧义。

因此 AI 落地顺序应该是：

  1. 建立代码规范和架构约束。
  2. 建立测试和扫描流水线。
  3. 建立模板、starter、脚手架。
  4. 给 AI 明确上下文和边界。
  5. 用 PR review 和指标验证结果。

8. Google SAIF：当微服务接入 AI 能力

如果金融微服务中加入 AI，例如智能客服、RAG 知识库、风控辅助、运营助手，需要额外考虑：

  • 用户输入可能包含 prompt injection。
  • 模型输出不能直接执行高风险操作。
  • prompt、日志、训练数据可能包含敏感数据。
  • 模型、向量库、工具调用需要访问控制。
  • AI Agent 的动作要可审计、可回放、可撤销。

SAIF 控制建议中包含输入/输出验证、访问控制、模型与数据资产盘点、红队测试、漏洞管理、威胁检测、事件响应和治理。对金融系统的落地做法：

  • AI 只给建议，高风险动作必须人工确认或规则系统二次校验。
  • 所有工具调用记录 traceId、用户、参数摘要、结果。
  • RAG 文档按权限过滤，不能让用户通过问答读到无权文档。
  • 模型输出进入业务系统前做结构化校验。

9. 本章练习

练习 1：API 授权审计

找一个账户查询接口，列出：

  • 认证方式。
  • 当前用户身份。
  • 对象所有权检查。
  • 管理员权限检查。
  • 日志脱敏。
  • 错误码。

练习 2：Semgrep 规则草案

写一条规则，扫描 Controller 中直接返回 *Entity 的方法。先用 AI 生成草案，再人工修正并在 CI 中验证。

练习 3：AI 生成测试

让 Copilot/AI 为支付幂等逻辑生成测试。要求只生成测试，不改生产代码。最后人工检查是否覆盖失败路径。

10. 本章检查清单

  • 能把 OWASP API Top 10 映射到金融 API。
  • 能解释内部服务为什么仍需要身份认证。
  • 能设计日志脱敏规则。
  • 能把 NIST SSDF/CISA/NCSC 转成 CI/CD 检查点。
  • 能安全使用 Copilot/AI 编码工具。
  • 能识别 AI Agent/RAG 引入的新风险。