Онлайн-сессии психолога на своём видеосервере: без чужих записей разговора

MAATRIX

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

Чем чужой видеосервис отличается от кабинета психолога

Оффлайн-кабинет вы выбираете сами: звукоизоляция, кто имеет ключи, что происходит с записями на диктофоне, если вы вообще его используете. Клиент доверяет не только вам, но и обстановке, в которой проходит сессия.

Публичный сервис видеосвязи — это чужая инфраструктура с чужими правилами. Вы регистрируете аккаунт, соглашаетесь с пользовательским соглашением, которое может измениться в любой момент без вашего участия, и дальше весь трафик сессии идёт через сервера, которыми управляет кто-то другой. Даже если сама компания добросовестна, вы физически не можете аудировать, что происходит с потоком на её стороне: какие метаданные звонка сохраняются, как долго, кто из сотрудников сервиса технически имеет доступ к логам, что происходит при запросе от третьей стороны.

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

Что технически происходит с потоком на стороне провайдера

Разберём по шагам, что видит инфраструктура любого видеосервиса, даже когда «запись» в интерфейсе выключена.

Сигнальный сервер. Прежде чем видео и звук пойдут между вами и клиентом, оба устройства обмениваются служебными сообщениями через сервер провайдера: кто подключился, когда, из какой сети, сколько длился звонок, кто вышел первым. Это метаданные, а не содержание разговора — но по ним восстанавливается график ваших консультаций, что само по себе конфиденциальная информация о клиенте.

Медиарелей (TURN). Прямое P2P-соединение между двумя участниками работает не всегда — мешают NAT и файрволы на обеих сторонах. Когда прямая связь не устанавливается, аудио и видео идут транзитом через relay-сервер провайдера. В этот момент поток физически проходит через чужую инфраструктуру, даже если он зашифрован end-to-end на уровне протокола — сервер видит факт передачи, объём трафика и продолжительность.

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

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

Своя система видеосвязи: архитектура и принцип

Решение — развернуть видеоконференц-систему на сервере, который арендуете и администрируете вы. Практический выбор для одного специалиста или небольшой практики — Jitsi Meet: открытый код, не требует лицензии, работает в браузере без установки приложения клиентом.

Из чего состоит система:

• Prosody — сигнальный сервер на базе XMPP. Именно он обрабатывает служебный обмен «кто подключился, когда, к какой комнате» — и это ваш сервер, а не чужой.
• Jicofo — координатор конференции, управляет распределением потоков между участниками.
• JVB (Jitsi Videobridge) — медиасервер, через который идёт видео и звук. Это ваш аналог того самого relay-сервера из предыдущего раздела — только теперь релей физически находится на арендованной вами машине.
• Веб-интерфейс — то, что видит клиент в браузере: комната с видео, без сторонних логотипов и без необходимости регистрироваться в чужом сервисе.

Ключевое отличие от облачного сервиса: весь путь пакета — от сигнала до медиапотока — остаётся в пределах вашей инфраструктуры. Запись по умолчанию выключена и требует отдельного модуля (Jibri), который вы либо не разворачиваете вообще, либо включаете осознанно и настраиваете сами. Логи ротируются по вашим правилам, а не по правилам, скрытым в чужом соглашении.

Честно о минусе: разворачивание и поддержка своей системы — это ответственность, которую раньше нёс провайдер. Обновления безопасности, мониторинг доступности, TLS-сертификаты — теперь ваша задача или задача того, кто администрирует сервер по вашему поручению. Для одного специалиста это несколько часов настройки один раз и минут пять внимания в месяц на обновления — не постоянная нагрузка, но и не «поставил и забыл».

Установка Jitsi Meet на сервере: пошагово

Понадобится VPS с публичным IP и доменом, указывающим на этот IP (A-запись). Минимально достаточно 2 vCPU и 4 ГБ RAM на одного специалиста с редкими одновременными звонками — если планируете групповые сессии на несколько человек одновременно, закладывайте больше по CPU: видеомост нагружает процессор пропорционально числу участников и разрешению.

Официальный способ разворачивания — docker-compose из репозитория проекта jitsi/docker-jitsi-meet. Порядок действий:

git clone https://github.com/jitsi/docker-jitsi-meet
cd docker-jitsi-meet
cp env.example .env

В .env задайте домен и ключевые параметры:

CONFIG=~/.jitsi-meet-cfg
HTTP_PORT=80
HTTPS_PORT=443
PUBLIC_URL=https://video.вашдомен.ru

# отдельно и явно — запись выключена
ENABLE_RECORDING=0

Создайте директории под конфиги и поднимите контейнеры:

mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}
docker compose up -d

TLS-сертификат — через Let's Encrypt, встроенный скрипт есть в самом проекте:

./gen-letsencrypt-cert.sh

После этого комната для сессии доступна по прямой ссылке вида https://video.вашдомен.ru/имя-комнаты. Клиенту не нужен аккаунт — заходит по ссылке в браузере. Чтобы посторонний не мог зайти в комнату случайно или по подобранной ссылке, включите защиту паролем на уровне модерации: как хост вы задаёте пароль комнаты прямо в интерфейсе перед звонком, и он не хранится на стороне третьей компании.

Отдельный нюанс безопасности — публичный доступ к созданию новых комнат. Для практики с одним специалистом стоит закрыть анонимное создание конференций и включить JWT-аутентификацию модератора (в конфиге Prosody), чтобы комнату мог открыть только вы, а не любой, кто угадал URL. Настройка описана в конфигурации prosody/config — она чуть менее тривиальна, чем базовая установка, поэтому если не готовы разбираться в XMPP-конфигах самостоятельно, для этого шага уже стоит подключить администратора.

TURN/coturn, NAT и стабильность связи

Здесь та деталь, которую часто упускают при переезде на свою инфраструктуру: если у вас или у клиента NAT не пропускает прямое соединение, в игру вступает TURN-сервер — тот самый релей, который в облачном сервисе принадлежал провайдеру. В связке docker-jitsi-meet TURN обычно поднимается тем же JVB, но при нестабильной связи из-за жёсткого NAT на стороне клиента (например, мобильный интернет) стоит развернуть отдельный coturn на сервере и явно указать его в конфиге JVB:

JVB_TURN_HOST=video.вашдомен.ru
JVB_TURN_PORT=443
JVB_STUN_SERVERS=stun.l.google.com:19302

Практический момент: используемые для медиапотока порты UDP должны быть открыты на файрволе сервера — по умолчанию JVB слушает диапазон UDP-портов, и если провайдер сервера или ваш собственный файрвол режет UDP, звонки будут либо не устанавливаться, либо соединение будет постоянно рваться и переустанавливаться. Если сталкиваетесь с обрывами именно у клиентов на мобильной сети или за корпоративным файрволом — это первое место для диагностики.

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

Записи сессий: включать или нет и как хранить

Самое частое допущение о своём видеосервере — что раз сервер свой, надо на нём же и записывать все сессии «на всякий случай». Это отдельное решение, а не следствие переезда на self-hosted, и относиться к нему стоит настолько же осторожно, как и к записи на диктофон в очном кабинете.

По умолчанию в конфигурации выше запись выключена (ENABLE_RECORDING=0) — это правильная точка отсчёта. Модуль Jibri, который добавляет запись и стриминг, разворачивается отдельным контейнером и требует дополнительных ресурсов (по сути, он открывает виртуальный браузер и захватывает экран конференции), так что случайно включить запись «по умолчанию» технически не получится — вы делаете это осознанным дополнительным шагом.

Если запись всё же нужна — например, для супервизии с вашим собственным супервизором по вашей специальности, — держите три правила:

• Информированное согласие клиента до, а не после — отдельным пунктом, не мелким шрифтом в общей оферте.
• Шифрование файла записи на диске, а не просто ограничение прав доступа к папке: диск сервера физически читается при определённых сценариях (утеря доступа хостером, изъятие носителя), и права на файловую систему это не остановят. О том, что именно защищает шифрование диска и какие сценарии оно не закрывает, — в разборе шифрования дисков.
• Хранение по локации, соответствующей закону об охраняемой законом тайне и месту жительства клиента — если работаете с российскими клиентами и персональными данными, вопрос юрисдикции сервера разобран отдельно в статье про законное размещение сервера с персональными данными.

Отдельно: если записи не нужны вообще — не держите инфраструктуру «на всякий случай». Модуль Jibri, который не используется, это лишняя поверхность для потенциальных уязвимостей и лишний контейнер, который нужно обновлять. Меньше компонентов — меньше того, что может сломаться или стать точкой утечки.

Если вы уже сравнивали Jitsi Meet с альтернативной open-source платформой BigBlueButton для организации приёма — у неё смещённый в сторону вебинаров и групповых занятий набор функций (доска, брейкаут-комнаты), и для формата «один на один» она обычно избыточна. Разница разобрана в статье Jitsi Meet или BigBlueButton — что выгоднее и когда. Подробный пошаговый гайд по установке с нуля, включая базовую настройку модерации, — в статье как установить и настроить Jitsi Meet на VPS.

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