什么是站点隔离：共享主机账户隔离机制与安全边界

站点隔离（Site Isolation）是指在同一台服务器、同一套操作系统内核之上，把不同租户或不同站点的文件系统、进程、资源配额与网络访问权限相互隔开的一套机制。它要回答的是一个很现实的问题：当几十个网站共用一套系统时，某个账户被入侵、被扫描器拖满 CPU，或者代码里写错一个路径，会不会连带影响同一台机器上的其他网站。判断隔离是否可靠，不看产品说明里列了多少功能，而看边界画在哪一层、绕过去有多难。

定义：站点隔离究竟隔开了什么

在共享主机语境下，站点隔离通常要同时处理四个层面，任何一层缺失都会让边界失效。

• 文件系统：A 账户的进程不能读取 B 账户的站点根目录、配置文件与邮件队列。默认权限 755/644 在多账户机器上几乎等于公开，需要靠运行身份与挂载视图共同限制。
• 进程与可见性：账户只能看到自己的进程树。/proc 默认对全机可见，能列出其他用户的命令行、环境变量甚至内存映射。
• 资源配额：CPU、内存、磁盘 IOPS、并发进程数与 inode 数量都需要独立上限。缺少这一层时，一个死循环脚本就能让整机平均负载失控。
• 网络与出站策略：发信端口与出站连接数要按账户限流，否则被入侵的站点会成为垃圾邮件源，整台服务器的 IP 声誉一起受损。

这四层是叠加关系而非替代关系：文件权限挡住误读，运行身份决定越权成本，资源配额把故障限制在单个账户，网络策略防止单点被滥用成公共出口。

站点隔离的实现方式与安全边界

从技术架构上看，共享主机的隔离方案经历了三代演进，每一代都在补上一代留下的缺口。理解这条演进线，比记住某个产品名更有用，因为绝大多数实际环境都是三代方案混用的结果。

早期做法是让所有 PHP 脚本以 Web 服务进程的同一身份运行，再用 open_basedir 一类的配置限制可访问目录。这种方式的短板很明显：脚本与 Web 服务同权限，一旦某个站点被上传 webshell，攻击者读到的就是 Web 服务身份能够触及的全部内容；open_basedir 只约束 PHP 自身的文件函数，对系统命令、符号链接与临时目录的处理并不完整。更麻烦的是上传目录一旦被设为可写且允许执行，边界就从”隔离”退化成”共用一套权限”。

第二代方案把运行身份拆开。Apache 的 suEXEC 机制让 CGI 程序以站点文件属主的身份执行，PHP-FPM 则以每个站点独立的 pool 运行在不同系统用户下。这一步解决了跨账户读写，却没有解决同账户内的横向移动，也没有解决资源争抢——一个 pool 把 CPU 跑满，其他 pool 照样被拖慢，因为内核并不区分这个进程属于哪个租户。

第三代方案在内核层补齐视图与配额。文件系统层面，为每个账户挂载一份独立的目录视图，用户看到的 /etc、/tmp、/var 都是自己的副本，其他账户的家目录在其命名空间里根本不存在，读取请求返回的是”没有这个文件”而不是”权限不足”。资源层面，按用户限制 CPU 时间、内存、IOPS 与并发入口数，超额时只惩罚超限账户，其他站点不受牵连。这套思路与容器化部署的安全边界同源：都在共享内核的前提下用命名空间与配额画线，区别只在隔离粒度是一个系统用户还是一个容器实例。

配置完成不等于隔离生效，还需要可验证。管理员可以用普通用户身份做三项检查：尝试读取相邻账户的家目录、查看 /proc 下他人进程、在配额之外申请内存。三项都被拒绝，才说明配置真正落地；只在控制面板里勾选过选项，不能作为证据。

应用场景：隔离强度决定故障半径

多站点虚拟主机是最典型的场景。一台机器托管几十个客户站点，客户之间没有任何信任关系，隔离失效意味着一次入侵可以横扫整台服务器，事后只能靠整机重装与全量恢复收场。转售型主机更敏感：代理商把空间再切分给终端用户，一旦下层隔离不严，代理商之间的边界就形同虚设，责任划分也会变成一笔糊涂账。

第二类场景是安全边界要求不一致的混合部署。同一个账户里跑着面向公众的 WordPress（内容管理系统）与内部测试程序，插件漏洞的概率远高于系统本身，隔离能把漏洞的影响面压缩到单个站点目录，也让回滚变得可控。第三类是临时账户与外包开发：临时开放 FTP 与数据库权限，交付完成后如果没有隔离，残留凭据仍可能成为长期后门，而这类凭据恰恰最难盘点。

第四类场景容易被忽略——同一台机器上同时运行多个业务域名，其中一个在做促销活动、流量突增。缺少配额时，突发流量会挤占其他站点的处理能力，表现为”别人的网站变慢”，排查往往从网络绕一大圈才回到资源争抢这个原点。

共享主机隔离、容器隔离与独立服务器的对比

三种托管形态都能提供隔离，差别在于边界画在哪个位置，以及为此付出的成本。把它们放在同一张表里对照，能看清取舍关系。

这张表说明一件事：隔离强度与成本同向增长。账户隔离把成本压到最低，代价是共享内核带来的逃逸面；容器在共享内核之上再加一层命名空间与镜像约束，逃逸难度上升，但攻击者一旦拿到内核漏洞，横向移动的范围依然是整台宿主机。选择哪一种，取决于业务能承受多长的故障半径，而不是谁的隔离”更强”。

常见误区与边界条件

关于站点隔离的误解，多数不是因为概念难，而是因为把某一层的配置当成了整套方案。以下四条在排查中反复出现。

• 把 open_basedir 当成全部隔离：它只作用于 PHP 的文件函数，对 shell 命令、系统调用与运行身份没有任何约束。真正的隔离要求运行身份、挂载视图与配额同时到位，少一层就等于没装。
• 认为隔离可以替代应用层加固：站点隔离限制的是影响范围，不是漏洞是否存在。一个未修补的反序列化漏洞，在自己的账户内依然能读写数据库、窃取凭据、篡改定时任务。
• 忽略隔离自身的性能开销：按用户挂载视图与配额统计都要消耗内核资源，账户数量上千时，进程数与 inode 统计本身会成为瓶颈，账户密度需要按机器规格规划，而不是能开多少开多少。
• 只隔离站点，不隔离备份与日志：备份目录、访问日志与会话文件经常放在共享路径下，权限一旦放宽，隔离层做得再细也会从侧门漏出去。

还有一条边界条件值得记下：隔离策略必须与实际运行方式一致。如果某个站点因为兼容性问题被临时降级到共用身份运行，那么它与相邻站点之间就不存在有效边界，这种情况在应急排障后最容易遗留，也应该出现在交接清单里。

参考资料

• CloudLinux 官方文档：账户级文件系统视图与资源限制的实现说明，包含配置项与限制语义。
• Apache suEXEC 文档：以站点属主身份执行 CGI 程序的机制、启用条件与已知限制。
• Linux namespaces 手册页：mount、pid、net、user 等命名空间的隔离语义与适用范围。

延伸阅读：虚拟主机是什么：定义、特点与应用场景，共享主机与 VPS（虚拟专用服务器）的取舍，以及四种托管方式全面对比。这三篇文档分别覆盖定义、升级决策与横向对照，可以与本篇的隔离层逐一对应。

如果需要在同一台机器上托管多个互不信任的站点，建议在采购前确认服务商是否提供按账户的文件视图隔离与资源配额，并在部署后用普通用户身份做一次越权读取与配额超限测试；只有测试被明确拒绝，隔离才算真正生效。