把管理通道收到一个点上
堡垒机（跳板机）的价值是把分散的服务器登录权限收拢：业务机只信任堡垒机来源的访问，人员认证、授权分配与操作记录都集中在堡垒机完成。这样做的直接好处是暴露面从 N 台服务器缩到 1 个入口，同时操作留痕不再依赖每台机器上各自的日志配置。没有商业产品时，一台加固过的跳板机加每人独立密钥、可审计的 sudo 配置，也能达成基本的收敛效果。
基本信息
| 加固项 | 管理通道收敛与运维审计 |
|---|---|
| 适用平台 | Linux/Windows 服务器群；云环境与物理机房均适用 |
| 权限要求 | 运维与网络管理员；云环境需要安全组管理权限 |
| 达标判据 | 管理端口不对个人网络开放，人员通过堡垒机访问 |
| 收敛对象 | SSH、RDP、数据库管理端口、云控制台账号 |
典型使用场景
- 等保三级“远程访问与运维审计”条款整改
- 多台云主机管理端口长期对公网开放的收敛
- 外包与合作方需要访问但不希望直接给服务器账号
- 运维人员流动时快速回收访问权限
- 安全事件后追溯“谁在哪台机器上做了什么”
主机侧：只放行堡垒机来源
主机侧：只放行堡垒机来源
# Ubuntu/Debian（ufw）：先加限源规则，再删除全来源放行
sudo ufw allow from 10.0.8.0/24 to any port 22 proto tcp
sudo ufw delete allow 22/tcp
# RHEL 系（firewalld）：用富规则限定来源
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.8.0/24" port port="22" protocol="tcp" accept'
firewall-cmd --permanent --remove-service=ssh && firewall-cmd --reload
ss -tlnp | grep ':22 ' # 服务仍在监听，但边界已限源云安全组与跳板机侧要点
云安全组与跳板机侧要点
# 云安全组：22/tcp 来源改为堡垒机所在安全组或指定网段，禁止 0.0.0.0/0
# 跳板机：禁用口令登录、每人独立密钥、开启 sudo 日志与会话记录
# /etc/ssh/sshd_config: PasswordAuthentication no ; PermitRootLogin prohibit-password
# 跳板机本身：最小化服务、独立安全组、纳入最高等级监控与备份收敛前后对比
| 维度 | 分散直连 | 堡垒机收敛 |
|---|---|---|
| 暴露面 | 每台机器的管理端口都需防护 | 只需防护堡垒机入口 |
| 认证 | 各机器各自管理账号密钥 | 统一身份与集中授权 |
| 审计 | 依赖每台机器的本地日志 | 操作记录集中留痕 |
| 回收 | 需逐台清理离职人员权限 | 在堡垒机侧一次收回 |
| 单点风险 | 无单点但管理成本高 | 堡垒机成为关键节点，需重点加固与冗余 |
堡垒机本身会成为单点：必须最严加固、最小端口开放、独立安全组与网络位置，并纳入应急预案（包含堡垒机不可用时的临时访问流程与审批方式）。同时多人共享同一把密钥是常见的功能劣化，每人独立密钥、操作可追溯到人，收敛才算真正完成。
收敛顺序建议先松后紧：先给堡垒机与运维人员开通新路径并验证可用，再逐批把业务机的管理端口从全来源改为限源，最后确认没有任何业务依赖直连。数据库中继、Windows RDP 与网络设备管理口要一并纳入清单，只收敛 SSH 会留下明显的旁路。