企业官网建设流程全解析

简介：GA/T1788.3—2021《公安视频图像信息系统安全技术要求 第3部分：安全交互》是公共安全行业标准PDF文档，面向公安视频传输网安全交互系统的规划设计、开发研制、部署实施、检测验收与运行维护人员。资源为1个PDF文件，压缩包约403KB，正文覆盖范围、规范性引用文件、术语和缩略语，以及安全交互系统架构、安全等级划分、安全策略、设备性能要求等核心章节。标准将安全交互系统分为横向边界安全交互和纵向安全防护两类体系，横向边界划分路由接入区、边界保护区、应用服务区、安全隔离区、安全监测与管理区五个安全域；同时规定从一级到五级的安全等级划分，以及身份验证、访问控制、加密保护、入侵检测、日志审计等安全策略，并引用GB/T22239、GB/T28181、GB35114-2017、GA/T1400、GA/T1788.1-2021等配套文件。目前已有276人学习下载，适合公安信息化建设者、安防标准研究者及视频监控系统集成工程师对照查阅，辅助理解安全交互标准整体框架与技术细节。

1. 安全交互：GAT 1788.3-2021 到底在管什么

很多做公安视频监控集成的同行第一次拿到 GAT 1788.3-2021《公安视频图像信息系统安全技术要求 第3部分：安全交互》时，第一反应是“这不就是网闸规范吗”。看完正文会发现，它管的是公安视频传输网上下级主干网之间、主干网与接入网之间、以及视频传输网与公安信息网、互联网、其他专网之间所有的跨网交换。视频流怎么过、数据库怎么同步、API 服务怎么开放、日志怎么上报，全部要落在同一个安全框架里。对谁有用：做公安视频图像信息系统规划设计的、给边界区选设备的、搞等保测评和项目验收的工程师，还有需要向用户解释“为什么边界要放三层设备”的方案售前。这份标准核心解决三件事：跨网交换时身份可信、内容可控、过程可审计。

2. 架构拆解：横向边界与纵向防护两条主线

2.1 横向边界安全交互系统：五大安全域怎么分工

第4章把横向边界安全交互系统切成五个安全域：路由接入区、边界保护区、应用服务区、安全隔离区、安全监测与管理区。很多项目把边界只理解成“一台网闸加两台防火墙”，这不够。

路由接入区负责把外部链路接进来，按接入对象和链路类型把视频流、数据流分流，做路由访问控制。边界保护区是一道硬墙，做访问控制、设备准入、统一威胁防护，含网络入侵防护和恶意代码防护。应用服务区处理各类应用相关操作，是对外信息发布、信息采集和数据交换的中间区域，支持应用代理、数据暂存、安全加固、恶意代码防护。注意一点：视频交换链路中，一般不强制要求建立应用服务区。很多集成商习惯把数据链路的配置模板套到视频链路上，硬塞一台代理机，结果时延超标，这就是没读透 4.2.4，后面避坑章再展开。

安全隔离区是横向边界系统的核心，视频交换链路和数据交换链路在这里走完全不同的策略：

视频交换链路针对互联网场景要提供单向导入、单向导出，并支持签名验签、协议识别、内容过滤、流量管控、服务认证、信令安全、媒体安全。数据交换链路走 GA/T1400 等通用数据隔离交换，额外增加格式检查。安全监测与管理区把前面所有组件的日志收上来，采集业务日志、资产信息、安全基线、运行状态，做集中监管并向上一级级联上报。实践里这个区往往就是一台安全管理平台或安全审计服务器，但它的功能定位和普通日志服务器不同——标准要求的是“策略管理”和“级联上报”，不是只收 Syslog 就完事。

2.2 纵向安全防护系统：上下级之间能通但可控

纵向安全防护系统解决的是两类接入：前端设备（有线/无线）直接接入公安视频传输网，以及下级公安视频图像信息系统连到上级。它只有两个区：安全防护区、安全监测与管理区。关键点在于“不隔离路由”——上下级系统之间应用路由可达，这与横向边界完全不同。很多设计容易把横向那套强隔离搬过来，结果路由全部被断，下级调不了上级的视图库，这就是没读透 4.1.3。

安全防护区要支持有线前端、无线前端、下级系统三类对象的双向交换。有线前端要提供设备准入、访问控制、统一威胁防护、协议识别、流量管控，视频流和视图库数据流都走。无线前端接入要注意：应采用运营商 VPDN 或无线专网链路，由纵向安全防护系统提供接入，还宜采用基于 GB35114-2017 的设备认证并符合 C 级规定。VPDN 这条在生产环境里经常被忽略，很多项目拿普通 4G 卡就接了前端，结果接入审查过不了。安全监测与管理区可以与横向边界系统共用，要求同样是日志采集、集中监管、级联上报，复用一套平台即可。

