Sicurezza in TYO Reach
La sicurezza è fondamentale per ciò che fa Reach: stai instradando il tuo traffico attraverso la nostra infrastruttura, quindi hai tutto il diritto di sapere esattamente come viene gestito.
Come si muove il tuo traffico attraverso Reach
Comprendere il percorso dei dati ti aiuta a valutare cosa possiamo e non possiamo vedere, e perché il design è fatto in questo modo.
Quando Reach è attivo, l'app client esegue un piccolo proxy locale (HTTP CONNECT e SOCKS5) a cui si connette il tuo browser. Per HTTPS, quando il tuo browser apre una connessione, il proxy locale restituisce "200 Connection Established" e inoltra i byte grezzi, ancora crittografati, al gateway di TYO Reach — in esecuzione su infrastruttura cloud gestita nella tua regione selezionata — tramite un tunnel autenticato; il gateway inoltra quegli stessi byte al server di destinazione. La sessione TLS originale del tuo browser viene eseguita end-to-end fino al sito di destinazione attraverso quel tunnel — Reach è un tubo, non un endpoint. Non vede mai testo in chiaro, non genera né presenta mai un certificato sostitutivo e non installa alcuna CA radice sul tuo dispositivo. La destinazione vede l'indirizzo IP del gateway, non il tuo.
Ciò che viene autenticato è il tunnel stesso, non il tuo traffico: il client invia un'intestazione X-Reach-Key quando apre il tunnel con il gateway, in modo che quest'ultimo possa identificare il tuo account e applicare la tua franchigia dati. L'applicazione della policy (quali domini escono attraverso quale gateway) e la misurazione vengono effettuate a partire dai metadati di connessione — l'host di destinazione che il tuo browser chiede al proxy di raggiungere, e il conteggio dei byte — mai leggendo il contenuto decrittografato.
Cosa registriamo e cosa deliberatamente non registriamo
Reach misura la quantità di dati che utilizzi. Per impostazione predefinita non registra cosa ne fai — un registro di connessione opzionale, disattivato a meno che tu o la tua organizzazione non lo abilitiate, è l'unica eccezione.
Cosa registriamo per impostazione predefinita
Registriamo il volume totale di dati (byte) trasferiti attraverso il tuo account per periodo di fatturazione. Queste sono le uniche informazioni necessarie per applicare la tua franchigia dati mensile, ed è l'unica cosa che registriamo a meno che tu non attivi il registro di connessione opzionale.
Cosa non registriamo
Non registriamo mai percorsi URL, stringhe di query, termini di ricerca o contenuti delle pagine. Non registriamo una cronologia dei domini che visiti a meno che tu (o la tua organizzazione) non attiviate il registro di connessione opzionale, e anche in quel caso vengono memorizzati solo il nome host e i tempi di connessione, mai i percorsi o il contenuto. Non creiamo profili di navigazione né condividiamo i dati sul traffico con inserzionisti o fornitori di analisi.
Registro di connessione opzionale e conservazione
I dati di misurazione del conteggio dei byte vengono conservati per il periodo di fatturazione corrente più una breve coda per la risoluzione delle controversie. Il registro di connessione (di accesso) opzionale è disattivato per impostazione predefinita; quando tu o la tua organizzazione lo abilitate, i metadati a livello di connessione (host, ora, durata) vengono conservati per un massimo di 30 giorni e poi eliminati. Tutti i log sono archiviati in Google Cloud nella regione di Sydney.
Identità supportata da TYO ID
L'autenticazione per TYO Reach è gestita da id.tyo.com.au, il servizio di identità di TYO, non da una piattaforma di terze parti che non controlliamo.
Identità ospitata in Australia
TYO ID viene eseguito su Google Cloud in Australia. Le credenziali del tuo account non transitano mai su una piattaforma di identità statunitense o europea. I flussi di accesso utilizzano OAuth 2.0 con token di sessione a breve durata: le credenziali a lunga durata non vengono mai memorizzate nell'app client.
MFA e TOTP
L'autenticazione a più fattori è disponibile tramite TOTP (password monouso basate sul tempo, compatibili con qualsiasi app di autenticazione RFC 6238). Gli amministratori del team possono richiedere l'MFA per tutti i membri del gruppo; gli utenti non possono rinunciare a una policy MFA imposta dal gruppo.
Accesso con Google e Microsoft
I team possono accedere con Google o Microsoft. La federazione di directory aziendali Azure AD / OIDC è disponibile su richiesta per le organizzazioni che ne hanno bisogno.
Come viene costruito e gestito il gateway
Il gateway viene eseguito su un'infrastruttura serverless gestita: nessuna macchina virtuale persistente, nessun accesso SSH, nessun segreto a lunga durata nell'ambiente.
Google Cloud Run
Il gateway proxy Reach viene eseguito su Cloud Run, la piattaforma di container serverless gestita da Google. Cloud Run scala automaticamente, applica la sicurezza dell'infrastruttura sottostante di Google e significa che non ci sono VM persistenti da patchare o su cui un utente malintenzionato possa persistere tra le distribuzioni.
Nessun accesso SSH alla produzione
Non c'è accesso SSH o shell al gateway in esecuzione. Tutte le distribuzioni passano attraverso la pipeline di distribuzione di Google Cloud. I rollback vengono eseguiti tramite ridistribuzione, non tramite accesso alla console.
GCP Secret Manager
Le credenziali sensibili (chiavi API, token di servizio, stringhe di connessione al database) sono archiviate in GCP Secret Manager, non in file di variabili d'ambiente o codice. Il gateway recupera i segreti all'avvio tramite un'API interna autenticata.
Patching automatico della piattaforma
Cloud Run gestisce automaticamente il patching del sistema operativo e del runtime. Noi manteniamo il livello dell'applicazione; Google mantiene la piattaforma. Non c'è una superficie di VM non patchate.
Hai trovato una vulnerabilità di sicurezza?
Se hai trovato un problema in TYO Reach, vogliamo saperlo prima che venga divulgato pubblicamente.
Invia una descrizione del problema a [email protected]. Includi:
- Una chiara descrizione della vulnerabilità e del suo potenziale impatto.
- Passaggi per riprodurla (una prova di concetto ci aiuta a fare il triage più velocemente).
- Screenshot, log o qualsiasi prova a supporto.
Miriamo a riconoscere tutti i rapporti di sicurezza entro un giorno lavorativo e fornire una tempistica di risoluzione entro tre giorni lavorativi dalla conferma del problema. Ti preghiamo di darci un tempo ragionevole per risolvere il problema prima di qualsiasi divulgazione pubblica.
Ti chiediamo di:
- Non accedere o modificare dati appartenenti ad altri utenti.
- Non eseguire test di negazione del servizio contro i sistemi di produzione.
- Agire in buona fede.
Attualmente non gestiamo un programma di bug bounty a pagamento, ma riconosceremo i ricercatori nelle note di rilascio con il loro permesso.
Reach vede le mie password?
No. Se stai accedendo a un sito tramite HTTPS — che è ciò che utilizzano praticamente tutte le pagine di accesso — la tua sessione TLS viene eseguita end-to-end tra il tuo browser e il sito di destinazione attraverso il tunnel di Reach; Reach inoltra solo byte crittografati e non li decrittografa mai. È strutturalmente incapace di vedere il contenuto del modulo di accesso, inclusa la tua password. Come regola generale: evita di inviare credenziali su HTTP non crittografato su qualsiasi rete.
Reach può leggere il mio contenuto di navigazione HTTPS?
Per HTTPS — praticamente tutta la navigazione moderna — no. Reach non intercetta né decrittografa il traffico HTTPS — inoltra semplicemente il tuo traffico, già crittografato, attraverso un tunnel, e la tua sessione TLS raggiunge il sito di destinazione end-to-end. Il gateway conosce il nome host di destinazione (es. example.com) solo perché il tuo browser dice al proxy dove connettersi (la destinazione CONNECT standard), non analizzando nulla all'interno dell'handshake crittografato — e non vede mai il percorso URL, la stringa di query o il contenuto della pagina. Questa è una garanzia strutturale del design del tunnel per l'HTTPS, non solo una policy di registrazione. Per impostazione predefinita non registriamo affatto i nomi host; vengono registrati solo se tu o la tua organizzazione abilitate il registro di connessione opzionale (solo nome host e tempi di connessione, conservati per 30 giorni). Per la piccola minoranza di traffico HTTP non crittografato che esiste ancora su internet, questa garanzia strutturale non si applica — il proxy locale è tecnicamente in grado di leggere la richiesta, come qualsiasi proxy di inoltro in chiaro, ma non ne ispezioniamo né ne memorizziamo il contenuto.
Dove sono archiviati i miei dati?
I dati dell'account, i record di misurazione ed eventuali log sono archiviati in Google Cloud nella regione di Sydney. Non replichiamo dati personali in giurisdizioni al di fuori dell'Australia, salvo quanto richiesto dalle operazioni di infrastruttura standard di Google. Consulta la nostra Informativa sulla privacy per tutti i dettagli.
Come segnalo una vulnerabilità?
Invia un'email a [email protected] con una descrizione del problema, i passaggi per riprodurlo e qualsiasi materiale di supporto. Miriamo a riconoscere tutti i rapporti entro un giorno lavorativo. Ti preghiamo di darci il tempo di risolvere il problema prima della divulgazione pubblica.