堡垒机与访问审计

堡垒机把对服务器的远程访问集中到一个入口:人员登录堡垒机,再由堡垒机连接目标资产。这样做的好处是——谁、在什么时间、通过什么账号、对哪台机器、做了什么,这条路能完整串起来。小环境里直连 SSH 很方便,但机器和人员数量一上去,直连的管理成本和审计盲区就暴露出来了,这时候就需要堡垒机。

一、直连 SSH 的问题

小环境里直接 SSH 到服务器很方便:

ssh root@192.168.10.129

但机器和人员数量上去以后,几个问题很快暴露:谁能登录哪台机器,只能靠每台服务器上的本地账号和口头约定维持;多人共用 root,操作分不清是谁做的;谁在什么时间做了什么,翻目标机日志才知道,而且命令级别的记录不完整;有人离职或权限变更,要逐台去清 key、改密码,漏一台就留一台;临时授权口头答应的事,什么时候撤也不知道;高危命令拦不住,出了事只能事后翻日志。

堡垒机把这些入口收回一个点:所有人先登录堡垒机,再由堡垒机去连资产。目标机器只信任堡垒机的来源地址,普通人员不直接持有生产机器的 SSH 入口。

访问链路大概是:

运维人员 -> 堡垒机 -> 目标服务器

展开来看:

用户身份 -> 堡垒机登录认证 -> 授权规则 -> 资产账号 -> SSH/RDP/数据库/Web 连接 -> 审计记录

堡垒机不只是一个跳板——跳板只管"能不能连过去",堡垒机还要回答"谁、什么时候、用什么身份、对哪台资产、做了什么"。所以它更接近远程操作的"门禁加录像机"。

二、核心对象:用户、资产、账号、授权

堡垒机里最容易搞混的就是这几个对象:用户(登录堡垒机的人,比如 admin、ops01)、资产(被管理的目标资源,比如 192.168.10.129 这台 Linux 主机)、账号(资产上的系统登录身份,比如 root、deploy)、授权(规定谁可以用哪个账号访问哪些资产)、审计(连接过程、命令、录像)。

这几个对象的关系一句话概括:

用户通过堡垒机，被授权使用某个资产账号，连接某台资产。

只创建资产是不够的。资产只是告诉堡垒机"这台机器存在",账号表示"可以用什么身份登录这台机器",授权表示"这个人可以使用这个身份"。三块里少任何一块,最后都在连接时报错。新手最常踩的坑就是:资产建了、账号建了,但忘了做授权,结果在终端里看得到资产却连不上。

三、JumpServer 测试环境

这次测试的环境:JumpServer 堡垒机在 192.168.10.11,被管理的主机是 192.168.10.129(Linux 测试机),堡垒机管理员账号 admin,连接测试机用的资产账号是 root。

访问 JumpServer:

http://192.168.10.11/

登录后进入控制台,能看到平台里资产、用户、会话这些对象的概况。

测试环境里 root/123 这种密码做实验省事,但只适合封闭环境。正式环境里共用 root 基本上不可接受——至少要拆个人账号、限制 sudo、开启 MFA,再配合命令审计。

四、资产

资产是堡垒机纳管的目标资源。Linux 主机、Windows 主机、数据库、Kubernetes 集群、Web 管理后台,都可以抽象成资产。

资产列表里能看到测试机:

资产列表里几个关键字段:名称是堡垒机里显示的名字(供人识别)、地址是目标主机 IP 或域名、账号显示已绑定到这台资产的账号数量、平台表示 Linux/Windows/数据库等类型(决定后续连接方式和协议)、连接性表示堡垒机到目标资产的网络和协议是否可用。

展开某个资产的编辑表单,能看到更详细的配置:

资产配置里几个容易混淆的字段说清楚:名称是给人看的名字,适合体现环境、用途和地址;IP/主机是堡垒机连接资产时实际用的地址;平台决定后续协议类型、账号管理和连接方式;协议是 SSH、SFTP、RDP 等,Linux 主机通常至少要有 SSH;节点是资产分组标签,后面可以用节点做批量授权;备注写资产用途,密码、Token 这类敏感信息不应该放在备注里。

资产的名字带上地址会比较实用,比如 test-rocky-192.168.10.129。纯业务名虽然更好看,但排查问题的时候地址比名字更不容易搞混——你看到 web-prod-03 还要想一下是哪台,看到 web-prod-03-10.0.1.23 就一目了然。

五、账号

账号是资产上的系统登录身份,不是堡垒机的登录用户。这个概念特别容易跟堡垒机用户搞混——登录堡垒机用的是一套身份,堡垒机帮你连接到目标资产时用的是另一套身份。

