运维人员离职后的服务器密码与权限回收流程

运维人员离职，最让团队心惊肉跳的往往不是业务交接，而是那串他脑子里没交出来的root密码，以及散落在各台服务器上连他自己都可能忘了的SSH Key。这种风险不是虚构的，很多公司都经历过离职员工在半夜用旧权限登录服务器删库跑路，或者离职半年后系统出现诡异问题，一查发现是他的自动化脚本还在以他的身份运行。处理服务器密码与权限回收，本质上是在做一次“数字资产的紧急排雷”，动作要快，覆盖要全，绝不能只改个密码就完事。

听到离职消息的第一反应，不是冲进系统把所有账号删掉。正确做法是先冻结。在Linux系统里，用passwd -l username锁定账号，或者用usermod -L username禁用登录。这比直接删除高明得多，因为直接删账号会导致该用户拥有的文件变成无主孤魂，后续排查归属权极其麻烦。冻结后，该账号无法登录，但其UID和文件归属关系完整保留。同时，用pkill -KILL -u username立即杀掉该用户所有正在运行的进程，包括后台任务和tmux/screen会话。这一步很多人会漏，导致人走了脚本还在跑。

这是最大的盲区。运维人员为了方便，往往在几十台服务器之间配置了SSH免密登录。你需要做的是：先检查authorized_keys文件，路径通常是~/.ssh/authorized_keys。用for循环批量扫描所有服务器上该用户的这个文件，把里面的公钥全部提取出来，与离职人员个人电脑、跳板机上的公钥做指纹比对。关键动作是直接清空或重命名该文件，而不是逐条删除，因为你永远不知道他有没有用其他名字存了备份公钥。同时检查/etc/ssh/sshd_config中是否配置了AuthorizedKeysFile指向了非标准路径，有些老练的运维会把公钥藏到别处。

# 批量检查所有服务器上某用户的authorized_keys
for host in $(cat server_list.txt); do
  echo "=== $host ==="
  ssh root@$host "cat /home/username/.ssh/authorized_keys 2>/dev/null"
done

光禁用账号不够，要检查该用户是否通过其他方式获取了特权。用groups username看他属于哪些组，重点看wheel、sudo、docker这些组。docker组尤其危险，因为能操作docker socket的用户基本等于root。检查/etc/sudoers文件和/etc/sudoers.d/目录下所有文件，用visudo -c做语法检查的同时，把该用户相关的所有sudo规则全部注释或删除。注意有些用户是通过AD/LDAP组映射获得sudo权限的，这种情况要去域控那边把用户从对应安全组里移除。

服务器密码只是第一层，真正要命的是应用配置文件里的数据库密码、API密钥、第三方服务凭证。运维人员脑子里记着的那些密码，必须全部视为已泄露。你需要立即轮转以下密码：所有数据库账号密码，特别是root和业务账号；消息队列如RabbitMQ、Kafka的认证密码；Redis密码；各类云服务API Access Key和Secret Key；CI/CD工具如Jenkins、GitLab Runner的凭证；监控系统如Zabbix、Prometheus的认证信息。轮转后要通知开发团队更新配置文件，并重启相关服务。这一步通常最耗时，但绝对不能跳过。

离职运维可能留下了大量自动化脚本，有些是定时执行的。用crontab -l -u username查看该用户的定时任务，同时检查/etc/crontab、/etc/cron.d/、/etc/cron.hourly/、/etc/cron.daily/等系统级定时任务目录，看有没有脚本是引用该用户家目录下的文件。systemd timer同样要排查，用systemctl list-timers --all列出所有timer，逐个检查其执行的脚本路径。如果发现有用脚本，不要直接删除，先迁移到公共目录，修改属主为root或其他在职运维，评估其必要性后再决定去留。

如果公司有堡垒机，这是权限回收的第一道关口。立即禁用该用户在堡垒机上的账号，并导出其所有操作日志存档备查。同时检查堡垒机上是否配置了该用户的自动登录规则或SSH隧道。有些运维会在跳板机上配置SSH端口转发，用ssh -L或ssh -R做内网穿透，这些隧道在他离职后可能还在运行。用ps aux | grep ssh | grep username检查跳板机上是否有残留的SSH进程，全部杀掉。

