acl是linux多租户数据隔离的核心机制，通过为租户单独授权（如setfacl -m u:tenant-a:rwx）、屏蔽反向访问（setfacl -m u:tenant-b:---）及启用默认acl自动继承权限，实现同目录下租户间严格互不可见。
服务器访问控制在多租户环境中，核心是避免“一权通用”，让每个客户只能碰自己那块数据、不能越界——不是靠信任，而是靠机制强制隔离。
用ACL精细化控制文件系统权限
Linux传统UGO（用户/组/其他）权限太粗，一个目录只能设一个属组，无法满足“A客户能进A目录、B客户完全进不去”的需求。ACL（Access Control List）正是为此设计：
- 为每个租户单独授权：比如
setfacl -m u:tenant-a:rwx /data/tenant-a，同时屏蔽反向访问setfacl -m u:tenant-b:--- /data/tenant-a - 启用默认ACL（
setfacl -d），确保该目录下新建的文件/子目录自动继承租户权限，不用每次手动设 - 管理员仍可通过root或指定高权限用户保留全量访问，不影响运维
按租户划分独立运行空间
光管文件不够，进程和服务也得隔开：
- 用Linux cgroups或systemd slice限制CPU、内存等资源配额，防止某租户服务异常拖垮整台服务器
- 不同租户的应用进程运行在各自命名空间（如user namespace）或容器中，PID、网络、挂载点彼此不可见
- Web服务可配合反向代理（如Nginx）按Host头或路径前缀路由到对应租户后端，天然形成访问边界
统一身份+租户上下文鉴权
所有服务入口必须校验“你是谁、属于哪个租户、能做什么”：
- 登录时绑定租户ID（如JWT中携带
tenant_id），后续所有API调用都带这个上下文 - 应用层做租户级数据过滤：查数据库时自动追加
WHERE tenant_id = ?；操作文件时校验路径是否归属当前租户 - 禁止硬编码路径或ID，所有租户标识由认证系统发放并全程透传，杜绝越权访问漏洞
Redis等中间件的租户隔离实践
共享中间件最容易成为隔离盲区，需主动加固：
- 键名强制前缀：如
tenant-a:cache:user:1001，应用层写入和读取都严格遵循，配合监控检查违规键 - Redis 6.0+启用ACL，为每个租户创建独立账号，只允许执行
GET/SET等必要命令，且限制KEY模式（如~tenant-a:*） - 避免使用SELECT切换DB——集群模式不支持，且DB间无权限隔离，纯属伪隔离
