为什么“本来就很清楚”的东西比项目本身还要贵
在工期压力下，安全项目的第一个牺牲品往往是设计阶段。这种逻辑看似合理：防护措施已选定，厂商已确定，工程师经验丰富——何必再花一个月时间写文档呢？然而代价随后才显现，并以其他形式体现出来：采购了错误的许可证，防火墙未能部署到网络中断点，因为实际流量拓扑与预期不符；迁移过程需要停机，却从未经过任何相关方确认；验收时才发现根本无法验证合规性——因为根本没有可衡量的具体要求。
HLD 和 LLD 解决同一个任务： 在付款之前将意图转化为可验证的方案这不是官僚主义，而是一种在错误仅需修改文档而非推迟发布阶段就能被发现的方法。
HLD 和 LLD 之间的界限
文档之间的混淆导致HLD膨胀成配置，而LLD则沦为一堆图片。区分依据只有一个特征： HLD 回答“是什么和为什么”，LLD 回答“具体怎么做”.
| Aspect | HLD（高层设计） | LLD（低级设计） |
|---|---|---|
| 问题 | 哪种架构能够应对威胁和需求 | 它是如何组装和配置的 |
| 读者 | CISO、架构师、采购、监管机构 | 实施与运维工程师 |
| 网络层 | 段、信任区域以及它们之间的流量 | VLAN、地址分配、路由、过滤规则 |
| 防护用品 | 资金类别及选择依据 | 型号、版本、许可证、接线图 |
| 容错能力 | 所需模式和允许停机时间 | 集群、同步、切换顺序 |
| 使用权 | 角色模型和权限划分原则 | 组、策略、具体权限 |
| 结果 | 经协调的架构和采购规范 | 用于组装和重现系统的文档 |
实际后果：仅凭HLD无法实施，仅凭LLD无法讨论架构。试图只用一份文档，要么导致无法执行的构想，要么产生缺乏依据的配置。
HLD 中应包含什么内容
- 系统边界和保护对象。 具体要保护什么：信息系统、网段、数据及其类别。缺少这一点，就无法评估防护措施是否充分。起点是资产盘点；对于关键信息基础设施（КИИ），这是强制要求，并已在文中单独说明。 关于盘点.
- 威胁和攻击者模型。 不是照搬方法论中的正式描述，而是针对您的具体环境：哪些场景是现实存在的，哪些措施可覆盖这些场景，哪些风险是经过深思熟虑后主动接受的。
- 要求。 规范性要求（FSTEC、ФСБ、行业）、合同性要求和内部要求——均已汇总成清单，其中每项要求均有对应的解决方案予以满足。这也将成为验收测试计划的基础。
- 建筑。 区域、流线、控制点、防护设备安装位置、管理与监控方案。
- 选择设备类别的依据。 为何选择应用层防火墙而非入侵检测系统；为何选用此类别的密码保护手段。对于经认证的解决方案，需明确要求的保护等级及有效的认证证书。
- 非功能性需求。 带宽、延迟、会话数量、事件存储深度、可用性模式。最常见的实施失败根源就是缺少这些要素。
- 规格。 包含许可证、支持服务和期限的采购清单。此处的错误会在几个月后才暴露出来，届时再追加采购为时已晚。
LLD 中应包含什么
- 接线图 每个设备：通过中断、镜像、代理的方式——并注明接口、地址和端口。
- 地址规划和过滤规则 以适合直接迁移到配置中的形式，而非以意图描述的形式。
- 配置和策略： 检查配置文件、关联规则、访问策略、与目录和监控系统的集成。
- 部署和迁移顺序： 步骤顺序、工作窗口、每个步骤的服务状态、进入下一步的判定标准。
- 回滚计划。 切换后服务不可用该怎么办？缺少此部分是实施过程中大多数夜间事故的原因。
- 试验环境和方法： 可验证的需求、步骤、预期结果。依据它来验收工作，监管机构后续也会据此进行检查。
- 运行程序： 更新、配置备份、故障应对措施、厂商支持联系方式。
典型失败及其根源
| 实施过程中发生了什么 | 项目中缺少了什么 |
|---|---|
| 防护措施无法承受高峰时段的负载 | HLD 中的非功能性需求和性能计算 |
| 已购买的许可证数量不足以覆盖实际节点数 | 与库存核对后的规格 |
| 实施导致了计划外的停机时间 | LLD 中的迁移顺序和协调工作窗口 |
| 系统已组装完毕，但无法接收 | 可测量形式的要求和试验计划 |
| 工具能正常工作，但事件没有发送到任何地方 | 监控集成方案和事件格式 |
| 承包商离开后，系统无法维护 | 操作规程和可重现的配置 |
| 监管机构要求提供措施依据，但没有依据 | “威胁 → 要求 → 措施 → 证据”链条 |
项目作为采购和验收的基础
HLD 和 LLD 不仅是工程文档，它们还解决了两个商业任务。
采购。 HLD 规格书能够从实质内容而非最终总价来比较各家方案：可清晰了解供货范围、所需许可证以及一年后需要追加采购的内容。我们所提供的经过认证的防护产品和密码设备均属于该解决方案的一部分。 网络安全设备供货加密保护工具（СКЗИ）的转让需要联邦安全局（ФСБ）的许可证——RESTART公司拥有该许可证（更多细节).
验收。 源于需求清单的测试计划将验收从争论转变为程序化流程：每项需求要么已验证，要么明确推迟。这也是后续监管机构检查的基础——证据已提前收集，而非事后补录。
接下来项目进入实施阶段—— «实施网络安全保护措施»，而网络部分则在 网络安全与边界防护.
当项目根据规范要求为强制性时
- 重要的 CII 对象。 根据第187号联邦法，重要设施安全系统的创建包括设计并论证相关措施，以及后续的验收——参见 「KII/187-FZ 的保护」.
- 个人信息系统。 保护措施的选择依赖于特定的保护级别和威胁模型；若无相关文件，则无法构建措施的依据—— 《152-FZ号联邦法与个人数据》.
- 国家信息系统。 防护等级和措施组成在设计阶段确定—— «GIS保护».
- 联邦技术出口管制局许可证相关工作。 防护设备设计属于许可经营的活动；RESTART 的许可业务已在决议中说明 «监管合规与信息系统保护».
HLD 和 LLD 质量检查清单
HLD
- 已列出保护对象和系统边界，并与库存清单进行了核对。
- 每个要求都对应一项措施，每项措施都有其依据。
- 存在带有数字而非形容词的非功能性需求。
- 已指明认证产品的所需等级，并已核实有效证书的存在。
- 规范涵盖了许可证、支持和期限；已与实际节点数和用户数核对一致。
- 已接受的风险已明确列出并由相关人员签署。
LLD
- 根据该文档，外部工程师无需进一步询问即可组装系统。
- 指明了每种设备的接口、地址、端口和接线图。
- 迁移流程分为若干步骤，每个步骤均包含过渡标准和回滚计划。
- 有一项试验计划，覆盖了HLD中的要求清单。
- 描述了事件的走向以及系统交付后的维护方式。
- 配置以可重现的形式存储，而不仅仅存在于植入者的记忆中。
常见问题
LLD 是什么？
LLD（Low-Level Design，低级别设计）是详细的技术设计方案，包括具体的组件、版本、地址分配、过滤规则、集成方式和访问策略。依据LLD可以构建、配置、验收并复现系统。
HLD 是什么？
HLD（High-Level Design，高层设计）是保护架构的高层设计方案：包括信任区域与分段、防护措施类别及其选型依据、数据流、容错性要求以及访问的角色模型。它在采购和实施前对架构进行协调确认。
HLD 与 LLD 有何区别？
HLD 回答“是什么以及为什么”的问题：哪种架构能够应对威胁和需求。LLD 回答“具体如何实现”：具体如何组装和配置。仅凭 HLD 无法实施，而仅凭 LLD 则无法讨论架构。
谁会阅读HLD和LLD？
HLD 由 CISO、架构师、采购人员和监管机构阅读。LLD 由实施和运维工程师阅读。
每个文档的输出结果是什么？
HLD 的成果是经协商一致的架构和采购规范。LLD 的成果是可用于构建和复现系统的文档。
RESTART 如何根据客户任务进行页面设计 网络安全系统的HLD和LLD设计.
RESTART 是如何做到的
我们的设计阶段是一个独立的解决方案 网络安全系统设计 / HLD 和 LLD. 工作逻辑：检查和 全面的信息系统审计 → 威胁模型和需求清单 → 高阶设计（HLD）及论证与规格说明 → 低阶设计（LLD）含配置、迁移和测试方案 → 实施 以及按照相同的程序进行验收。
具体产品的选择基于 合作伙伴和供应商生态系统，而复杂解决方案则在试验台上进行验证。 网络安全实验室 在采购之前，而不是之后。
需要对具体回路进行分析—— 写信给我们.
让我们讨论一下您的环境
描述任务、当前系统、约束和预期结果。我们将提供实用的第一步：诊断、试点、审计、路线图或项目团队。
