服务器访问管理：IP 白名单 和 用户权限结合

IP白名单与用户权限必须叠加使用才能实现三层安全控制。白名单需分层配置：管理接口限固定IP、应用层按业务划分、Web层用allow/deny规则；用户权限须最小化，独立账号、细粒度授权、动态密钥管理；配置前须验证防锁死，三者协同方为真正安全。

IP 白名单和用户权限不是二选一，而是必须叠加使用的安全组合。单独开白名单，可能被内部账号滥用；只设强密码，挡不住撞库或横向移动。两者配合，才能实现“谁（身份）+ 从哪来（来源）+ 能做什么（权限）”的三层控制。

白名单要分层配置，不能一刀切

不同服务、不同角色应匹配不同粒度的 IP 控制：

• 管理接口（如 admin 端口、SSH、数据库后台）：必须用最严策略，只允许办公网固定 IP 段或跳板机 IP，例如 admin-allow-ip = 192.168.5.0/24,10.10.20.100；禁止公网直连，哪怕配了强密码也不行。
• 应用接入层（如 Cetus Proxy、DBProxy 的 client 连接）：按业务系统划分，比如订单服务只允许来自 172.20.10.0/24 的机器连接，且绑定专用账号 [email protected].%。
• Web 层（如 Nginx）：可在 server 块中用 allow/deny 控制访问源，注意规则顺序——allow 在前、deny all 在末尾，否则会失效。

用户权限要按最小化原则拆分

每个应用或服务都该有独立账号，避免共用 root 或 admin：

• Cetus/DBProxy 的 users.json 中，为每个业务系统定义专属用户，client_pwd 和 server_pwd 分开设置，不复用同一密码。
• MySQL 后端账号本身也要限制权限，比如 order_service 只能查写 order_* 表，不能删库或改用户表。
• 避免在配置中硬编码密码；生产环境建议通过远程配置中心动态下发密钥，或使用 Vault 类工具注入。

关键操作细节容易踩坑

配置生效前务必验证，否则可能把自己锁在外面：

• Linux 防火墙（iptables/firewalld）启用白名单时，先加自己的 IP，再设 default DROP；建议保留一个带超时的临时规则（如 iptables -I INPUT 1 -s 当前IP -j ACCEPT -m connlimit --connlimit-upto 3），防误操作断连。
• Cetus 的 proxy-allow-ip 支持 User@IP 格式，比纯 IP 更精准；但若写成 [email protected]，则只有 root 用户从该 IP 连才放行，其他用户即使同 IP 也会被拒。
• Nginx 的 allow/deny 不支持正则，但支持 CIDR；测试时可用 curl -v --interface 192.168.1.100 http://localhost:8080 模拟指定源 IP 请求，验证规则是否命中。

真正安全的访问管理，不是靠某一条规则兜底，而是靠白名单卡住入口、用户权限管住行为、日志审计盯住异常。三者缺一不可。