为什么给外部顾问开 MySQL 只读权限比想象中麻烦

外部顾问需要查询内网 MySQL 数据库做数据核对或报表分析，这类需求在项目实施期非常普遍。真正动手做的时候，难点通常不在 MySQL 本身——GRANT SELECT 一条语句就能搞定只读账号——而在于怎么让顾问的客户端安全地“够到”内网数据库。3306 端口如果直接暴露到公网，等于把数据资产放在扫描器眼皮底下；用 VPN 又涉及网络改造、账号开通、权限收口一堆流程。很多团队最后选择临时开一个公网白名单 IP，结果顾问换了办公地点就断连，或者白名单被运维遗忘在安全组里长期挂着。

只读访问之所以棘手，是因为它同时踩中了三个敏感点：网络暴露面、账号权限边界、操作留痕。单解决任何一个都不难，难的是三者都不牺牲。下面会把这三件事逐个拆开，给出能落地的判断依据。

MySQL 只读授权：用最小的数据库权限兜住底线

先把数据库层面的控制做实。外部顾问访问的只读账号，不建议直接授予库级别的 SELECT，更不要图省事用 root 或者某个已有业务账号。正确的粒度是：只开放顾问实际需要查询的那几张表，字段能收窄就收窄，避免把整库的结构和数据暴露给不需要的查询。

一条常见的授权思路如下：

  • 创建独立账号，限定来源主机为访问链路最终会出现的地址段，而不是使用 % 通配；
  • 只对明确指定的表授予 SELECT，必要时通过视图收紧字段，敏感列（手机号、身份证号、密钥字段）直接不放进授权范围；
  • 设置 MAX_QUERIES_PER_HOUR 和 MAX_UPDATES_PER_HOUR 为 0 或极小值，进一步阻断误操作和异常批量拉取；
  • 开启 general_log 或从审计插件层面确认该账号的每一条 SQL 可追溯。

这里有一个容易被忽略的点：只读账号并不等于无风险。一个只有 SELECT 权限的连接，如果跨过数据库直接利用 MySQL 版本漏洞或者被用作内网探测跳板，风险同样存在。所以数据库授权是底线，不是完整方案。

内网 MySQL 暴露给外部访问的常用方案对比

顾问访问内网 MySQL，市面上通行的做法可以归为四类，各自有明确的适用边界。

方案典型实现优势主要限制
公网直接暴露在路由器/防火墙上把 3306 映射到公网 IP，加 IP 白名单部署快，顾问只需拿到 IP 和端口攻击面大，白名单维护成本高，缺乏细粒度访问控制
VPN 拨入IPsec/OpenVPN/WireGuard 拨入后访问内网地址网络层统一收敛，适合长期、多资源访问需要网络改造和证书分发，权限粒度粗，审计落在网络层
SSH 隧道顾问通过 SSH 账号建立本地端口转发无需复杂改动，加密传输需开放 SSH 端口，账号管理混乱时难以追责，权限与系统账号强绑定
反向连接/代理组网内网侧主动发起出站连接，外网侧通过客户端接入无需公网 IP 和入站端口，不改变现有网络需要接受新增组网组件，选型要关注授权和审计能力

反直觉的一点是：最不推荐的往往是看着最省事的公网直连。它的运维成本和风险都不低，只是成本被“延迟支付”了——通常是在一次撞库或扫描事件之后才暴露出来。SSH 隧道适合临时、单次、个人使用的场景，但一旦涉及外部顾问多人、多时段访问，账号和权限的管控成本会快速上升。

如果顾问访问是短期项目制、且内网不方便做入站改造，反向连接类方案在部署形态上更贴合。它的关键是：内网侧只需要有出站能力，不需要把任何端口暴露给公网。

用 NexTunnel 落地只读访问：端口、设备、审计三层卡位

NexTunnel 的做法是把访问链路收敛到一套可控通道里。Server 装在内网侧，作为内网资源的出口；Client 装在顾问的外网电脑上，用来接入。中间不需要公网 IP，也不需要调整现有防火墙的入站规则。顾问在 Client 上只能看到管理员明确开放出来的资源端口，其他内网资产对这个设备是看不到的。

针对“外部顾问只读访问内网 MySQL”这个目标，落地时可以按三层卡：

  • 端口白名单：在 NexTunnel 管理后台中，只把目标 MySQL 实例的 3306（或实际监听端口）开放给该项目。顾问无法通过这条链路探测其他端口或服务，端口之外的内网资源默认不可见。
  • 设备授权：把目标 Client 设备绑定到资源授权范围，只有被明确授权的设备才能发起连接。顾问换电脑或者临时用自己机器访问，需要管理员重新授权，杜绝设备层面的“借用账号”。
  • 访问审计：后台会记录设备接入和资源侧端口访问行为。配合 MySQL 自身的只读账号审计，能从“谁在什么时间连接了哪个端口”和“该连接执行了哪条 SQL”两个维度做追溯。遇到异常的批量导出或非常规时间段访问，可以快速定位。

这个模型的硬约束是：MySQL 的只读授权必须先做好。NexTunnel 解决的是“谁能连过来、连到哪个资源、连了多久”，它不负责替数据库做权限判定。两者缺一不可——没有数据库只读授权，通道再收敛也挡不住一个已有高权限账号被滥用；没有通道收敛，数据库授权做得再好，暴露面依然不可控。

[插图建议：NexTunnel Server 部署在内网、Client 位于外网访问 MySQL 的链路示意，突出端口只开 3306、设备授权与审计位置]

外部顾问项目周期的常见踩坑与排查顺序

顾问访问类需求是典型的有生命周期：项目启动时开通，项目结束后收回。最容易出问题的不是开通，而是收口。

  • 访问周期未预设：顾问项目应该在一开始就确定访问起止时间，到点自动或者至少人工触发回收。等数据已经用完再“想起来关掉”，是很多数据泄露的前置条件。
  • 设备绑定与账号绑定混为一谈：设备授权控制的是“哪台机器能连”，MySQL 账号控制的是“连上之后能干什么”。外面一个只读账号密码如果泄露，但有设备层限制，风险还可控；反过来，设备都放行，数据库账号被撞一下就是灾难。
  • 只读账号被用于扫描：有些顾问会用客户端试图连同一网段下的其他 MySQL 实例。端口白名单在这一层提供结构性阻断，不要寄望于网络安全意识培训来解决问题。
  • 排障顺序颠倒：顾问反馈“连不上数据库”时，最常见的前三个原因依次是：设备未被 NExTunnel 管理后台授权、端口未放通、本地数据库客户端配置了错误的内网地址解析。先查通道，再查 MySQL 账号和网络参数，能省掉大量无效排查时间。

只读访问只是起点，收口制度比技术更重要

外部顾问访问内网数据库，本质上是一次小范围、短期、可控的资源开放。真正稳妥的方案不会把宝押在单个环节上，而是用“数据库最小权限 + 端口/设备层收敛 + 操作留存”三层叠加后的剩余风险来决定是否放行。

如果你们的顾问访问场景已经明确——固定几台外网机器、只访问一个 MySQL 实例、需要留痕——可以先用 NexTunnel 的最小授权模型跑通一个项目窗口：内网只装一个 Server，外网侧只授权一个 Client，资源只放一个 3306 端口，打通之后再逐步复制到其他顾问项目和内网资源。