3、用户认证与授权管理：本地用户管理、角色权限模型、最小权限原则实践
用户认证与授权管理，说白了就是解决两个问题：你是谁，以及你能干什么。在 Commissioner 的日常运维里，这块要是没搞好，后面所有安全策略都是空中楼阁。我见过太多团队把精力花在防火墙规则上，结果一个普通运维账号就能删库跑路——嗯，这真不是段子。
3.1 本地用户管理：别让账号变成后门
Commissioner 默认装好后，会有一个超级管理员账号 admin。我个人习惯，第一件事就是把它改名或者禁用掉。为什么？因为黑客扫描工具第一个试的就是 admin/admin，你想想看，这跟把家门钥匙放在门口地毯下有什么区别？
创建本地用户的步骤其实不复杂，但有几个坑要注意。我直接给一套我常用的操作流程：
- 创建专用服务账号——每个业务模块用独立的系统账号，不要共用。
- 设置强密码策略——长度至少16位，包含大小写、数字、特殊字符。
- 启用SSH密钥认证——密码认证能关就关，密钥比密码安全一个量级。
- 配置登录限制——只允许特定IP段或管理跳板机登录。
- 定期审计账号列表——每季度清理一次僵尸账号。
我曾经在一个客户的系统里发现，他们有个三年前离职员工的账号还在用，而且权限没回收。你猜怎么着？那个账号的密码还是默认的。所以定期审计这事，真不是走形式。
lastlog 和 awk 写个脚本，每月自动拉出超过90天未登录的账号列表，发邮件给安全组。
3.2 角色权限模型：别让每个人都拿着万能钥匙
Commissioner 的权限模型基于 RBAC（基于角色的访问控制）。核心思路很简单：把权限打包成角色，再把角色分配给用户。这样你就不用一个个给用户授权了，管理成本直线下降。
我建议至少划分四个基础角色：
| 角色名称 | 权限范围 | 适用人员 |
|---|---|---|
| 超级管理员 | 全部系统权限，包括用户管理、审计日志、系统配置 | 安全负责人、运维主管 |
| 安全审计员 | 只读权限，可查看所有配置和日志，不可修改 | 合规审计、第三方安全评估 |
| 运维操作员 | 日常运维操作权限，如启停服务、查看告警、执行脚本 | 一线运维工程师 |
| 只读用户 | 仅可查看仪表盘和基础状态信息 | 开发人员、业务方 |
这里有个容易犯的错误：很多人觉得「先给个大权限，后面再收回来」。但实际上一旦权限放出去，就很难收回来了。我建议一开始就按最小权限来，不够再加，而不是反过来。
3.3 最小权限原则实践：给得少，反而更安全
最小权限原则（Principle of Least Privilege, PoLP）听起来高大上，说白了就是：一个人只需要完成工作所需的最小权限，多一个都不要给。
我在实际项目中总结了一套落地方法，分为三步：
- 权限梳理——列出每个角色实际需要的操作清单，逐条确认。
- 权限拆分——把大权限拆成细粒度的小权限。比如「管理所有用户」拆成「创建用户」「禁用用户」「修改用户角色」。
- 权限回收——设置权限有效期，临时任务完成后自动回收。
举个例子。有一次我们做安全加固，发现一个运维脚本居然有 root 权限。查了半天，原来是三年前为了部署一个服务临时给的，后来忘了收。这就是典型的权限膨胀。后来我们改成了用 sudo 配合命令白名单，只允许执行那一个脚本，其他命令一律拒绝。
/api/v1/config 只允许超级管理员访问，/api/v1/status 允许所有角色访问。
下面这张图展示了 Commissioner 用户认证与授权管理的整体逻辑，我画出来方便你理解：
3.4 避坑指南：我踩过的那些坑
做安全配置这么多年，有些坑我是一路踩过来的。分享几个典型的，你遇到了能少走弯路：
- 权限回收不及时——我曾经有个项目，临时给外包团队开了高权限做数据迁移，结果项目结束三个月后才发现权限没关。从那以后，我所有临时权限都设了 TTL（生存时间），到期自动失效。
- 角色定义太粗——一开始只分了「管理员」和「普通用户」两个角色，结果普通用户要执行运维操作还得临时提权，流程繁琐不说，还容易出错。后来我改成细粒度角色，每个角色只包含必要的权限。
- 忽略审计日志——权限配得再好，没有审计日志等于白搭。因为你根本不知道谁在什么时候做了什么。Commissioner 的审计日志一定要开启，并且定期归档到外部存储。
- 密码策略形同虚设——有些团队设了密码复杂度，但允许用户把密码写在便签纸上贴在显示器上。技术手段再强，也防不住人的惰性。所以除了技术控制，还要有安全意识培训。