图中 root 账号绑定到了 test-rocky-192.168.10.129:

账号列表里 密文 这个状态表示 JumpServer 保存了认证凭据(密码或私钥),连接目标资产时可以代填。这样用户不需要知道目标机器的真实密码,也能通过授权来访问——凭据统一托管在堡垒机里。

这同时也意味着:堡垒机掌握了大量资产凭据,它本身就成了高价值目标。堡垒机的管理员账号、数据库备份、配置文件、密钥文件,都要按生产核心系统的标准来保护。堡垒机一旦被攻破,所有资产的凭据全部暴露。

管理资产账号有几种方式,各有取舍:托管密码连接方便(用户不需要知道真实密码),但堡垒机被侵入时凭据全部暴露;托管私钥适合 Linux 主机批量管理,但私钥要定期轮换,轮换流程要定义清楚;手动输入适合临时连接或者不想托管凭据的场景,审计仍然在,但每次输密码体验较差;个人账号责任清楚,配合 sudo 使用能更精确审计,但账号从入职到离职的生命周期管理会更复杂。

生产环境里比较合理的做法是用个人账号加 sudo,而不是所有人共用 root。root 保留给少数应急场景,日常操作走个人身份,这样出了事至少能追到具体的人。

六、授权规则

授权规则是把用户、资产、账号串起来的那条线。

授权列表里能看到已经配好的规则:

这条规则的含义是:admin 这个用户可以访问 192.168.10.129,并且有一个账号可以用。

展开一条授权规则的详情:

一条授权规则包含这些部分:用户(哪些堡垒机用户可以用这条授权)、用户组(按岗位分组批量授权,比逐个用户授权好维护)、资产(授权到具体某台资产)、节点(授权到资产分组,加入节点的资产自动获得授权)、账号(允许用哪些资产账号,比如 root、deploy)、协议(SSH、SFTP、RDP 等)、动作(连接、文件传输、剪贴板共享、会话分享等)、有效期(临时授权的过期时间,到期自动失效)。

授权规则不仅要看"能不能连上",还要检查权限是不是太宽了。几种有风险的授权方式要警惕:所有人授权到所有资产(权限面太大,人员变动时很难收敛)、所有账号都可用(用户可以随便选高权限账号,绕过了最小权限原则)、永不过期的临时授权(一次临时需求变成长期持有)、同时开放文件传输和剪贴板(数据带出风险增高——可以下载文件、粘贴数据到本地)。

临时排障时经常需要高权限,事情办完后要及时收回。如果靠人记,大概率会忘掉——授权规则里设置过期时间,到期自动失效,比写在工单备注里靠谱得多。

七、Web Terminal 连接资产

JumpServer 的 Web Terminal 叫 Luna。普通用户进入 Luna 后,看到的是自己被授权的那棵资产树——没有被授权的资产不显示,这点很重要,授权收敛直接体现在用户能看到的范围上。

点击资产后出现连接确认弹窗:

弹窗里能看到几个关键信息:协议是 SSH、账号是 root(资产托管的)、连接方式是 Web CLI(在浏览器里打开终端)、自动登录未勾选(下次仍然手动确认连接方式)。

连接成功后在终端里验证身份和地址:

whoami       # 确认当前登录到目标机后的系统用户
hostname -I  # 查看目标机 IP，确认没有连错资产

结果确认当前用户是 root,目标地址是 192.168.10.129。这个确认动作虽然基础,但远程运维里值得保留——连上机器后先确认身份、主机名、IP,再动手改配置,能避免"改错机器"这种灾难性事故。

八、审计能力与局限

堡垒机通常提供这几类审计能力:登录日志(谁在什么时间、从哪个 IP 登录了堡垒机,有没有异常来源)、资产连接日志(谁连接了哪台资产、用了什么账号)、命令记录(SSH 会话里执行了哪些命令)、会话录像(回放完整的交互过程,适合事故复盘)、文件传输记录(上传、下载、SFTP 操作)、改密记录(托管账号的密码有没有按时轮换)。

命令审计不等于变更管理——它更多是事后追溯,而不是事前拦截。真正降低风险的还是授权收敛、危险命令控制、操作窗口和回滚方案这些措施。

另外,命令审计也有覆盖不到的地方,要心里有数:进入交互程序(比如 vim、mysql、redis-cli)里具体做了什么,不一定会完整展开在命令记录里;执行脚本时审到的是脚本入口(bash deploy.sh),脚本内部做了什么要看脚本内容和执行日志;二进制工具能记录到命令名(iptables、kill),但如果审计里只有 kill 1234,还要到 systemd 或应用日志里确认 1234 是哪个服务、退出后有没有自动拉起;SFTP 的文件传输行为,终端命令记录里看不出。

