华为云云堡垒机CBH实战：主机纳管、运维会话、命令控制与审计回放

一、背景：为什么云主机不该被直接登录

弹性云服务器建好后，最常见的做法是把远程登录端口对若干办公出口放开，再把密钥或口令发给运维和开发。时间一长，谁在什么时候登录过哪台机器、执行过哪些命令、有没有把文件拷出去，往往说不清。人员变动后账号没收干净，临时放开的来源忘记收回，出了事故只能翻系统日志，还不一定完整。

自己在跳板机上做转发也能收拢入口，但账号、授权、会话录像和命令限制都要自己维护，机器一多就容易散。华为云云堡垒机（下文简称 CBH）把主机纳管、人员授权、运维会话和审计回放放到同一处：登录先经过堡垒机，再到达被管主机。它不是替代安全组和主机安全，而是把“谁能以什么身份操作哪台机器”变成可审批、可回放的过程。本文按“认清概念 → 开通实例 → 纳管主机与人员 → 会话和命令控制 → 审计与费用”的顺序说明做法。菜单名称以控制台当前版本为准。

二、核心概念

堡垒机实例：对外提供运维入口的托管环境，是使用 CBH 的基本单位。实例名称建议带环境和用途，例如 cbh-prod-ops。测试和生产的授权习惯不要混在一起。

部门与用户：人员的组织方式。部门名记为 <部门名称>，用户名记为 <运维用户>。用户应对应到具体的人，不要多人共用一个登录名。

主机资源：被纳管的弹性云服务器或其他服务器。主机名记为 <主机名称>，系统账号记为 <系统账号>。纳管不等于已经允许所有人登录，还要再做授权。

授权规则：决定谁能在什么时间、用什么协议访问哪台主机。规则名称记为 <授权规则>。规则要写得尽量具体，避免“全体人员可访问全部主机”。

命令控制：在会话中限制高危操作，例如删除目录、改权限、停服务。控制策略记为 <命令策略>。刚启用时先观察命中情况，再改为阻断。

会话与审计：一次登录形成一条会话，命令、文件传输和图形操作应能回放。会话标识记为 <会话标识>，审计存放位置记为 <审计存储>。

三、开通实例并接入网络

进入云堡垒机控制台，选择与业务相同的区域后创建实例：

1. 按当前要纳管的主机数量和并发运维人数选择规格，不要按不确切的远期峰值买过大实例；
2. 填写名称，例如 cbh-dev-manage，测试与生产分开；
3. 配置网络：虚拟私有云、子网和安全组。安全组只放行运维人员访问堡垒机入口，以及堡垒机访问被管主机的登录端口，不要对全部地址放开远程登录；
4. 设置管理员 <管理员用户> 和口令，口令只通过安全渠道保管，不要写进脚本或公开文档；
5. 确认计费方式后提交，等待实例变为可用，再记录入口信息。这些信息不要出现在对外文章中。

实例可用只说明堡垒机本身起来了，不代表已能登录业务主机。先确认运维网段能访问堡垒机入口，堡垒机网段能访问被管主机的登录端口，被管主机安全组不再对公网开放远程登录。切换期间保留可回退的管理通路，但要把临时放行标上到期时间，切完立刻收回。开通前检查配额。管理账号只留给少数管理员，日常运维使用个人用户。

四、纳管主机并给人员授权

不要把全部主机一次性导入后再补权限。先纳管一两台测试机，跑通登录、命令审计和文件传输，再按部门和业务分批接入。

纳管时重点核对：

1. 主机名称用 <主机名称>，带上环境和用途，避免一长串无法辨认的编号；
2. 正确选择协议和端口，字符终端登录与图形桌面登录不要混用同一套约定；
3. 系统账号用 <系统账号>，优先使用专用运维账号，不要让所有人直接使用超级用户；
4. 口令或密钥只保存在堡垒机受控的账号托管里，不要再通过聊天工具分发；
5. 主机加入对应部门或资源组，方便按组授权，而不是每来一个人就勾选全部机器。

授权建议写成清单：

