Безопасность в TYO Reach
Безопасность — это основа работы Reach. Вы направляете свой трафик через нашу инфраструктуру, поэтому имеете полное право знать, как именно он обрабатывается.
Как ваш трафик проходит через Reach
Понимание пути прохождения данных помогает оценить, что мы можем видеть, а что нет, и почему архитектура устроена именно так.
Когда Reach активен, клиентское приложение запускает небольшой локальный прокси (поддерживающий HTTP CONNECT и SOCKS5), к которому подключается ваш браузер. Для HTTPS, когда браузер открывает соединение, локальный прокси возвращает «200 Connection Established», а затем передаёт исходные, всё ещё зашифрованные байты на шлюз TYO Reach — работающий на управляемой облачной инфраструктуре в выбранном вами регионе — через аутентифицированный туннель; шлюз пересылает эти же байты на целевой сервер. Исходный TLS-сеанс вашего браузера работает через этот туннель сквозным образом (end-to-end) до целевого сайта — Reach выступает трубой, а не конечной точкой. Он никогда не видит открытый текст, никогда не генерирует и не предъявляет поддельный сертификат и не устанавливает на ваше устройство корневой сертификат (CA). Целевой сервер видит IP-адрес шлюза, а не ваш.
Аутентифицируется сам туннель, а не ваш трафик: при открытии туннеля с шлюзом клиент отправляет заголовок X-Reach-Key, чтобы шлюз мог определить ваш аккаунт и применить ваш лимит трафика. Применение политик (какие домены выходят через какой шлюз) и учёт трафика выполняются на основе метаданных соединения — хоста назначения, к которому ваш браузер просит прокси подключиться, и количества байт, — а не путём чтения расшифрованного содержимого.
Что мы журналируем, а что намеренно не делаем
Reach измеряет объём используемых вами данных. По умолчанию он не записывает, что именно вы с ними делаете, — единственное исключение составляет необязательный журнал соединений, отключённый, пока вы или ваша организация его не включите.
Что мы журналируем по умолчанию
Мы записываем общий объём данных (в байтах), переданных через ваш аккаунт за расчётный период. Это единственная информация, необходимая для контроля вашего ежемесячного лимита трафика, и это единственное, что мы журналируем, пока вы не включите необязательный журнал соединений.
Чего мы не журналируем
Мы никогда не журналируем пути URL, строки запросов, поисковые запросы или содержимое страниц. Мы не ведём историю посещённых вами доменов, если только вы (или ваша организация) не включите необязательный журнал соединений, но и в этом случае сохраняются только имя хоста и время соединения, но никогда пути или содержимое. Мы не создаём профили активности пользователей и не передаём данные о трафике рекламодателям или провайдерам аналитики.
Необязательный журнал соединений и хранение
Данные учёта трафика хранятся в течение вашего текущего расчётного периода плюс небольшой дополнительный срок для разрешения споров. Необязательный журнал соединений (доступа) по умолчанию отключён; когда вы или ваша организация его включаете, метаданные на уровне соединения (хост, время, продолжительность) хранятся максимум 30 дней, после чего удаляются. Все журналы хранятся в Google Cloud в регионе Сидней.
Идентификация на базе TYO ID
Аутентификация для TYO Reach обрабатывается id.tyo.com.au — собственной службой идентификации TYO, а не сторонней платформой, которую мы не контролируем.
Австралийский хостинг системы идентификации
TYO ID работает в Google Cloud в Австралии. Ваши учётные данные никогда не проходят через американские или европейские платформы идентификации. Процессы входа используют OAuth 2.0 с сеансовыми токенами с коротким сроком действия — долгоживущие учётные данные никогда не сохраняются в клиентском приложении.
MFA и TOTP
Многофакторная аутентификация (MFA) доступна через TOTP (одноразовые пароли на основе времени — совместимы с любым приложением-аутентификатором по стандарту RFC 6238). Администраторы команд могут требовать использования MFA для всех участников команды; пользователи не могут отказаться от политики MFA, принудительно установленной для команды.
Вход через Google и Microsoft
Команды могут входить через Google или Microsoft. Корпоративная федерация каталогов Azure AD / OIDC доступна по запросу для организаций, которым это необходимо.
Как устроен и работает шлюз
Шлюз работает на управляемой бессерверной инфраструктуре — никаких постоянных виртуальных машин, никакого SSH-доступа, никаких долгоживущих секретов в рабочей среде.
Google Cloud Run
Прокси-шлюз Reach работает на Cloud Run — управляемой бессерверной контейнерной платформе от Google. Cloud Run масштабируется автоматически, применяет базовые средства безопасности инфраструктуры Google и означает, что у нас нет постоянных виртуальных машин, которые нужно обновлять или на которых злоумышленник мог бы закрепиться между развёртываниями.
Отсутствие SSH-доступа к рабочей среде
К работающему шлюзу нет доступа по SSH или через командную оболочку. Все развёртывания проходят через конвейер развёртывания Google Cloud. Откаты выполняются путём повторного развёртывания, а не через доступ к консоли.
GCP Secret Manager
Конфиденциальные учётные данные — ключи API, сервисные токены, строки подключения к базам данных — хранятся в GCP Secret Manager, а не в файлах переменных среды или в коде. Шлюз извлекает секреты при запуске через аутентифицированный внутренний API.
Автоматическое обновление платформы
Cloud Run автоматически устанавливает исправления для ОС и среды выполнения. Мы обслуживаем уровень приложения, а Google — платформу. Поверхность атаки в виде необновлённых виртуальных машин отсутствует.
Нашли уязвимость в системе безопасности?
Если вы обнаружили проблему в TYO Reach, мы хотим узнать о ней до того, как она будет раскрыта публично.
Отправьте описание проблемы на [email protected]. Пожалуйста, укажите:
- Чёткое описание уязвимости и её потенциального влияния.
- Шаги для воспроизведения (доказательство концепции (PoC) помогает нам быстрее провести сортировку).
- Скриншоты, журналы или любые подтверждающие материалы.
Мы стремимся подтверждать получение всех отчётов о безопасности в течение одного рабочего дня и предоставлять сроки решения в течение трёх рабочих дней после подтверждения проблемы. Пожалуйста, дайте нам разумное время на исправление проблемы до её публичного раскрытия.
Мы просим вас:
- Не получать доступ к данным других пользователей и не изменять их.
- Не проводить тестирование на отказ в обслуживании (DoS) рабочих систем.
- Действовать добросовестно.
В настоящее время у нас нет программы выплаты вознаграждений за найденные ошибки (bug bounty), но мы с радостью упомянем исследователей в примечаниях к выпуску с их разрешения.
Видит ли Reach мои пароли?
Нет. Если вы входите на сайт по протоколу HTTPS (который используют практически все страницы входа), ваш TLS-сеанс работает сквозным образом между вашим браузером и целевым сайтом через туннель Reach; Reach лишь пересылает зашифрованные байты и никогда их не расшифровывает. Структурно он не способен увидеть содержимое формы входа, включая ваш пароль. Общее правило: избегайте отправки учётных данных по незашифрованному протоколу HTTP в любой сети.
Может ли Reach читать содержимое моих HTTPS-сеансов?
Для HTTPS — то есть практически для всего современного веб-трафика — нет. Reach не перехватывает и не расшифровывает HTTPS-трафик — он лишь пересылает ваш уже зашифрованный трафик через туннель, а ваш TLS-сеанс достигает целевого сайта сквозным образом. Шлюз узнаёт имя хоста назначения (например, example.com) только потому, что ваш браузер сообщает прокси, куда подключиться (стандартная цель CONNECT), а не анализируя что-либо внутри зашифрованного рукопожатия — и он никогда не видит путь URL, строку запроса или содержимое страницы. Это структурная гарантия архитектуры туннеля для HTTPS, а не просто политика журналирования. По умолчанию мы вообще не журналируем имена хостов; они записываются, только если вы или ваша организация включите необязательный журнал соединений (только имя хоста и время соединения, хранятся 30 дней). Для незначительной доли незашифрованного HTTP-трафика, который всё ещё существует в интернете, эта структурная гарантия не действует — локальный прокси технически способен прочитать запрос, как и любой прокси, пересылающий открытый текст, но мы не проверяем и не храним его содержимое.
Где хранятся мои данные?
Данные аккаунта, записи учёта трафика и любые журналы хранятся в Google Cloud в регионе Сидней. Мы не реплицируем персональные данные в юрисдикции за пределами Австралии, за исключением случаев, когда это требуется для стандартных операций инфраструктуры Google. Подробности см. в нашей Политике конфиденциальности.
Как сообщить об уязвимости?
Напишите на [email protected] с описанием проблемы, шагами для воспроизведения и любыми подтверждающими материалами. Мы стремимся подтверждать получение всех отчётов в течение одного рабочего дня. Пожалуйста, дайте нам время на устранение проблемы до её публичного раскрытия.