端口之间的防火墙不是主机边界

网站在 443 上应答，VPN 在 1194 上应答，防火墙恰好放行这两个端口，审查就通过了。这一连串步骤里，没有任何一步追问过 Web 工作进程能读什么、能改写哪些文件。被入侵的工作进程并不需要开放端口，只要它能碰到控制套接字或可写的配置目录。边界在于权限，监听端口只是最容易看见的那部分。

独立的服务名只是标签；独立的身份才是安全属性。

统计工作进程的权限，而不是端口

从运行用户、它的用户组、它的能力以及它的文件系统视图开始。一个恰好属于 VPN 组的服务账户，即使没有任何端口开放，也能读取密钥材料。可写挂载是另一半：上传和缓存应当远离策略文件与机密，而一个不必要共享的可写目录会让整洁的命名功亏一篑。检查真正执行该操作的进程，因为有特权的父进程与无特权的工作进程并不共享同一份权限。

守护进程启动时能读取 VPN 密钥，并不意味着 Web 工作进程需要它。把守护进程的读取与应用被授予的访问分开。

看起来不起眼、授予却更多的套接字

有些端点其实是披着指标数据流外衣的管理 API。VPN 的管理接口可以更改会话、断开客户端并读取状态。容器运行时套接字更宽：访问它就等于控制主机，远远超出 Web 应用的需要。两者都不该出现在普通应用的挂载集合里，而统计监听端口时也看不到它们。

把管理监听器绑定到本地地址是起点，而不是完整限制，因为通往该地址的每一条入口路径仍然重要。只允许预期的来源和接口。

容器共享同一个内核

容器增加了进程、文件系统和网络边界，但它们与主机共享同一个内核。这使得能力选择、主机挂载和守护进程访问成为决定性的：挂载主机机密或授予特权运行时控制，会抹掉容器标签所暗示的边界。独立虚拟机确实提供独立的来宾内核，而管理程序、管理身份、存储和备份仍然共享。要选择那些配置与更新都有明确负责人的边界。

没人维护的复杂方案，比真正被审查的简单方案更糟。

先测拒绝，再测服务

在工作进程的真实上下文中使用经批准的检查，确认它无法修改 VPN 策略、读取不必要的机密或触碰管理接口。以管理员身份成功读取，并不能检验这条拒绝。随后验证网站、一项普通且被允许的 VPN 操作，以及两者在重启时的表现。保留一条不依赖修复 VPN 的恢复路径，让错误始终可恢复。

两种角色仍然共享 CPU、内存、上行带宽和维护事件。即使权限边界干净，这些共享资源也必须写进方案。

记录每个进程能做什么、停止时什么会失效，以及哪条边界仍然共享。端口数量不是这份记录。