Workerman 不能替代堡垒机做SSH层审计，仅能通过透传堡垒机会话ID实现操作日志标记；数据库访问必须经堡垒机代理，禁用exec类函数，启用非交互式连接审计。
Workerman 本身不提供命令行审计能力，也不能直接对接堡垒机（如阿里云 Bastionhost）的 SSH 隧道或运维令牌机制。如果你希望对开发人员通过 Workerman 启动的后端服务执行的数据库/系统命令做权限审计，必须明确一点：审计对象不是 Workerman 进程本身，而是它所代理或触发的下游操作行为。真正的审计入口在堡垒机侧，Workerman 只能配合完成身份透传与操作日志标记。
Workerman 无法替代堡垒机做 SSH 层审计
堡垒机的命令行审计（比如用 DBeaver + SSH 隧道连 RDS）依赖于 SSH 协议层的会话劫持与命令拦截，而 Workerman 是 PHP 实现的 TCP/WebSocket 服务，不走 SSH 协议栈，也不持有终端会话（pty）。你不能把 Workerman 当成一个“跳板机”去转发 SSH 流量——它没这个能力，也违背设计初衷。
常见误操作是试图让开发人员连接 Workerman WebSocket 服务，再由服务端调用 shell_exec() 执行 mysql 命令。这不仅绕过堡垒机审计，还直接暴露高危函数、无会话隔离、无命令回溯，属于严重安全违规。
- 堡垒机审计生效的前提：所有数据库/服务器访问必须经由其提供的 SSH 网关或 MySQL 代理协议入口
-
Workerman若需访问数据库，应使用普通连接（如 PDO），且连接凭证必须来自最小权限账号，而非开发人员个人账号 - 任何
exec/system/shell_exec调用都应被禁用或严格白名单控制，PHP 配置中需设disable_functions = exec,system,shell_exec,passthru
如何让 Workerman 的操作可被堡垒机关联审计
虽然 Workerman 不处理 SSH，但它可以成为审计上下文的“标注器”：在调用数据库前，把当前操作者身份、意图、来源 IP、时间戳等信息写入日志，并与堡垒机侧的运维令牌（token）或会话 ID 建立映射关系。
前提是开发人员登录堡垒机时已获取了带身份标识的运维令牌（如阿里云 Bastionhost 的 session_id 或 ticket_id），该令牌需在前端或网关层透传到 Workerman 服务中。
- 前端 Web 页面或 CLI 工具在发起请求时，将堡垒机返回的
X-Bastion-Session-ID或X-Operation-Token作为 HTTP Header 传给Workerman的 WebSocket 或 HTTP 接口 -
Workerman在onMessage或自定义路由中解析该 header，并存入$connection->session_id或 Redis 中的临时映射表（bastion:session:{id} → {user_id, role, expire_at}） - 当该连接后续触发数据库操作（如执行 SQL），日志中必须包含该
session_id，格式示例：[2026-05-22 20:45:11] [session:abc123] [user:dev-alice] [sql:SELECT * FROM users LIMIT 10] - 这些日志需集中采集（如 Filebeat → ES），并与堡垒机导出的审计日志按
session_id关联分析
为什么不能用 Workerman 做数据库代理网关
有人尝试用 Workerman 实现一个“MySQL Proxy”，监听客户端请求、解析 MySQL 协议、转发到真实 DB。这条路理论上可行，但实际踩坑极多：
- MySQL 协议复杂（握手、认证、压缩、SSL、COM_STMT_PREPARE 多阶段），
Workerman没有成熟协议解析库，自行实现极易出错或被绕过 - 无法兼容堡垒机的审计逻辑：堡垒机要求流量经过其 TLS 终结点和会话管理模块，而自建 proxy 会截断原始连接上下文
- 性能与稳定性风险：PHP 不适合长连接+二进制协议解析场景；连接池、超时、重试、错误码映射都需重造轮子
- 审计字段缺失：自建 proxy 很难还原原始客户端 IP、终端类型、SSH 会话 ID 等堡垒机原生支持的审计维度
结论很直接：别这么干。堡垒机就是干这个的，Workerman 应专注业务逻辑，把协议层、审计层、权限网关层交给专业系统。
真正可行的协作链路
Workerman 和堡垒机不是替代关系，而是分层协作关系。典型合规链路如下：
- 开发人员通过堡垒机运维门户或 DBeaver + SSH 隧道，以个人最小权限账号直连数据库 —— 审计由堡垒机完成
- 开发人员通过前端页面调用
Workerman提供的 API（如“生成报表”），该 API 内部调用数据库 —— 此时Workerman使用服务账号连接 DB，并在日志中标记调用者身份（来自哪个堡垒机会话） - 所有数据库连接统一走堡垒机的 MySQL 代理地址（如
proxy-bastion.example.com:3306），而非直连 RDS 内网地址；该代理由堡垒机部署并管控 -
Workerman的数据库配置中，host必须设为堡垒机提供的代理域名，且启用PDO::ATTR_EMULATE_PREPARES = false，避免预处理语句绕过审计
最易被忽略的一点：堡垒机的 MySQL 代理默认只审计交互式会话（mysql -h 命令行），对程序化连接（PDO/MySQLi）是否开启审计，取决于堡垒机后台策略配置 —— 你得确认开启了“非交互式连接审计”开关，否则 Workerman 的请求压根不会进审计流水。
