先说结论：我们公司八个人的运维权限，最后是靠一台跳板机收住的。在此之前，我们的生产服务器密码躺在一个叫「服务器密码.txt」的腾讯文档里，谁都能点开、谁都能复制。那份文档在半年里被转发过二十多次，密码从最初的六位数变成了十二位，中间还混着两台已经下线的机器的旧密码。这不是个安全故事，这是一个迟早要出事的定时炸弹，而它最后真的响了。
如果你手上的服务器超过三台、并且超过两个人需要登录，这台机器就是你的资产入口，也是审计的起点：狗云DOGYUN（高性价比云服务器，机型齐全，适合做跳板机所在的固定节点）、RackNerd（全球 VPS 节点多，多机房批量铺业务机时方便统一纳管）。机器的规格不重要，一条稳定、带宽够用、不轻易被重装的线路就够了；重要的是从一开始就只有这一条路能进生产机。
去年十一月一个周六凌晨两点，我被电话吵醒：外网服务大面积超时，CDN 回源全是 502。登进第一台机器看进程、查 crontab、看 `/tmp` 目录，什么都没发现没有陌生 IP，没有挖矿进程，没有被删的二进制文件。折腾到快四点才在第二台机器上找到线索：某个目录里躺着一个伪装成 `systemd` 的脚本，占用了大量 CPU，而它的父进程是 root 通过 SSH 正常登录后手动执行并放进去的。
那一刻我才明白问题不在于「有人破解了密码」，而在于「有人用合法的密码登进来了」。查回溯面板，那台机器的 SSH 登录记录里写着一次来自公司内网的登录，时间是周五晚上十一点。顺着内网往下查，密码是从那份共享文档里被人拷走的离职两个月的同事，账号还在文档里没删，密码也没改。整条链路里没有一个环节触发过告警，因为每一步都是「合法」的。这就是共享密码最要命的地方：它把所有风险都伪装成了正常操作。
很多人以为跳板机就是堡垒机，其实差距很大。跳板机解决的是「唯一入口」：所有人先登跳板机，再从跳板机连目标机，目标机上根本不允许直接登录。堡垒机在跳板机之上多了三件事：集中身份认证、细粒度授权、会话全程记录与回放。
具体一点说，我们踩过的坑是这样的：光有跳板机的时候，谁都能用跳板机上的统一账号连任意一台机器，权限依然是「一把万能钥匙交到每个人手上」，只是钥匙换了个地方放。后来补上堡垒机之后，逻辑才真正闭环：运维小王只被授权了「测试环境全部机器 + 生产环境只读查看」，生产环境能执行 deploy 脚本但不能 rm；实习生能进跳板机，但连不上任何生产资产；外包同学的工作台有到期时间，到点自动失效。
换句话说，堡垒机改变的不是「怎么登录」，而是「谁在什么时间以什么身份对哪台机器做了什么」，并且这些答案事后能查、能回放。我们上线堡垒机那周做的第一件事，是把共享文档里的密码全部作废。
不做概念宣讲，直接说我改了哪些东西，因为这部分是可以照着干的。
第一，全部改成密钥登录，密码只留一个应急账号。目标机的 `/etc/ssh/sshd_config` 里关掉 `PasswordAuthentication yes`，保留一个应急用的系统账号并锁定密码（`passwd -l`），密钥放在跳板机上，运维只拿堡垒机里的资产账号，不直接接触密钥本身。
第二，权限从「按机器」改成「按角色」。我把资产按环境分成测试、预发、生产三组，再按职能分成运维、研发、值班、审计四个角色，每个角色绑定一组资产和一个允许的命令集合。授权的时候不再问「张三能不能连这台机器」，而是问「运维角色能不能连生产库那台」。
第三，生产资产的敏感命令加过滤。rm -rf、chmod 777、dd、mkfs、iptables -F、useradd 这类命令要么直接拦下要么弹二次确认，拦下的动作会连同操作者一起推到群里。我们上线第一周就拦掉过一次 `rm -rf /data/*`，是同事手滑打错了路径。
第四，会话录像必须落盘，而且要有留存期。这一点最容易被忽略。录像存在堡垒机的本地磁盘上，机器一重装就全没了，磁盘一满就静默停录。我们后来把录像存储挪到兼容 S3/OSS 的对象存储上，保留 180 天，出事那天正好调出了那个晚上的完整回放，直接锁定了操作人。
第五，资产账号的密码由系统托管并定期轮换。资产账号的密码存在堡垒机的加密保险箱里，运维永远看不到明文，运维只在堡垒机里操作，密码由堡垒机代填。这一步直接消灭了「密码必须发到群里才能干活」这个动作。
第六，双因子登录在堡垒机这一层做。堡垒机本身暴露在公网，它的失守等于全部资产失守，所以我给它加了 TOTP 动态口令，甚至限制只能从公司 VPN 段访问。
坑一：堡垒机自己成了单点。刚开始所有人都只往堡垒机上跳，堡垒机重启的那 10 分钟，全公司没人能登生产机。解决办法是准备两台，做主备，配置同步，VIP 浮动。现在我给它的定位是「它可以慢、可以旧，但必须一直在线」。
坑二：录像文件把磁盘写满。一次批量重启 20 台机器，产生了大概 40GB 录像，直接把存储盘撑到 100%，连带审计功能罢工。我们给录像单独划了分区并加了容量告警，同时对纯只读操作降级成只记命令不存全量录像。
坑三：命令过滤规则太严，把同事正常操作挡了。上线第一周，有同事用 `find / -name xxx` 排查问题被规则误拦，因为里面带了通配符和大范围路径。规则不能一刀切，得按角色分级，并且一定要留一个「白名单申请 + 临时放行」的通道，不然大家会绕着你走。
坑四：忘了给自己留后门。改完 sshd 配置重启的那一刻，如果配置写错，所有人包括你都进不去。稳妥的做法是保留一个带密码的应急账号，并且跑一条命令验证新配置再重启 sshd，别直接 restart。
坑五：审计日志没人看。上线三个月，告警响过两次，都是堡垒机自己磁盘满。我们后来加了两条规则：非工作时间登录生产资产、连续登录失败超过 5 次，都直接推送到值班群。审计这东西，不主动推送到人眼前，就是一堆躺在硬盘里的过期日志。
如果只有一两台机器、一两个人维护，说实话用不着上堡垒机，把密钥登录和 sudo 权限收好就够了，徒增运维成本。但一旦越过「机器超过三台、登录的人超过两个」这条线，共享密码带来的风险就会指数级上升因为人多了，密码就一定会出现在聊天记录、文档、截图里，而任何一个离职的人留下的凭证都是一颗定时炸弹。
我们最终的形态其实不复杂：一台跳板机（两台做主备）+ 一套开源堡垒机（我们用的是 JumpServer，它是国内团队维护的开源堡垒机，账号托管、授权、审计、录像这些模块都有，装在跳板机上），业务机一律只接受来自跳板机网段的 SSH 连接，其余入口在安全组和 sshd 两层同时关掉。八个人的运维权限，靠一套授权矩阵管住，再也没有共享文档。
回头看，那次凌晨的事故真正留下的教训不是「机器被入侵了」，而是「我们没有任何办法回答『到底是谁动的手』」。如果那时就有堡垒机，回放两分钟就能给出答案。技术手段的价值，很多时候不在于防止坏事发生，而在于出事之后你能不能把话说清楚。
