什么是HLD
HLD 代表 High-Level Design，即一个高级项目。在网络安全中，这是一份架构文档，解释了目标信息保护系统应该如何构建：我们保护什么画像、信任边界在哪里、需要什么级别的网络安全、如何划分区域、哪些数据流至关重要以及如何将解决方案构建到现有 IT 环境中。
HLD不应该变成抽象的图画。其目标是在采购和实施开始之前，让 CIO、CISO、架构师、系统所有者、采购和运营人员对未来路径达成共识。在这个层面上，原则、依赖、限制、目标方案和解决方案都是固定的，不能在配置阶段不知不觉地改变。
HLD在企业架构中的地位
在企业环境中，HLD位于网络安全策略和详细技术设计之间。它链接业务流程、监管要求、威胁模型、IT 架构、网络分段、IAM/PAM、SOC/SIEM、DevSecOps、ERP、DWH、云、分支机构、远程访问和操作流程。
对于大公司来说，HLD 作为架构合同很有用：它显示了哪些系统包含在范围内、涵盖了哪些风险、哪些解决方案必须兼容、需要哪些集成、哪些地方需要试点以及哪些更改将影响用户。此类文档有助于避免出现以下情况：购买了网络安全系统，但无法协同工作、无法在 SIEM 中生成必要的事件、破坏业务流程或未通过运营验收。
| 企业层 | HLD记录什么？ |
|---|---|
| 商业与监管 | 关键流程、适用要求、ISPD、CII、GIS、个人数据、商业秘密、审计和检查要求。 |
| IT 格局 | 系统、环路、网络、分支、云、集成、访问通道、数据交换点和基础设施依赖性。 |
| 网络安全架构 | 安全区域、安全信息类、访问模型、日志记录、监控、响应、加密、端点、Web/API 和数据保护。 |
| 运营 | 角色、变更流程、监控要求、SLA/OLA、维护、冗余、更新和性能监控。 |
什么是LLD
LLD 代表 Low-Level Design，即底层设计或详细技术设计。如果 HLD 回答“环境应如何布置”的问题，那么 LLD 则回答“具体如何组装、配置、连接和接受”的问题。
LLD 包括特定组件、版本、网络接口、寻址、互连规则、与目录集成、SIEM、ITSM、PAM、扫描仪、EDR/XDR、WAF、DLP、CIPF、访问策略、日志和备份。对于实施团队来说，LLD 成为操作指南（未来的文档）和验收指南（检查解决方案是否与架构真正匹配的基础）。
LLD在企业架构中的地位
LLD更贴近实施和产业运营。它将架构决策转化为配置、规则、参数、清单、迁移步骤和验收标准。在企业环境中，这一点尤其重要，因为一种设置可能会影响网络、域结构、业务应用程序、监控、帮助台和监管报告。
好的 LLD 不只是产品设置列表。它描述了解决方案如何存在于真实的操作模型中：谁管理策略，谁接收事件，如何处理异常，如何更新规则，日志存储在哪里，如何执行回滚，什么被认为是成功接受，以及哪些指标表明保护正在发挥作用。
| 实用层 | LLD 记录什么？ |
|---|---|
| 成分 | 服务器、代理、传感器、网关、策略、版本、角色、帐户、证书和依赖项。 |
| 网络和集成 | IP/FQDN、端口、路由、防火墙规则、API、系统日志、Webhooks、队列、与 AD/LDAP、SIEM、ITSM 和存储的连接。 |
| 网络安全设置 | 访问策略、例外、扫描配置文件、用例、关联规则、日志记录级别、保留和响应规则。 |
| 验收及运行 | 分步实施计划、测试、负面场景、回滚、操作手册、管理员说明和转移到支持的标准。 |
HLD 和 LLD：比较
HLD 和LLD 不相互竞争。这是一种设计的两个级别：需要 HLD 来协调目标架构和管理决策，需要 LLD 来在基础设施中安全且可验证地实施它们。
| 标准 | HLD / High-Level Design | LLD / Low-Level Design |
|---|---|---|
| 主要问题 | 目标安全架构应该如何设计？ | 具体如何实现、配置并接受？ |
| 观众 | CIO、CISO、企业架构师、系统所有者、采购、项目办公室。 | 实施工程师、管理员、运营、SOC、DevOps/DevSecOps、测试。 |
| 详细程度 | 画像、区域、解决方案类、原则、流程、依赖性和约束。 | 组件、参数、地址、规则、策略、集成、测试和运行手册。 |
| 无文件风险 | 他们买错了东西，没有考虑依赖性，最终导致架构冲突和昂贵的返工。 | 我们在不同的团队中以不同的方式实施它，失去了设置，并且无法做出和支持决定。 |
| 结果 | 一致的目标架构和项目框架。 | 实施和操作的工作技术设计。 |
什么时候真正需要 HLD/LLD？
当项目影响多个系统、团队和需求时，HLD 和 LLD 尤为重要：网络安全系统的实施、边界现代化、ISPDn、CII 或 GIS 保护、SOC/SIEM/SOAR、PAM/IDM、DLP、WAF、EDR/XDR、CIPF、DevSecOps、API 保护、AI 环境、分支网络或关键集成。
如果项目较小，您可以从轻量级 HLD 和简短的 LLD 开始。如果循环是受监管的、关键的或分布式的，设计节省几乎总是在返工中得到回报：策略冲突、不完整的 SIEM 事件、访问错误、不可接受的异常、手动解决方法以及 IT、安全和承包商之间的争议。
RESTART如何进行设计
范围和审查
我们修复业务任务、监管机构、环境边界、系统、网络、角色、数据、当前网络安全系统、限制和操作痛点。
HLD架构
我们描述目标保护模型、区域、解决方案类别、流程、集成、基础设施要求、风险和架构解决方案的选项。
LLD 详细说明
我们准备设置、交互方案、访问矩阵、规则、日志要求、测试场景、实施计划和回滚。
接待及接送
我们就准备标准达成一致，与 IT/IS/运营部门进行审查，准备运行手册、实施积压工作和开发建议。
交付成果
- HLD 文档，包含目标架构、区域、流程、网络安全类别、依赖关系和架构解决方案；
- LLD 文档，包含组件、设置、集成、网络规则、访问矩阵、日志记录和测试；
- 架构图：画像、分段、数据流、管理渠道、SIEM/SOC 中的事件、与 IAM/PAM/ITSM 的集成；
- 需求矩阵：法规、威胁模型、业务风险、操作要求和验收标准；
- 实施路线图：阶段、依赖关系、试点、回滚、迁移、培训、转移到维护和开发积压。
实施和运营链接
仅当设计可用于实现和维护系统时才有意义。因此，RESTART将HLD/LLD与供应商选择、试点、采购、实施、策略配置、与SIEM/SOC集成、管理员培训和调试连接起来。
设计完成后，团队可以继续实施信息保护系统、提供许可证、配置、测试、制定法规、试运行和支持。如果客户已经拥有部分解决方案，HLD/LLD 有助于不必重新购买整个堆栈，而是在现有架构中构建新的安全措施。
对于端点项目，HLD/LLD 捕获设备组、EPP/EDR/XDR 策略、异常、与 SIEM/SOAR、PAM/IDM 和 ITSM 的集成，然后传输到 端点安全的实施.
实验室 HLD/LLD 测试
最好在最终 LLD 之前检查一些架构决策：WAF 规则、SIEM 中的事件收集、代理负载、PAM 访问、网络路由、CIPF 和故障场景。网络安全实验室将设计假设转化为经过验证的工业实施的约束和要求。
常见问题
不做HLD可以做LLD吗？
从技术上讲这是可能的，但在企业项目中这是有风险的：团队将很快进入产品设置，而没有就领域、责任边界、数据流和操作要求达成一致。
HLD 只是一个模式吗？
不会。蓝图很重要，但 HLD 还捕获了架构决策、需求、依赖关系、约束、安全类别、风险、集成原则和准备标准。
谁应该就 HLD 和 LLD 达成一致？
HLD 通常由 CISO、IT 架构、系统所有者和运营部门达成一致。 LLD 另外还要接受管理员、SOC、DevOps/DevSecOps 和实施团队的工程审查。
HLD 和 LLD 哪个更重要？
这两个级别对于验证都很重要。 HLD证明了安全架构和控制的有效性，LLD证明了控制是以特定的、可验证的和可控的方式实现的。
文件可以用于采购吗？
是的。 HLD 帮助定义解决方案类别和集成的要求，而 LLD 则阐明实施范围、承包商工作、验收标准和操作限制。
如果已经购买了网络安全怎么办？
您可以从架构审查开始：检查哪些解决方案已经涵盖了风险、哪些地方存在重复、哪些集成尚未实施以及哪些需要根据工业模型进行调整。
让我们讨论一下您的环境
描述任务、当前系统、约束和预期结果。我们将提供实用的第一步：诊断、试点、审计、路线图或项目团队。