规则名称 = <授权规则>
运维用户 = <运维用户>
所属部门 = <部门名称>
主机名称 = <主机名称>
系统账号 = <系统账号>
协议 = 字符终端或图形桌面
可用时段 = <开始时间> 到 <结束时间>
文件传输 = 默认关闭，按需单独打开
描述 = 仅开放该人员职责内的主机

能收窄到具体人和具体主机，就不要写全体放行。开发人员默认不能登录生产主机，应急访问走临时授权并设置到期时间。人员入职按部门模板发放，离职当天禁用用户并检查未结束会话。主机下线后要从资源列表移除，避免授权还指向已回收的机器。

同一人若同时承担开发和应急值班，应拆成不同授权，而不是把生产权限做成长期默认开通。授权变更后，用一次合法登录和一次应被拒绝的登录确认规则生效。

五、运维会话、命令控制与文件传输

所有生产登录都应从堡垒机进入，而不是绕过入口直连。会话开始后，运维人员使用自己的 <运维用户>，再切换到被授权的 <系统账号>。需要提权时，应能在审计中看到原因和操作过程，而不是私下共用超级用户口令。

命令控制建议这样落地：

1. 先收集本团队确实会用到的日常命令，再把高危命令放入 <命令策略>，例如递归删除、关闭安全代理、改启动项和清空审计日志；
2. 刚启用时可用告警或审批模式，确认没有误伤后再改为阻断；
3. 策略按环境分开，测试可以宽一些，生产必须更严；
4. 临时放开某条命令要记下原因和到期时间，用完收回；
5. 命中记录要能回到 <会话标识>、操作人和主机，便于复盘。

文件上传下载默认关闭，只有发布或取日志等明确场景才对指定人、指定主机打开，并限制方向和大小。能在对象存储或制品库完成的发布，就不要用交互会话拷贝文件。图形会话同样要开启审计，不能因为是窗口操作就留下空白。

若有自动巡检或变更脚本，也尽量纳入可审计的作业通道，而不是在某台个人电脑上直接连生产主机执行。会话超时和空闲断开要打开，避免人已经离开、会话还挂在生产机器上。多人同时操作同一台主机时，应能区分各自的会话，不要共用一个已登录窗口。

六、审计回放、告警与成本控制

没有回放的堡垒机，出了问题仍然只能靠回忆。生产环境应保留足够的会话录像和命令记录，覆盖一次完整的排查和审计窗口，存放位置记为 <审计存储>。只看到“已开启审计”却从未抽查回放，真正需要时往往会发现存储不足、权限不够或早期会话已被覆盖。

日常建议关注：

1. 是否出现绕过堡垒机直连主机的登录尝试，这类情况应在安全组和主机侧一并堵住并告警；
2. 是否有非工作时段登录、短时间大量失败认证，或从非常用人员发起的生产访问；
3. 命令策略命中是否突然增多，是误报还是真实的高危操作；
4. 文件传输是否出现未申请的出站拷贝。

告警可以和消息通知服务联动，但不要把每一次普通登录都发短信。更合理的是对生产主机的异常登录、命令阻断、审计存储将满和实例状态异常告警。抽查回放时，既要看成功的日常变更，也要看被阻断的会话，确认策略仍然符合当前操作习惯。

费用主要来自实例规格、并发会话和审计存储。控制费用不是缩短到无法追溯的保留期，而是测试实例用完及时释放，下线主机及时移出，规格按真实并发调整，过期审计按制度转存或清理。实例变更、用户和授权的修改应能在记录中查到，管理员权限保持在最小范围。入口信息、账号和密钥只放在内部配置里。

七、小结

云堡垒机的关键不是“已经开通”，而是把生产登录收拢成一条可解释的路径：哪些 <主机名称> 被纳管，哪些 <运维用户> 能在什么时间使用哪些 <系统账号>，高危命令如何控制，会话能否回放到某一次操作。安全组、主机安全和身份权限仍然要各司其职，堡垒机补的是运维入口的收口和审计。

先把主机和人员按部门理清楚，再分批纳管并收回直连端口；先有命令策略、会话回放和临时授权到期机制，再当作生产依赖。入口地址、账号和密钥不要写进公开文档。