Авторизованный удалённый доступ через VNC

Авторизованный удалённый доступ через VNC — это механизм, при котором подключение к рабочей станции пользователя возможно только после явного подтверждения со стороны самого пользователя.

Добрый день, уважаемые читатели )!

Решил разместить здесь один из проектов, реализованных в рамках работы в корпоративной сети.
Поступило требование ИБ - создать решение, в рамках которого подключение по протоколу VNC должно было следовать нескольким правилам :
1. все подключения должны фиксироваться на уровне корпоративной БД
2. доступ должен быть авторизован, пользователь должен видеть кто к нему подключается.
Принимать решение "разрешить подключение или нет" должен именно получатель услуги.
3. Подключение должно иметь уникальный пароль, который пользователь должен сообщить сотруднику поддержки по средствам корпоративной связи, например по телефону.

Так появился механизм, который по сути является «шлюзом доступа» (AccessGate) между инженером и рабочей станцией пользователя.

Если описывать максимально просто, то схема работы выглядит так:

1. Инженер инициирует подключение к рабочей станции пользователя

2. На стороне пользователя появляется окно с запросом на подключение

3. Пользователь видит, кто к нему подключается, и принимает решение

4. После подтверждения устанавливается VNC-сессия

5. В момент подключения создаётся запись в базе данных

6. При завершении работы фиксируется время отключения

То есть подключение делится на два этапа:

— авторизация пользователем

— фактическое подключение инженера

Без первого этапа второй невозможен.

Ниже привел скрин экрана рабочей программы, именно это видит пользователь после возникновения таблички
"Разрешить доступ..."

Как выглядит структура данных - которые отправляются BD

CREATE TABLE public.vnc_stat (
    session_id      TEXT PRIMARY KEY,

    -- данные пользователя (куда подключились)
    dst_host        TEXT,
    dst_ip          TEXT,
    dst_mac         TEXT,
    dst_uname       TEXT,

    -- данные инженера (кто подключился)
    eng_ip          TEXT,
    eng_mac         TEXT,
    eng_uname       TEXT,

    -- тайминги
    connected       TIMESTAMP,
    disconnected    TIMESTAMP
);

Ключевой частью решения является взаимодействие между VNC и приложением ассистента через DBus.

Стандартный x11vnc из коробки не умеет работать по такой схеме, поэтому был доработан модуль, который при определённых событиях вызывает методы DBus.

Таким образом получилось разделить ответственность:

— VNC отвечает за сетевое подключение

— ассистент отвечает за логику авторизации и учёт

По сути, VNC перестаёт быть «самостоятельным инструментом» и становится источником событий, а вся логика переносится в отдельное приложение.

Это позволило уйти от жёсткой связки и сделать нормальное межпроцессное взаимодействие.

Ниже привожу схему - как взаимодействия между x11 VNC и AccessGate

При работе x11vnc генерирует события, которые отправляются в ассистент через DBus.

Основные события:

— requestOpenAssistantWindow(ip)  
  попытка подключения инженера  

— requestConfirmAssistantConnected(ip)  
  инженер реально подключился  

— requestRejectAssistantConnection(ip)  
  неуспешная попытка (например, неверный пароль)  

— requestCloseAssistantWindow(ip)  
  завершение сессии или потеря соединения

Без такого разделения невозможно корректно реализовать:

1. авторизацию на стороне пользователя

2. контроль момента реального подключения

3. корректное логирование

Если писать в БД на этапе попытки — появляются «мусорные» записи. Если не разделять события — невозможно понять, подключился инженер или нет. В результате DBus здесь играет роль шины событий между VNC и ассистентом, через которую проходит вся логика работы системы.

По сути - в этом вся магия LINUX ,почему мне он и нравится для работы в "корпоративной" среде . По сути сама архитектура ОС является не препятствием , а фундаментом работы решения.

В итоге получилось решение, которое закрывает изначальные требования ИБ, но при этом не усложняет жизнь ни пользователю, ни сотруднику поддержки.
Пользователь всегда понимает, что происходит:
1.кто к нему подключается

2.когда происходит подключение и может в любой момент принять решение

С другой стороны, техническая поддержка получает нормальный инструмент для работы:

1.без «ручных» схем

2.без потери контроля с прозрачной историей всех подключений

3. Все это дело записывается в BD, благодаря чему, как ИБ так и другие отделы могут отследить историю подключений, что в свою очередь делает расследование в случае непонятных ситуаций - прозрачнее и понятнее.

Отдельный плюс вся логика вынесена в отдельный слой, а VNC используется только как транспорт. Это позволяет при необходимости дорабатывать решение под конкретную инфраструктуру без переписывания всего с нуля.

Исходники, скорее всего, выложу отдельно на git - кому нужно, можно будет использовать как основу.
Но, как показывает практика, почти всегда требуется адаптация под конкретную инфраструктуру.

Если у вас, уважаемые читатели, есть интерес к внедрению или доработке под задачи - можно обсудить отдельно:

Telegram:@SAANEE2000
Email:mail@anvilstation.com

Авторизованный удалённый доступ через VNC

AccessGate

Схема работы

Взаимодействие между x11 VNC и AccessGate через шину DBUS

Заключение

Комментарии

Кузница

Категории