2.3 边界区设备清单参考

方案阶段我一般先按安全域列设备，再逐台对功能项：

一台设备可以跨区承担职责，但功能点必须能对应到标准条文。比如防火墙可以放在边界保护区做访问控制，同时路由接入区的 ACL 也在它上面做，验收时按域梳理功能比按设备梳理清楚得多。

3. 安全等级划分：基本级、增强Ⅰ级、增强Ⅱ级怎么选

3.1 三个等级的差异到底在哪

横向视频交换链路等级从低到高是基本级、增强Ⅰ级、增强Ⅱ级。基本级的策略清单很长但都是常见项：IP/MAC 地址绑定、设备指纹等设备认证准入、防 DDoS、访问控制、统一威胁防护、安全加固、恶意代码防护、签名验签、协议识别、内容过滤、流量管控、服务认证、业务审计、集中监控、级联管理、双向隔离或单向导入导出。

增强Ⅰ级在基本级基础上增加两项：基于 GB35114-2017 的设备认证准入控制、针对控制信令的内容过滤。增强Ⅱ级继续增加针对媒体流的内容过滤。三个等级的本质区别是“认证强度”和“内容深度”：基本级认设备指纹，增强级认国标数字证书；基本级只保证信令合规，增强Ⅱ级还要管媒体流内容。

纵向安全防护系统等级同样分三级，但策略清单和横向差异明显：

注意差异：横向基本级有签名验签、服务认证、业务审计这些跨网交换专属项，纵向基本级没有——它的定位是接入防护，不承担跨网交换。做纵向系统方案时，照抄横向的签名验签要求只会增加预算，没有实际验收意义。

3.2 行政级别与等级对应

标准 5.3 条给了一个很实际的选型对应：

“应”和“宜”的强制属性要分清。“应不低于增强Ⅰ级”是底线，达不到验收过不了；“宜采用增强Ⅱ级”是推荐级别，但做省级项目时基本被当作硬性要求执行。我一般会建议预算允许就直接按增强Ⅱ级设计，后期升级不用动网络架构，只加策略模块。

3.3 数据交换链路不分等级：一刀切设计

横向数据交换链路不区分安全等级，这句话容易被当成设计冗余。标准原文对数据交换链路列出的策略包括设备证书、IP/MAC 地址绑定、防 DDoS、访问控制、统一威胁防护、安全加固、恶意代码防护、签名验签、协议识别、格式检查、内容过滤、流量管控、服务认证、业务审计、集中监控、级联管理、双向隔离或单向导入导出。

也就是说，无论哪个行政级别，数据交换链路策略清单完全一样，且明确要求设备证书认证，比视频链路的基本级更严格。原因不难理解：数据链路承载的是数据库同步、FTP、API 这类通用数据，一旦被横向突破就是整体风险，必须一刀切。规划预算时，数据链路设备不能按县级项目就降级配置，这往往是采购审计时被卡的第一个点。

3.4 等级选型实操顺序

做方案前先定等级再选设备。我一般按这样走：第一步确认项目是横向边界还是纵向防护，还是两个都要；第二步看行政级别，对照 5.3 条锁定最低等级；第三步看是否涉及互联网或专网接入，涉互联网的视频链路还要确认单向传输需求；第四步按等级要求逐项对照设备功能表，先过等级再过性能，最后才会到部署环节。等级不定，设备选型后面一定来回返工。

4. 安全策略落地：从访问控制到单向导入的实操映射

4.1 六类基础策略：先过设备验收再谈整体

第6章从 6.1 到 6.18 列了十几项安全策略，落地时先过六类基础项：访问控制、设备准入、统一威胁防护、安全加固、恶意代码防护、签名验签。

访问控制要求通过防护规则实现网络访问控制，对不符合防护规则的访问应拦截并告警。这是边界设备出厂标配，但要注意告警是否落到集中监控——很多防火墙的告警只在本地控制台闪一下，没有对接安全监测与管理区，验收时这一项是扣分点。

设备准入在横向边界侧要支持对具有唯一性标识的设备进行认证，也要支持对具有数字证书的设备进行认证；支持设备注册，注册信息含设备 IP/MAC、设备 ID、设备属性；宜支持采集外部接入设备的硬件信息、操作系统补丁状态、病毒库、进程、注册表、账户信息，为信任评估提供实时环境数据。纵向防护侧则按 GA/T1788.2—2021 的规定做认证，不需要和横向完全一致。

