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, wybrany ruch z Twojego urządzenia trafia do bramki TYO Reach przez szyfrowane połączenie HTTPS. Bramka — działająca na Google Cloud Run w Sydney — przekazuje żądanie do serwera docelowego w Twoim imieniu. Serwer docelowy widzi adres IP bramki, a nie Twój. TLS jest wymuszany na każdym przeskoku: od Twojego urządzenia do bramki i od bramki do miejsca docelowego.
TYO Reach używa mitmproxy jako swojego bazowego silnika proxy. „Man-in-the-middle” to techniczny opis sposobu, w jaki proxy przechwytuje połączenie, a nie opis intencji. To przechwycenie jest konieczne do dwóch konkretnych celów:
- Autoryzacja. Reach dodaje nagłówek
Proxy-Authorisation, aby bramka mogła zidentyfikować, do którego konta należy żądanie i egzekwować Twój limit danych. - Egzekwowanie polityki. Reguły routingu — które domeny wychodzą przez którą bramkę — są stosowane w tej warstwie.
Proxy kończy Twoją sesję TLS, sprawdza metadane HTTP (nazwę hosta i metodę), stosuje politykę i ponownie szyfruje żądanie przed przekazaniem go dalej. Certyfikaty TLS miejsca docelowego są normalnie weryfikowane przez bramkę. Jest to ten sam model, który jest używany przez korporacyjne bramki bezpieczeństwa sieciowego.
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?
Jeśli logujesz się do strony przez HTTPS — czego używają praktycznie wszystkie strony logowania — zawartość formularza logowania, w tym Twoje hasło, jest szyfrowana end-to-end między Twoją przeglądarką a stroną docelową. Bramka Reach widzi nazwę hosta połączenia, ale nie może odczytać zawartości żądania, w tym pól haseł. 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 połączeń HTTPS bramka widzi nazwę hosta (np. example.com), ale nie ścieżkę URL, ciąg zapytania ani zawartość strony. 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, bramka jest technicznie zdolna do odczytania żądania, 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.