网络设备是另一个重灾区。运维人员通常知道交换机、路由器、防火墙的登录密码，以及SSL VPN的账号密码。这些设备的管理员密码必须轮转，VPN账号立即禁用。如果用的是OpenVPN或WireGuard，直接吊销该用户的证书。防火墙规则中如果有基于IP的信任策略，而该IP是离职人员的固定办公IP或家庭IP，也要一并清理。云平台的安全组规则、网络ACL中如果放行了特定IP，同样需要审查。

在云原生环境里，权限回收的重点从操作系统转移到了云平台IAM。立即禁用或删除该用户在AWS IAM、阿里云RAM、腾讯云CAM中的账号。关键动作是检查并禁用所有Access Key和Secret Key，这些密钥很可能被硬编码在代码仓库里或者配置文件中。用云平台提供的“最后使用时间”功能，查看这些密钥近期是否还在活跃，判断是否有自动化任务依赖它们。同时检查该用户创建的IAM Role和Instance Profile，特别是那些授予了宽泛权限的角色，评估是否需要回收或缩小权限范围。

GitLab、GitHub、Gitee上的仓库权限要立即回收。把离职人员从所有项目组中移除，撤销其Deploy Key和Personal Access Token。这些Token如果泄露，攻击者可以直接推送恶意代码到仓库。CI/CD流水线中如果配置了该用户的凭证用于部署，比如Jenkins里存的SSH私钥、Docker Registry密码，必须全部更换。检查Jenkins的credentials.xml文件或凭据管理界面，找出属于该用户的凭据并删除。

单独把数据库拿出来说，是因为数据库账号管理通常比较混乱。运维人员可能直接给了开发团队root权限，或者创建了多个具有ALL PRIVILEGES的账号。用SQL命令查询所有用户及其权限：MySQL用SELECT user,host FROM mysql.user;然后逐个用SHOW GRANTS FOR 'user'@'host';查看权限。PostgreSQL用\du命令。找出离职人员创建的账号，评估哪些是业务在用、哪些是临时测试账号。测试账号直接删除，业务账号修改密码并通知对应负责人。

-- MySQL查询所有用户及其权限概览
SELECT user, host, 
  Select_priv, Insert_priv, Update_priv, Delete_priv, 
  Create_priv, Drop_priv, Grant_priv 
FROM mysql.user 
WHERE user NOT IN ('mysql.session','mysql.sys','root');

权限回收完成后，要做一次彻底的操作审计。导出离职人员近30天的所有操作日志，包括SSH登录记录、命令历史、堡垒机录像、云平台操作审计日志。重点看他有没有执行过异常的数据导出、批量下载、权限变更操作。命令历史文件.bash_history容易被删除或篡改，更可靠的是审计日志系统如auditd的记录。如果公司没有部署审计系统，这次事件本身就是推动部署的最佳理由。

每次处理离职都是手忙脚乱，说明流程有问题。你需要把上述步骤固化为标准操作流程文档，最好做成自动化脚本。脚本的思路是：输入用户名，自动在所有服务器上执行账号冻结、进程查杀、SSH Key清理、定时任务备份迁移，然后生成一份回收报告。这份SOP要放在团队知识库里，确保任何一个运维人员都能按步骤执行，不会因为某个核心运维离职导致流程断档。

说到底，密码和权限混乱的根源是管理方式落后。如果团队还在用Excel或者脑子记密码，这种风险会反复出现。强制使用密码管理器，比如HashiCorp Vault或者1Password的团队版，所有生产密码、API密钥、证书都存进去，按项目分库分权限。运维人员日常操作通过Vault动态获取临时凭证，离职时只需在Vault里禁用账号，所有密码自动失效。这比事后挨个改密码高效得多，也是行业最佳实践。

不要等到离职才想起权限回收。每季度做一次全量权限审计，检查所有服务器上的账号、SSH Key、sudo权限、数据库账号、云平台IAM用户，找出长期未登录的幽灵账号和权限过大的账号。很多安全合规认证如ISO27001、等保都要求定期权限审计。把审计变成自动化任务，用脚本生成报告，发现异常自动告警。这样即使有人偷偷留了后门，也能在定期审计中被发现。

服务器密码与权限回收不是技术难题，而是执行力和细致程度的问题。真正危险的不是你知道的密码，而是你不知道的、散落在各个角落的信任关系。每次处理离职，都要假设该人员拥有比你想象中更多的权限，然后像入侵检测一样去排查所有可能的入口。做完上述所有步骤后，再问自己一句：如果这个人现在想登录系统，他还有没有办法？如果答案是“不确定”，那就继续排查，直到你能肯定地说“没有任何办法”为止。