简体中文
还在共享 root 密码？多人运维的权限与审计怎么做
共享 root 密码是很多中小团队还在用的运维方式：一个 root 账号、一个密码，谁要上服务器就发给谁。它的出发点通常是省事，但当团队超过两三个人，这种"省事"很快就会变成多人运维权限管理与运维审计上的大坑——你分不清是谁执行了那条高危命令，也无法在出事后追溯到具体的人。
本文围绕多人运维场景，讲清楚三件事：为什么共享 root 密码必须停下来、如何把账号和权限收敛到"一人一账号、按需授权"、以及怎样借助开源堡垒机把每一步操作都变成可审计的记录。文中以 Next Terminal 开源堡垒机为例说明落地方式，读者也可以对照 JumpServer、Teleport 等同类产品做替代选型。
一、为什么共享 root 密码必须停下来
先看共享 root 密码带来的三个现实风险。
第一，无法区分操作者。 当一个密码被多人共用，日志里留下的只有 root 这一个身份。某台数据库被误删、某个配置被改错，你无法回答"这是谁干的"，只能靠回忆和猜测。
第二，权限不可回收。 员工离职或外包结束，只要密码没改，对方（以及可能被截图、转发出去的密码）就仍然有效。改密码的成本又很高，因为要通知所有仍在用这个密码的人。
第三，一处泄露，全部沦陷。 共享的 root 凭证往往具备最高权限，一旦泄露，攻击者可以直达所有用同一密码的主机，横向移动几乎没有阻力。
设想一次典型事故：凌晨某台核心数据库被误执行了 drop table，第二天业务报障。安全团队翻遍日志，只看到一条来自 root 的操作记录，既不知道是值班的谁，也分不清是人为误操作还是凭证泄露后的恶意行为。这正是共享凭证最致命的地方——它同时抹掉了"谁"和"为什么"这两个最关键的审计要素。
这三个问题，本质上是同一个根因：把"身份"和"凭证"都压缩到了一个共享的 root 上。要解决它们，思路也很直接——把账号归还到每个人，把凭证收进集中管理，把每一次操作记录成证据。这正是堡垒机要解决的问题。
二、账号归人、凭证集中：从"一个 root"到"一人一账号"
多人运维的第一步，是让每个运维人员使用自己的账号登录，而不是共用 root。这需要两件事配合：
- 账号归人：每个人在堡垒机里有独立账号，登录动作能精确对应到人。
- 凭证集中：目标资产（服务器、数据库、网络设备）的真实账号密码不再直接发给个人，而是作为"授权凭证"集中保管，个人账号通过堡垒机间接使用这些凭证，看不到、也拿不到明文。
在 Next Terminal 中，这一层通过"授权凭证"实现：先统一录入资产的账号密码，新增资产时选择账户类型为授权凭证即可复用（见 资产管理）。运维人员只用自己的堡垒机账号登录，系统按授权关系决定他能访问哪些资产、用什么权限，而不是人人手握 root。
这样改完之后，root 密码本身可以不再下发，甚至可以定期轮换而不影响日常运维——因为大家不再依赖直接持有它。凭证的轮换、回收都由堡垒机集中完成，一次改动即可生效于所有相关资产，这是"人人持有密码"模式做不到的。
三、按人、按组、按资产做最小授权
账号归人只是第一步。第二步是把"谁能访问什么"显式地管理起来，也就是最小权限。
最小权限的原则是：每个人只拥有完成自己工作所需的最小范围。落地时按三个维度切分：
| 维度 | 要回答的问题 | Next Terminal 中的对应能力 |
|---|---|---|
| 人/组 | 这个账号是谁、属于哪个团队 | 用户与用户组，资产授权可指定到人 |
| 资产 | 能访问哪台服务器/数据库 | 资产分组与授权范围（资产管理） |
| 权限 | 能看、能连、还是能改 | 按资产授权 + 命令过滤（见下文） |
除了按人授权，用户组可以把一批同职责的人归为一组统一授权，避免为每个人重复配置；登录策略还可以对访问时间与来源做约束（例如仅工作时间、仅办公网段），进一步收窄暴露面。
权限不再是"给了 root 就给了全部"，而是每台资产、每个账号都能单独配置。新成员入职，只授权他负责的那几台；转岗、离职时，在堡垒机里取消对应授权即可，无需改共享密码，更不会出现"密码改了、忘了通知某人"的尴尬。这种"授权即授予、收回即失效"的模型，是多人运维权限管理的关键（更多细节见 资产访问）。
四、强身份认证：把"知道密码"升级为"证明是你"
账号归人之后，还要防止账号本身被冒用。多人共用密码时，认证方式只有"知道密码"这一种；一旦进入堡垒机模式，可以叠加更强的身份认证，把登录门槛从"知道密码"升级为"证明是你"：
- TOTP / 2FA：登录时要求一次性验证码（见 2FA(TOTP)）。
- Passkey / WebAuthn：使用设备上的通行密钥做无密码登录。
- 企业 IdP 对接：通过 OIDC 接入公司已有的统一身份系统。
- mTLS 客户端证书：在反向代理层先验证客户端证书再放行。
叠加这些之后，即便某个账号的密码被钓鱼或泄露，没有第二重因子或对应设备/证书，攻击者也难以进入。再配合登录策略对时间与来源网段的约束，就形成了"你是谁 + 你在哪 + 现在该不该登录"的多重校验。这与共享 root 密码"一个密码打天下"形成了鲜明对比。
五、高危命令：事前拦截，而不是事后追责
权限管理的理想状态，是危险操作在发生之前就被拦下来。共享 root 密码模式下，root 可以执行任何命令，rm -rf / 这类误操作没有任何缓冲。堡垒机则可以在命令层面加一道闸门。
Next Terminal 通过 SSH 代理服务器提供命令过滤能力：对高危命令进行拦截或转审批，只有得到豁免/批准才能执行。常见的分级策略可以这样设计：
| 命令示例 | 风险 | 建议策略 |
|---|---|---|
rm -rf / | 删除根目录，系统不可恢复 | 直接拦截 |
drop database ... | 删除整库数据 | 拦截或转审批 |
shutdown -h now | 停机影响业务 | 转审批 |
chmod 777 /etc | 权限过度放开 | 审计告警 |
同时，运维人员无需安装专用客户端，仍可用标准 SSH 客户端接入，保持原有习惯：
bash
# 直连模式：一步连接到已授权资产
ssh username:asset-name@host -p 2022配合数据库的 SQL 审计（见 数据库审计），即便是直连数据库的高危操作也在审计范围之内。这种分级拦截的思路，本质上是在"安全"和"效率"之间取平衡：既不让人人拥有 root 级任意执行权，也不因过度限制而拖慢日常发布与排障。命令过滤把"高危操作可追溯"提前到了"高危操作可阻止"。关于 SSH 代理服务器的配置与两种连接模式，见 SSH 代理服务器。
六、每一步可追溯：会话录像与审计
权限和拦截解决了"谁能不能干"，审计解决的是"谁干了什么、留下了什么证据"。这是多人运维审计的最后一环，也是对外（等保、内审）最常被检查的一环。
Next Terminal 提供的审计能力包括：
- 会话审计与录像：SSH/RDP 等会话可录像并回放，文本与图形会话都能追溯（见 合规与审计）。
- 文件操作日志：SFTP 上传下载等文件操作留痕。
- SQL 审计：数据库操作记录到人（数据库审计）。
- 访问日志分析：聚合分析访问行为，辅助发现异常（增强版能力）。
审计证据的留存同样重要：会话录像与操作日志既可以存储在本地，也可以落到对象存储（如 S3）做长期保存，配合一定的留存周期，才能满足内审与等保对证据保存时间的要求。
有了这些，出问题时可以从一条命令反查到"是谁、在什么时候、从哪个地址、对哪台资产做的"，而不是面对一屏 root 无从下手。
七、从共享 root 迁移到堡垒机的落地清单
把上面几步串起来，一个典型团队从"共享 root"迁移到堡垒机可以这样推进：
- 部署堡垒机并接入身份（容器安装），开通 SSH/数据库等资产的统一入口（安全网关）。
- 把资产真实凭证收进"授权凭证"，按人/组建立授权，root 密码不再下发。
- 对高风险资产叠加 TOTP/Passkey 或 mTLS。
- 配置命令过滤，拦截高危命令并转审批。
- 开启会话录像与数据库审计，定期回看访问日志。
- 建立轮换与回收制度：定期轮换授权凭证中的密码，离职/转岗当天回收授权。
迁移不是一次到位，可以先从最敏感的几台生产服务器开始，逐步推广。
八、迁移中的两个常见误区
误区一：以为收了 root 密码就等于合规。 把密码收进凭证库里，只是把"直接持有"变成了"间接使用"，如果仍然人人最高权限、操作不留痕，问题并没有解决。审计闭环（录像、日志、可回放）才是合规的关键。
误区二：一刀切拦掉所有命令。 命令过滤如果配得过死，会让运维瘫痪、逼着大家绕道。更合理的做法是分级：高危命令直接拦截，敏感命令走审批，常规命令放行但全程审计。既守住底线，又不牺牲效率。
结语
共享 root 密码是多人运维里代价最高的一种"省事"。把账号归还到人、凭证收进集中管理、按最小权限授权、高危命令事前拦截、每一步操作事后可审计，这套组合正是开源堡垒机的价值所在。Next Terminal 作为开源的堡垒机、JumpServer 与 Teleport 的替代方案，能把这套机制私有化部署、落地到自己的环境里。