首先定义边界
分离普通客户端设备、基础设施服务和管理接口的角色。仅当了解允许的流量时,边界才有用。设计应该从依赖项清单开始:哪个客户端需要哪个服务,哪个服务需要存储,哪个管理员需要管理访问权限。
保持管理深思熟虑
管理接口应该可以通过有意的管理路径访问,而不是在允许客户端流量的地方公开。现有实验室采用远程访问;下一个设计步骤是记录该访问进入的位置、可以到达的内容以及如何在不丢失恢复路径的情况下将其删除。
考虑存储依赖性
TrueNAS 和 ZFS 支持记录的存储环境,Linux 和容器工作负载取决于路径、权限和网络可达性。分段更改需要保留这些依赖性。服务可能看起来正常,但其存储路径或所需的网络连接不可用。
验证允许和拒绝的路径
未来的测试矩阵应包括允许的客户端到服务连接、拒绝的客户端到管理连接、批准的管理连接以及服务到存储检查。记录源区域、目的地、协议、预期结果、观察结果和回滚步骤。这些测试是发布计划,而不是报告的测试结果。
设计恢复路径
记录如何在更改网络边界之前恢复管理访问权限。配置备份、已知的本地访问方法以及带有明确回滚的小更改使设计更容易排除故障。在呈现恢复时间结果之前测量锻炼过程中的恢复情况。
外卖
分段应该使访问和依赖关系更容易解释。图表、访问矩阵和观察到的测试结果将比网络工具列表更清楚地证明这一点。
探索相关项目 →