Архитектура безопасности Remio — без прикрас.

§01 · Краткое содержание

Remio — приложение удаленного рабочего стола, построенное на архитектуре с нулевым разглашением и прямыми соединениями между устройствами. Содержимое экрана, данные ввода и потоки звука защищены сквозным шифрованием между устройствами по отраслевому стандарту DTLS-SRTP — той же модели безопасности, на которую опирается любой продукт на основе WebRTC. В отличие от централизованных решений, сервер подключений Remio лишь помогает установить первоначальное соединение — он никогда не видит, не обрабатывает и не хранит данные сеанса.

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

§02 · Модель угроз

Архитектура безопасности Remio рассчитана на ряд сценариев угроз, актуальных для использования удаленного рабочего стола как в корпоративной, так и в личной среде. Мы прямо говорим, от чего защищаем и где проходят границы доверия.

От каких угроз мы защищаем

• Прослушивание. Весь мультимедийный трафик (видео, звук) и каналы данных (ввод, клавиатура, курсор) шифруются с помощью SRTP и DTLS соответственно. Наблюдатель в сети видит только зашифрованные пакеты и не может восстановить содержимое сеанса.
• Атака «человек посередине» (MITM). Рукопожатие DTLS с проверкой отпечатка сертификата не дает перехватить соединение. Канал подключения использует TLS 1.3 с совершенной прямой секретностью.
• Компрометация сервера. Даже если наш сервер подключений полностью скомпрометирован, злоумышленники получат доступ лишь к метаданным подключения (IP-адреса, временные метки). Содержимое сеанса никогда не передается через наши серверы и не хранится на них.
• Несанкционированный доступ. Для создания пары нужно отсканировать QR-код хоста, ввести ID устройства и PIN-код, которые он показывает, или войти в одну и ту же учетную запись Remio на обоих устройствах. Базы данных учетных данных, доступной удаленно, для атаки не существует.
• Кража учетных данных. Нет паролей, нет учетных записей, нет центрального хранилища учетных данных. Доверие к устройству устанавливается созданием пары по PIN-коду; токены сеанса (JWT) недолговечны и привязаны к устройству.
• Повторное воспроизведение сеанса. Встроенная в SRTP защита от повторов и порядковые номера DTLS не позволяют повторно воспроизвести перехваченные пакеты.
• Атаки на цепочку поставок. Все исполняемые файлы Remio подписаны кодом. Сборки для macOS нотаризуются Apple. Сборки для iOS распространяются исключительно через App Store.

Границы доверия

Наша модель угроз явно определяет три границы доверия:

1. Граница устройства. Каждое устройство получает доверие только после проверки PIN-кода. Защита на уровне ОС (песочница и защищенное хранилище каждой системы, например связка ключей) защищает данные на устройстве.
2. Граница сети. Все передаваемые данные шифруются. Мы исходим из того, что сеть враждебна.
3. Граница сервера. Наши собственные серверы считаются недоверенными ретрансляторами. Они помогают установить соединения, но не могут просматривать содержимое.

§03 · Обзор архитектуры

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

Плоскость подключения и плоскость данных

Единственная задача сервера подключений — передавать предложения и ответы SDP и кандидатов ICE между устройствами при установке соединения. После установки прямого соединения сервер подключений больше не участвует.

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

§04 · Уровни шифрования

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

Совершенная прямая секретность

Каждый сеанс Remio создает уникальный набор недолговечных ключей шифрования с помощью обмена ключами ECDHE.

• Компрометация текущего ключа сеанса не раскрывает прошлые сеансы.
• Компрометация текущего ключа сеанса не раскрывает будущие сеансы.
• Каждая пара ключей существует только в течение одного сеанса.
• Ключи никогда не записываются на диск — они существуют только в памяти.

Наборы шифров

# Signaling — TLS 1.3 cipher suites (in order of preference)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Media — SRTP protection profile (WebRTC industry default)
SRTP_AES128_CM_SHA1_80   # AES-128 counter mode, HMAC-SHA1-80 auth

# DTLS certificates
Self-signed ECDSA (P-256), verified out-of-band via SDP fingerprints

Смена ключей

Ключи меняются автоматически на следующих границах:

