Appearance
02｜堡垒机与访问审计
上一篇用 SSH 直连服务器。机器不多、人就自己一个时，直连很方便。但机器和人员一多，几个问题就冒出来：同事离职了，他本地的 SSH 密钥还在不在？几个人共用 root，出了问题谁干的？临时给外包开个账号，事完忘了收回。
| 问题 | 直连 SSH 的表现 |
|---|---|
| 权限管理 | 本地账号+口头约定，离职时逐台清理密钥 |
| 操作追溯 | 多人共用 root，无法区分具体操作人 |
| 高危命令 | 执行完才知道，无事前拦截 |
| 临时授权 | 口头答应，过期了没人记得收回 |
堡垒机把这些入口收回一个点：所有人先登录堡垒机，再由堡垒机连接资产。核心价值是谁、在什么时间、通过什么账号、对哪台机器、做了什么——全链路审计。本篇以 JumpServer 为例讲堡垒机的核心对象、权限模型、审计能力，原理适用于同类产品。
一、核心对象关系
堡垒机最容易搞混的是几类对象:
| 对象 | 含义 | 示例 |
|---|---|---|
| 用户 | 登录堡垒机的人 | admin、ops01 |
| 资产 | 被管理的目标资源 | Linux 主机、Windows、数据库 |
| 账号 | 资产上的系统登录身份(不是堡垒机用户) | root、deploy |
| 授权规则 | 规定哪个人可以用哪个账号访问哪些资产 | admin → root@192.168.10.129 |
| 审计 | 连接过程、命令、录像 | 连接日志、命令记录、会话回放 |
关系一句话概括:
用户通过堡垒机,被授权使用某个资产账号,连接某台资产。只创建资产不够——资产告诉堡垒机"这台机器存在",账号表示"用什么身份登录",授权表示"这个人可以使用这个身份"。缺任何一块最终都连不上。新手最常踩的坑:资产建了、账号建了,但忘了做授权。
二、JumpServer 实验环境
| 组件 | 地址 |
|---|---|
| JumpServer | http://192.168.10.11/ |
| 被管理主机 | 192.168.10.129 |
| 堡垒机管理员 | admin |
| 资产账号 | root |
登录入口
打开浏览器访问 http://192.168.10.11/,使用 admin 账号登录。控制台展示平台概览——资产、用户、会话等对象入口。
实验环境使用简单密码;生产环境必须开启 MFA、强密码策略、来源 IP 限制。
三、资产纳管
创建资产
导航:进入 JumpServer,左侧菜单「资产管理」→「资产列表」→「创建资产」
| 字段 | 推荐值 | 说明 |
|---|---|---|
| 名称 | test-rocky-192.168.10.129 | 建议名字带地址,排查时一眼识别 |
| IP/主机 | 192.168.10.129 | 堡垒机连接资产的实际地址 |
| 平台 | Linux | 决定协议类型与连接方式 |
| 协议 | SSH + SFTP | Linux 主机至少 SSH |
| 节点 | /默认/ | 按节点批量授权 |
名称建议带地址,如 test-rocky-192.168.10.129——纯业务名(web-prod-03)需要想一下是哪台,带地址的 web-prod-03-10.0.1.23 一目了然。
密码、Token 等敏感信息不要放在备注里。
四、资产账号
创建账号
导航:进入资产详情 →「账号」→「创建账号」
| 字段 | 推荐值 | 说明 |
|---|---|---|
| 用户名 | root | 目标主机上的登录用户名 |
| 密码/密钥 | 托管密码或私钥 | 凭据由堡垒机托管,用户不需要知道真实密码 |
| 权限 | 密文 | 表示JumpServer保管了认证凭据 |
凭据统一托管在堡垒机,用户不需要知道目标机器的真实密码。
凭据托管的含义
账号列表的 密文 状态表示 JumpServer 保存了凭据。好处是用户只需通过授权即可访问,不需要接触真实的密码或私钥。
账号管理的几种方式
| 方式 | 优点 | 缺点 |
|---|---|---|
| 托管密码 | 用户不需要知道真实密码 | 堡垒机被攻破后凭据全部暴露 |
| 托管私钥 | 适合批量 Linux 主机管理 | 私钥需定期轮换 |
| 手动输入 | 临时连接,审计仍在 | 每次输入,体验差 |
| 个人账号+sudo | 责任清晰,可追溯具体人 | 账号生命周期管理复杂 |
生产推荐:个人账号 + sudo + 命令审计。root 保留给少数应急场景,日常操作走个人身份。
五、授权规则
授权规则把用户、资产、账号串联起来。
创建授权
导航:左侧菜单「权限管理」→「授权规则」→「创建授权」
| 区域 | 字段 | 配置要点 |
|---|---|---|
| 基本信息 | 名称 | 说明谁对什么资产的授权 |
| 用户/用户组 | 选择用户 | 哪些堡垒机用户可用此授权,建议按用户组权限管理 |
| 资产/节点 | 选择资产 | 授权到具体资产或节点(建议节点:加入节点的资产自动获得授权) |
| 账号 | 选择账号 | 允许使用哪些资产账号(如 root、deploy) |
| 协议 | SSH/SFTP/RDP | 按需勾选 |
| 动作 | 连接/文件传输 | 按需勾选,谨慎开放文件传输 |
| 有效期 | 开始和结束时间 | 临时授权必须设过期时间,到期自动失效 |
授权规则的风险信号
| 风险 | 处理 |
|---|---|
| 所有人授权所有资产 | 权限面太大,人员变动难收敛 |
| 所有账号都可用 | 用户可随意选高权限账号,绕过最小权限原则 |
| 永不过期的临时授权 | 过期自动失效比人记更可靠 |
| 同时开放文件传输+剪贴板 | 数据带出风险增高 |
临时排除时需要高权限时,在授权规则里设过期时间,到期自动失效。
六、Web Terminal 连接
普通用户进入 JumpServer 的「Web Terminal」(Luna)后,只能看到被授权的资产树——没授权的资产不显示。
连接步骤
- 登录 JumpServer Web 控制台
- 进入「Web Terminal」(Luna)
- 在资产树中选择目标资产
- 确认连接弹窗中的信息:
| 字段 | 值 |
|---|---|
| 协议 | SSH |
| 账号 | root(资产托管的) |
| 连接方式 | Web CLI |
- 点击连接,浏览器中打开终端
连接后确认
bash
whoami # 确认当前系统用户
hostname -I # 确认目标 IP,避免连错机器远程运维的习惯:连上后先确认身份、主机名、IP,再动手改配置——能避免"改错机器"这种灾难性事故。
七、审计能力与局限
堡垒机通常提供的审计能力
| 审计类型 | 内容 | 用途 |
|---|---|---|
| 登录日志 | 谁在什么时间、从什么 IP 登录堡垒机 | 异常来源发现 |
| 连接日志 | 谁连接了哪台资产、用了什么账号 | 操作追溯 |
| 命令记录 | SSH 会话中执行的命令 | 操作审计 |
| 会话录像 | 完整的交互过程回放 | 事故复盘 |
| 文件传输 | 上传/下载/SFTP 操作 | 数据防泄漏 |
| 改密记录 | 托管密码是否按时轮换 | 合规检查 |
命令审计的覆盖盲区
| 盲区 | 具体表现 |
|---|---|
| 交互程序 | vim、mysql、redis-cli 内部操作不全 |
| 执行脚本 | 只记录 bash deploy.sh,脚本内部内容看脚本自身 |
| 二进制工具 | 记录 kill 1234,但不知 1234 是哪个进程 |
| SFTP | 终端命令记录看不到文件传输 |
堡垒机是远程入口治理的一个环节,不是全部工具。命令审计 + 应用日志 + 数据库审计结合起来,才能完整还原一次操作的全貌。
八、MFA 与登录保护
堡垒机能连接大量资产,入口的登录认证需要比普通系统更严格。 一台服务器被攻破是单点损失;堡垒机密码泄露就等于所有资产的访问权。
| 措施 | 作用 |
|---|---|
| MFA(多因素认证) | 密码加动态码/硬件令牌,拿到密码也登录不了 |
| 强密码策略 | 降低弱口令被撞库的风险 |
| 登录失败锁定 | 连续错误后锁定,防暴力破解 |
| 来源 IP 限制 | 只允许办公网/VPN 访问堡垒机入口 |
| 管理员账号一人一个 | 审计日志才能精确到人 |
| 定期审计管理员 | 及时清理离职/转岗残留权限 |
管理员账号如果多人共用一个,审计日志只能记录"admin 做了什么",追踪不到具体责任人。
九、常见故障排查
资产可见但无可用账号
现象:Luna 中能看到资产,点击连接时提示没有可用账号。
排查顺序:
| 步骤 | 检查项 | 要确认什么 |
|---|---|---|
| 1 | 资产是否存在 | 资产列表中有目标机器 |
| 2 | 账号是否绑定 | 账号列表中有对应资产的账号 |
| 3 | 授权规则是否包含此账号 | 规则"账号"栏勾选了此账号 |
| 4 | 授权是否对用户生效 | 用户/用户组匹配,启用状态正常,在有效期内 |
| 5 | 协议是否匹配 | SSH 资产需要授权规则包含 SSH 协议 |
只授权了资产但没有授权账号,就会出现"看得到但连不上"。
连接失败:两段排查
用户 → JumpServer(第 1 段)
JumpServer → 目标资产(第 2 段)第 1 段失败:登录堡垒机——账号状态、MFA、浏览器访问。
第 2 段失败:从 JumpServer 机器测试:
bash
nc -vz 192.168.10.129 22 # 端口通?
ssh -i key user@192.168.10.129 # 认证通?端口不通→目标机器防火墙/安全组;认证失败→账号密码/密钥/sshd 配置。
审计缺命令:确认是否绕过了堡垒机
如果用户还能绕过堡垒机直连目标机器,堡垒机当然审不到。
目标机器侧收紧来源:
bash
# 只允许堡垒机 192.168.10.11 访问 SSH
iptables -A INPUT -p tcp --dport 22 -s 192.168.10.11 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP远程改防火墙规则时需要确认:当前连接来源、回滚方式、VNC/控制台入口。 否则直接 DROP 22 把自己关在外面。
十、上线关键点
堡垒机上线不是装起来就完工,真正费力的部分是把资产、用户、授权、审计理顺:
| 事项 | 做法 |
|---|---|
| 资产来源 | 从 CMDB 或云平台同步,不靠手工维护 |
| 用户来源 | 对接 LDAP/AD,员工离职在源头停掉,堡垒机联动失效 |
| 授权模型 | 按岗/环境/节点分组授权,不逐个用户配 |
| 高危权限 | root、DBA、生产写权限单独审批 |
| 审计留存 | 明确日志和录像保留期,满足合规要求 |
| 绕行治理 | 目标资产只允许堡垒机 IP 访问 |
| 应急入口 | 堡垒机故障时保留受控的应急登录方式 |
上线后定期检查两件事:
- 目标资产还能被绕过堡垒机直连吗?——绕行使审计断掉
- 授权规则是否保持过大的范围?——人员变动后权限没回收
这两件事不管好,堡垒机就只是个摆设。