Примерно в 2022-2023 годах несколько вендоров видеостен сделали ставку на облачно-управляемое будущее — конфигурация стены, маршрутизация источников, иногда само видео, всё через SaaS-плоскость управления. К 2026 году у этой ставки чёткий вердикт: чисто облачный подход провалил compliance-проверку в каждой регулируемой отрасли, куда пытался зайти. Выжил — и стал теперь архитектурой по умолчанию — гибридный паттерн. Эта статья разбирает, что размещается в облаке, что остаётся на объекте, и почему это деление — не компромисс, а правильный дизайн.
Почему чисто облачное управление видеостеной провалилось
Чисто облачная подача на бумаге привлекательна: управляй каждой стеной на каждом объекте из одного браузера, раскатывай обновления централизованно, нет on-prem-сервера для обслуживания. Проблема в том, что видеостена в диспетчерской, NOC или SOC несёт контент, который регуляторы не разрешают выпускать за пределы здания.
NOC-стена показывает живую сетевую топологию и данные о сбоях, влияющих на клиентов. SOC-стена показывает живые фиды камер безопасности и SIEM-тревоги. Диспетчерская энергетики показывает SCADA-телеметрию с критической инфраструктуры. Маршрутизация чего-либо из этого через сторонее облако — даже просто как управляющий сигнал, который подразумевает нижележащие данные — запускает compliance-проверку, которую чисто облачные архитектуры пройти не могут.
Четыре стены compliance
- GDPR (ЕС). Живые фиды камер с идентифицируемыми лицами — персональные данные по статье 4(1). Обработка этих данных через плоскость управления, размещённую вне ЕС — или облачным провайдером с US-штаб-квартирой, подпадающим под US CLOUD Act — требует Schrems-II-safeguards, которые большинство объектов установить не могут.
- ФЗ-152 и ФЗ-187 (Россия). Локализация персональных данных требует, чтобы данные граждан РФ обрабатывались на серверах в России. ФЗ-187 добавляет правила критической информационной инфраструктуры — энергетика, транспорт, финансы, госуправление обязаны держать операционный слой в стране и часто air-gapped.
- FedRAMP и DoD impact levels (федеральный сегмент США). Видеостена на федеральном объекте, обрабатывающая контролируемую или классифицированную информацию, не может маршрутизироваться через коммерческую SaaS-плоскость управления без авторизации, которую закупочный отдел почти никогда не получает.
- BSI C5 (Германия). Немецкий федеральный каталог критериев облачной безопасности задаёт планку, которой большинство универсальных SaaS-плоскостей управления не соответствуют, толкая развёртывания немецкого госсектора к on-prem или суверенно-облачным дизайнам.
Любого одного из этих достаточно, чтобы дисквалифицировать чисто облачную видеостену из регулируемого развёртывания. На практике большинство крупных закупщиков диспетчерских сталкиваются хотя бы с одним.
Гибридный паттерн — что где размещается
Гибридная архитектура делит систему по чёткой линии: плоскость управления может жить в облаке; плоскость данных остаётся на объекте. Mersive артикулировал это деление рано, и теперь оно — категорийный default.
Что может жить в облаке
- Сам 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-prem-first по дизайну. Композер, приём источников и полная конфигурация работают на commodity Linux-сервере внутри объекта. Браузерный UI управления по умолчанию отдаётся с того же on-prem-сервера — что означает, что базовое развёртывание и есть air-gapped-случай, вообще без облачной зависимости.
Облачная плоскость управления — это опциональный слой сверху, для заказчиков с несколькими объектами, которым нужно централизованное управление — и он следует строгому делению выше: только метаданные и управление, никогда видео, с полностью функциональным 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. Операторы аутентифицируются через облако, управляют layout'ами там, а команды уходят обратно на on-prem стену. Сами пиксели видео никогда не покидают сеть клиента. Этот паттерн проходит GDPR, ФЗ-152, FedRAMP, BSI C5 review там, где чистый cloud video wall падает.
Почему cloud-only видеостена не прошла compliance-review?
Большинство регулируемых отраслей (энергетика, банки, здравоохранение, госсектор) классифицируют операционные видеопотоки как «high-sensitivity» или «критическая инфраструктура». Передача в облако — даже с подходящими сертификатами — триггерит compliance-фреймворки (GDPR data localisation, ФЗ-152 локализация ПДн, BSI C5 controls для критической инфраструктуры, FedRAMP impact-level Moderate / High). Cloud-only вендорам пришлось либо уйти из регулируемых рынков, либо разворачиваться в hybrid.
Как hybrid cloud видеостена справляется с GDPR?
Видеоданные — это персональные данные, когда они захватывают идентифицируемых людей. Hybrid-паттерн оставляет эти данные внутри GDPR-контролируемой среды оператора — в облако уходят только не-идентифицирующие метаданные. Облачная control plane обрабатывает только данные состояния системы (layout'ы, ID операторов, URL источников) — никаких кадров, никакого face recognition output, никаких биометрических выводов. Европейские операторы обычно требуют DPA (Data Processing Agreement), покрывающий только metadata-канал; остальное — out of scope.
Что идёт в облако, а что остаётся on-prem?
Облако: identity / access management, описания layout'ов стены, метаданные инвентаря источников, audit-логи активности операторов, дистрибуция обновлений ПО, состояние координации мульти-площадок. On-prem: все кадры видео, весь capture (HDMI, NDI, RTSP), локальная control plane, исполняющая команды операторов, все output биометрии / AI inference, все конфигурации customer-domain (сетевые ACL, креденшелы интеграций).
Hybrid cloud видеостена — это стандартная архитектура 2026?
Для регулируемых отраслей — да, hybrid заменил cloud-only как buyer-acceptable default. Для не-регулируемого AV (корпоративные boardroom, образование, retail) чистое cloud-managed развёртывание продолжает доминировать, потому что compliance-review не является binding constraint. Чистый on-prem всё ещё выигрывает air-gap развёртывания (оборонка, ядерная отрасль). Архитектурный выбор сейчас сильно коррелирует с регуляторной средой, а не техническими предпочтениями.