简介：这份H3C网络安全系统规划方案投标建议书以doc文档形式呈现，面向网络安全工程师、售前方案人员及参与政企安全项目投标的技术人员，用于解决安全体系规划与整体方案设计缺乏参考模板的问题。文档围绕安全系统整体规划、网络及安全现状分析、网络安全整体解决方案三大板块展开，涵盖方案设计原则、安全体系模型、网络结构与安全层次分析，并从网络层、系统层、管理层、用户层逐层梳理安全需求，进而给出基础设施安全部署、防火墙系统防护、内部入侵防御机制、端点准入控制、网络流量分析及病毒防范等具体设计内容，目录结构完整、层次清晰。资源包共1个doc文件，约1.21MB，便于直接查阅与二次编辑。目前已有89人学习下载，适合需要撰写安全规划方案、搭建安全体系框架或进行投标文档参考的读者借鉴使用。
1. 一份投标建议书为什么值得当成技术方案来读
很多人拿到「H3C网络安全系统规划方案投标建议书.doc」这个标题，第一反应是把它归到售前文档里，觉得跟一线技术关系不大。但真正做过政企、教育、医疗这类项目交付的人都清楚，投标建议书里的技术部分，往往就是后面实施阶段要照着落地的架构蓝图。它决定了设备选什么型号、安全域怎么划、策略怎么下、日志往哪送，甚至决定了你后期排障时有没有后悔药可吃。
这份文档的核心，是把 H3C 的网络与安全产品线，按客户业务需求组织成一套可交付、可验收、可运维的体系。它面向的是需要独立完成方案编写、设备选型、拓扑设计和报价支撑的工程师，而不是只做单一设备调试的人。下面我按自己写这类方案的顺序，把从需求拆解到设备清单、从安全域划分到策略落地的完整路径讲清楚，中间会带上 H3C 设备上真实要敲的命令和参数。
2. 从需求到拓扑：H3C网络安全系统规划方案怎么搭骨架
2.1 先分清客户要的是合规驱动还是攻防驱动
写方案第一步不是翻产品手册，而是判断项目性质。合规驱动的项目，比如等保测评整改，重点在边界隔离、日志留存、访问控制，设备清单里防火墙、入侵防御、日志审计、堡垒机基本是标配。攻防驱动的项目，比如参加网络安全赛事保障或红蓝对抗，重点在流量可视化、威胁狩猎、快速封禁，这时候 H3C 的态势感知平台和流量探针权重会明显上升。
判断方法很直接：看招标文件里的评分表。如果技术分里「符合等保三级要求」占大头，就按合规路线写；如果出现「实战化攻防」「威胁情报联动」这类词，就往攻防路线靠。两条路线的设备选型差异很大，混着写容易在评标时被挑出逻辑矛盾。
2.2 安全域划分：别把 VLAN 当安全域用
很多新手写方案时，直接把现有 VLAN 划成安全域，这是典型的翻车点。VLAN 是二层隔离，安全域是策略边界，两者维度不同。正确的做法是先按业务重要性分三级：核心业务区、普通办公区、外联接入区，再在每个区内部按需细分。
以典型的三层架构为例，出口部署 H3C SecPath 防火墙做边界隔离，核心区旁挂入侵防御系统，办公区通过核心交换机划分 VLAN 后接入防火墙子接口。这里有个关键参数：防火墙子接口的 MTU 建议设成 1500 以下，比如 1400，给 GRE 或 IPsec 隧道留出封装空间，否则大包分片会拖慢跨域访问。
# H3C 防火墙子接口配置示例 interface GigabitEthernet1/0/1.100 vlan-type dot1q 100 ip address 10.10.100.1 255.255.255.0 mtu 1400 quit这段配置的逻辑是：在物理接口上创建子接口，用vlan-type dot1q绑定 VLAN 100，再配 IP 作为该安全域的网关。mtu 1400是给后续可能建立的隧道预留空间。参数说明：子接口编号建议和 VLAN ID 保持一致，方便后期排查；IP 地址段要提前规划好，避免和客户现有网段冲突。
2.3 设备选型：用吞吐和并发反推型号
H3C 安全设备型号多，选型时最容易犯的错是只看端口数量。正确做法是先算两个数：峰值吞吐和最大并发连接数。峰值吞吐按核心业务带宽的 1.5 倍估算，并发连接数按人均 200 到 500 条估算。
比如一个 500 人的单位，核心带宽 200M，峰值吞吐需求约 300M，并发连接数约 10 万到 25 万。对应到 H3C 产品线，SecPath F1000 系列中端型号基本能覆盖。如果客户要求冗余，就上双机热备，这时候要注意心跳线必须直连，不要经过交换机，否则主备切换时延会明显增大。
| 选型维度 | 估算方法 | 常见取值 |
|---|---|---|
| 峰值吞吐 | 核心带宽 × 1.5 | 300M |
| 并发连接 | 人数 × 200~500 | 10万~25万 |
| 新建连接 | 并发数 × 10% | 1万~2.5万 |
| 接口需求 | 业务口 + 管理口 + 心跳口 | 不少于 6 个千兆口 |
表格里的新建连接参数容易被忽略，但它直接决定设备在突发流量下会不会丢包。如果客户有大量短连接业务，比如 Web 查询类系统，新建连接指标要比并发数更重视。
3. 安全策略与日志体系：让方案能落地而不是只过评审
3.1 策略编写：从默认拒绝开始做减法
安全策略的黄金法则是默认拒绝，按需放行。但实际写方案时，很多人为了省事写成默认允许，再逐条拒绝，这在等保测评里直接不合格。正确顺序是：先配一条 any 到 any 的拒绝策略放在最底部，然后按业务需求逐条插入允许策略。
H3C 防火墙的策略匹配是从上到下，所以允许策略要放在拒绝策略之前。每条策略要写清楚源域、目的域、源地址、目的地址、服务、时间范围。时间范围这个参数很多人不写，结果策略 7×24 小时生效，后期审计时说不清楚。
# H3C 防火墙安全策略配置示例 security-policy ip rule 10 name Allow_Web_Access source-zone Trust destination-zone Untrust source-address 10.10.100.0 255.255.255.0 destination-address 172.16.1.10 255.255.255.255 service http https time-range WorkTime action pass rule 100 name Default_Deny action drop这段配置里，rule 10的编号留出间隔，方便后期插入新策略。time-range WorkTime引用预先定义的时间段，只在工作时间放行 Web 访问。rule 100是兜底拒绝。参数说明：策略编号建议按 10 的倍数递增，源地址尽量精确到网段，不要用 any，否则策略审计时会被扣分。
3.2 日志留存：别等出了事才发现没记录
网络安全基线检查里，日志留存是硬指标。等保要求日志保存不少于 6 个月，但很多方案只写「部署日志审计系统」，没写清楚哪些日志要采、采多大、存哪里。
H3C 设备支持把日志送到 Syslog 服务器，也可以送态势感知平台。建议至少采三类日志：会话日志、攻击日志、配置变更日志。会话日志用于溯源，攻击日志用于告警，配置变更日志用于追责。日志服务器容量按每天每设备 500MB 到 1GB 估算，500 人规模的项目，6 个月大约需要 1TB 到 2TB 存储。
# H3C 设备日志外送配置示例 info-center enable info-center loghost 10.10.200.50 info-center source default channel loghost log level informational info-center timestamp loghost date这段配置开启信息中心，把日志送到 10.10.200.50 这台日志服务器，日志级别设为 informational，时间戳用日期格式。参数说明：日志级别不要设成 debugging，否则日志量会暴涨；时间戳必须带日期，否则跨天排查时无法定位。
3.3 高可用：双机热备的心跳和切换参数
方案里写双机热备，不能只写「部署两台防火墙做 HA」，要写清楚心跳接口、切换条件、切换时间。H3C 防火墙支持主备和负载分担两种模式，主备模式配置简单，负载分担模式利用率高但排障复杂。
心跳接口建议用独立物理口直连，不要走业务口。切换条件一般设成接口故障或链路故障，切换时间控制在 1 到 3 秒。如果客户对中断敏感，可以开启抢占模式，但抢占延时建议设成 30 秒以上，避免主备频繁切换。
# H3C 防火墙双机热备配置示例 interface GigabitEthernet1/0/6 ip address 192.168.254.1 255.255.255.252 quit hotbackup enable hotbackup interface GigabitEthernet1/0/6 hotbackup track interface GigabitEthernet1/0/1 hotbackup preempt delay 30这段配置指定 GE1/0/6 为心跳口，跟踪 GE1/0/1 的业务状态，抢占延时 30 秒。参数说明：心跳口 IP 用 30 位掩码，只留两个可用地址；track 接口要根据实际业务口调整；preempt delay 太短会导致震荡，太长会影响回切速度。
4. 投标建议书里的技术参数怎么写才不被挑刺
4.1 参数响应表：用「满足」和「优于」区分
评标时技术参数响应表是重点审查对象。常见错误是全部写「满足」，结果被评委追问具体指标时答不上来。正确做法是：核心指标写「优于」并附具体数值，普通指标写「满足」，不相关指标写「无偏离」。
比如防火墙吞吐要求 200M，你选型设备标称 4G，就写「优于，实测吞吐 4Gbps」。如果只写「满足」，评委可能认为你刚好卡线，印象分就低了。但也不能全写「优于」，否则显得不真实，一般「优于」占比控制在 30% 以内。
4.2 拓扑图：别只画设备不画流量
拓扑图是方案的门面，但很多人只画设备图标和连线，不标流量方向和安全域边界。正确的拓扑图要包含：安全域边界用虚线框标出，流量方向用箭头标注，关键设备旁写型号和接口。
如果客户有多个出口，比如同时接互联网和专线，拓扑图上要明确标出哪条走防火墙、哪条走路由器。H3C 设备堆叠的场景，要在图上标出堆叠线缆和主备关系，否则后期实施时容易接错。
4.3 报价支撑：设备清单和维保要分开列
报价部分最容易出问题的是维保。很多方案把设备和维保打包成一项，结果客户砍价时连维保一起砍。正确做法是设备清单和维保服务分开列，设备按台报价，维保按年报价。
H3C 设备的维保一般分基础服务和原厂服务，基础服务响应时间 4 小时，原厂服务可以做到 2 小时。如果客户是核心业务系统，建议推原厂服务，虽然贵但故障时能直接拉原厂工程师。普通办公区用基础服务就够了。
5. 避坑与排查：投标方案里没写但实施时一定会遇到的事
5.1 现象：防火墙策略放行了但业务不通
原因：策略匹配顺序问题，或者 NAT 没配。H3C 防火墙如果做了源 NAT，策略里的源地址要写 NAT 前的地址，不是 NAT 后的地址。很多人在这里搞反，导致策略看似放行实际被丢弃。
解决：先用display security-policy ip查看策略命中计数，如果计数为 0，说明流量没匹配到这条策略。再检查 NAT 配置，确认策略里的地址是 NAT 前还是 NAT 后。实在不确定，就临时加一条 any 到 any 的允许策略测试，通了再逐条收紧。
5.2 现象：双机热备切换后业务中断超过 10 秒
原因：心跳口和业务口混用，或者切换条件设得太敏感。心跳口如果走业务口，业务口流量大时心跳报文会丢，导致误切换。
解决：心跳口必须独立物理口直连，不要经过交换机。切换条件只跟踪关键业务口，不要跟踪所有接口。如果客户对切换时间要求高，可以考虑负载分担模式，但排障复杂度会上升。
5.3 现象：日志服务器收不到 H3C 设备日志
原因：日志级别设错，或者路由不通。H3C 设备默认日志级别是 informational，如果改成 debugging，日志量太大会被服务器丢弃。另外设备到日志服务器的路由必须可达，很多人只配了 IP 没配路由。
解决：先用ping测试设备到日志服务器的连通性，再检查info-center source的日志级别。如果日志量确实大，可以在日志服务器上按设备 IP 分目录存储，避免单文件过大。
5.4 现象：堆叠口满了导致新设备加不进去
原因：堆叠口带宽不足，或者堆叠线缆质量差。H3C 交换机堆叠时，堆叠口建议用万兆口，千兆口在流量大时容易成为瓶颈。
解决：先查display stack看堆叠状态，如果显示异常，检查线缆和光模块。堆叠口满了就加堆叠线缆做聚合，或者换更高带宽的接口。堆叠成员数不要超过 4 台，太多会影响收敛速度。
5.5 现象：设备启动失败，Console 无输出
原因：电源故障、BootRom 损坏、或者配置丢失。H3C 设备启动失败时，Console 口通常会有提示信息，如果完全无输出，先查电源和线缆。
解决：换电源线和 Console 线测试，如果还是无输出，可能是 BootRom 问题，需要返厂。如果 Console 有输出但卡在某一步，按提示进入 BootRom 菜单，检查启动文件是否存在。配置丢失的话，提前备份的配置文件就能派上用场。
6. 把方案变成可复用的模板：我的三个习惯
写这类方案写了几年，我最大的教训是：不要每次从零开始。第一个习惯是建一个参数库，把 H3C 常用型号的吞吐、并发、接口数、维保价格整理成表格，下次选型时直接查表，不用翻手册。第二个习惯是拓扑图分层画，物理拓扑、逻辑拓扑、安全域拓扑分开存，投标时按需组合。第三个习惯是策略模板化，把等保三级、等保二级、攻防保障三类场景的策略框架提前写好，实施时只改 IP 和端口。
验证方案是否靠谱，有个简单方法：拿给没参与编写的同事看，如果他能顺着拓扑图和设备清单把数据流向讲清楚，说明方案逻辑是通的。如果他自己都绕晕了，评委大概率也会晕。
最后一个技巧是关于时间管理的。投标截止前三天不要再改技术方案，只检查格式和错别字。技术方案改多了容易前后矛盾，反而扣分。把时间花在报价核对和资质文件上，性价比更高。
希望帮到你。
本文还有配套的精品资源，点击获取
