Beveiliging bij TYO Reach
Beveiliging is fundamenteel voor wat Reach doet — je routeert je verkeer via onze infrastructuur, dus je hebt elk recht om precies te weten hoe ermee wordt omgegaan.
Hoe je verkeer door Reach beweegt
Het begrijpen van het gegevenspad helpt je te evalueren wat we wel en niet kunnen zien — en waarom het ontwerp is zoals het is.
Wanneer Reach actief is, reist geselecteerd verkeer van je apparaat naar de gateway van TYO Reach via een versleutelde HTTPS-verbinding. De gateway — draaiend op Google Cloud Run in Sydney — stuurt het verzoek namens jou door naar de doelserver. De bestemming ziet het IP-adres van de gateway, niet dat van jou. TLS wordt bij elke hop afgedwongen: van je apparaat naar de gateway, en van de gateway naar de bestemming.
TYO Reach gebruikt mitmproxy als onderliggende proxy-engine. "Man-in-the-middle" is een technische beschrijving van hoe de proxy de verbinding onderschept, niet een beschrijving van de intentie. Deze onderschepping is nodig voor twee specifieke doeleinden:
- Authenticatie. Reach voegt een
Proxy-Authorisation-header toe zodat de gateway kan identificeren bij welk account het verzoek hoort en je datalimiet kan afdwingen. - Beleidsafhandeling. Routeringsregels — welke domeinen via welke gateway gaan — worden op deze laag toegepast.
De proxy beëindigt je TLS-sessie, inspecteert de HTTP-metadata (hostnaam en methode), past beleid toe en versleutelt het verzoek opnieuw voordat het wordt doorgestuurd. TLS-certificaten van de bestemming worden normaal gevalideerd door de gateway. Dit is hetzelfde model als dat van zakelijke webbeveiligingsgateways.
Wat we loggen — en wat we bewust niet loggen
Reach meet hoeveel gegevens je gebruikt. Standaard registreert het niet wat je ermee doet — een optionele verbindingslog, die uitstaat tenzij jij of je organisatie hem inschakelt, is de enige uitzondering.
Wat we standaard loggen
We registreren het totale volume aan gegevens (bytes) dat via je account wordt overgedragen per factuurperiode. Dit is de enige informatie die nodig is om je maandelijkse datalimiet af te dwingen, en het is het enige dat we loggen tenzij je de optionele verbindingslog inschakelt.
Wat we niet loggen
We loggen nooit URL-paden, query-strings, zoektermen of paginainhoud. We registreren geen geschiedenis van de domeinen die je bezoekt tenzij jij (of je organisatie) de optionele verbindingslog inschakelt, en zelfs dan worden alleen de hostnaam en verbindingstiming opgeslagen, nooit paden of inhoud. We bouwen geen browseprofielen en delen geen verkeersgegevens met adverteerders of analyseproviders.
Optionele verbindingslog en bewaartermijn
Gegevens over byte-telling worden bewaard voor je huidige factuurperiode plus een korte periode voor geschillenbeslechting. De optionele verbindingslog (toegangslog) staat standaard uit; wanneer jij of je organisatie deze inschakelt, wordt metadata op verbindingsniveau (host, tijdstip, duur) maximaal 30 dagen bewaard en daarna verwijderd. Alle logs worden opgeslagen in Google Cloud in de regio Sydney.
Identiteit ondersteund door TYO ID
Authenticatie voor TYO Reach wordt afgehandeld door id.tyo.com.au — TYO's eigen identiteitsdienst — niet door een platform van derden dat we niet controleren.
In Australië gehoste identiteit
TYO ID draait op Google Cloud in Australië. Je accountgegevens gaan nooit via een identiteitsplatform in de VS of EU. Inlogstromen gebruiken OAuth 2.0 met sessietokens met een korte levensduur — langdurige inloggegevens worden nooit opgeslagen in de client-app.
MFA en TOTP
Multi-factor authenticatie is beschikbaar via TOTP (time-based one-time passwords — compatibel met elke RFC 6238 authenticator-app). Teambeheerders kunnen MFA verplichten voor alle groepsleden; gebruikers kunnen zich niet afmelden voor een door de groep afgedwongen MFA-beleid.
Google & Microsoft inloggen
Teams kunnen inloggen met Google of Microsoft. Zakelijke Azure AD / OIDC-directoryfederatie is op aanvraag beschikbaar voor organisaties die dit nodig hebben.
Hoe de gateway is gebouwd en wordt beheerd
De gateway draait op beheerde serverless infrastructuur — geen persistente virtuele machines, geen SSH-toegang, geen langdurige geheimen in de omgeving.
Google Cloud Run
De Reach-proxy-gateway draait op Cloud Run — Google's beheerde serverless containerplatform. Cloud Run schaalt automatisch, past Google's onderliggende infrastructuurbeveiliging toe en betekent dat er geen persistente VM's zijn die we moeten patchen of waar een aanvaller tussen implementaties op kan blijven staan.
Geen SSH-toegang tot productie
Er is geen SSH- of shell-toegang tot de draaiende gateway. Alle implementaties gaan via de implementatiepijplijn van Google Cloud. Rollbacks worden uitgevoerd via herimplementatie, niet via console-toegang.
GCP Secret Manager
Gevoelige inloggegevens — API-sleutels, servicetokens, database-verbindingsreeksen — worden opgeslagen in GCP Secret Manager, niet in omgevingsvariabelebestanden of code. De gateway haalt geheimen op bij het opstarten via een geauthenticeerde interne API.
Automatische platform-patching
Cloud Run handelt OS- en runtime-patching automatisch af. Wij onderhouden de applicatielaag; Google onderhoudt het platform. Er is geen oppervlak van ongepatchte VM's.
Een beveiligingslek gevonden?
Als je een probleem hebt gevonden in TYO Reach, willen we het horen voordat het publiekelijk bekend wordt gemaakt.
Stuur een beschrijving van het probleem naar [email protected]. Vermeld:
- Een duidelijke beschrijving van de kwetsbaarheid en de potentiële impact ervan.
- Stappen om het te reproduceren (een proof of concept helpt ons sneller te triëren).
- Screenshots, logs of ander ondersteunend bewijsmateriaal.
We streven ernaar om alle beveiligingsrapporten binnen één werkdag te erkennen en binnen drie werkdagen na bevestiging van het probleem een resolutietijdlijn te bieden. Geef ons alsjeblieft redelijke tijd om het probleem op te lossen voordat er enige openbaarmaking plaatsvindt.
We vragen je om:
- Geen gegevens van andere gebruikers te openen of te wijzigen.
- Geen denial-of-service-tests uit te voeren tegen productiesystemen.
- Te handelen te goeder trouw.
We hebben momenteel geen betaald bug bounty-programma, maar we zullen onderzoekers met hun toestemming vermelden in de release-opmerkingen.
Ziet Reach mijn wachtwoorden?
Als je inlogt op een site via HTTPS — wat vrijwel alle inlogpagina's gebruiken — is de inhoud van het inlogformulier, inclusief je wachtwoord, end-to-end versleuteld tussen je browser en de doelsite. De Reach-gateway ziet de hostnaam van de verbinding, maar kan de inhoud van het verzoek, inclusief wachtwoordvelden, niet lezen. Als algemene regel: vermijd het verzenden van inloggegevens via onversleutelde HTTP op welk netwerk dan ook.
Kan Reach mijn HTTPS-browse-inhoud lezen?
Voor HTTPS-verbindingen ziet de gateway de hostnaam (bijv. example.com) maar niet het URL-pad, de query-string of de paginainhoud. Standaard loggen we hostnamen helemaal niet; ze worden alleen geregistreerd als jij of je organisatie de optionele verbindingslog inschakelt (alleen hostnaam en verbindingstiming, 30 dagen bewaard). Voor de kleine minderheid van onversleuteld HTTP-verkeer dat nog op internet bestaat, is de gateway technisch in staat om het verzoek te lezen, maar we inspecteren of bewaren de inhoud ervan niet.
Waar worden mijn gegevens opgeslagen?
Accountgegevens, meetgegevens en eventuele logs worden opgeslagen in Google Cloud in de regio Sydney. We repliceren geen persoonlijke gegevens naar rechtsgebieden buiten Australië, behalve zoals vereist door de standaard infrastructuuractiviteiten van Google. Zie ons Privacybeleid voor alle details.
Hoe rapporteer ik een kwetsbaarheid?
E-mail [email protected] met een beschrijving van het probleem, stappen om te reproduceren en eventueel ondersteunend materiaal. We streven ernaar om alle rapporten binnen één werkdag te erkennen. Geef ons tijd om het probleem aan te pakken voordat er openbaarmaking plaatsvindt.