Linux 服务器权限隔离的最佳技术方案实践案例

Linux服务器权限隔离需分层设防：以UID/GID为基础身份隔离，ACL或User Namespace细化控制，必要时叠加chroot/cgroup限制资源；典型场景包括双账号物理隔离、租户目录ACL隔离、User Namespace容器化隔离及sudo精细化授权。

Linux服务器权限隔离没有“唯一最佳方案”，只有适配场景的合理组合。核心思路是分层设防：用UID/GID做基础身份隔离，ACL或User Namespace细化访问控制，必要时叠加chroot或cgroup限制资源边界。下面几个典型应用案例，覆盖不同安全等级和运维复杂度需求。

双账号物理隔离（金融/电信生产环境）

适用于对责任划分和操作审计要求极高的场景，比如宝兰德BES中间件部署。

• 创建独立账号：useradd -m -d /home/bes bes 和 useradd -m -d /home/app app，确保产品文件与应用运行目录完全分离
• 中间件安装在/home/bes/BES952，仅bes账号可读写；应用包部署在/home/app/myapp，仅app账号可操作
• 关键避坑：chmod 755不能乱用——产品bin目录需保留x权限，但conf目录应设为750并确保app账号无权进入；日志目录建议755但配合setfacl -m u:app:rx只开放读取

ACL租户目录隔离（SaaS多租户共享服务器）

当多个业务团队共用一台服务器、需共享根路径但数据必须互不可见时，ACL比建组更轻量。

• 在/srv/multi-tenant下建tenant-a和tenant-b子目录，父目录设755保证可遍历
• 执行两条命令完成单向授权：setfacl -m u:tenant-a:rwx tenant-a 和 setfacl -m u:tenant-a:--- tenant-b
• 加默认ACL保障新建文件继承：setfacl -d -m u:tenant-a:rwx tenant-a，这样tenant-a在自己目录里touch的文件，自动带对应ACL规则

User Namespace容器化隔离（DevOps自助式环境）

面向开发人员提供可自主管理的容器环境，又不允许其获得宿主机root权限。

• Docker启动时启用用户命名空间映射：docker run --userns-remap=default ...，让容器内UID 0映射到宿主机上非特权UID（如100000）
• Kubernetes中通过Pod securityContext强制指定：runAsUser: 1001 + fsGroup: 2001，避免容器以root运行且挂载卷时属组混乱
• 配合--cap-drop=ALL --cap-add=NET_BIND_SERVICE，只放开绑定端口能力，其他高危系统调用全部禁用

普通用户sudo精细化授权（日常运维提权）

替代直接给root密码，让普通用户只能执行明确允许的管理动作。

• 编辑/etc/sudoers，添加：%ops ALL=(ALL) /usr/sbin/useradd, /usr/bin/passwd [a-zA-Z]*, !/usr/bin/passwd root
• 禁止su切换root：Defaults targetpw + Defaults !authenticate，强制所有sudo命令走密码验证，且不支持su -
• 设置会话超时：export TMOUT=300加入/etc/profile.d/timeout.sh，5分钟无操作自动退出，防止终端长时间无人看管