4. 权限管理基础
在测试平台中，权限管理并不是“登录之后顺便加个角色”这么简单。它决定了谁能进入平台、能操作哪些资源、能执行哪些高风险动作，以及当出现越权访问时如何追溯。理解权限管理，需要先厘清三个层次：认证解决“你是谁”，授权解决“你能做什么”，权限模型解决“这种能力如何被组织和分配”。三者层层递进，缺一不可。
一、核心原理：认证、授权与权限模型的关系
认证（Authentication）是身份确认过程。用户输入账号密码、扫码、使用 SSO 单点登录或 API ，系统验证凭证是否有效，并建立会话。认证的结果通常是“当前请求属于哪个用户或服务账号”。
授权（Authorization）发生在认证之后。系统根据已确认的身份，判断该身份是否具备访问某资源或执行某操作的资格。例如，测试工程师可以创建测试用例，但不能删除生产环境配置；访客可以查看报告，但不能触发流水线。授权的结果是“允许”或“拒绝”。
权限模型则是授权的组织方式。它把“用户—角色—资源—操作—条件”这些要素结构化，使权限可以批量分配、继承、审计和回收。常见模型包括 ACL、RBAC 和 ABAC。它们不是互斥关系，实际平台中经常组合使用。
一句话区分：认证回答“你是张三吗”，授权回答“张三能不能删除这条用例”，权限模型回答“张三为什么能或不能，以及这种规则如何被管理”。
二、方法流程：从请求到放行的完整链路
在测试平台中，一次受保护操作的典型流程如下：
- 身份认证：用户通过登录页或 SSO 完成认证，平台颁发会话 Cookie 或 JWT 。
- 请求携带凭证：前端每次请求在 Header 中携带 ，后端网关或中间件解析身份。
- 策略匹配：授权引擎根据请求中的用户、资源、操作和环境属性，匹配已配置的权限策略。
- 决策与执行：匹配结果为 Allow 则放行，Deny 则返回 403，并记录审计日志。
- 审计与复盘：记录“谁在什么时间对什么资源执行了什么操作”，用于安全审计和问题追溯。
以测试平台为例，当用户点击“删除测试用例”时，后端会检查：该用户是否属于“测试管理员”角色？该用例是否属于当前项目？当前环境是否为生产环境？只有全部条件满足，才允许删除。
三、案例场景：测试平台中的权限设计
假设一个测试平台包含以下资源：测试用例、测试计划、执行任务、环境配置、报告、用户管理。不同角色的权限需求差异很大：
| 角色 | 测试用例 | 执行任务 | 环境配置 | 用户管理 |
|---|---|---|---|---|
| 访客 | 只读 | 无 | 无 | 无 |
| 测试工程师 | 增删改查 | 创建/执行 | 只读 | 无 |
| 测试管理员 | 增删改查 | 创建/执行/终止 | 增删改查 | 无 |
| 平台管理员 | 全部 | 全部 | 全部 | 全部 |
这种设计通常采用 RBAC：先定义角色，再把权限绑定到角色，最后把用户分配到角色。当组织架构调整时，只需修改用户与角色的关系，而不需要逐个资源重新授权。
实践建议：测试平台初期可从 RBAC 起步，角色数量控制在 5～8 个以内；当出现“同一角色在不同项目、不同环境、不同时间段权限不同”的需求时，再引入 ABAC 作为补充。
四、误区与复盘：权限管理常见问题
- 把认证当授权：认为“登录成功就能操作一切”，导致越权漏洞。认证只证明身份，授权必须独立判断。
- 角色粒度过粗：所有管理员共用一个“admin”角色，无法区分测试管理员与平台管理员，审计时无法定位责任人。
- 硬编码权限判断：在业务代码中写死
if (user.role == "admin")，导致权限规则分散、难以维护和测试。 - 忽视环境属性：生产环境与测试环境使用同一套权限，容易造成误操作。ABAC 可将“环境”作为策略条件。
- 缺少审计日志：权限变更和敏感操作没有记录，出现问题后无法回溯“谁在何时改了什么”。
# 权限策略配置示例（RBAC + 环境条件）
role: test_engineer
permissions:
- resource: test_case
actions: [create, read, update, delete]
- resource: execution
actions: [create, execute]
condition:
environment: [dev, test] # 不允许在生产环境执行
- resource: environment_config
actions: [read]复盘时，可以用“最小权限原则”检查每个角色：是否真的需要该权限？权限是否可以通过角色继承获得？是否存在长期未使用的权限？定期清理冗余权限，比事后补救更有效。
安全底线：任何涉及生产环境、用户数据、密钥配置的操作，都必须经过独立授权判断，并记录完整审计日志。不要依赖前端隐藏按钮来实现权限控制，后端必须做最终校验。
总结来看，认证、授权和权限模型共同构成测试平台的安全底座。ACL 适合简单直接的资源绑定，RBAC 适合企业级角色管理，ABAC 适合动态、细粒度的策略控制。实际落地时，建议以 RBAC 为主干，按需叠加 ABAC 条件，并始终配合审计日志与最小权限原则，才能在可用性与安全性之间取得平衡。