一次 Spring Boot Actuator 暴露风险的复盘与加固实践

背景

这几年做外网资产梳理时，Spring Boot Actuator 暴露仍然是比较常见的问题。它不一定等同于“直接拿权限”，但如果管理端点暴露在公网，往往会带来配置泄露、环境变量泄露、服务探测、健康状态枚举等风险。更麻烦的是，很多团队在测试环境开放了 Actuator，后续通过镜像、配置中心或脚手架同步到了生产环境。

本文整理一次比较典型的复盘思路，重点放在如何识别风险、验证影响、定位配置来源以及做长期加固。内容不涉及未授权攻击利用链，只讨论在授权范围内的安全检查和修复。

问题场景

某业务上线后做例行外网巡检，发现其中一个子域名存在 Spring Boot 特征。进一步检查时，服务返回了 Actuator 相关端点信息。该服务本身没有明显的登录入口，属于后端 API 网关后的一个业务服务，但由于历史配置原因，部分管理端点被暴露到了公网。

常见暴露入口包括：

• /actuator
• /actuator/health
• /actuator/info
• /actuator/env
• /actuator/configprops
• /actuator/metrics
• /actuator/loggers

实际风险取决于端点类型、Spring Boot 版本、Spring Security 配置、网络访问控制以及是否启用了敏感端点。不要看到 /actuator/health 就直接下结论，还是要结合响应内容和访问控制判断。

技术分析

Spring Boot Actuator 设计初衷是提供运行状态观测能力，例如健康检查、指标、应用信息、日志级别管理等。问题通常不是 Actuator 本身，而是管理面和业务面没有隔离。

几个值得关注的点：

• 端点暴露范围：由 management.endpoints.web.exposure.include 或 exclude 控制。
• 访问路径：默认基础路径一般是 /actuator，也可能通过 management.endpoints.web.base-path 修改。
• 管理端口：如果没有配置独立 management.server.port，管理端点会和业务接口共用端口。
• 认证控制：仅依靠“路径不公开”不可靠，需要明确认证和授权策略。
• 信息脱敏：部分端点可能返回环境变量、配置项、依赖信息、实例元数据等。

在旧版本或不当配置下，env、configprops、beans、mappings 等端点可能泄露较多内部信息。即便敏感值被 Spring Boot 默认脱敏，键名、服务地址、队列名称、数据库类型、第三方组件路径也可能帮助攻击者完善画像。

授权检查步骤

下面是一套偏防守的检查流程，适合用于内部巡检、上线前验收或应急排查。

1. 确认是否存在 Actuator 特征

可以从响应头、错误页、路径特征、返回结构判断。授权环境中可直接访问基础端点。

curl -i  检查健康端点返回内容
curl -i  核查敏感端点访问控制
重点检查以下端点是否需要认证：
/actuator/env
/actuator/configprops
/actuator/beans
/actuator/mappings
/actuator/metrics
/actuator/loggers
/actuator/threaddump
/actuator/heapdump
检查目标不是获取敏感内容，而是确认访问控制是否正确。对于内部审计，建议记录 HTTP 状态码、响应摘要、认证要求和网络来源限制。
4. 定位配置来源
Actuator 暴露通常不是单点配置造成的，常见来源包括：
应用自身 application.yml 或 application.properties
配置中心，如 Nacos、Apollo、Spring Cloud Config
Kubernetes ConfigMap 或环境变量
基础镜像内置默认配置
网关、Ingress、Nginx 路由转发规则
建议从运行时和代码仓库两条线同时排查。代码侧可以检索：
grep -R "management.endpoints.web.exposure" -n .
grep -R "management.server.port" -n .
grep -R "show-details" -n .
Kubernetes 环境中可以查看 Deployment、ConfigMap、Ingress 是否把管理路径暴露到了公网入口。
kubectl get ingress -A
kubectl get configmap -A | grep -i actuator
kubectl describe deploy -n your-namespace your-app
加固建议
1. 最小化暴露端点
生产环境建议只暴露必要端点，例如健康检查和基础信息。其他端点默认不开放。
management:
  endpoints:
    web:
      exposure:
        include: health,info
  endpoint:
    health:
      show-details: never
