纯云端视频墙管理为何失败

纯云端方案在纸面上很有吸引力：在一个浏览器中管理所有站点的所有视频墙，集中推送更新，无需维护本地服务器。

问题在于，控制室、NOC 或 SOC 中的视频墙所承载的内容，是监管机构不允许离开建筑物的。

NOC 视频墙显示实时网络拓扑和影响客户的故障数据；SOC 视频墙显示实时安防摄像头画面和 SIEM 告警；公用事业控制室显示来自关键基础设施的 SCADA 遥测数据。

只要其中任何数据经由第三方云传输——哪怕只是能够推断出底层数据的控制信号——就会触发合规审查，而纯云端架构很少能通过这类审查。

四道合规壁垒

GDPR（欧盟）。含有可识别个人的实时摄像头画面，属于第 4(1) 条所定义的个人数据。通过托管在欧盟境外的控制平面处理这些数据，或交由受美国《云法案》（CLOUD Act）约束、总部位于美国的云服务商处理，都需要有据可查的传输机制和风险评估（自 2023 年 7 月起生效的欧美数据隐私框架，或标准合同条款），而许多设施并不愿意承担这些工作。
FZ-152 与 FZ-187（俄罗斯）。FZ-152（第 18 条第 5 款）要求俄罗斯公民的个人数据在位于俄罗斯境内的数据库中记录和存储。FZ-187 针对能源、交通、金融等行业增加了关键信息基础设施规则，这些规则通常被解读为：运行层须留在俄罗斯境内，且往往需要物理隔离。
FedRAMP 与 DoD 影响级别（美国联邦）。在处理受控非密信息的联邦设施中，视频墙不能经由商用 SaaS 控制平面传输数据，除非服务商持有相应影响级别的 FedRAMP 授权；涉密信息不属于 FedRAMP 的适用范围，只能留在独立的涉密网络上。
BSI C5（德国）。这份德国联邦云安全标准目录设定的门槛，是大多数通用 SaaS 控制平面达不到的，这促使德国公共部门的项目转向本地部署或主权云方案。

其中任何一项都可能足以让纯云端视频墙被排除在受监管部署之外。实际上，大多数大型控制室买方至少会遇到其中一项。

混合模式：云端与本地如何分工

混合架构沿着一条清晰的界线拆分系统：控制平面可以放在云端，数据平面留在本地。

会议室领域的 Mersive Solstice Cloud 就是一例：云端门户负责管理部署，而屏幕内容始终不会离开现场的 Pod 设备。

可以放在云端的部分

管理界面本身——管理员用来配置视频墙的浏览器应用，以 SaaS 应用形式托管
配置元数据——布局定义、命名场景、用户账户与权限、信号源目录（信号源的地址，而非其内容）
全局遥测数据——哪些视频墙在线、软件版本、各站点的健康状态
审计日志——记录谁在何时更改了什么（即变更的元数据，而非所显示的内容）

必须留在本地的部分

视频本身——每一路信号源画面的每一个像素。摄像头视频流、数据看板渲染画面、KVM 会话都不会离开本地网络
合成器——把信号源排布到视频墙上的引擎，运行在本地服务器上，靠近它所驱动的显示屏
信号源接入——NDI、RTSP、IPMX、KVM 端点连接的是本地服务器，而不是云端端点
回退路径——如果云端控制平面无法访问，本地服务器必须按最后一次已知配置维持视频墙运行。视频墙的显示不能依赖云端连接。

云端的控制平面

在数据平面已正确保留在本地的前提下，云端控制平面真正能带来的价值包括：

多站点管理——NOC 操作员通过一个界面管理分布在十几处设施中的视频墙
集中下发配置——一次性把新的命名场景推送到所有站点
全局可见性——无需逐台操作服务器，即可掌握所有站点的健康状态和版本情况

确保这一模式安全的约束条件是：控制平面只处理地址和定义，从不处理内容。

云端控制平面发出“把 10.20.30.40 上的信号源放入 3 号窗口”的指令，是合规的；云端控制平面转发来自 10.20.30.40 的视频，则不合规。架构必须强制落实这条界线，而不能只是写进文档。

本地的视频平面

本地服务器承担不能离开建筑物的工作：接入每一路信号源、运行合成器、驱动显示屏，并在本地保存一份完整的配置副本，以便在云端中断时照常运行。

对于受监管的部署，本地服务器同时也是物理隔离的边界：它可以在完全没有出站互联网连接的情况下运行，此时云端控制平面完全不可用，视频墙在本地进行管理。

