«Открыть RDP/SSH/VNC из браузера» звучит просто, но на практике за этим стоят разные цели: кому-то нужен безопасный bastion host с контролем доступов и журналами, кому-то — быстрый web-клиент для пары серверов, а кому-то — изоляция рабочих сессий в одноразовых окружениях.
Чаще всего в shortlist попадают три решения: Kasm Workspaces, Apache Guacamole и noVNC. У них похожий UX (всё в браузере), но очень разная «начинка» и зона ответственности.
Ниже — практичный разбор без маркетинга: как они устроены, где у каждого сильные и слабые стороны, и как выбрать под требования по browser-based access, 2FA, audit и session recording.
Что именно сравниваем: одинаковые слова — разные продукты
Важно сразу развести понятия: эти инструменты пересекаются по интерфейсу, но решают задачи на разных уровнях.
- Kasm Workspaces — платформа управляемых рабочих пространств (часто контейнерных) + веб-доступ. Это не просто «клиент к RDP», а способ выдавать окружения, задавать политики и контролировать жизненный цикл сессии.
- Apache Guacamole — gateway/прокси для интерактивного удалённого доступа (RDP/VNC/SSH) через браузер. По роли ближе всего к bastion host для админских сессий.
- noVNC — веб-клиент для VNC. По сути это компонент (WebSocket↔VNC), который встраивают в свою схему. Авторизация, ACL, аудит и запись — обычно «внешняя обвязка».
Архитектура на пальцах: где живёт сессия и кто кого проксирует
Kasm Workspaces
Типовая логика Kasm: пользователь логинится в портал и запускает workspace (контейнер с браузером/desktop/инструментами). Сессия живёт в изолированной среде, а в браузер отдаётся интерактивный поток. Такой подход хорош, когда вы хотите дать доступ к рабочей среде, а не к конкретному серверу по RDP/VNC.
Если цель — подрядчикам «рабочий стол в браузере» без раздачи VPN и без привязки к их локальному ПК, Kasm часто точнее попадает в задачу, чем Guacamole/noVNC.
Apache Guacamole
Guacamole — это веб-приложение и демон guacd, который держит соединение до целевой машины (RDP/SSH/VNC) и транслирует его в веб. С точки зрения сети это классический jump/bastion: снаружи у вас один URL, а внутрь guacd ходит по нужным портам в приватные подсети.
Плюс: можно полностью убрать прямую видимость RDP/SSH/VNC из интернета. Минус: безопасность и контроль сильно зависят от того, как вы настроили учётки, хранение секретов, ACL, сегментацию сети и логирование.
noVNC
noVNC обычно живёт рядом с VNC-сервером или прокси, который делает VNC доступным через WebSocket. Он минималистичен: сам по себе не является бастионом и не закрывает вопросы доступа «кто/куда/почему», если это не построено вокруг него.
Guacamole и noVNC в первую очередь решают «доступ». Kasm решает «контролируемую рабочую среду», и доступ становится лишь частью общей политики безопасности.
Практический совет: для bastion/gateway обычно удобнее выделять отдельную машину (или пару) в DMZ/edge-сегменте, с предсказуемыми правилами фаервола и обновлений. Часто это проще всего начать на VDS с отдельной сетью и понятной моделью доступов.
Протоколы и сценарии: RDP, SSH, VNC и реальная жизнь
По протоколам различия обычно такие:
- Apache Guacamole: RDP/SSH/VNC — основной профиль использования.
- noVNC: только VNC (и всё, что вы сможете «превратить» во VNC).
- Kasm Workspaces: чаще даёт собственное окружение в браузере (desktop/apps). Интеграции с внешними ресурсами бывают, но это не «универсальный клиент ко всему».
Отсюда и практичный выбор:
- Единый web-доступ админам к Windows (RDP) и Linux (SSH) — чаще выигрывает Apache Guacamole.
- Нужно быстро открыть одну VNC-консоль (виртуалка, лабораторный стенд, GUI-сервис) — часто достаточно noVNC.
- Нужно выдавать изолированные сессии с инструментами (браузер, терминал, утилиты), стандартизировать среду и упростить offboarding — смотрят в сторону Kasm Workspaces.
Безопасность: 2FA, bastion host, секреты и границы доверия
Модель «bastion host»
Под bastion host обычно подразумевают единый входной пункт, где централизована аутентификация, есть MFA, понятны права доступа, а внутренние RDP/SSH/VNC не торчат наружу.
Apache Guacamole в эту роль ложится естественно: он и есть «шлюз». noVNC может быть частью бастиона, но бастионом не становится без внешней обвязки (reverse proxy, SSO, ACL, сегментация). Kasm Workspaces чаще играет роль «контролируемой рабочей среды» и может дополнять бастион: например, когда доступ в прод-сеть разрешён только из выданного админского окружения.
2FA/MFA: где реально включать
По MFA важно разделять «в продукте есть 2FA» и «как вы сделаете это в проде». На практике почти всегда работают три подхода:
- MFA на уровне IdP/SSO (самый управляемый вариант): продукт доверяет внешней аутентификации, а MFA и политики доступа живут в одном месте.
- MFA на уровне reverse proxy: когда продукт не дружит с вашим SSO или нужен быстрый контур защиты перед веб-частью.
- Встроенная 2FA в продукте: годится для небольших установок, но часто сложнее масштабировать по политикам, группам и жизненному циклу пользователей.
Для Guacamole и Kasm на практике чаще удобнее SSO-подход (особенно если людей больше «пары админов»). Для noVNC почти всегда придётся строить внешний контур авторизации.
Секреты к целевым серверам: типовые ошибки
Самая болезненная часть «RDP/SSH/VNC из браузера» — где живут пароли/ключи и кто может их увидеть.
- Хранить RDP-пароли «как есть» в конфигурации и не иметь ротации.
- Использовать общие логины на целевых хостах вместо персональных учёток и групп.
- Разрешать пользователю подключаться «куда угодно», если он знает адрес (без ACL и сетевых ограничений).
- Не ограничивать исходящие соединения со стороны gateway (шлюз превращается в удобный pivot).
Минимальный «санитарный набор» для бастиона: сегментировать сеть, ограничить исходящий доступ шлюза только к нужным подсетям/портам, держать отдельные учётки, и продумать offboarding (отзыв доступа, удаление пользователя, ротация секретов).
Аудит и логирование: кто заходил, что делал, и можно ли это доказать
Ключевой момент: логи browser-gateway — это только верхний слой. Для расследований и комплаенса нужна цепочка событий от точки входа до целевой ОС.
Apache Guacamole
Сильная сторона — централизованный факт подключений: кто, когда, к какому соединению. Но аудит действий внутри упирается в протокол и возможности целевой ОС. В SSH почти всегда нужны дополнительные серверные журналы и контроль команд. В RDP/VNC обычно важны события на Windows/Linux и отдельная стратегия по записи экрана (если она требуется).
Kasm Workspaces
Аудит обычно лучше раскрывается в сценарии «все работают внутри выданного окружения»: проще однозначно связать пользователя с сессией, задавать таймауты, управлять жизненным циклом и сокращать время жизни доступа. Для многих организаций это проще, чем «дожимать» до комплаенса чистый RDP-шлюз.
noVNC
noVNC сам по себе почти ничего не даёт для аудита: вы получите логи веб-доступа на уровне reverse proxy и инфраструктуры вокруг, а смысловые события придётся собирать на VNC-сервере и целевой ОС.
Если вам нужен аудит «ради доказуемости», стройте цепочку: IdP → gateway/reverse proxy → целевая ОС → централизованное хранилище логов с ретеншном.
Session recording: ожидания vs реальность
Под session recording часто понимают «видео всей сессии». На практике полезно разделять три класса записей:
- Запись экрана (GUI-сессии RDP/VNC и браузерные desktops).
- Запись команд/ввода (SSH): часто полезнее видео из-за поиска, диффа и контекста.
- Событийный аудит: кто подключался, куда, на сколько, откуда.
У Guacamole нередко ожидают «как у enterprise bastion», но дальше упираются в ограничения протоколов и необходимость доп.инструментов на уровне ОС. У Kasm контроль и запись логичнее в сценарии, где работа реально происходит внутри платформы. У noVNC всё придётся собирать «из конструктора».
Производительность и UX: латентность, раскладки, буфер обмена, файлы
Чтобы решение не возненавидели пользователи, заранее проверьте типовые болевые точки:
- Латентность: browser-based доступ чувствителен к RTT и потерям. Иногда выгоднее поставить gateway ближе к целевым серверам (в том же сегменте/ДЦ).
- Клавиатура и раскладки: в VNC чаще всплывают проблемы с сочетаниями и нестандартными раскладками.
- Буфер обмена: это одновременно удобство и канал утечки. В платформенном подходе политики обычно навязывать проще, чем в самодельной обвязке.
- Файловый обмен: «перекинуть файл» — самый частый запрос. Решайте заранее, разрешаете ли вы это и как именно (по ролям, с журналированием, с ограничениями типов/размеров).
Отдельно проверьте заголовки и базовую веб-гигиену на точке входа. Если вы поднимаете reverse proxy, полезно свериться с практиками по заголовкам безопасности: настройка HTTP security headers для Nginx и Apache.
Эксплуатация: обновления, бэкапы, HA и “что будет, если упадёт”
noVNC
Сущностей мало, но ответственности много: вы сами выбираете VNC-сервер, WebSocket-прокси, авторизацию, TLS-терминацию, логи и ротацию. Плюс — гибкость. Минус — легко собрать небезопасную схему, если нет строгих сетевых ограничений и контроля доступа.
Apache Guacamole
Один продукт, который удобно стандартизировать как сервис. Нужны бэкапы конфигурации и БД (если используется), тест обновлений, план отката, контроль прав доступа и интеграций с каталогом пользователей. Для малого/среднего масштаба часто это «золотая середина».
Kasm Workspaces
Платформа тяжелее: больше компонентов, образы рабочих пространств, политики, интеграции, лимиты ресурсов. Зато и эффект другой: вы управляете не только доступом, но и средой. Для продовой эксплуатации заранее определите квоты, изоляцию, обновления и совместимость образов.
Матрица выбора: что ставить под вашу задачу
Ниже — шпаргалка по соответствию целей.
Выбирайте Kasm Workspaces, если
- нужны изолированные рабочие сессии «выдал — отозвал — уничтожил»;
- важны политики (копипаст, файлы, таймауты, контроль окружения);
- вы хотите давать доступ к инструментам в безопасной среде, а не к серверам напрямую;
- нужно снизить риск утечек с админских ноутбуков.
Выбирайте Apache Guacamole, если
- нужен понятный bastion host для RDP/SSH/VNC через браузер;
- надо централизовать вход и убрать наружу торчащие порты;
- важны ACL на подключения и модель «пользователь → список соединений»;
- вы готовы отдельно продумать глубокий аудит и запись (на уровне ОС и лог-инфраструктуры).
Выбирайте noVNC, если
- нужен только VNC в браузере как компонент;
- у вас уже есть портал/SSO, и вы хотите контролировать всю обвязку сами;
- сценарий узкий: одна-две консоли, временный доступ, лаборатория.
Референс-схемы внедрения (без привязки к вендорам)
Схема 1: Guacamole как bastion host + сегментация сети
Один публичный вход (TLS), дальше — доступ к внутренним RDP/SSH/VNC по строго разрешённым направлениям. Логи входа и событий подключений уходят в централизованное хранилище. Доступ выдаётся по группам и ролям, а не через общий пароль.
Схема 2: Kasm как «админский рабочий контур»
Админы заходят в Kasm (через SSO с MFA), получают рабочее пространство (терминал, браузер, утилиты) и уже из него ходят в прод. В идеале — без прямого доступа с ноутбука в прод-сеть. Подход хорошо уменьшает blast radius и стандартизирует среду.
Схема 3: noVNC для точечного GUI-доступа
Reverse proxy с аутентификацией и короткими токенами, дальше WebSocket к noVNC, далее — VNC. Сеть ограничена, ретеншн логов определён, есть понятный процесс выдачи/отзыва доступа. Иначе noVNC легко превращается в «дырку с GUI».
Чеклист перед запуском в прод
- Только HTTPS и понятная модель доверия к сертификатам.
- MFA там, где это реально контролируется (обычно IdP/SSO).
- Сегментация сети: пользователи не должны видеть целевые RDP/SSH/VNC напрямую.
- Роли и минимальные привилегии: отдельные учётки, без общих паролей.
- Логи: кто вошёл, кто подключался, откуда, сколько длилось, куда.
- Offboarding: удаление пользователей, отзыв прав, ротация секретов.
- План отказа: что будет при падении gateway, как восстановиться, как быстро ограничить доступ в инцидент.
Итог: коротко о выборе
Kasm Workspaces выбирают, когда нужен управляемый «browser-based рабочий контур» с изоляцией и политиками. Apache Guacamole — когда нужен универсальный «RDP/SSH/VNC через браузер» и удобный бастионный шлюз. noVNC — когда нужен именно VNC-вебклиент как строительный блок, а всю безопасность, доступы и аудит вы выстраиваете вокруг.
Если вы публикуете такой портал в интернет, не экономьте на сертификатах и политике их обновления: для внешних контуров обычно логично брать отдельные SSL-сертификаты под нужные домены/поддомены и заранее продумывать HSTS и набор security headers.
