Коротко

Примерно в 2022-2023 годах несколько вендоров видеостен сделали ставку на облачно-управляемое будущее — конфигурация стены, маршрутизация источников, иногда само видео, всё через SaaS-плоскость управления. К 2026 году вердикт, по нашей оценке, ясен: чисто облачное управление редко проходит проверку на соответствие требованиям в регулируемых отраслях. Проверку там выдерживает гибридный паттерн. Эта статья разбирает, что размещается в облаке, что остаётся на объекте, и почему это деление — не компромисс, а правильный дизайн.

Почему чисто облачное управление видеостеной провалилось

Чисто облачная подача на бумаге привлекательна: управляй каждой стеной на каждом объекте из одного браузера, раскатывай обновления централизованно, нет on-prem-сервера для обслуживания. Проблема в том, что видеостена в диспетчерской, NOC или SOC несёт контент, который регуляторы не разрешают выпускать за пределы здания.

NOC-стена показывает живую сетевую топологию и данные о сбоях, влияющих на клиентов. SOC-стена показывает живые фиды камер безопасности и SIEM-тревоги. Диспетчерская энергетики показывает SCADA-телеметрию с критической инфраструктуры. Маршрутизация чего-либо из этого через сторонее облако — даже просто как управляющий сигнал, который подразумевает нижележащие данные — запускает проверку на соответствие требованиям, которую чисто облачные архитектуры проходят редко.

Четыре стены compliance

GDPR (ЕС). Живые фиды камер с идентифицируемыми лицами — персональные данные по статье 4(1). Обработка этих данных через плоскость управления, размещённую вне ЕС — или облачным провайдером с US-штаб-квартирой, подпадающим под US CLOUD Act — требует задокументированного механизма передачи и оценки рисков (рамочная программа EU–US Data Privacy Framework, действующая с июля 2023 года, или стандартные договорные условия), а многие объекты предпочитают этим не заниматься.
152-ФЗ и 187-ФЗ (Россия). 152-ФЗ (ч. 5 ст. 18) требует, чтобы запись и хранение персональных данных граждан РФ велись с использованием баз данных, находящихся в России. 187-ФЗ добавляет правила критической информационной инфраструктуры для таких отраслей, как энергетика, транспорт и финансы; их принято толковать как требование держать операционный слой в стране и часто — в изолированном контуре.
FedRAMP и DoD impact levels (федеральный сегмент США). Видеостена на федеральном объекте, где обрабатывается контролируемая несекретная информация, не может работать через коммерческую SaaS-плоскость управления, если у провайдера нет авторизации FedRAMP соответствующего уровня воздействия; секретная информация в сферу FedRAMP не входит и остаётся в отдельных засекреченных сетях.
BSI C5 (Германия). Немецкий федеральный каталог критериев облачной безопасности задаёт планку, которой большинство универсальных SaaS-плоскостей управления не соответствуют, толкая развёртывания немецкого госсектора к on-prem или суверенно-облачным дизайнам.

Любой из этих четырёх стен может оказаться достаточно, чтобы дисквалифицировать чисто облачную видеостену для регулируемого развёртывания. На практике большинство крупных закупщиков диспетчерских сталкиваются хотя бы с одной из них.

Гибридный паттерн — что где размещается

Гибридная архитектура делит систему по чёткой линии: плоскость управления может жить в облаке; плоскость данных остаётся на объекте. Пример из мира переговорных комнат — Mersive Solstice Cloud: облачный портал управляет развёртыванием, а контент экранов не покидает установленное на объекте устройство Solstice Pod.

Что может жить в облаке

Сам UI управления — браузерное приложение, которым администратор конфигурирует стены, размещённое как SaaS-приложение
Метаданные конфигурации — определения раскладок, именованные сцены, учётные записи и права, каталоги источников (адрес источника, не его содержимое)
Телеметрия парка — какие стены онлайн, версии ПО, статус здоровья по объектам
Журналы аудита — запись о том, кто что изменил и когда (метаданные изменений, не показанный контент)

Что обязано остаться на объекте

Само видео — каждый пиксель каждого фида. Потоки камер, рендеры дашбордов, KVM-сессии никогда не покидают локальную сеть
Композер — движок, раскладывающий источники на стену, работает на on-prem-сервере рядом с дисплеями, которыми управляет
Приём источников — NDI, RTSP, IPMX, KVM-конечные устройства подключаются к on-prem-серверу, не к облачному endpoint
Путь fallback — если облачная плоскость управления недоступна, on-prem-сервер обязан держать стену работающей с последней известной конфигурацией. Стена не может зависеть от облачной связности, чтобы отображать.

Плоскость управления в облаке

Ценность, которую облачная плоскость управления действительно даёт, как только плоскость данных корректно оставлена локальной:

Мультиобъектное управление — один интерфейс для NOC-оператора, управляющего стенами на дюжине объектов
Централизованная раскатка конфигурации — отправить новую именованную сцену на все объекты сразу
Видимость парка — статус здоровья и версий по всему хозяйству без обращения к каждому серверу

Ограничение, которое делает это безопасным: плоскость управления оперирует адресами и определениями, никогда — контентом. Облачная плоскость управления, которая говорит «помести источник 10.20.30.40 в плитку 3» — compliant. Облачная плоскость управления, которая ретранслирует видео с 10.20.30.40 — нет. Архитектура должна обеспечивать эту линию, а не просто задокументировать её.

Плоскость видео на объекте

On-prem-сервер делает работу, которая не может покинуть здание: принимает каждый источник, крутит композер, управляет дисплеями и держит полную локальную копию конфигурации, чтобы она пережила облачный сбой. Для регулируемого развёртывания on-prem-сервер — это ещё и граница air-gap: он может работать вообще без исходящего интернета, при просто недоступной облачной плоскости управления и стене, управляемой локально.