这就是检验任何自称“混合”的厂商的试金石：拔掉互联网连接，视频墙必须继续运行，并且仍可在本地管理。

如果视频墙功能降级，或管理界面无法访问，那么这种架构就是依赖云端的，而不是混合架构。

混合模式中的 KVM

IP-KVM 是最能体现本地边界重要性的场景。KVM 会话意味着操作员实时接管一台信号源计算机——这是视频墙上最敏感的流量。

在混合架构中，KVM 会话严格限定在本地：云端控制平面可以知道存在一条 KVM 路由以及谁有权使用它，但键盘、视频和鼠标流量完全在本地网络中传输。

任何 KVM 路径经过云端的厂商，都没有构建出合规的混合系统。

Craft Wall 的定位

Craft Wall 在设计上就是纯本地部署。合成器、信号源接入和完整配置都运行在设施内部的一台通用 Linux 服务器上。

基于浏览器的控制界面同样由这台本地服务器提供，因此每一套部署都可以在物理隔离环境中运行，完全不依赖云端。

Craft Wall 没有云端控制平面：管理和配置都保留在本地服务器上，因此任何数据——包括元数据——都无需离开站点，上文的“拔网线”测试在设计上即可通过。

本地部署的设计请参阅 NOC 参考架构；各厂商在云端依赖问题上有何差异，请参阅八大平台对比——云端依赖是这一品类中较为鲜明的分界线之一。

结语

纯云端视频墙曾是一个合理的押注，但合规环境已基本把它排除在受监管的控制室之外。

混合并非权宜之计，而是正确的架构：云端做云端擅长的事（多站点管理、集中下发），本地层做监管要求的事（每一个像素都留在建筑物内）。

买方的检验方法简单直接，而且可以动手验证：拔掉互联网连接，看视频墙能否照常工作。能，就是混合架构；不能，就是贴着混合标签的云端依赖架构。

延伸阅读：NOC 参考架构，了解本地部署的设计；AI 增强视频墙，了解为什么本地推理遵循同样的合规逻辑；以及 Craft Wall 与 Userful 对比，了解真实评估中的云端依赖差异。

常见问题

什么是“元数据在云端、像素在本地”的视频墙模式？

这是一种架构划分：视频和配置保留在本地（满足合规要求），而有关视频墙状态、操作员活动、布局和信号源清单的元数据则流向云端控制平面。管理员可以在云端集中管理布局并推送到本地视频墙，但在互联网链路中断时，操作员仍必须能够在本地登录并控制视频墙。实际的视频像素始终不会离开客户网络。在我们看来，这种模式通过 GDPR、FZ-152、FedRAMP 或 BSI C5 审查的可能性远高于纯云端视频墙。

纯云端视频墙为何未能通过合规审查？

大多数受监管行业（能源、银行、医疗、公共部门）将运营视频信号归为“高敏感”数据或“关键基础设施数据”。把这些数据发送给云服务商——即便对方具备相应认证——也会触发一系列合规框架（GDPR 关于向第三国传输数据的规则、俄罗斯 FZ-152 个人数据本地化要求、BSI C5 云安全标准、Moderate 或 High 基线的 FedRAMP 授权）。在我们看来，这正是纯云端管理在受监管控制室中进展甚微的原因：这类买方期望的是本地部署或混合设计。

混合云视频墙如何满足 GDPR 要求？

视频数据只要拍到可识别的个人，就属于个人数据。混合模式把这类数据保留在运营方受 GDPR 管控的环境之内——只有最少量的运行元数据流向云端，而这些元数据可能包含操作员标识，它们同样属于个人数据。云端控制平面只处理系统状态数据（布局、操作员 ID、信号源 URL）——没有视频帧，没有人脸识别结果，也没有生物特征推断。欧盟运营方通常会签署一份数据处理协议（第 28 条），涵盖元数据通道，其中包括操作员标识；视频本身不在服务商的处理范围之内。

哪些放在云端，哪些留在本地？

云端：用户账户和角色的中央副本、视频墙布局定义、信号源清单元数据、操作员活动审计日志的副本（其中包含操作员标识）、软件更新分发、多站点协同状态。本地：所有视频帧、所有采集（HDMI、NDI、RTSP 信号）、执行操作员命令并在断网时继续为操作员进行身份验证的本地控制平面、一份完整的本地配置副本、所有生物特征 / AI 推理结果、所有客户域配置文件（网络 ACL、集成凭据）。