所以堡垒机是远程入口治理的一个环节,不是全部。比如堡垒机只记录了 bash deploy.sh,目标机应用日志里同一分钟出现 database migration started,数据库审计里接着出现 ALTER TABLE——这几条线对上之后,才知道脚本内部到底改了什么。

九、MFA 和登录保护

堡垒机能连接很多资产,入口的登录认证需要比普通系统更严格。堡垒机账号密码一旦泄露,影响面比单台服务器大得多——攻击者拿到一个堡垒机账号,就等于拿到它名下所有资产的访问权。

常见的登录保护措施:MFA(密码之外再加动态验证码或硬件令牌,拿到密码也登不进来)、强密码策略(降低弱口令被撞库的风险)、登录失败锁定(连续输错 N 次后临时锁定,防暴力尝试)、来源 IP 限制(只允许办公网、VPN 或固定出口访问堡垒机入口)、管理员账号分离(日常用的账号和堡垒机管理员账号分开)、定期审计管理员(清除离职或转岗后残留的管理员权限)。

管理员账号如果多人共用一个,审计日志虽然记录了"admin 做了某操作",但实际上是多个人中某一个人做的,追踪不到具体责任人——所以管理员账号必须一人一个,各用各的。

十、常见故障排查

资产可见但无可用账号

这种状态是 Luna 里能看到资产,点击连接时提示没有可用账号。

排查时按这个顺序,从"有没有"到"能不能"逐步确认:

检查项	要确认什么
资产是否存在	资产列表里能不能看到目标机器
账号是否绑定	账号列表里是否有对应资产的账号
授权是否包含这个账号	授权规则在"账号"那栏有没有勾选这个账号
授权是否对当前用户生效	有效期、启用状态、用户/用户组是否匹配
协议是否匹配	SSH 资产需要授权规则里包含 SSH 协议

只授权了资产但没有授权账号,就会出现"看得到但连不上"。这种问题从 Luna 页面看像系统故障,实际上大部分时候是授权配置没补全。

连接失败

连接失败要拆成两段看:

用户 -> JumpServer
JumpServer -> 目标资产

第一段失败,看堡垒机登录是否正常——账号状态、MFA、浏览器访问。第二段失败,看堡垒机到目标机器的网络和认证——IP 是否可达、端口是否开放、密码或密钥是否正确。

在 JumpServer 上测到目标机器的连通性:

nc -vz 192.168.10.129 22

端口不通的话,检查目标机器防火墙和安全组。端口通了但认证失败,检查资产账号的密码、密钥和 sshd 配置。

审计缺失命令

先确认连接是不是经过堡垒机发起的——如果用户还能绕过堡垒机直连目标机器,堡垒机当然审不到。

目标机器侧可以收敛 SSH 来源地址,只允许堡垒机连接:

iptables -A INPUT -p tcp --dport 22 -s 192.168.10.11 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

这段规则只允许堡垒机 192.168.10.11 访问 SSH 端口,其他来源一律拒绝。要注意的是,远程修改防火墙规则时,当前连接的来源、回滚方式、带外访问入口都要提前确认好——远程直接 DROP 22 把自己关在外面的事并不少见。通常的做法:先加 ACCEPT 规则,确认生效后,再加 DROP 规则;保留一个已有的 SSH 会话作为回滚入口,再测新规则。

十一、上线关注点

堡垒机上线不是把 JumpServer 装起来就完工。真正费力的部分是把资产、用户、授权、审计这几条线理顺:

事项	要做什么
资产来源	从 CMDB、云平台或固定资产台账同步,不靠手工长期维护
用户来源	对接 LDAP/AD/企业身份源,员工离职时身份在源头停掉,堡垒机侧联动失效
授权模型	按岗位、环境、资产节点分组授权,不逐个给用户配
高危权限	root、数据库管理员、生产写权限单独审批
审计留存	明确日志和录像保留时间,满足合规要求
绕行治理	目标资产只允许堡垒机或管理网段访问,降低绕过堡垒机直连的可能
应急入口	堡垒机如果出故障,保留受控的应急登录方式

上线后还需要定期检查两件事:目标资产是不是还能被人绕过堡垒机直连(绕行是否有效封堵),授权规则是不是长期保持过大的范围没有收敛(人员变动后权限没有回收)。前者让审计断掉,后者让误操作的影响面扩大——这两件事不管好,堡垒机就只是个摆设。