Nacos配置中心鉴权缺失导致数据库密码泄露

Nacos 配置中心鉴权缺失，本质上就是你把家门钥匙放在门垫下面，以为只有自己知道。攻击者根本不需要什么高级手段，只要扫到你的 Nacos 控制台端口，就能像翻自家抽屉一样把数据库密码、Redis 密钥、云服务 AK/SK 全部拖走。这不是漏洞利用，这是信息泄露的“自助餐”。

Nacos 从 1.x 到 2.x 版本，默认配置下控制台和 API 接口都是裸奔的。很多团队用 Docker 一键部署，把 8848 端口往公网一映射，配置中心就上线了。这时候任何人访问 http://your-ip:8848/nacos 就能直接进入控制台，不需要输入任何账号密码。更致命的是，Nacos 提供了一系列开放 API，比如 /nacos/v1/cs/configs 这个接口，可以直接拉取配置文件内容。攻击者只需要构造一个简单的 HTTP 请求，就能批量下载所有命名空间下的配置。

GET /nacos/v1/cs/configs?dataId=application-prod.yml&group=DEFAULT_GROUP&tenant=public HTTP/1.1
Host: target-ip:8848

这个请求发出去，返回的响应体里就是完整的生产环境配置文件。数据库连接串、用户名、密码明文躺在里面，一行都不会少。如果你们还把多套环境的配置都放在同一个 Nacos 实例里，攻击者拿到开发环境配置后，顺着内网地址还能继续横向移动，这就是一起典型的连锁事故。

Nacos 官方文档其实写得很清楚，鉴权功能需要手动开启。设计初衷是方便开发者快速上手测试，但大量用户直接把测试态跑成了生产态。Nacos 2.x 版本引入了默认的鉴权插件，但开关仍然是关闭的。很多运维人员甚至不知道 application.properties 里有个 nacos.core.auth.enabled 参数，更不用说去修改默认的 secret.key 了。这个 secret.key 是 JWT Token 的签名密钥，Nacos 源码里有一个硬编码的默认值，如果你不修改，攻击者完全可以自己生成一个合法 Token 绕过登录。这等于你虽然装了个门锁，但钥匙是淘宝上五块钱一把的通用款。

第一步，资产发现。攻击者通过 Shodan、ZoomEye 这类网络空间搜索引擎，用 "Nacos" 或者 "8848" 作为关键词，能搜出几十万个暴露在公网的 Nacos 实例。第二步，未授权访问验证。直接访问 /nacos/v1/console/server/state 接口，如果返回了服务器状态信息，说明这个实例完全没设防。第三步，配置枚举。调用 /nacos/v1/cs/configs 接口遍历 dataId 列表，常见的命名规则比如 application.yml、application-prod.yml、datasource.yml 一猜一个准。第四步，敏感信息提取。从返回的配置内容里正则匹配 jdbc:mysql、redis.password、oss.accessKeyId 等关键字，把账号密码全部提取出来。第五步，持久化控制。拿到数据库密码后直接连接生产库，导出用户数据、修改余额、植入后门，整个业务系统彻底沦陷。

很多人只盯着数据库密码，但实际上 Nacos 配置文件里还藏着大量其他致命信息。Redis 密码泄露后，攻击者可以清空缓存、写入恶意 Session、甚至通过主从复制拿到服务器 Shell。云服务 AK/SK 泄露后，攻击者能调用你的 OSS、SMS、ECS 接口，轻则数据被拖走，重则服务器被创建出来挖矿，一个月账单几十万。第三方 API 密钥泄露，比如微信支付密钥、支付宝私钥、短信接口 Key，直接导致资金安全和业务中断。还有内部系统地址和账号，比如跳板机 IP、VPN 配置、LDAP 密码，这些信息拼在一起就是一张完整的内网拓扑图。

第一步，修改 application.properties 配置文件，找到并修改以下参数。这一步必须在部署前完成，已经上线的服务需要滚动重启。

nacos.core.auth.enabled=true
nacos.core.auth.system.type=nacos
nacos.core.auth.plugin.nacos.token.secret.key=你需要自己生成一个Base64字符串
nacos.core.auth.server.identity.key=自定义的key
nacos.core.auth.server.identity.value=自定义的value

第二步，生成高强度的 secret.key。绝对不要用默认值，也不要用弱字符串。Linux 环境下可以用 openssl 命令生成：

openssl rand -base64 32

