Bezpieczeństwo w TYO Reach
Bezpieczeństwo jest fundamentem tego, co robi Reach — kierujesz swój ruch przez naszą infrastrukturę, więc masz pełne prawo wiedzieć dokładnie, jak jest on obsługiwany.
Jak Twój ruch przemieszcza się przez Reach
Zrozumienie ścieżki danych pomaga ocenić, co możemy, a czego nie możemy zobaczyć — i dlaczego projekt wygląda tak, a nie inaczej.
Gdy Reach jest aktywny, aplikacja kliencka uruchamia małe lokalne proxy (HTTP CONNECT i SOCKS5), z którym łączy się Twoja przeglądarka. W przypadku HTTPS, gdy przeglądarka otwiera połączenie, lokalne proxy zwraca „200 Connection Established”, a następnie przekazuje surowe, wciąż zaszyfrowane bajty do bramki TYO Reach — działającej na zarządzanej infrastrukturze chmurowej w wybranym regionie — przez uwierzytelniony tunel; bramka przekazuje te same bajty dalej do serwera docelowego. Oryginalna sesja TLS Twojej przeglądarki działa przez ten tunel od końca do końca (end-to-end) aż do witryny docelowej — Reach jest rurą, nie punktem końcowym. Nigdy nie widzi tekstu jawnego, nigdy nie generuje ani nie przedstawia zastępczego certyfikatu i nie instaluje żadnego głównego urzędu certyfikacji (root CA) na Twoim urządzeniu. Serwer docelowy widzi adres IP bramki, a nie Twój.
Uwierzytelniany jest sam tunel, a nie Twój ruch: klient wysyła nagłówek X-Reach-Key podczas otwierania tunelu z bramką, aby bramka mogła zidentyfikować Twoje konto i egzekwować Twój limit danych. Egzekwowanie polityki (które domeny wychodzą przez którą bramkę) i pomiar są stosowane na podstawie metadanych połączenia — docelowego hosta, o połączenie z którym Twoja przeglądarka prosi proxy, oraz liczby bajtów — nigdy poprzez odczyt odszyfrowanej zawartości.
Co logujemy — a czego celowo nie logujemy
Reach mierzy, ile danych zużywasz. Domyślnie nie rejestruje, co z nimi robisz — jedynym wyjątkiem jest opcjonalny log połączeń, wyłączony, chyba że włączysz go Ty lub Twoja organizacja.
Co logujemy domyślnie
Rejestrujemy całkowitą ilość danych (w bajtach) przesłanych przez Twoje konto w okresie rozliczeniowym. Jest to jedyna informacja potrzebna do egzekwowania Twojego miesięcznego limitu danych i jedyna rzecz, jaką logujemy, chyba że włączysz opcjonalny log połączeń.
Czego nie logujemy
Nie logujemy ścieżek URL, ciągów zapytań, haseł wyszukiwania ani zawartości stron — nigdy. Nie rejestrujemy historii odwiedzanych domen, chyba że Ty (lub Twoja organizacja) włączysz opcjonalny log połączeń, a nawet wtedy przechowywane są jedynie nazwa hosta i czasy połączeń, nigdy ścieżki ani zawartość. Nie budujemy profili przeglądania ani nie udostępniamy danych o ruchu reklamodawcom czy dostawcom analityki.
Opcjonalny log połączeń i przechowywanie
Dane o pomiarze zużycia bajtów są przechowywane przez bieżący okres rozliczeniowy oraz krótki czas po nim w celu rozstrzygania sporów. Opcjonalny log połączeń (dostępu) jest domyślnie wyłączony; gdy Ty lub Twoja organizacja go włączysz, metadane na poziomie połączenia (host, czas, czas trwania) są przechowywane maksymalnie przez 30 dni, a następnie usuwane. Wszystkie logi są przechowywane w Google Cloud w regionie Sydney.
Tożsamość wspierana przez TYO ID
Autoryzacja dla TYO Reach jest obsługiwana przez id.tyo.com.au — własną usługę tożsamości TYO — a nie platformę zewnętrzną, której nie kontrolujemy.
Tożsamość hostowana w Australii
TYO ID działa na Google Cloud w Australii. Twoje dane logowania nigdy nie przechodzą przez platformę tożsamości w USA lub UE. Przepływy logowania używają OAuth 2.0 z krótkotrwałymi tokenami sesji — długotrwałe dane logowania nigdy nie są przechowywane w aplikacji klienckiej.
MFA i TOTP
Uwierzytelnianie wieloskładnikowe jest dostępne przez TOTP (oparte na czasie jednorazowe hasła — kompatybilne z każdą aplikacją uwierzytelniającą RFC 6238). Administratorzy zespołu mogą wymagać MFA dla wszystkich członków grupy; użytkownicy nie mogą zrezygnować z polityki MFA wymuszonej przez grupę.
Logowanie przez Google i Microsoft
Zespoły mogą logować się przez Google lub Microsoft. Federacja katalogów Azure AD / OIDC dla przedsiębiorstw jest dostępna na życzenie dla organizacji, które tego potrzebują.
Jak bramka jest zbudowana i obsługiwana
Bramka działa na zarządzanej infrastrukturze bezserwerowej — brak trwałych maszyn wirtualnych, brak dostępu SSH, brak długotrwałych sekretów w środowisku.
Google Cloud Run
Bramka proxy Reach działa na Cloud Run — zarządzanej przez Google platformie kontenerów bezserwerowych. Cloud Run skaluje się automatycznie, stosuje podstawowe bezpieczeństwo infrastruktury Google i oznacza, że nie ma trwałych maszyn wirtualnych, które musielibyśmy łatać lub na których atakujący mógłby się utrzymać między wdrożeniami.
Brak dostępu SSH do produkcji
Nie ma dostępu SSH ani powłoki do działającej bramki. Wszystkie wdrożenia przechodzą przez potok wdrażania Google Cloud. Wycofywanie zmian odbywa się przez ponowne wdrożenie, a nie dostęp przez konsolę.
GCP Secret Manager
Wrażliwe dane logowania — klucze API, tokeny serwisowe, ciągi połączeń z bazami danych — są przechowywane w GCP Secret Manager, a nie w plikach zmiennych środowiskowych czy kodzie. Bramka pobiera sekrety przy starcie przez uwierzytelnione wewnętrzne API.
Automatyczne łatanie platformy
Cloud Run obsługuje łatanie systemu operacyjnego i środowiska uruchomieniowego automatycznie. My utrzymujemy warstwę aplikacji; Google utrzymuje platformę. Nie ma powierzchni ataku w postaci niezałatanego VM.
Znalazłeś lukę w zabezpieczeniach?
Jeśli znalazłeś problem w TYO Reach, chcemy o tym usłyszeć, zanim zostanie on ujawniony publicznie.
Wyślij opis problemu na adres [email protected]. Prosimy o dołączenie:
- Jasnego opisu luki i jej potencjalnego wpływu.
- Kroków do odtworzenia (dowód koncepcji pomaga nam szybciej przeprowadzić triaż).
- Zrzutów ekranu, logów lub wszelkich dowodów wspierających.
Staramy się potwierdzić wszystkie zgłoszenia dotyczące bezpieczeństwa w ciągu jednego dnia roboczego i zapewnić harmonogram rozwiązania w ciągu trzech dni roboczych od potwierdzenia problemu. Prosimy o danie nam rozsądnego czasu na naprawienie problemu przed jakimkolwiek publicznym ujawnieniem.
Prosimy, abyś:
- Nie uzyskiwał dostępu ani nie modyfikował danych należących do innych użytkowników.
- Nie przeprowadzał testów odmowy usługi (DoS) przeciwko systemom produkcyjnym.
- Działał w dobrej wierze.
Obecnie nie prowadzimy płatnego programu bug bounty, ale za zgodą badaczy będziemy wymieniać ich w informacjach o wydaniu.
Czy Reach widzi moje hasła?
Nie. Jeśli logujesz się do strony przez HTTPS — czego używają praktycznie wszystkie strony logowania — Twoja sesja TLS działa od końca do końca między Twoją przeglądarką a stroną docelową przez tunel Reach; Reach jedynie przekazuje zaszyfrowane bajty i nigdy ich nie odszyfrowuje. Strukturalnie nie jest w stanie zobaczyć zawartości formularza logowania, w tym Twojego hasła. Ogólna zasada: unikaj przesyłania danych logowania przez nieszyfrowany HTTP w jakiejkolwiek sieci.
Czy Reach może odczytać zawartość mojego przeglądania HTTPS?
W przypadku HTTPS — czyli praktycznie całej współczesnej przeglądarki internetowej — nie. Reach nie przechwytuje ani nie odszyfrowuje ruchu HTTPS — jedynie przekazuje Twój już zaszyfrowany ruch przez tunel, a Twoja sesja TLS dociera od końca do końca do strony docelowej. Bramka zna docelową nazwę hosta (np. example.com) wyłącznie dlatego, że Twoja przeglądarka informuje proxy, z czym się połączyć (standardowy cel CONNECT), a nie poprzez analizowanie czegokolwiek wewnątrz zaszyfrowanego uzgadniania — i nigdy nie widzi ścieżki URL, ciągu zapytania ani zawartości strony. To strukturalna gwarancja wynikająca z projektu tunelu dla HTTPS, a nie tylko polityka logowania. Domyślnie w ogóle nie logujemy nazw hostów; są one rejestrowane tylko wtedy, gdy Ty lub Twoja organizacja włączycie opcjonalny log połączeń (wyłącznie nazwa hosta i czasy połączeń, przechowywane przez 30 dni). W przypadku niewielkiej mniejszości nieszyfrowanego ruchu HTTP, który wciąż istnieje w internecie, ta strukturalna gwarancja nie ma zastosowania — lokalne proxy jest technicznie zdolne do odczytania żądania, tak jak każde proxy przekazujące ruch w postaci czystego tekstu, ale nie sprawdzamy ani nie przechowujemy jego zawartości.
Gdzie są przechowywane moje dane?
Dane konta, rekordy pomiarowe i wszelkie logi są przechowywane w Google Cloud w regionie Sydney. Nie replikujemy danych osobowych do jurysdykcji poza Australią, chyba że jest to wymagane przez standardowe operacje infrastrukturalne Google. Zobacz naszą Politykę Prywatności, aby uzyskać pełne szczegóły.
Jak zgłosić lukę w zabezpieczeniach?
Wyślij e-mail na adres [email protected] z opisem problemu, krokami do odtworzenia i wszelkimi materiałami wspierającymi. Staramy się potwierdzić wszystkie zgłoszenia w ciągu jednego dnia roboczego. Prosimy o danie nam czasu na rozwiązanie problemu przed publicznym ujawnieniem.