统一威胁防护要求对蠕虫、后门、木马、间谍软件、Web 攻击、拒绝服务都有防御手段，只看 IPS 特征库还不行，要确认设备支持检测、阻断、限流、审计报警四种动作，缺了“限流”这一项，遇到突发流量就只能硬扛。安全加固和恶意代码防护属于系统层面，常见做法是出安全配置基线文档，关掉不需要的服务端口，并启用恶意代码检测引擎。

签名验签是跨网交换最常配错的一项。标准要求支持签名验证，确保交换数据真实性、完整性和不可抵赖性，对无签名或验证不通过的数据拦截丢弃并日志报警。落地常见做法是在安全隔离区前部署签名服务器，对 GB35114-2017 的媒体流和视图库同步数据做验签。验签失败的会话要能明确区分“网络原因丢弃”和“签名失败丢弃”，否则排障时容易把问题推给网络。

4.2 单向导入导出与双向隔离：三句话理解边界机制

6.13 到 6.15 定义了三种跨网机制，很容易混淆。

单向导入：数据物理单向传输，确保无任何反向通道，导入过程记日志。单向导出：同样物理单向，只是方向相反。双向隔离：按事先定义安全策略对协议头剥离，再按策略再生协议头；通过协议隔离方式断开内部 TCP/IP 连接，数据摆渡过程中不同时连接两侧主机，摆渡过程记日志。

很多刚接触安全交互的工程师会把“单向”理解成防火墙的一条方向规则，这是血泪教训。物理单向意味着硬件链路层面就不存在反向通道，常见设备是单向光闸，发送端和接收端物理分离，反向只有确认信号甚至完全无通道。双向隔离对应网闸类设备，TCP/IP 协议层断开，数据通过私有协议摆渡。做方案不要把两者混着写：互联网视频接入如果要满足视频流单向传输，就写“单向导入/导出设备”；其他专网场景写“双向隔离设备”。

4.3 服务认证、信令安全、媒体安全：面向协议本身的安全

服务认证面向 API 和数据服务。要求支持数字证书、口令密码、动态令牌、Token 等多凭证鉴权；对服务调用方做权限控制，确保最小授权；服务支持注册、编目、查询、变更、注销。在公安视频图像信息系统里，服务注册功能通常落在视图库和共享服务平台侧，边界侧提供认证代理。实际部署时，API 服务注册数和 API 并发数直接对应设备性能表，选型前要先统计业务峰值。

信令安全面向 GB/T28181 信令，要求用签名或加密保证信令协议自身安全，抵御篡改、夹带、窃听。媒体安全面向视频流，同样要求媒体流签名或加密。这两个策略直接影响后端解码：若启用媒体流加密，解码设备和录像平台都要配套证书，方案里必须提前说明，否则项目上线时录像回放黑屏，排障要折腾很久。

4.4 业务审计、集中监控、级联管理：把日志变成管理体系

审计和监控不是最后加的，而是设计阶段就要规划。业务审计要求支持 Syslog、JDBC、FTP、API 等接口采集业务日志，对采集到的数据做范式化、标准化处理，再向相关系统报送。集中监控要求资产管理、运行状态检测、策略管理、安全反制、服务配置管理。

安全反制是里面容易被忽略的一项。它要求持续改进安全策略做动态防御，阻断非合规访问和后续访问——说白了就是要有联动封禁能力。我一般会先画一条数据流：边界设备产生日志、采集接口、范式化、标准化、本级集中监控、级联上报，每个环节对应一个功能点，然后做成验收表逐项打勾。级联管理解决上下级数据报送、审批、通报，这块和等保里的“集中管控”要求能复用同一套界面，能省就省。

5. 安全交互落地常见问题：六个高频坑位与解法

5.1 把物理单向当成软件策略

现象：单向光闸部署后，业务侧反馈反向链路不通，运维用防火墙 ACL 模拟单向效果，结果验收时被质疑“无反向通道”没有硬件证据。

原因：把标准 6.13“数据物理单向传输，确保无任何反向通道”理解成软件层单向策略。防火墙 ACL 阻断的是网络层访问，物理链路仍然存在，不符合“物理单向”定义。

解决：采购时确认是单向光模块还是双向可逆设备，方案里明确标注物理单向。验收时做双向访问测试：反向 Ping 不通且设备日志里有阻断记录，同时查看光模块收发状态，确认接收端无发射光。

5.2 视频链路硬上应用服务区导致时延超标

现象：视频交换链路按数据链路模板加了应用代理，结果时延超过标准要求。横向视频链路的传输时延要求基本级≤200ms、增强Ⅰ级≤300ms、增强Ⅱ级≤400ms，实测经常到 500ms 以上。

原因：标准 4.2.4 写明视频交换链路一般不强制建立应用服务区。视频流每经过一跳应用代理，就多一次协议解析和转发，时延被成倍放大。

