多个站点放在同一台服务器时，真正容易造成越权的往往不是站点数量，而是身份共用：一个数据库账号能读写所有数据，一个系统用户能修改所有文件。要判断营销站点之间如何隔离数据库与文件权限，先把问题拆成两部分：每个站点能访问哪些数据，以及运行进程能读写哪些目录。两边都设边界，才不至于一处配置失误就影响全部站点。
先选对隔离层级：数据库分开，账号也分开
“独立数据库”并不自动代表权限隔离。若多个站点仍共用一个拥有全部权限的账号，只要某个站点的连接凭据泄露，其他库仍可能暴露。更清晰的做法是每个站点拥有独立数据库和专属数据库角色（或用户），凭据只授予该站点所需的读写权限。
以 PostgreSQL 为例，可为不同站点分别创建数据库和角色，并仅允许对应角色连接、操作自己的数据库。MySQL 也可按站点创建独立数据库及受限账号。具体授权语法因版本和托管环境而异，但原则一致：不用管理员账号供应用运行，不授予不必要的建库、授权或全局管理权限。
- 独立数据库、独立账号：边界最直观，适合站点由不同团队维护、备份恢复周期不同，或需要降低单站点凭据泄露影响的场景；代价是账号、连接配置和备份对象更多。
- 同一数据库中的独立 schema 或表前缀：资源管理较集中，但授权与迁移更容易相互牵连；适用于隔离要求较低、由同一维护主体管理的站点，必须逐项核对权限。
- 共用高权限账号：配置最省事，却难以审计和限制影响范围，不适合作为多个独立站点的默认方案。
文件边界要落到系统用户和目录权限
数据库隔开了记录，不能保护上传文件、配置文件和缓存目录。较稳妥的基础设计是让每个站点由不同的 Unix 用户运行，并把代码、上传内容、临时文件分别放在边界明确的目录中。站点甲的运行用户不应拥有站点乙目录的写权限；若服务必须读取共享资源，应只开放指定目录的只读访问。
Linux 文件权限中的 750、640 等数字只是起点，实际是否可访问，还要看文件所有者、所属组、目录逐级执行权限和访问控制列表（ACL）。例如，目录设为仅所有者可读写执行，可限制其他用户进入；配置文件则应避免对所有本机用户开放读取。不要把整个站点树设成全员可写，也不要仅靠隐藏目录名来防护。
按顺序实施，并在上线前验证
- 盘点身份：列出每个站点的运行用户、数据库账号、数据目录、上传目录、配置文件和备份任务；标记任何跨站共用的凭据或可写目录。
- 拆分数据库权限：为各站点建立独立数据库及专属角色，替换应用配置中的共享账号。只授予运行所需权限，并确认应用无需数据库管理权限也能完成日常操作。
- 拆分文件所有权：让站点文件归对应运行用户或受控部署用户所有。代码目录通常应限制写入，确有上传或生成需求的目录再单独授予写权限；部署账号与运行账号不必合并。
- 清理秘密与备份：数据库密码放在访问受限的配置位置，不写入公开代码目录。备份文件应限制读取者，避免把多个站点的备份集中放进所有运行用户都能访问的目录。
- 做反向验证：分别以站点运行身份检查：甲能否读取乙的配置、修改乙的上传文件、连接乙的数据库；理想结果是未授权访问失败。再确认部署、定时任务和备份流程仍能完成。
迁移时别只检查“新权限是否生效”
已运行的站点往往遗留旧账号、宽松文件权限或共享备份目录。迁移前先备份并记录现有授权；切换后核对应用日志、上传功能、定时任务和恢复流程。若某个站点确实要共享素材或数据，应通过明确的只读目录、受限数据库授权或受控导出流程实现，不要因此重新开放整棵目录或整个数据库。
简言之，回答营销站点之间如何隔离数据库与文件权限，关键不是单独创建几个数据库，而是让数据库角色、系统用户、文件目录和备份访问一一对应，并用跨站访问测试验证边界。这样即使某个站点的应用凭据或文件权限出现问题，也更容易把影响限制在单站点范围内。
常见问题
每个站点一定要用独立数据库服务器吗？
不一定。同一数据库服务器上建立独立数据库和受限账号，通常已能形成清晰的逻辑边界；若要求更强的资源、管理或故障隔离，再评估是否拆分服务器。
多个站点可以共用同一个系统用户吗？
技术上可以，但文件权限难以按站点划分。需要限制互相读写时，优先为站点分配不同运行用户，并检查目录和所属组权限。
使用 ACL 后还需要传统文件权限吗？
需要。ACL 是补充访问控制方式，仍应检查所有者、所属组、基础权限及目录路径权限，避免 ACL 规则与基础权限组合后产生意外结果。
完成配置后怎样判断隔离有效？
用各站点实际运行身份分别尝试访问其他站点的数据库、配置和上传目录；未授权操作应被拒绝，同时检查应用自身功能和备份恢复流程正常。
