1. 权限隔离的核心问题与架构目标
1.1 隔离需求来源
权限隔离的驱动力并非单一业务功能，而是来自三个相互纠缠的源头。架构师必须在设计初期识别这些来源，否则后期难以建立清晰的隔离边界。
| 来源维度 | 典型场景 | 隔离诉求 |
|---|---|---|
| 合规与审计 | GDPR、SOX、金融监管 | 操作可追溯、敏感数据不可跨模块访问 |
| 多租户 | SaaS 平台、企业级 PaaS | 租户间数据与功能严格隔离 |
| 内部安全分层 | 微服务架构、第三方插件 | 最小权限、横向移动防御 |
关键判断：如果需求来源中“合规”占主导，则隔离模型的刚性要高于灵活性；如果“多租户”是核心，则重点在资源隔离而非代码级隔离；若“内部安全”最强，则身份与信任链的设计优先级最高。
1.2 安全原则
权限隔离设计必须遵守以下五个安全原则，它们构成了架构的合法性基础：
- 最小权限（Least Privilege） —— 每个模块只拥有完成任务所需的最小权限集合。
- 纵深防御（Defense in Depth） —— 多道防线，单点突破不导致全系统沦陷。
- 默认拒绝（Default Deny） —— 所有跨模块访问请求未经显式允许即视为拒绝。
- 职责分离（Separation of Duties） —— 敏感操作需要多个模块协同赋予权限。
- 可审计性（Accountability） —— 每一次权限决策都能追溯到请求者、目标、上下文。
实践提示：在架构初期，建议以“默认拒绝 + 最小权限”作为基线，后续再根据性能与体验需求放宽。不要一开始就追求“零信任”完美模型，容易导致设计方案过于理想化而难以落地。
1.3 设计目标
从隔离需求源头和安全原则出发，架构设计的目标需覆盖以下六个维度：
- 精确性：权限规则能精确表达“谁、在哪、对什么资源、执行什么操作”。
- 可扩展性：新增一个模块或租户时，不要求重新设计整个权限模型。
- 低延迟：权限校验不应成为模块间调用路径的瓶颈（通常要求 ≤ 5ms 额外开销）。
- 可迁移性：权限配置能在不同部署环境（本地、云、混合）间一致迁移。
- 可观测性：拒绝请求的日志应能快速协助定位误判或攻击企图。
- 可维护性：权限规则的增删改不需要修改模块核心代码。
1.4 架构权衡基线
上述六个设计目标之间存在固有张力。架构师必须在项目早期建立明确的权衡基线，否则后续迭代将陷入无休止的争吵。
| 权衡对 | 冲突描述 | 推荐基线（90%场景） |
|---|---|---|
| 精确性 ↔ 延迟 | 细粒度权限检查次数越多，延迟越高 | 尽量批量校验，允许 10% 的精度损失换取 50% 延迟优化 |
| 可扩展性 ↔ 精确性 | 完全抽象的模型很难表达高度特定的业务规则 | 采用 RBAC + ABAC 混合模型，硬编码只接受到模块边界 |
| 可观测性 ↔ 延迟 | 每次决策都写日志会增加 I/O 开销 | 拒绝日志必须同步写入；允许日志可以异步采样（1:1000） |
| 可维护性 ↔ 低延迟 | 基于策略引擎的动态规则比硬编码慢 | 核心链路上的规则编译为二进制白名单，非核心链路使用策略引擎 |
架构风险点：如果团队忽略了这些权衡基线，常见的失败场景是：先追求极致精确性导致延迟不可接受，然后仓促引入缓存导致权限过期遗漏，最终造成越权漏洞。建议在架构评审时直接把权衡基线画在墙上，每次决策都对照它。
上图展示了本章的核心逻辑链条：先厘清隔离需求来源（合规、多租户、内部分层），再结合安全原则推导出设计目标，最后通过架构权衡基线收敛为可落地的权限隔离模型。后续所有章节均围绕这一主线展开：如何定义模块边界（第2-5章）、设计信任链路（第6-10章）、选择隔离粒度（第11-15章）、以及验证与演进（第26-30章）。