核心思路是按职责切分权限、用时收紧、行为留痕：禁用万能账号，基于rbac定义最小能力集，敏感操作单独审批，采用临时令牌替代长期高权限账号，并强化mfa、上下文校验、命令级审计与数据加密，定期清理僵尸权限。
核心思路是：不让高权限账号成为“万能钥匙”，把权限拆开、用时收紧、行为留痕。
按职责切分权限，不给“全能账号”
管理员账号不是越全能越好。比如数据库运维人员不需要访问代码仓库，代码审核员也不该有生产环境的服务器 root 权限。要基于具体任务定义最小能力集：
- 用角色基础访问控制（RBAC）建模，如 DBA 只能执行备份、慢查询分析、索引优化，禁止直接 SELECT * FROM user_info；
- 敏感操作（如导出全量客户表、下载源码压缩包）必须单独审批，不预置在任何角色中；
- 避免“admin”“root”类泛化账号长期存在，改用带时效的临时权限令牌（如 AWS IAM Roles for EC2 或 HashiCorp Vault 动态凭据）。
关键操作强制二次验证与上下文校验
即使账号本身有权限，也不能让一次登录就畅通无阻：
- 对高危动作（如执行 mysqldump、git clone --mirror、scp 到外网IP）启用多因素认证（MFA）强校验，且 MFA 必须由独立设备触发，不能仅靠短信或邮箱；
- 加入行为上下文判断：非工作时间、非常用设备、异地 IP、连续多次导出请求——自动冻结操作并通知安全团队；
- 命令级审计日志需记录完整参数（如 mysqldump -u root -p -h 10.1.2.3 customer_db users > /tmp/leak.sql），而不仅是“用户执行了 mysqldump”。
数据本身加锁，权限≠可读明文
权限管的是“能不能访问”，加密管的是“拿到后能不能用”：
- 核心数据库字段（如身份证号、手机号、密钥）启用透明列加密（TDE）或应用层加密，即使 DBA 导出整库，敏感字段仍是密文；
- 代码仓库启用 Git 加密提交（如 git-crypt）或服务端透明加密（如 GitLab 自带的文件级加密策略），防止 clone 后直接看到配置密钥；
- 所有备份介质（NAS、对象存储、磁带）启用 AES-256 全盘加密，密钥由独立 KMS 管理，与服务器账号体系隔离。
定期清理+动态回收，堵住“僵尸权限”漏洞
离职、转岗、项目结束，都是权限失控的高发点：
- 建立账号生命周期自动流程：HR 系统触发离职事件 → 自动禁用账号 + 撤销所有关联权限（包括第三方系统 API Key、跳板机白名单、云平台子账号）；
- 每季度运行权限稽查脚本，识别“90 天未登录但仍有生产数据库写权限”的账号，并自动发起复核工单；
- 对长期高权限账号（如运维主管）实行“权限沙盒”：日常操作走受限子账号，仅在审批后临时提权，且提权会话全程录像。
