强制执行关键操作必须经过双人授权，不是靠改几行 sudo 配置就能实现的，核心在于把“谁申请”“谁审批”“谁执行”三者拆开，用日志、脚本和审批通道串起来。它不改变 sudo 本身，而是让 sudo 只响应“已被双签确认”的命令。
明确角色与权限边界
不能让同一个人既提申请又点通过。需提前划分两组用户：
- 申请人组（如 dev-team）：可运行封装脚本提交命令，但无任何 sudo 权限；脚本自动记录申请人、主机、命令原文及 SHA256 哈希值，生成唯一请求 ID（如 REQ-20260617-8A3F）
- 审批人组（如 ops-lead、sec-audit）：不直接接触目标服务器，仅通过独立审批终端或企业微信机器人查看待审请求详情，输入 approve REQ-20260617-8A3F 完成签名
用脚本封装所有高危操作入口
禁用直接 sudo，所有需双审的操作（如 systemctl restart nginx、rm -rf /var/log/*、修改 /etc/hosts）必须走统一入口，例如：
sudo-approve --cmd "systemctl restart nginx" --reason "证书更新后重启"
该脚本会：
- 校验申请人是否在白名单组内
- 生成带时间戳和哈希的请求记录，存入 /var/log/sudo-approval/
- 触发审批通知（如向审批群发消息 + 写入 Redis 待审队列）
- 拒绝立即执行，返回“已提交，等待审批（ID: REQ-…）”
审批通过后动态放行，限时生效
审批人确认后，系统自动在 /etc/sudoers.d/ 下生成一个带过期时间的临时授权文件，例如：
/etc/sudoers.d/req-20260617-8A3F: %ops-lead ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
该文件设置 5 分钟有效期，超时自动清理；同时记录审批人、时间、原始请求 ID 到审计日志；执行完成后立即删除该片段，不留持久权限。
全程留痕并支持回溯核查
每次操作闭环都留下三条可关联的日志：
- 申请人侧：/var/log/sudo-approval/request.log（含命令哈希、申请人、时间）
- 审批侧：/var/log/sudo-approval/approve.log（含审批人、请求 ID、批准时间）
- 执行侧：/var/log/auth.log 中 sudo 成功记录（含匹配的临时 sudoers 条目名）
三者可通过请求 ID 关联，满足审计要求。不复杂但容易忽略。
