附录 H：堡垒机架构与选型指引
第 26 章用 webterm_demo 演示了堡垒机的核心骨架(PTY over WebSocket + 会话录制 + 审计)。 本附录补充:一个生产级堡垒机的完整架构、关键技术选型,以及自研与选用现成方案的权衡。
H.1 堡垒机要解决的四件事
堡垒机(跳板机 / 特权访问管理 PAM)的价值可以归纳为「4A」:
| A | 含义 | 技术落点 |
|---|---|---|
| Authentication 认证 | 统一登录,支持 2FA/SSO | 第 17、23 章:JWT + TOTP;企业接 LDAP/OIDC |
| Authorization 授权 | 谁能连哪台、用什么账号、能执行什么 | 第 23 章:RBAC/资源级授权 |
| Audit 审计 | 全程录制、可回放、可追责 | 第 26 章:会话录制 + 操作日志 |
| Accounting 账号 | 目标机凭据托管、定期轮换、用完回收 | 第 20 章:凭据加密存储 + 轮换 |
webterm_demo 覆盖了认证与审计骨架,授权可接第 23 章,账号托管可接第 20 章——堡垒机本质是本书多个模块的组合应用。
H.2 生产架构
text
运维 ──浏览器/SSH 客户端──▶ 堡垒机
├─ 认证层：登录 + 2FA + SSO
├─ 授权层：这次访问允许吗？（人 × 目标 × 账号 × 时间窗）
├─ 代理层：SSH/RDP/数据库协议代理到目标机
│ （凭据从保险库取，运维看不到目标机密码）
├─ 录制层：全程 I/O 录像 + 命令解析
└─ 管控层：实时监控、危险命令阻断、一键掐断会话
目标服务器（运维从不直接接触其凭据）关键设计原则:
- 凭据不落地到人:运维登录堡垒机,堡垒机从保险库(第 20 章加密存储)取目标机凭据去连,运维全程看不到目标机的密码/密钥。离职、轮岗只需在堡垒机回收权限,不必改目标机密码。
- 旁路无法绕过:目标机应配置成只接受来自堡垒机的连接(网络策略/安全组),否则运维绕过堡垒机直连就前功尽弃。
- 协议感知:能解析 SSH/RDP/数据库协议,才能做命令级审计与阻断(而不只是录一段黑屏视频)。
H.3 Rust 技术选型
自研堡垒机时,各层的 Rust 生态:
| 能力 | crate | 说明 |
|---|---|---|
| SSH 服务端/客户端 | russh | 纯 Rust SSH 2.0,做 SSH 代理的核心 |
| PTY | portable-pty | 第 26 章已用,本地 shell / 桥接 |
| Web 终端前端 | xterm.js(前端) | 浏览器里的成熟终端组件 |
| WebSocket | axum(ws) | 第 24 章,浏览器 ⇄ 堡垒机 |
| 凭据加密 | aes-gcm + KMS | 第 20 章 |
| 录像存储 | 对象存储 + 哈希链 | WORM、加密、防篡改 |
H.4 自研 vs 选用现成
先考虑现成方案。堡垒机是成熟品类,自研成本高、安全责任重:
- 开源:Apache Guacamole(无客户端远程桌面网关)、Teleport(现代化、支持 SSH/K8s/DB,Go 编写)、JumpServer(国内广泛使用)
- 商业:各云厂商的堡垒机 / 特权访问管理(PAM)产品
什么时候值得自研或深度定制:已有平台要把「访问 + 审计」深度嵌进自己的业务和权限体系(比如本书假想的资产管理 SaaS,要让堡垒会话和资产、租户、子账号权限打通),或有特殊合规/信创要求。即便如此,也建议代理层选用成熟组件、只自研管控与集成层,别从零实现 SSH/RDP 协议栈——那是安全事故高发区。
H.5 小结
- 堡垒机 = 4A(认证/授权/审计/账号),是本书第 17/20/23/24/26 章的组合应用
- 核心原则:凭据不落地到人、旁路不可绕过、协议感知才能做命令级管控
- Rust 自研关键 crate:russh(SSH 代理)、portable-pty、axum(ws)
- 优先选用成熟方案(Teleport/Guacamole/JumpServer),自研聚焦管控与集成层
- 无论自研选用,录像的加密与防篡改、目标机的网络隔离是不可省的两条底线
导航：返回目录