决定哪些内容属于公开侧。

1。描述人员和任务。

对于每项服务，完成这句话：“担任此角色的人需要从这种设备执行此操作。”阅读公共时间表、编辑内部程序和维护数据库是不同的任务。不要仅仅因为一名志愿者偶尔需要远程访问就把服务设为公开。

将网络访问与应用授权分开。访问登录页面并不等于有权阅读成员文件。反过来，将服务隐藏在专用网络后面并不能决定哪些成员可以编辑或导出其内容。记录这两层以及当某人离开时移除访问权限的流程。

将账户恢复保留在同一讨论中。一个只有一个人能解锁的私有服务会造成另一种故障，即使其初始访问规则看起来限制严格。

2。填写一个小的访问矩阵。

这里有一个假设的社区工作坊设置。这些选择是供讨论的示例，而不是现成的网络设计。

在每一行旁边写下实际机制：应用程序账户、经批准的私有访问方法或其他有记录的控制措施。没有机制和测试的“私有”只是一个标签。

3。检查登录页面周围的路径。

列出反向代理、应用程序监听器、数据库端口和管理工具。应用程序可以有一个精心配置的登录屏幕，而另一个接口仍然可以访问。在更改已部署的配置之前检查它，并为任何控制远程访问的内容保留恢复路径。

当 Docker 是您部署环境的一部分时，它值得单独检查。未指定主机地址的端口映射通常会在所有主机地址上发布。在文档所述的默认 NAT 情况下，回环绑定会限制访问，但网络模式、直接路由和旧版 Docker 行为都有关联。请阅读文档以了解实际拓扑，然后在您使用的 IPv4 和 IPv6 路径上验证可达性。 Docker 端口发布与映射.

4。检查实际有效的控制，而不是令人安心的标签。

将防火墙与创建网络规则的软件一起检查。Docker 文档指出，已发布的容器流量可能在常规 UFW 输入规则生效之前被改道。因此，UFW 状态看起来干净并不能证明容器端口不可访问。不要为了快速解决问题而禁用 Docker 的防火墙管理；文档描述了这样做会带来的网络后果。 Docker 数据包过滤与防火墙.

单独检查应用程序角色。例如，BookStack 会组合角色能力并允许内容级覆盖，因此用户的实际权限可能与所分配角色的名称不同。审查完整分配，并测试具有代表性的页面和附件。 BookStack 权限规则.

5。将传输和信任纳入计划。

仅限成员访问的服务仍然携带凭据和私有内容。应为实际客户端规划 HTTPS 和证书信任，而不是教成员忽略浏览器警告。在笔记本中保留证书续期责任归属和失败检查，与域名访问放在一起。

Caddy 的文档将公共证书验证与其本地证书颁发机构区分开来。客户端必须信任本地颁发机构，才能无警告地使用其证书。对于公共证书，HTTP 和 TLS-ALPN 验证需要各自相应的入站路径；DNS 验证是单独配置的替代方案。请选择适合预期访问边界的方法。 Caddy 自动 HTTPS 与本地信任.

这是一个访问规划步骤，并非声称仅凭证书就能使应用程序变为私有或获得适当授权。

6。同时测试允许和拒绝的路径。

为已注销访客、普通成员和编辑者使用独立的浏览器会话。检查普通页面、直接本地附件 URL、导出操作和管理路由。在移除账户或更改其角色后重新测试。在尝试操作之前记录预期结果，以免意外成功被误认为是便利。

从您获授权用于测试的网络中，验证公共服务可达且预期的私有接口不可达。测试相关地址族和实际端点，而不仅仅是可能解析结果不同的主机名。记录日期、来源网络和结果。这些检查必须在您的部署环境中执行；此处不声称已完成任何检查。

在已注销状态以及使用未授权成员身份，通过直接 URL 测试机密嵌入图片。BookStack 图片默认是公开的，与本地附件不同；仅限制页面是不够的。请查阅 图片安全 以及 访问指南中的存储与权限区别 后再接受该边界。

7。将失败的边界视为需要重新审视的决定。

如果未授权账户可以读取数据，请停止扩大访问权限，并检查角色继承、共享和直接文件路径。如果私有端口可达，请在通过猜测添加另一层之前审查其绑定和网络规则。如果预期维护者无法连接，请使用文档所述的恢复途径，而不是授予所有人更广泛的访问权限。

将修正后的规则和可重复检查放入 访问笔记本。将其链接到 服务清单 和 恢复演练。这些边界在正确实施时可减少不必要的访问；它们不承诺匿名，也不消除更新和谨慎处理数据的需求。