heapdump 端点没关：一次 3.2GB 内存转储被拖走、AK/SK 当场落地的事故复盘

一、现象：一个"运维排查请求"，把生产密钥全拖走了

上个月给一家做电商中台的客户做季度安全复盘。他们上个月被通报：生产环境的对象存储 AK/SK（明文）出现在了某次渗透测试的报告附件里。客户第一反应是"内鬼"，因为他们确认过：.env 没进 git、配置中心访问有审计、容器镜像里没有密钥文件。

真正的时间线是这样的：

• T0：运维为排查一次 OOM，在 K8s 节点上用 curl 拉了 http://<pod-ip>:8080/actuator/heapdump，耗时 47 秒，拿到 3.2GB 的 hprof 文件，用 Eclipse MAT 分析后删除；
• T1：同一台节点上，另一个实习生的容器里跑了个安全扫描器（公司默认镜像里带的），它按"发现即枚举"策略扫到了 /actuator/env，顺手也拉了一份 heapdump 存到本地工作区；
• T2：这份 hprof 跟着一次"排查材料打包"被同步到了外部协作网盘——密钥就此流出。

影响面：1 组对象存储 AK/SK、1 个 Redis 密码、1 个内部 SSO 的 JWT 签名密钥（HS256 的 32 字节 secret，明文躺在 SecretKeySpec 对象里）。全部从一份 3.2GB 的 hprof 里用 strings 30 秒内提取出来。

规模上：这套系统 6 个 pod，全部开着同样的 actuator 配置，等于 6 份可拖的内存快照。

二、根因：为什么"只开了 /health"却还能拖 heapdump

倒推下来，根因不是"有人恶意"，而是三个默认值叠加：

1. management.endpoints.web.exposure.include 的继承陷阱。主配置写了 include: health,info，但有一个 profile（dev）里写了 include: "*"，而生产 K8s 的 SPRING_PROFILES_ACTIVE 因为一次改名事故实际是 dev——生产环境跑在 dev profile 上，actuator 全端点暴露。这一点在审计日志里是静默的，没有任何告警。
2. heapdump 端点的本质。它不是"返回一个密钥"，而是把整个 JVM 堆做一次快照导出：任何在堆里以 char[]/byte[]/String 形式存在过的敏感数据都会被序列化进去。密钥、token、用户手机号、密码明文（哪怕只存在了 10ms）都在里面。3.2GB 的 hprof 里 strings 一下，能提取的明文远超你想象。
3. 网络层没有兜底。actuator 和业务共用 8080，Ingress 规则是 /* → 8080，没有对 /actuator/* 做路径级 ACL。也就是说：只要知道端口，任何能到 pod IP 的东西都能拖 heapdump，不需要任何凭据。

一句话根因：把"诊断端点"当"内部接口"来用，却按"公开接口"的暴露面来部署。

三、具体做法：怎么查、怎么堵（可复现）

1. 确认你的 actuator 到底开了什么

# 直接探测，不需要任何凭据
curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
  http://<target>:8080/actuator/heapdump
# 200 + 大 size_download = 已暴露，立即处置
curl -s http://<target>:8080/actuator/env | jq '.activeProfiles'

2. 生产配置最小化（application-prod.yml）

management:
  endpoints:
    web:
      exposure:
        include: health,info   # 白名单，绝不写 "*"
        exclude: heapdump,env,beans,threaddump,shutdown
  endpoint:
    health:
      show-details: never     # 细节只留 /health 给 LB 探针
    heapdump:
      enabled: false          # 双保险，端点级别直接禁用

3. 网络层兜底（Ingress / 防火墙）

# Ingress：actuator 路径不对外
- host: api.example.com
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend: ...
      - path: /actuator/
        pathType: Prefix
        backend:
          service: { name: deny-all, port: { number: 8080 } }  # 指向一个返回 403 的服务

K8s NetworkPolicy 里，只允许 namespace=monitoring 的 pod 访问 8080 的 /actuator/*（用 egress/ingress + 端口组合，L7 路径交给 Ingress）。

4. 如果已经泄露：按"已泄露"处置，而不是"可能泄露"

# 1) 立即轮换 AK/SK、Redis 密码、JWT secret（顺序：密钥 > 凭据 > 证书）
# 2) 用 strings 验证 hprof 里确实有什么（在隔离环境做）
strings -n 8 heapdump.hprof | grep -E "LTAI|AKID|password|secret" | head
# 3) 审计 CDN / OSS 的访问日志，看泄露后有没有异常下载

5. 防再次发生：CI 里加一条"生产镜像 actuator 自检"

# 在镜像构建后、发布前跑
docker run --rm <image> sh -c \
  'java -jar app.jar --management.endpoints.web.exposure.include=health & \
   sleep 20 && curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/actuator/heapdump'
# 期望输出 404；非 404 直接 fail 流水线

四、踩过的坑 / 反直觉之处

1. exclude 和 include 的优先级：include 是白名单，exclude 是在白名单里再挖洞。很多人以为写了 exclude: heapdump 就安全了，但如果另一个 profile 里 include 没写 heapdump，exclude 根本不生效——白名单才是唯一可信的边界。
2. strings 提取密钥的命中率远高于预期：3.2GB 的 hprof，strings -n 8 | grep LTAI 在第 12 行就命中了 AK。密钥不是"藏在深处"，它在堆里就是明文 char[]。
3. SPRING_PROFILES_ACTIVE 的静默漂移：一次 profile 改名（production → prod），环境变量没同步，生产实际跑在 dev 上，没有任何报错、没有任何告警，只有 actuator 的 env 端点能看到 activeProfiles: [dev]。这类"配置漂移"是安全审计里最容易被漏掉的。
4. heapdump 不是"大文件"，是"高价值文件"：3.2GB 听起来大，但 strings 30 秒就能提取关键密钥。它的价值密度远超文件大小给人的直觉。

五、结论与可复用清单

结论：actuator 的 heapdump/env/beans 这类端点，默认是"高危资产"，不是"运维工具"。它们的暴露面 = 你的整个 JVM 堆。生产环境必须：白名单暴露 + 端点级禁用 + 网络层 ACL 三层防御，任何一层缺失都等于裸奔。

可复用清单（可直接贴进安全基线）：

• [ ] management.endpoints.web.exposure.include 只列 health,info，绝不写 *
• [ ] management.endpoint.heapdump.enabled: false（端点级禁用）
• [ ] Ingress / NetworkPolicy 对 /actuator/* 做路径级 ACL，不依赖应用层
• [ ] CI 发布前跑 actuator 自检，/actuator/heapdump 必须返回 404
• [ ] 审计 SPRING_PROFILES_ACTIVE 实际值与预期是否一致（防 profile 漂移）
• [ ] 密钥泄露后，按"已泄露"处置：立即轮换 + 审计访问日志，不要"观察几天再说"
• [ ] 生产镜像里不带任何安全扫描器/调试工具的默认二进制（本次事件的 hprof 就是被镜像里自带工具拖走的）

本文基于一次真实事故复盘，数据已脱敏。