1. 园区网络安全需求分析

园区网络安全建设最容易犯的错误，是"先买设备、后想需求"。防火墙、IPS、准入系统堆了一屋子，等到真正发生横向渗透或勒索加密时，才发现关键资产没被识别、关键路径没有监控、关键合规项没有覆盖。需求分析的价值，就是把这些"事后才发现"的问题提前到设计阶段解决。本章围绕四个动作展开：识别资产、识别威胁、识别脆弱性、明确合规与业务连续性要求，最终收敛为一份可评审、可追溯的安全需求清单。

一、先建立分析框架：资产—威胁—脆弱性—影响

安全需求分析的本质，是回答"什么东西值得保护、谁会来攻击、哪里容易被攻破、攻破后损失多大"。这四个问题分别对应资产（Asset）、威胁（Threat）、脆弱性（Vulnerability）和影响（Impact）。风险可以近似理解为三者的组合：风险 ≈ 资产价值 × 威胁可能性 × 脆弱性严重度。这个公式不是精确计算工具，而是提醒我们：只盯着威胁买设备，忽略资产价值和脆弱性，投入就会错配。

下面这张图给出本节的分析主线：从资产盘点出发，分别向威胁与脆弱性两个方向展开，再叠加合规与业务连续性约束，最终汇聚成安全需求清单，并回流到设计验证。

二、资产识别：从"有什么"到"值多少"

资产识别不是简单列设备清单，而是要回答三个层次的问题：有哪些资产、它们承载什么业务、一旦受损影响多大。园区网中常见的资产类别包括：核心业务系统（ERP、OA、财务）、数据库与文件服务器、网络基础设施（核心交换机、出口路由器、防火墙）、安全设备、终端（办公PC、打印机、IP电话）、无线接入点与访客网络、以及账号、证书、配置文件和业务数据等无形资产。

实操中建议按"业务—系统—组件"三层展开。以某制造企业园区为例：业务层是"生产执行系统MES"，系统层是"MES应用服务器 + 数据库 + 工控采集网关"，组件层是"服务器主机、操作系统、中间件、数据库实例、网络端口"。每一层都要标注责任人、部署位置、对外暴露面和数据敏感级别。资产价值可以用"高/中/低"三级定性，也可以按业务中断每小时损失金额定量，后者更容易说服管理层投入。

三、威胁与脆弱性：一对必须同时看的变量

威胁是"可能造成损害的外部或内部因素"，脆弱性是"资产自身存在的可被利用的弱点"。二者必须成对分析：一个未打补丁的Web服务器（脆弱性），只有遇到针对该漏洞的攻击工具（威胁）才会形成实际风险；反过来，即使威胁很强，如果资产没有对应脆弱性，风险也可控。

园区网典型威胁包括：来自互联网的扫描与暴力破解、钓鱼邮件导致的终端失陷、失陷终端向服务器区的横向渗透、内部人员越权访问敏感数据、违规外联和私接设备、以及勒索软件对文件服务器的加密。典型脆弱性包括：弱口令与口令复用、系统与中间件补丁滞后、安全域划分不清导致"一墙之隔"、服务器区与办公区之间缺乏访问控制、日志未集中采集导致无法追溯、备份未隔离导致勒索时被一并加密。

建议用一张"威胁—脆弱性—受影响资产"对照表来收敛分析结果，避免分析停留在泛泛而谈。例如：

四、合规与业务连续性：需求的硬约束

合规要求决定了"必须做什么"，业务连续性要求决定了"做到什么程度"。等保2.0对园区网提出的核心要求包括：安全区域边界划分、访问控制策略、入侵防范、恶意代码防范、安全审计与日志留存（通常要求不少于6个月）、身份鉴别与权限管理。行业规范可能更细，例如金融行业对网络隔离和交易审计的要求、医疗行业对患者数据保护的要求。

业务连续性方面，需要与业务部门共同确认关键指标：RTO（恢复时间目标）和RPO（恢复点目标）。例如核心交易系统可能要求RTO≤30分钟、RPO≤5分钟，而一般办公系统可以放宽到RTO≤4小时。这些指标会直接转化为对链路冗余、设备双机、数据备份频率和切换机制的需求。如果只写"要保证高可用"而不量化，后续设计和验收就没有依据。

五、输出安全需求清单

分析的最终交付物是一份结构化的安全需求清单。每条需求应包含：需求编号、需求描述、来源（合规/风险/业务）、优先级、验证方式和责任方。下面给出一份可直接参考的示例片段（示例数据，非实测结果）：

需求编号    需求描述                                    来源      优先级   验证方式
SEC-001    办公区与服务器区之间实施访问控制，仅放行必要端口   风险驱动  高      策略核查+连通性测试
SEC-002    所有网络设备与服务器启用强口令策略并定期更换       合规+风险  高      配置核查
SEC-003    关键服务器区部署入侵检测，异常流量可告警           合规      高      告警验证
SEC-004    全网日志集中采集，留存不少于180天                 合规      中      日志平台查询
SEC-005    核心业务系统RTO≤30分钟，RPO≤5分钟                 业务连续  高      切换演练
SEC-006    终端接入实施准入控制，未注册设备禁止入网           风险驱动  高      准入测试
SEC-007    重要数据每日备份，备份介质与生产网络隔离           风险驱动  高      恢复演练

清单形成后，需要组织业务、运维、安全三方评审，确认优先级和可落地性。评审通过的清单将作为后续安全域划分、访问控制策略设计、设备选型和验收测试的直接输入。需求分析做得越扎实，后面的设计和实施就越少返工。

最后提醒一点：安全需求不是一次性文档。业务上线、系统变更、新合规要求出台时，都应触发需求清单的更新。把需求清单作为活文档维护，才能让园区安全体系持续匹配真实风险。