ACL是多租户系统实现数据隔离与安全共享的核心机制，需依托租户上下文识别、分层策略模型（租户级/资源级/共享策略级）、运行时声明式校验及共享场景专项设计，并与租户建模、审计日志深度耦合。
ACL（访问控制列表）是多租户系统中实现数据隔离与安全共享的核心机制之一。关键不在于“加权限”，而在于设计清晰的租户标识、资源粒度和策略继承关系——租户间默认隔离，跨租户共享需显式授权，且权限变更必须可审计、可追溯。
租户上下文与资源标记：隔离的前提
没有租户上下文，ACL就无从生效。请求进入系统时，必须通过Token、Header或Session明确识别当前租户ID（如 tenant_id: "t-001"），并将其注入整个调用链。所有核心数据表（如订单、用户、配置）都应包含 tenant_id 字段，并在查询时强制作为WHERE条件（推荐通过ORM拦截器或数据库行级安全策略自动注入）。资源本身也需打标：文件、API、配置项等均应携带所属租户信息，避免“裸资源”导致ACL误判。
分层ACL模型：兼顾隔离与共享灵活性
单一扁平ACL难以应对复杂场景，建议采用三层结构：
- 租户级ACL：定义本租户内角色（如admin、editor、viewer）及其对默认资源集合的访问能力（CRUD）；
- 资源级ACL：针对特定敏感资源（如某份财务报表），单独设置可访问的租户ID或用户ID白名单；
- 共享策略ACL：由平台管理员统一配置跨租户共享规则，例如“允许t-001的report-reader角色读取t-002公开数据集”，该策略需绑定有效期与审计开关。
运行时权限校验：轻量、可靠、可观测
ACL校验应嵌入API网关或服务入口处，避免每个业务方法重复判断。推荐使用声明式方式（如Spring Security的@PreAuthorize("hasPermission(#id, 'document', 'READ')")），背后由统一权限引擎解析：谁（subject）→ 在什么上下文（tenant+resource）→ 能否执行什么操作（action）。每次校验结果必须记录日志，包含租户ID、资源ID、操作类型、是否放行、拒绝原因；高危操作（如DELETE跨租户数据）需触发实时告警。
共享场景下的典型实践
真实业务中常见三类共享需求，ACL需针对性支持：
- 只读共享数据集：创建“共享视图”资源，ACL允许目标租户角色拥有READ权限，底层仍走原租户数据表，但查询自动注入源租户ID + 行级过滤；
- 协同编辑文档：文档资源ACL开放给多个租户指定角色，同时引入“协作会话”概念，每次编辑前校验会话有效性与参与者租户归属；
- 第三方应用接入：为外部应用分配独立client_id，并绑定最小租户范围与权限集，其token携带租户上下文，ACL按client_id+tenant_id双因子校验，不依赖用户身份。
ACL不是银弹，它需要与租户建模、资源生命周期、审计日志深度耦合。一次配置错误可能导致越权访问，因此务必在测试环境模拟跨租户请求，并定期执行权限巡检（如扫描“无租户ID字段的表”“ACL为空的敏感资源”）。不复杂但容易忽略。
