Percona 于 2026 年 8 月 19 日发布了一项高危 PMM 安全公告：攻击者可能通过 PMM 中的 Grafana 数据源获得对 ClickHouse 的高权限访问。受影响范围为 PMM 3.9.0 及以下版本。对于把 PMM 用于生产监控、且允许较多用户访问 Grafana 的团队，这不是一个可以等到常规维护窗口再处理的问题。
公告摘要没有披露完整利用细节，因此应避免自行假设漏洞触发条件或攻击路径；但从风险描述看，团队应将 Grafana 数据源配置、ClickHouse 凭据暴露面，以及 PMM 的升级状态作为排查重点。
风险不止于“看见监控数据”
Grafana 数据源通常被视为只读看板背后的连接配置，但其实际权限取决于数据源使用的数据库账户。若该路径可被利用以取得高权限 ClickHouse 访问，影响可能超出指标查询本身：
- 可读取 ClickHouse 中该账户有权访问的数据，包括监控历史、查询分析数据或其他被接入的数据集。
- 可执行该账户被授予的管理或数据操作。
- 可进一步利用存储在监控平台中的连接信息，扩大对内部基础设施的访问范围。
- 在共享 Grafana、委托运维或多团队共用 PMM 的环境中，低权限平台用户与高权限数据库身份之间可能形成不应存在的权限跳跃。
这里的关键不是 Grafana 是否“只用于展示”，而是它代表 PMM 持有并使用了什么级别的 ClickHouse 身份。
先确认资产与暴露面
需要优先盘点所有 PMM 实例，尤其是可从办公网、VPN、跳板机网络或互联网访问的实例。版本低于或等于 3.9.0 的 PMM 都应纳入处置范围。
可以这样实践：在已获授权的运维主机上检查容器化部署的 PMM 镜像信息。以下命令只读取本机 Docker 元数据，不会修改运行中的服务：
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}' | grep -i pmm
docker inspect pmm-server \
--format 'name={{.Name}} image={{.Config.Image}} created={{.Created}}'
若 PMM 使用 Kubernetes 部署，可先定位工作负载和镜像版本：
kubectl get deployments,statefulsets -A \
-o custom-columns='NAMESPACE:.metadata.namespace,TYPE:.kind,NAME:.metadata.name,IMAGES:.spec.template.spec.containers[*].image' \
| grep -i pmm
命令中的 pmm-server、命名空间和工作负载名称需要替换为实际环境的名称。版本判断应以 Percona 提供的正式修复公告、发行说明和升级目标版本为准，不要仅依据镜像标签猜测是否已修复。
修复前的即时控制措施
升级是处理已知高危产品漏洞的首选路径。在完成升级前，目标是降低可利用性和高权限账户的影响半径，而不是把临时限制当成永久修复。
可以按以下顺序执行：
- 将受影响 PMM 实例列入紧急变更，依据 Percona 的官方修复版本完成升级。
- 限制 PMM Web 与 Grafana 的网络入口，仅允许必要的管理网络、VPN 或跳板机访问。
- 审核 PMM 内 Grafana 用户、组织成员、管理员角色及匿名访问设置，移除不再需要的账户与权限。
- 审核用于相关数据源的 ClickHouse 账户，确认其不具备与监控无关的库、表或管理权限。
- 为可能已经暴露的数据库连接凭据制定轮换计划，并在轮换后验证 PMM 数据采集和看板查询。
例如，可以在反向代理或负载均衡层仅放行管理网段。下面是一个 Nginx 访问控制片段，网段和上游地址均为示例，应用前应按实际网络拓扑调整：
server {
listen 443 ssl;
server_name pmm.example.internal;
allow 10.20.0.0/16;
allow 192.168.50.0/24;
deny all;
location / {
proxy_pass http://pmm-server:443;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
网络限制只能减少攻击入口，无法消除已受影响版本中的漏洞本身；升级完成前仍应把该实例视为存在风险。
用最小权限重新审视 ClickHouse 账户
此事件提醒团队，监控系统的数据库账户也应遵循最小权限原则。数据源账户不应因为“部署方便”而复用 ClickHouse 管理员账户，更不应与业务系统使用同一组高权限凭据。
可以这样实践：先通过 ClickHouse 的系统表审计账户及其授权。以下查询用于检查当前用户、账户定义和授权信息；执行者本身需要具有查看相应系统信息的权限。
SELECT name, auth_type, host_ip, host_names
FROM system.users
ORDER BY name;
SHOW GRANTS FOR pmm_monitoring;
在测试环境验证监控所需的最小权限后，再创建或调整专用账户。具体授权语句取决于 PMM 当前版本、部署方式和采集功能，因此应以产品文档和实际查询需求为准。不要直接把下面的示意性思路照搬到生产：
-- 示例思路：为监控用途使用独立身份，并限制其可访问范围。
CREATE USER IF NOT EXISTS pmm_monitoring
IDENTIFIED WITH sha256_password BY 'replace-with-a-secret-from-your-vault';
GRANT SELECT ON system.* TO pmm_monitoring;
生产环境还应将密码存入密钥管理系统，限制账户来源地址，并对授权变更保留审计记录。若旧凭据曾被用于受影响的 PMM 实例，轮换时要同时更新 PMM 配置，避免因凭据失效造成监控盲区。
处置完成前的检查清单
在关闭事件前，建议确认以下事实，而不只是确认“服务已经重启”：
- 所有 PMM 实例均已确认版本，且受影响实例已经升级到 Percona 指定的修复版本。
- PMM 与 Grafana 的外部访问路径已收敛，匿名访问和不必要的管理员账户已清理。
- 与 Grafana 数据源相关的 ClickHouse 账户已完成权限审计，不再使用超出监控需求的高权限身份。
- 对可能暴露的 ClickHouse 凭据完成轮换，并验证数据采集、告警和仪表盘正常工作。
- 已检查 PMM、Grafana、反向代理和 ClickHouse 的访问日志，以便根据组织的事件响应流程判断是否存在异常访问。
这类漏洞的处置重点很明确：尽快升级修复，同时把监控平台当作持有生产数据访问权的关键基础设施来保护。版本修复解决已知缺陷，最小权限、网络隔离和凭据轮换则决定同类问题出现时的实际影响范围。