如果业务不需要 info，也可以只保留 health。
2. 管理端口与业务端口隔离
更推荐将管理端点绑定到独立端口，并通过安全组、网络策略或服务网格限制访问来源。
management:
  server:
    port: 9001
  endpoints:
    web:
      exposure:
        include: health,prometheus
外部用户访问业务端口，监控系统访问管理端口。这样即便应用路由配置有误，也能降低管理面暴露概率。
3. 增加认证与授权
如果必须开放较多管理能力，应显式配置认证，并限制角色访问。示例仅表达思路，实际要结合项目中的 Spring Security 版本调整。
@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .securityMatcher("/actuator/**")
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/actuator/health").permitAll()
            .anyRequest().hasRole("ADMIN")
        )
        .httpBasic(Customizer.withDefaults());
    return http.build();
}
注意，管理端认证不要和普通用户登录态混用。内部管理账号也应纳入统一身份治理和审计。
4. 限制网关和反向代理路由
如果应用部署在 Nginx、Ingress 或 API 网关后面，建议在入口层直接拦截管理路径。即使应用侧误配置，入口层仍能提供一层兜底。
location ^~ /actuator/ {
    return 403;
}
对于 Kubernetes Ingress，需要确认没有把 /actuator 透传到公网域名。内部监控可以通过 ClusterIP、ServiceMonitor 或私有网关访问。
5. 检查敏感信息脱敏
即便端点只在内网访问，也建议做好敏感配置治理。不要把明文密钥、数据库密码、Token 长期放在普通配置文件中。优先使用密钥管理服务或 Kubernetes Secret，并配合权限控制。
同时检查是否存在自定义 InfoContributor、启动参数打印、异常堆栈输出等额外泄露点。
风险判断参考
发现项
风险等级参考
说明
公网可访问 /actuator/health，仅返回 UP
低
仍建议确认是否业务需要
公网可访问 health 且返回组件详情
中
可能泄露内部组件和依赖状态
公网可访问 env/configprops/beans/mappings
高
可能泄露配置、路由、组件结构
公网可访问 heapdump/threaddump
高
可能包含敏感对象、线程信息和运行时细节
管理端点具备修改能力且无认证
严重
需立即下线暴露面并排查日志
日志与应急排查
如果确认曾经存在公网暴露，建议不要只改配置就结束。至少做一次访问日志回溯：
检查网关、Nginx、Ingress 日志中是否有 /actuator 相关访问。
关注 /env、/heapdump、/threaddump、/loggers 等敏感路径。
排查访问来源是否异常，例如云主机扫描器、境外 IP、短时间批量路径探测。
如果疑似泄露密钥或连接串，应按泄露处理流程轮换凭据。
简单的日志筛选示例：
grep -i "actuator" access.log | awk '{print $1,$4,$7,$9}' | sort | uniq -c | sort -nr | head -50
如果使用集中日志平台，可以按路径、状态码、来源 IP、User-Agent 聚合。重点不是追求“有没有被打穿”，而是判断是否存在敏感端点访问和数据外泄可能。
上线前检查清单
生产环境是否只暴露必要 Actuator 端点。
管理端点是否与业务端口隔离。
公网入口是否拦截 /actuator 等管理路径。
健康检查是否避免返回组件详情。
敏感端点是否具备认证、授权和来源限制。
配置中心是否存在全局默认开放配置。
监控系统访问方式是否走内网链路。
日志中是否能审计管理端点访问行为。
总结
Actuator 暴露问题的本质是管理面边界不清。实际修复时，不建议只把某个路径改名或临时加一条黑名单规则，这类处理很容易在后续发布中回退。更稳妥的做法是：端点最小化、管理端口隔离、入口层拦截、认证授权、日志审计一起做。
从长期看，可以把 Actuator 暴露纳入基线检查和 CI/CD 配置扫描。很多安全问题不是漏洞本身复杂，而是默认配置、环境差异和上线流程共同造成的。把这类问题前移到发布前处理，收益会比事后应急高很多。