• Начало сеанса. Новое рукопожатие DTLS создает новые ключи для каждого подключения.
• Получение ключей SRTP. Ключи мультимедиа выводятся из рукопожатия DTLS и уникальны для каждой дорожки.
• Повторное подключение. Если сеанс прерван и подключен заново, происходит полностью новый обмен ключами.

§05 · Аутентификация и создание пары

Remio намеренно избегает традиционной аутентификации по имени пользователя и паролю. Вместо этого мы используем модель создания пары устройств по PIN-коду, которая устраняет самые частые векторы атак в ПО для удаленного рабочего стола.

Создание пары по PIN-коду

Когда клиент хочет подключиться к хосту в первый раз, процесс выглядит так:

1. Хост показывает на экране короткий цифровой PIN-код (или QR-код).
2. Клиент вводит PIN-код, который по каналу подключения отправляется на хост.
3. Хост проверяет PIN-код и подтверждает или отклоняет создание пары.
4. При успехе устанавливается отношение доверия между устройствами.
5. Последующие подключения с того же устройства не требуют повторного создания пары.

Модель доверия к устройствам

После создания пары каждое устройство определяется уникальным ID устройства. Хост хранит локальный список доверенных устройств. Это отношение доверия:

• Хранится локально только на устройстве-хосте, в защищенном хранилище, которое предоставляет его система, — связка ключей на Mac, зашифрованное системное хранилище в Windows, закрытый файл в Linux.
• Никогда не передается — серверу неизвестно, какие устройства доверенные.
• Может быть отозвано — хост может в любой момент удалить доверенное устройство.

Токены сеанса (JWT)

После создания пары для аутентификации на сервере подключений используются недолговечные подписанные токены (срок действия 24 часа).

Эти токены аутентифицируют устройство на сервере подключений для создания комнаты и ретрансляции сообщений. Они не дают доступа к содержимому сеанса, которое защищено отдельным рукопожатием DTLS.

Доступ ИИ-агентов (сервер Remio MCP)

Remio распространяет эту же модель доверия на ИИ-агентов. Инструменты вроде Claude Code, Codex или приложения Claude могут удаленно управлять вашими компьютерами через сервер Remio MCP — и граница безопасности та же, что пересекает человек-клиент:

• Все закрыто вашим входом. Агент может добраться только до хостов, которые в сети и для которых создана пара с учетной записью, в которую вы вошли (вход через Google или Apple, по OAuth). Нет прошедшей проверку учетной записи — нет инструментов.
• Remio — посредник, а не оператор. Единственная задача сервера MCP — предоставить набор инструментов, ограниченных вашей аутентифицированной учетной записью, и передать их ИИ-инструменту, который вы выбрали подключить. Remio не может сам начать сеанс с вашим компьютером — хост принимает только подключения, подтверждающие авторизацию вашей учетной записи, точно как в модели доверия к устройствам выше.
• Тот же зашифрованный транспорт. Сеансы агентов идут по тем же каналам со сквозным шифрованием, что описаны в §04. Наши серверы по-прежнему видят только зашифрованные блоки — свойства нулевого разглашения из §06 действуют без изменений.
• Заметный, отключаемый, с журналом. Сеанс агента отображается на хосте, пока идет, его можно мгновенно прервать аварийным выключателем, и он записывается в локальный журнал аудита.

§06 · Архитектура с нулевым разглашением

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

Что могут видеть наши серверы

• IP-адреса подключающихся устройств (нужны для работы сети).
• Временные метки подключений.
• ID устройств (непрозрачные идентификаторы, не связанные с личной информацией).
• Метаданные подключения: обмен предложением и ответом SDP, кандидаты ICE.

Чего наши серверы не могут видеть

• Содержимое экрана — видеокадры шифруются SRTP сквозным шифрованием.
• Звук — то же шифрование SRTP, что и у видео.
• События ввода — мышь, клавиатура и касания шифруются DTLS.
• Положение курсора — передается по зашифрованному каналу данных.
• Содержимое файлов — любая передача файлов идет по зашифрованным каналам.
• Данные буфера обмена — зашифрованный канал данных.
• Состояние приложений — какие приложения вы запускаете и над чем работаете.

Политика хранения данных

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

