权限校验如何完善加固

本文目录导读：

1. 认证（Authentication）加固：确认“你是谁”
2. 授权（Authorization）加固：确认“你能做什么”
3. 实现与编码层面的加固
4. 审计与监控（不可抵赖与快速发现）
5. 生命周期管理
6. 一个完善的权限校验加固清单

权限校验（Authentication & Authorization）是系统安全的第一道防线，要“完善加固”权限校验，不能只停留在“验证用户名密码”或“简单角色判断”层面，需要从传输、存储、验证逻辑、访问控制模型、审计等全链路进行加固。

以下是针对不同层面的完善加固方案：

认证（Authentication）加固：确认“你是谁”

这是权限校验的第一步,验证用户身份的真伪。

1. 强化密码策略

   • 复杂度：强制要求大小写字母、数字、特殊字符，长度至少8-16位。
   • 历史/过期：禁止使用最近N次使用过的密码，建议90-180天强制更换。
   • 防暴力破解：
     • 锁定策略：连续输入错误N次（如5次），锁定账号15-30分钟。
     • CAPTCHA：增加图形验证码或行为验证码（如滑块、点选）。
     • 延迟：每次登录失败后，增加递增的响应延迟（如0.1s、0.5s、1s）。

2. 多因素认证（MFA）

   • 场景：敏感操作（支付、修改关键配置、重置密码）必须启用MFA。
   • 方式：TOTP（Google/Microsoft Authenticator）、SMS验证码、硬件密钥（YubiKey）、生物识别。

3. 凭证存储安全

   • 散列算法：绝不可明文或MD5存储密码，必须使用加盐的强哈希算法，如 bcrypt、scrypt、Argon2。
   • 会话管理：
     • 使用随机、不可预测的Session ID或JWT（JSON Web Token）。
     • 设置合理的过期时间（Access Token短时效，如15分钟；Refresh Token长时效，如7天）。
     • 防Session Fixation：登录成功后，必须重置/重新生成Session ID。
     • 提供“设备管理”或“退出所有登陆”功能。

4. 传输安全

   • 全站HTTPS：任何涉及凭证传输（登录、注册、重置密码）的页面必须使用TLS 1.2+，禁止HTTP页面存在登录框。
   • 敏感字段加密：传输密码等敏感字段时，可额外使用前端公钥加密（如RSA），后端私钥解密，防止中间人攻击。

授权（Authorization）加固：确认“你能做什么”

这是权限校验的第二道门,决定已验证用户能操作哪些资源。

1. 采用更细粒度的模型

   • RBAC（基于角色的访问控制）：基础但需要完善，角色不应直接与用户绑定，应通过“用户 -> 组/角色 -> 权限”的层级管理。
   • ABAC（基于属性的访问控制）：更现代、更动态，不只看“角色”，还看“用户属性（部门、职级）”、“资源属性（文档密级、所有者）”、“环境属性（IP、时间、设备）”。
     • 示例：只有当用户.部门 == 财务部 AND 文档.密级 <= 机密 AND 当前时间 == 工作时间 AND 访问来源IP == 公司内网IP，才允许查看财务报表。
   • ReBAC（基于关系的访问控制）：适用于社交网络、分享型系统（如Google Drive、飞书），权限取决于资源与用户之间的关系（如“文档的访问者”、“文件夹的成员”）。

2. 前后端双重校验

   • 铁律：后端是最终防线，前端只能作为体验优化。
   • 前端：隐藏无权限的按钮、菜单，提示用户不可操作（如按钮置灰、显示404/403提示）。
   • 后端：所有API接口，每一次请求都需要独立校验当前用户是否有权限执行该操作或访问该资源。

3. 权限校验的全链路覆盖

   • API层（控制器）：在业务逻辑执行前进行权限检查。@PreAuthorize("hasRole('ADMIN')")。
   • 服务层（业务逻辑）：处理复杂权限判断，用户只能修改自己创建的订单（Ownership Check）。
   • 数据层（ORM/DAO）：通过数据权限过滤（Data Permission Filtering）避免返回未授权数据，SQL查询自动加上 WHERE owner_id = current_user_id 或 WHERE dept_id IN (user.dept_ids)。不要只依赖前端或服务层过滤。

4. 最小权限原则（PoLP）

   • 默认拒绝：访问控制策略的默认行为应为“拒绝”，只有明确授权的才放行。
   • 最小化：用户、服务账户、API Key只授予完成其任务所需的最小权限，阅读者不能有编辑权限；备份服务账户只需要读取权限，不需要写入或DDL权限。
   • 临时权限：对于高风险操作，提供“Just-In-Time (JIT)”或“临时提升权限”机制（如：申请后台1小时管理员权限，需要上级审批且自动过期）。

实现与编码层面的加固

1. 防越权漏洞

   • 水平越权：用户A试图操作用户B的同级资源（如访问别人的订单）。
     • 加固：每次API请求必须校验资源所有者是否是当前用户。updateOrder(orderId, userId) -> 后端必须验证 order.userId == session.userId。
   • 垂直越权：普通用户试图执行管理员操作（如调用管理API）。
     • 加固：严格执行RBAC/ABAC检查，使用@Secured或@PreAuthorize等注解层层守卫。

2. API与微服务间通信

   • 服务间认证：微服务调用之间不能直接暴露内部API，使用mTLS（双向TLS）、JWT Token、API Gateway鉴权。
   • 接口级别：每个内部API也需要明确权限声明（只允许“订单服务”调用“用户服务”的某个特定接口）。

审计与监控（不可抵赖与快速发现）

1. 全面日志记录

   • 记录所有权限校验的成功与失败事件（登录成功/失败、越权尝试、权限变更、敏感操作）。
   • 日志必须包含：谁（用户ID）、什么时间（时间戳）、从哪里（IP、User-Agent）、做了什么（API、参数、操作类型）、结果（成功/拒绝/错误代码）。
   • 防篡改：将日志写入独立的、只追加的日志服务器或安全日志服务（如使用WORM存储方案）。

2. 实时监控与告警

   • 设置阈值告警：单个IP/Session在短时间内连续触发403/401错误次数超过阈值，自动封禁或通知安全团队。
   • 发现可疑模式：如凌晨批量下载、异常地理位置登录等。

生命周期管理

1. 账号/权限生命周期
   • 入职/出职流程：员工入职自动分配最小权限，离职或转岗时，必须自动或手动（经审批）立即回收权限。
   • 定期审查：每季度/半年审查一次所有用户、角色和权限映射，清理僵尸账号、过时角色和多余权限。

一个完善的权限校验加固清单

一句话总结：不要相信任何来自客户端的输入或声明，后端必须是每一次请求的唯一且最终的权限仲裁者，在此基础上，通过 RBAC + ABAC + 数据权限过滤 + MFA + 最小权限 的组合拳，才能实现比较完善的权限校验加固。