Appearance
堡垒机与访问审计
堡垒机把对服务器的远程访问集中到一个入口：人员登录堡垒机，再由堡垒机连接目标资产。这样做的好处是——谁、在什么时间、通过什么账号、对哪台机器、做了什么，这条路可以完整地串起来。
一、直接 SSH 有什么问题
小环境里直接 SSH 到服务器很方便：
bash
ssh root@192.168.10.129但机器和人员数量上去以后，几个问题会很快暴露：
| 问题 | 直接 SSH 时的典型状态 |
|---|---|
| 谁能登录哪台机器 | 靠每台服务器上的本地账号和口头约定维持 |
| 谁用了哪个系统账号 | 多人共用 root，操作分不清是谁做的 |
| 谁在什么时间做了什么 | 翻目标机日志才知道，而且命令级别的记录不完整 |
| 离职或权限变更 | 要逐台去清 key、改密码，漏一台就留一台 |
| 临时授权 | 口头答应的事，什么时候撤也不知道 |
| 高危命令 | 拦不住，出了事只能事后翻日志 |
堡垒机把这些入口收回一个点：所有人先登录堡垒机，再由堡垒机去连接资产。目标机器只信任堡垒机的来源地址，普通人员不直接持有生产机器的 SSH 入口。
访问链路大概是：
text
运维人员 -> 堡垒机 -> 目标服务器展开来看：
text
用户身份 -> 堡垒机登录认证 -> 授权规则 -> 资产账号 -> SSH/RDP/数据库/Web 连接 -> 审计记录堡垒机不只是一个跳板——跳板只管"能不能连过去"，堡垒机还要回答"谁、什么时候、用什么身份、对哪台资产、做了什么"。所以它更接近远程操作的门禁加录像机。
二、用户、资产、账号、授权——这几个概念不能混
堡垒机里最容易搞混的就是这几个对象：
| 对象 | 是什么 | 例子 |
|---|---|---|
| 用户 | 登录堡垒机的人 | admin、ops01 |
| 资产 | 被管理的目标资源 | 192.168.10.129 这台 Linux 主机 |
| 账号 | 资产上的系统登录身份 | root、deploy、mysql_admin |
| 授权 | 规定谁可以用哪个账号访问哪些资产 | admin 可以用 root 连接 192.168.10.129 |
| 审计 | 连接过程、命令、录像 | 会话录像、命令记录 |
这几个对象的关系可以写成一句话：
text
用户通过堡垒机，被授权使用某个资产账号，连接某台资产。只创建资产是不够的。资产只是告诉堡垒机"这台机器存在"；账号表示"可以用什么身份登录这台机器"；授权表示"这个人可以使用这个身份"。三块里少任何一块，最后都在连接时报错。
三、JumpServer 测试环境
这次测试的环境：
| 角色 | 地址 | 说明 |
|---|---|---|
| JumpServer | 192.168.10.11 | 堡垒机 |
| 被管理主机 | 192.168.10.129 | Linux 测试机 |
| 堡垒机管理员 | admin | 登录 JumpServer |
| 资产账号 | root | 连接测试机 |
访问 JumpServer：
text
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。纯业务名虽然更好看，但排查问题的时候地址比名字更不容易搞混。
五、账号
账号是资产上的系统登录身份，不是堡垒机的登录用户。这个概念特别容易跟堡垒机用户搞混——登录堡垒机用的是一套身份，堡垒机帮你连接到目标资产时用的是另一套身份。
图中 root 账号绑定到了 test-rocky-192.168.10.129：
账号列表里 密文 这个状态表示 JumpServer 保存了认证凭据（密码或私钥），连接目标资产时可以代填。这样用户不需要知道目标机器的真实密码，也能通过授权来访问。
这同时也意味着堡垒机掌握了大量资产凭据。堡垒机本身就成了高价值目标——它的管理员账号、数据库备份、配置文件、密钥文件，都要按生产核心系统的标准来保护。
管理资产账号的几种方式：
| 方式 | 适用场景 | 需要注意的问题 |
|---|---|---|
| 托管密码 | 连接方便，用户不需要知道真实密码 | 堡垒机被侵入时凭据全部暴露 |
| 托管私钥 | 适合 Linux 主机批量管理 | 私钥要定期轮换，轮换流程要定义清楚 |
| 手动输入 | 临时连接、或者不想托管凭据 | 审计仍然在，但每次输密码体验较差 |
| 个人账号 | 责任清楚，配合 sudo 使用能更精确审计 | 账号从入职到离职的生命周期管理会更复杂 |
生产环境里比较合理的做法是用个人账号加 sudo，而不是所有人共用 root。root 保留给少数应急场景，日常操作走个人身份，这样出了事至少能追到具体的人。
六、授权规则
授权规则是把用户、资产、账号串起来的那条线。
授权列表里能看到已经配好的规则：
这条规则的含义是：admin 这个用户可以访问 192.168.10.129，并且有一个账号可以用。
展开一条授权规则的详情：
一条授权规则包含这些部分：
| 部分 | 说明 |
|---|---|
| 用户 | 哪些堡垒机用户可以使用这条授权 |
| 用户组 | 按岗位分组批量授权，比逐个用户授权更好维护 |
| 资产 | 授权到具体某台资产 |
| 节点 | 授权到资产分组，加入节点的资产自动获得授权 |
| 账号 | 允许使用哪些资产账号（root、deploy 等） |
| 协议 | SSH、SFTP、RDP 等 |
| 动作 | 连接、文件传输、剪贴板共享、会话分享等 |
| 有效期 | 临时授权的过期时间，到期自动失效 |
授权规则不仅要看"能不能连上"，还要检查权限是不是太宽了：
| 有风险的授权方式 | 具体问题 |
|---|---|
| 所有人授权到所有资产 | 权限面太大，人员变动时很难收敛 |
| 所有账号都可用 | 用户可以随便选高权限账号，绕过了最小权限原则 |
| 永不过期的临时授权 | 一次临时需求变成长期持有 |
| 同时开放文件传输和剪贴板 | 数据带出风险增高——可以下载文件、粘贴数据到本地 |
临时排障时经常需要高权限，事情办完后要及时收回。如果靠人记，大概率会忘掉。授权规则里设置过期时间，到期自动失效，比写在工单备注里靠谱得多。
七、通过 Luna 连接资产
JumpServer 的 Web Terminal 叫 Luna。普通用户进入 Luna 后，看到的是自己被授权的那棵资产树——没有被授权的资产不显示。
点击资产后出现连接确认弹窗：
弹窗里能看到几个关键信息：
| 项目 | 当前值 | 含义 |
|---|---|---|
| 协议 | SSH | 用 SSH 连接 Linux 主机 |
| 账号 | root | 使用资产上托管的 root 账号 |
| 连接方式 | Web CLI | 在浏览器里打开终端 |
| 自动登录 | 未勾选 | 下次仍然手动确认连接方式 |
连接成功后在终端里验证身份和地址：
bash
whoami # 确认当前登录到目标机后的系统用户
hostname -I # 查看目标机 IP，确认没有连错资产
结果确认当前用户是 root，目标地址是 192.168.10.129。这个确认动作虽然基础，但远程运维里值得保留——连上机器后先确认身份、主机名、IP，再动手改配置。
八、审计能看什么，不能看什么
堡垒机通常提供这几类审计能力：
| 审计类型 | 能回答什么问题 |
|---|---|
| 登录日志 | 谁在什么时间、从哪个 IP 登录了堡垒机，有没有异常来源 |
| 资产连接日志 | 谁连接了哪台资产，用了什么账号 |
| 命令记录 | 在 SSH 会话里执行了哪些命令 |
| 会话录像 | 回放完整的交互过程，适合事故复盘 |
| 文件传输记录 | 上传、下载、SFTP 操作 |
| 改密记录 | 托管账号的密码有没有按时轮换 |
命令审计不等于变更管理。它更多是事后追溯，而不是事前拦截。真正降低风险的还是授权收敛、危险命令控制、操作窗口和回滚方案这些措施。
另外，命令审计也有覆盖不到的地方：
| 场景 | 审计的局限 |
|---|---|
| 进入交互程序 | vim、mysql、redis-cli 里具体做了什么，不一定会完整展开在命令记录里 |
| 执行脚本 | 审到的是脚本入口（bash deploy.sh），脚本内部做了什么要看脚本内容和执行日志 |
| 二进制工具 | 命令名能记录到（iptables、kill），具体影响了什么要结合系统日志看 |
| 文件传输 | SFTP 的文件传输行为，终端命令记录里看不出 |
所以堡垒机是远程入口治理的一个环节，不是全部。目标机器上的 sudo 日志、系统日志、应用日志、数据库审计也得贯通起来。
九、MFA 和登录保护
堡垒机能连接很多资产，入口的登录认证需要比普通系统更严格。堡垒机账号密码一旦泄露，影响面比单台服务器大得多。
常见的登录保护措施：
| 措施 | 说明 |
|---|---|
| MFA | 密码之外再加动态验证码或硬件令牌，拿到密码也登不进来 |
| 强密码策略 | 降低弱口令被撞库的风险 |
| 登录失败锁定 | 连续输错 N 次后临时锁定，防止暴力尝试 |
| 来源 IP 限制 | 只允许办公网、VPN 或固定出口访问堡垒机入口 |
| 管理员账号分离 | 日常用的账号和堡垒机管理员账号分开，不混用 |
| 定期审计管理员 | 清除离职或转岗后残留的管理员权限 |
管理员账号如果多人共用一个，审计日志虽然看起来记录了"admin 做了某操作"，但实际上是多个人中某一个人做的，追踪不到具体责任人。
十、两个常见故障的排查
1、"看得到资产，但连不上"——没有可用账号
这种状态是 Luna 里能看到资产，点击连接时提示没有可用账号。
排查时按这个顺序——从有没有到能不能，逐步确认：
| 检查项 | 要确认什么 |
|---|---|
| 资产是否存在 | 资产列表里能不能看到目标机器 |
| 账号是否绑定 | 账号列表里是否有对应资产的账号 |
| 授权是否包含这个账号 | 授权规则在"账号"那栏有没有勾选这个账号 |
| 授权是否对当前用户生效 | 有效期、启用状态、用户/用户组是否匹配 |
| 协议是否匹配 | SSH 资产需要授权规则里包含 SSH 协议 |
只授权了资产但没有授权账号，就会出现"看得到但连不上"。这种问题从 Luna 页面看像系统故障，实际上大部分时候是授权配置没补全。
2、连接失败
连接失败要拆成两段看：
text
用户 -> JumpServer
JumpServer -> 目标资产第一段失败，看堡垒机登录是否正常——账号状态、MFA、浏览器访问。第二段失败，看堡垒机到目标机器的网络和认证——IP 是否可达、端口是否开放、密码或密钥是否正确。
在 JumpServer 上测到目标机器的连通性：
bash
nc -vz 192.168.10.129 22端口不通的话，检查目标机器防火墙和安全组。端口通了但认证失败，检查资产账号的密码、密钥和 sshd 配置。
3、审计里看不到命令
先确认连接是不是经过堡垒机发起的——如果用户还能绕过堡垒机直连目标机器，堡垒机当然审不到。
目标机器侧可以收敛 SSH 来源地址，只允许堡垒机连接：
bash
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 规则，确认 ACCEPT 规则生效后，再加 DROP 规则。保留一个已有的 SSH 会话作为回滚入口，再测新规则。
十一、上线时要关注的几条线
堡垒机上线不是把 JumpServer 装起来就完工。真正费力的部分是把资产、用户、授权、审计这几条线理顺：
| 事项 | 要做的 |
|---|---|
| 资产来源 | 从 CMDB、云平台或固定资产台账同步，不靠手工长期维护 |
| 用户来源 | 对接 LDAP/AD/企业身份源，员工离职时身份在源头停掉，堡垒机侧联动失效 |
| 授权模型 | 按岗位、环境、资产节点分组授权，不逐个给用户配 |
| 高危权限 | root、数据库管理员、生产写权限单独审批 |
| 审计留存 | 明确日志和录像保留时间，满足合规要求 |
| 绕行治理 | 目标资产只允许堡垒机或管理网段访问，降低绕过堡垒机直连的可能 |
| 应急入口 | 堡垒机如果出故障，保留受控应急登录方式 |
上线后还需要定期检查两件事：目标资产是不是还能被人绕过堡垒机直连（绕行是否有效封堵），授权规则是不是长期保持过大的范围没有收敛（人员变动后权限没有回收）。前者让审计断掉，后者让误操作的影响面扩大。