• Содержимое сеанса. Никогда не хранится. Только поток в реальном времени.
• Журналы подключений. Метаданные подключений хранятся до 30 дней для отладки, затем удаляются. Не содержат содержимого сеанса.
• Учетные записи пользователей. Учетные записи не нужны. Необязательные данные Firebase Auth управляются инфраструктурой Google и могут быть удалены пользователем.
• Сведения об устройствах. Хранятся локально на каждом устройстве. Если вы решили войти, список ваших устройств синхронизируется с вашей учетной записью (см. политику конфиденциальности).

Поток данных с приоритетом прямого соединения

В большинстве подключений (где проход через NAT удается) данные идут напрямую между устройствами, не касаясь ни одного сервера:

# Best case: direct P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ No server involvement

# Fallback: TURN relay
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ Still E2E encrypted
                            ↑ Server sees only encrypted blobs

Даже в запасном сценарии с ретранслятором TURN сервер-ретранслятор обрабатывает только зашифрованные пакеты. Он выступает как «глупая труба» — не может расшифровывать, проверять или изменять данные.

§07 · Сетевая безопасность

Установка соединения между устройствами

Remio использует протокол ICE (Interactive Connectivity Establishment), чтобы найти наилучший путь соединения между устройствами:

1. Кандидаты хоста — прямое соединение по локальной сети в одной сети.
2. Кандидаты с отражением от сервера (STUN) — проход через NAT с помощью серверов STUN для определения публичного IP-адреса.
3. Кандидаты-ретрансляторы (TURN) — зашифрованный ретранслятор, когда прямое соединение установить нельзя.

Агент ICE проверяет все пары кандидатов одновременно и выбирает путь с наименьшей задержкой и наибольшей надежностью. Прямое соединение всегда предпочтительнее.

Настраиваемые политики транспорта

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

Ограничение частоты запросов

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

Устаревшие ограничители автоматически очищаются с интервалом 5 минут и временем жизни 10 минут, что предотвращает исчерпание памяти при распределенных атаках.

Защита от DDoS

Наша инфраструктура подключений защищена Cloudflare, которая обеспечивает:

• DNS с anycast и глобальную сеть узлов.
• Защиту от DDoS на уровнях 3, 4 и 7.
• Брандмауэр веб-приложений (WAF).
• Ограничение частоты запросов на периферии до того, как трафик дойдет до источника.
• Обнаружение ботов и страницы проверки.

§08 · Безопасность клиента

Remio использует весь набор средств безопасности каждой операционной системы, чтобы защищать локальные данные и обеспечивать целостность приложения.

macOS

• Интеграция со связкой ключей. Все конфиденциальные данные (токены доверия устройств, JWT) хранятся в связке ключей macOS, защищенной учетными данными входа пользователя и аппаратным шифрованием.
• Песочница приложений. Remio работает в изолированной среде с минимальными разрешениями. Для захвата экрана и универсального доступа нужно явное подтверждение пользователя.
• Подпись кода. Все сборки подписаны сертификатами Apple Developer.
• Нотаризация. Сборки для macOS нотаризуются Apple, что подтверждает отсутствие известного вредоносного ПО.
• Усиленная среда выполнения. Не допускает внедрения кода, перехвата библиотек и отладки в рабочих сборках.

iOS

• App Transport Security (ATS). Все сетевые подключения должны использовать HTTPS/TLS. Исключения не настроены.
• Защита данных. Элементы связки ключей шифруются ключами, которые устройство получает из собственного оборудования, а элементы, помеченные «только на этом устройстве», никогда его не покидают, даже в резервной копии.
• Службы связки ключей. Учетные данные устройства хранятся в связке ключей iOS с классом защиты kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.
• Проверка App Store. Все сборки для iOS проходят процесс проверки безопасности Apple.
• Никаких данных в фоне. Приложение не собирает и не передает данные, когда работает в фоновом режиме.

Подпись кода и проверка

# Verify Remio macOS binary — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · Реагирование на инциденты

История безопасности

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

Сообщение об уязвимостях

Мы поощряем ответственное раскрытие информации исследователями безопасности. Если вы обнаружили потенциальную уязвимость:

1. Напишите на security@remio.net с подробным описанием.
2. Укажите шаги для воспроизведения, если применимо.
3. Мы подтверждаем получение в течение 48 часов.
4. Мы стремимся устранять подтвержденные уязвимости в течение 30 дней.
5. Авторов сообщений мы упоминаем в нашем журнале изменений безопасности, если они не предпочитают анонимность.