把这个命令输出的字符串完整复制到 secret.key 配置项里。这个密钥一旦设置就不能随意更改，否则所有已登录的客户端 Token 会全部失效，导致服务调用中断。建议在业务低峰期操作，并且提前通知所有微服务团队。

第三步，配置服务端身份识别。identity.key 和 identity.value 这两个参数是 Nacos 集群节点之间通信的认证凭证，同样不能使用默认值。如果集群节点之间的通信被伪造，攻击者可以注册一个恶意的 Nacos 节点到你的集群里，同步走所有配置数据。

第四步，开启配置加密。Nacos 2.1 版本开始支持配置内容加密存储，需要在配置文件里额外开启：

nacos.config.encrypt.enabled=true

开启后，存储在 Nacos 数据库里的配置内容会是密文，即使攻击者通过 SQL 注入拿到了数据库权限，看到的也是加密后的乱码。但这只是纵深防御的一环，不能替代鉴权本身。

Nacos 的 8848 端口绝对不应该直接暴露在公网上。正确的做法是，Nacos 集群只监听内网 IP，所有微服务通过内网访问。如果开发人员需要从本地调试，应该通过堡垒机或者 VPN 接入内网后再访问。对于必须暴露的测试环境，至少要在安全组或者防火墙里配置 IP 白名单，只允许公司出口 IP 和必要的 CI/CD 服务器 IP 访问。Nginx 反向代理也是一个有效的中间层，可以在 Nginx 层面加上基础认证或者限制访问路径，把 /nacos/v1/cs/configs 这类敏感接口直接拦截掉。

Nacos 支持命名空间级别的权限隔离，但很多团队为了方便，所有服务共用一个命名空间，甚至全部放在 public 空间里。正确的做法是，每个业务域创建独立的命名空间，每个命名空间分配独立的只读或读写账号。配置管理员的账号和普通开发者的账号权限要严格区分，开发者默认只给只读权限，需要修改配置时走审批流程。Nacos 的权限模型支持角色和资源的细粒度绑定，花一个小时配置好，比事后花一个月做安全整改划算得多。

开启 Nacos 的审计日志功能，记录所有配置变更操作和登录行为。关键参数如下：

nacos.core.auth.enable.userAgentAuthWhite=false

这个参数关闭后，所有请求都必须经过鉴权，包括来自 User-Agent 白名单的请求。审计日志要接入公司的 SIEM 系统或者至少输出到独立的日志文件里，设置告警规则：非工作时间的配置读取、大量配置项被批量拉取、来自陌生 IP 的登录请求，这些行为都应该触发实时告警。攻击者往往在凌晨两三点动手，如果没有监控，第二天上班才发现数据库被删光了。

如果你的 Nacos 已经裸奔了一段时间，不要心存侥幸。第一步，立即开启鉴权并修改 secret.key，阻断后续的未授权访问。第二步，排查过去 30 天的访问日志，重点关注 /nacos/v1/cs/configs 接口的调用记录，找出可疑 IP 和数据拉取行为。第三步，轮换所有已暴露的密码和密钥，包括数据库密码、Redis 密码、云服务 AK/SK、第三方 API 密钥。数据库密码改完后要检查是否有异常账号被创建，云服务控制台要检查是否有未经授权的资源被开通。第四步，检查数据库审计日志，看是否有陌生 IP 的连接记录或者大量数据导出的操作。如果发现数据已经被拖走，需要按照数据安全法和个人信息保护法的要求，及时向监管部门报告。

安全问题不能只靠运维在线上堵。在 CI/CD 流水线里加入安全检查，扫描配置文件里是否包含硬编码密码，检测 Nacos 实例是否开启了鉴权。Docker 镜像构建时，基础镜像里就应该把 Nacos 的安全配置固化进去，而不是依赖部署人员手动修改。Kubernetes 部署时，用 ConfigMap 挂载配置文件，确保每次部署都是安全的基线版本。代码仓库里绝对不能出现真实的数据库密码，本地开发用 Docker Compose 起一个本地数据库，生产环境的密码通过 CI/CD 在部署时注入。

Nacos 配置中心鉴权缺失这件事，技术上没有任何门槛，完全就是安全意识的问题。把默认配置直接上生产，等同于把数据库密码写在公司门口的 LED 屏幕上。安全配置不是可选项，是生产环境上线前的必做清单。现在就去检查你的 Nacos 控制台，看看是不是还在裸奔。