本文结构In This Post
一、二选一为何会失败I. Why Either-Or Fails
纯 RBAC 在复杂组织里会产生角色爆炸；纯 ABAC 则容易把策略写成“条件迷宫”。两种极端都让权限模型难以维护。Pure RBAC creates role explosion in complex organizations, while pure ABAC can become a condition maze. Both extremes hurt maintainability.
真正的问题不是“用哪种模型”，而是“在什么层面使用哪种模型”。The real question is not which model to pick, but where to apply each model.
二、分层授权模型II. Layered Authorization Model
基础层：RBAC 定义职责边界Base Layer: RBAC Defines Duties
先用角色描述组织职责和系统边界，保证最小权限可解释。Use roles first to represent organizational duties and system boundaries with explainable least privilege.
上下文层：ABAC 处理动态条件Context Layer: ABAC Handles Dynamics
在角色允许的前提下，使用设备状态、位置、时间窗、风险评分等属性进行实时收敛。Within role allowance, apply attributes like device trust, location, time window, and risk scores for real-time constraint.
三、策略引擎的落地要点III. Policy Engine Implementation
将策略从应用代码中剥离，改为集中管理与版本化发布。每次策略变更都应支持评估、回滚和影响分析。Externalize policy from application code into centralized, versioned management. Every policy change should support simulation, rollback, and impact analysis.
对开发团队来说，策略引擎应提供可读规则语义；对安全团队来说，应提供审批流与证据链。For engineering teams, policy semantics must be readable. For security teams, approvals and evidence trails must be first-class capabilities.
四、审计与持续治理IV. Audit and Continuous Governance
授权不是一次性项目，而是持续治理。每季度应执行角色清理、权限 recertification、异常访问复盘，确保策略与组织现实保持一致。Authorization is not a one-time project but ongoing governance. Quarterly role cleanup, access recertification, and anomaly reviews keep policy aligned with reality.