Это тест для любого вендора, заявляющего «гибрид»: отключите интернет — и стена обязана продолжать работать и оставаться локально управляемой. Если стена деградирует или UI управления становится недоступен, архитектура облачно-зависимая, а не гибридная.

KVM в гибридной модели

IP-KVM — случай, где on-prem-граница важна больше всего. KVM-сессия — это оператор, берущий живое управление компьютером-источником, самый чувствительный трафик на стене. В гибридной архитектуре KVM-сессия строго on-prem: облачная плоскость управления может знать, что KVM-маршрут существует и кто авторизован его использовать, но трафик клавиатуры, видео и мыши идёт полностью по локальной сети. Любой вендор, чей KVM-путь касается облака, не построил compliant-гибридную систему.

Где размещается Craft Wall

Craft Wall по своей архитектуре работает только on-premises. Композер, приём источников и полная конфигурация работают на commodity Linux-сервере внутри объекта. Браузерный UI управления отдаётся с того же on-prem-сервера, поэтому любое развёртывание может работать в изолированном контуре, вообще без облачной зависимости.

У Craft Wall нет облачной плоскости управления: управление и конфигурация остаются на on-prem-сервере, поэтому ничто — включая метаданные — не обязано покидать объект, а описанный выше тест с отключением интернета стена проходит уже в силу архитектуры.

См. референсную архитектуру NOC для on-prem-дизайна и сравнение восьми платформ — как вендоры различаются по вопросу облачной зависимости; это одна из самых резких разделительных линий в категории.

В заключение

Чисто облачная видеостена была разумной ставкой, которую регуляторные требования в значительной мере закрыли для диспетчерских регулируемых отраслей. Гибрид — не полумера, это правильная архитектура: облако делает то, в чём облако хорошо (мультиобъектное управление, централизованная раскатка), а on-prem-слой делает то, что требует регулирование (каждый пиксель остаётся в здании). Тест для заказчика простой и физический: отключите интернет — и стена продолжает работать. Если да — архитектура гибридная. Если нет — это облачно-зависимая система с гибридным лейблом.

Читать дальше: референсная архитектура NOC — on-prem-дизайн, видеостены с AI-обвязкой — почему on-prem-inference следует той же compliance-логике, и сравнение Craft Wall vs Userful — контраст по облачной зависимости в реальной оценке.

Частые вопросы

Что за паттерн «metadata-in-cloud, pixels-on-prem» для видеостен?

Архитектурный split: видео и конфигурация остаются on-prem (compliance-совместимо), а метаданные о состоянии стены, активности операторов, layout'ах и инвентаре источников идут в облачную control plane. Администраторы могут централизованно управлять раскладками в облаке и отправлять их на on-prem-стену, но операторы должны сохранять возможность входить в систему и управлять стеной локально, когда интернет-канал недоступен. Сами пиксели видео никогда не покидают сеть клиента. По нашей оценке, такой паттерн проходит проверку по GDPR, 152-ФЗ, FedRAMP или BSI C5 гораздо чаще, чем чисто облачная видеостена.

Почему cloud-only видеостена не прошла compliance-review?

Большинство регулируемых отраслей (энергетика, банки, здравоохранение, госсектор) классифицируют операционные видеопотоки как «high-sensitivity» или «критическая инфраструктура». Передача в облако — даже с подходящими сертификатами — попадает под действие регуляторных рамок (правила GDPR о передаче данных в третьи страны, локализация персональных данных по 152-ФЗ, критерии облачной безопасности BSI C5, авторизация FedRAMP на базовом уровне Moderate или High). По нашей оценке, именно поэтому чисто облачное управление почти не прижилось в диспетчерских регулируемых отраслей: заказчики там ожидают on-prem- или гибридных решений.

Как hybrid cloud видеостена справляется с GDPR?

Видеоданные — это персональные данные, когда они захватывают идентифицируемых людей. Hybrid-паттерн оставляет эти данные внутри GDPR-контролируемой среды оператора — в облако уходит лишь минимум эксплуатационных метаданных, и в них могут входить идентификаторы операторов, которые тоже являются персональными данными. Облачная control plane обрабатывает только данные состояния системы (layout'ы, ID операторов, URL источников) — никаких кадров, никакого face recognition output, никаких биометрических выводов. Европейские операторы обычно заключают договор об обработке данных (DPA, статья 28), охватывающий канал метаданных, включая идентификаторы операторов; само видео остаётся вне зоны ответственности провайдера.

Что идёт в облако, а что остаётся on-prem?

Облако: центральные копии учётных записей и ролей, описания layout'ов стены, метаданные инвентаря источников, копии audit-логов активности операторов (в них есть идентификаторы операторов), дистрибуция обновлений ПО, состояние координации мульти-площадок. On-prem: все кадры видео, весь capture (HDMI, NDI, RTSP), локальная control plane, которая исполняет команды операторов и продолжает аутентифицировать их при отключённом интернете, полная локальная копия конфигурации, все output биометрии / AI inference, все конфигурации customer-domain (сетевые ACL, креденшелы интеграций).

Hybrid cloud видеостена — это стандартная архитектура 2026?

По нашей оценке, в регулируемых отраслях проверку проходят гибридные или полностью on-prem-решения, а чисто облачные — редко. В нерегулируемом AV (корпоративные переговорные, образование, ритейл) облачное управление распространено, потому что проверка на соответствие там не является жёстким ограничением. Для изолированных развёртываний (оборона, атомная отрасль) полностью on-prem остаётся единственным вариантом. Выбор архитектуры, как правило, следует за регуляторной средой, а не за техническими предпочтениями.