解决：视频链路按 GB/T28181、GB35114-2017 协议直通转发，应用服务区只留给数据链路。如果必须对视频流做内容检查，把内容过滤下放到媒体层设备处理，不要叠加代理。

5.3 等级选型把“宜”当“应”导致预算虚高或不足

现象：省级项目按增强Ⅰ级报了预算，评审专家要求补齐媒体流内容过滤，预算差一截；另一头县级项目按地市级标准上了增强Ⅰ级设备，预算严重超支。

原因：5.3 条省级以上“宜采用增强Ⅱ级”被理解成可选项，县级“可根据需求选择基本级”被理解成必须上增强级。

解决：省级以上项目直接按增强Ⅱ级做方案，把媒体流内容过滤设备费用提前进预算；县级项目先做需求评审，确认无互联网接入就按基本级设计，把钱花在数据链路上一刀切策略上。

5.4 并发路数和吞吐量对不上账

现象：纵向安全防护系统选了标称 1000 Mbit/s 吞吐的机型，实际跑 250 路 1080P 视频开始丢包。标准要求并发路数≥250 路（按每路 4 Mbit/s 计算）。

原因：纯按吞吐量算，250 路×4 Mbit/s 刚好 1000 Mbit/s，但设备在小包混合流量下实际吞吐达不到标称值，每路视频还带 GB/T28181 信令开销，实测每路会到 4.5Mbit/s 左右。

解决：选型时看“并发路数”指标，不要只看吞吐量，并按 4.5Mbit/s/路预留 30% 冗余。我一般按每路 4.5 到 5 Mbit/s 做容量规划，宁多勿少。

5.5 日志采集不范式化，级联上报丢数据

现象：边界集中监测系统日志采集速率显示达到 800 条/s，但上级系统收到的数据缺时间戳和源 IP，级联上报延时经常超过 10s 标准要求。

原因：设备原始日志格式混乱，采集后没有做范式化标准化就直接报送。有的是时间格式不统一，有的源 IP 字段为空，上级系统入库时因字段缺失直接丢弃。

解决：采集后先做字段映射，统一时间格式、源 IP、事件类型，再按标准格式打包。级联链路加队列缓冲和重传机制，上报失败时自动补报。

5.6 信令内容过滤开启后控制信令被误杀

现象：启用对 GB/T28181 控制信令的内容过滤后，PTZ 控制指令间歇性失效，拉流请求也有部分被拦截。标准要求增强Ⅰ级以上必须对控制信令做内容过滤。

原因：过滤规则写得太粗，把合法的设备巡检信令、心跳报文、SIP 的 OPTIONS 请求都识别成异常报文拦掉了。

解决：先开审计模式跑一周，统计误拦截率，再按信令类型细化白名单。规则上线前用真实的 GB/T28181 客户端做回归测试，重点验证 PTZ、拉流、布撤防三类操作，确认不影响正常业务后再切换到阻断模式。

6. 性能指标与验收：把标准表变成可核对清单

6.1 四张性能表汇总

标准第7章给了四张表，选型和验收都靠它们：

6.2 现场验证办法

时延：在安全交互设备两侧抓包，记录 SIP 信令 INVITE 从入口到出口的时间差。常见做法是两侧各放一台抓包终端，用同一时间源同步，抓三组取平均值。

吞吐量：用两台打流仪分别接在设备两侧，按 UDP 大包测。注意实际视频流量是小包加突发混合流量，实验室结果要乘 0.7 到 0.8 的系数才接近真实值。

并发路数：用 GB/T28181 模拟器并发注册和拉流，观察丢包和时延变化，边跑边看设备 CPU 和内存。拉到 250 路时 CPU 超过 70%，就要考虑扩容。

数据库同步速率：在源库和目标库之间跑增量同步脚本，统计每秒入库条数，连续跑 10 分钟取平均值，不要只看峰值。

级联上报延时：在安全管理平台手动产生一条告警，记录本地时间与上级接收时间差，标准要求≤10s。这个测试要在业务高峰时段做，低峰期测不出来。

APP 并发数：用接口测试工具对 API 服务并发发请求，观察响应时间从 100 并发到 1000 并发的拐点，拐点明显低于 1000 就说明设备性能不达标。

6.3 一个小技巧

把四张性能表做成一张 Excel 核对清单，每个性能项一行，分“时延”“吞吐”“并发”“日志”“级联”五个 sheet，验收时一组人负责一类数据。测试结果直接填进清单，和标准值做差值，超标的立刻定位责任设备。从那以后，每次做安全交互边界项目，我都强制先把性能表打印出来贴在方案第一页，让设备和网络负责人先签字再进场，省掉回头扯皮的时间。性能问题在进场前暴露，比上线后暴露成本低得多，希望帮到你。

本文还有配套的精品资源，点击获取