Политика ответственного раскрытия

• Мы просим окно в 90 дней до публичного раскрытия.
• Мы не предпринимаем юридических действий против исследователей, действующих добросовестно.
• Мы расставляем приоритеты исправлений по серьезности: критическая, высокая, средняя, низкая.
• Формальная программа вознаграждения за найденные ошибки есть в нашем плане развития.

Процесс реагирования на инциденты

В случае подтвержденной проблемы безопасности:

1. Сдерживание. Изолировать затронутые системы в течение 1 часа.
2. Оценка. Определить масштаб и последствия в течение 24 часов.
3. Информирование. Уведомить затронутых пользователей в течение 72 часов (в соответствии с GDPR).
4. Устранение. Выпустить исправления через инфраструктуру автоматического обновления.
5. Разбор. Опубликовать отчет о прозрачности.

§10 · Соответствие требованиям

Готовность к GDPR

Архитектура Remio с нулевым разглашением по своей природе дружественна к GDPR, потому что мы сводим сбор данных к абсолютному техническому минимуму:

• Минимизация данных. Мы собираем только то, что необходимо для установки соединения.
• Право на удаление. Поскольку мы не храним содержимое пользователей, удалять нечего. Необязательные данные учетной записи можно удалить по запросу.
• Переносимость данных. Данные о доверии к устройствам хранятся локально и контролируются пользователем.
• Согласие. Создание пары по PIN-коду — явный механизм согласия для каждого устройства.
• Никакой трансграничной передачи содержимого. Прямые соединения оставляют данные между устройствами; они никогда не попадают в нашу инфраструктуру.

SOC 2

Пока нет

• Независимый аудит безопасности — тестирование на проникновение или проверка кода третьей стороной пока не проводились.
• SOC 2 Type I — отчета пока нет.
• SOC 2 Type II — отчета пока нет.
• Программа вознаграждения за найденные ошибки — формальные вознаграждения за ответственное раскрытие.

Расположение данных

Поскольку в Remio приоритет у прямых соединений, данные сеанса находятся там же, где ваши устройства. Ваши данные никогда не покидают прямое соединение между вашими устройствами. Сервер подключений (размещен у Cloudflare и DigitalOcean) обрабатывает только метаданные подключения — и эти метаданные не связаны с личной информацией.

§11 · Сравнение с альтернативами

Отрасль удаленных рабочих столов страдает от громких взломов. Вот как архитектура Remio принципиально отличается от централизованных альтернатив.

Почему централизованные архитектуры дают сбой

Принципиальная проблема централизованных сервисов удаленного рабочего стола в том, что один взлом может скомпрометировать всех пользователей. Когда в феврале 2024 года были взломаны рабочие серверы AnyDesk, злоумышленники украли сертификаты подписи кода, что потенциально позволяло им распространять вредоносное ПО под видом настоящего ПО AnyDesk. Пришлось сбрасывать пароли всех пользователей.

Когда APT29 (российская группировка, действующая при поддержке государства) взломала корпоративную сеть TeamViewer в июне 2024 года, это поставило вопрос о целостности самого продукта — ведь централизованная архитектура означает, что у поставщика есть техническая возможность получить доступ к сеансам.

Remio полностью исключает этот класс атак. Взлом нашего сервера подключений даст лишь метаданные подключений. Нет учетных данных, которые можно украсть, нет сеансов, к которым можно получить доступ, нет сертификатов, которыми можно подписать вредоносное ПО, нацеленное на устройства наших пользователей.

§12 · Заключение

Безопасность Remio — не набор функций, прикрученных к продукту, а следствие архитектурных решений, принятых с первого дня. Выбрав прямые соединения вместо централизованных, создание пары по PIN-коду вместо паролей и нулевое разглашение вместо сбора данных, мы построили удаленный рабочий стол, где безопасность — состояние по умолчанию, а не необязательное улучшение.

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

По вопросам, корпоративным проверкам безопасности или чтобы сообщить об уязвимости:

• Вопросы безопасности: security@remio.net
• Корпоративные продажи: enterprise@remio.net
• Общие вопросы: hello@remio.net