Sicherheit bei TYO Reach
Sicherheit ist grundlegend für das, was Reach tut – Sie leiten Ihren Datenverkehr über unsere Infrastruktur, also haben Sie jedes Recht zu wissen, wie genau er gehandhabt wird.
Wie sich Ihr Datenverkehr durch Reach bewegt
Das Verständnis des Datenpfads hilft Ihnen zu bewerten, was wir sehen können und was nicht – und warum das Design so ist, wie es ist.
Wenn Reach aktiv ist, betreibt die Client-App einen kleinen lokalen Proxy (HTTP CONNECT und SOCKS5), mit dem sich Ihr Browser verbindet. Bei HTTPS gibt der lokale Proxy, sobald Ihr Browser eine Verbindung öffnet, "200 Connection Established" zurück und leitet die rohen, weiterhin verschlüsselten Bytes über einen authentifizierten Tunnel an das Gateway von TYO Reach weiter – das auf verwalteter Cloud-Infrastruktur in Ihrer gewählten Region läuft; das Gateway leitet dieselben Bytes an den Zielserver weiter. Die ursprüngliche TLS-Sitzung Ihres Browsers läuft über diesen Tunnel Ende-zu-Ende bis zur Zielwebsite – Reach ist ein Rohr, kein Endpunkt. Es sieht niemals Klartext, erzeugt oder präsentiert niemals ein Ersatzzertifikat und installiert keine Root-CA auf Ihrem Gerät. Das Ziel sieht die IP-Adresse des Gateways, nicht Ihre.
Authentifiziert wird der Tunnel selbst, nicht Ihr Datenverkehr: Der Client sendet beim Öffnen des Tunnels zum Gateway einen X-Reach-Key-Header, damit das Gateway Ihr Konto identifizieren und Ihr Datenkontingent durchsetzen kann. Richtliniendurchsetzung (welche Domains über welches Gateway ausgehen) und Messung erfolgen anhand von Verbindungsmetadaten – dem Ziel-Host, mit dem Ihr Browser den Proxy verbinden lässt, und der Byteanzahl –, niemals durch Lesen entschlüsselter Inhalte.
Was wir protokollieren – und was wir bewusst nicht protokollieren
Reach misst, wie viele Daten Sie verbrauchen. Standardmäßig zeichnet es nicht auf, was Sie damit tun – ein optionales Verbindungsprotokoll, das deaktiviert ist, sofern Sie oder Ihre Organisation es nicht aktivieren, ist die einzige Ausnahme.
Was wir standardmäßig protokollieren
Wir zeichnen das Gesamtvolumen der Daten (Bytes) auf, die pro Abrechnungszeitraum über Ihr Konto übertragen werden. Dies ist die einzige Information, die erforderlich ist, um Ihr monatliches Datenkontingent durchzusetzen, und es ist das Einzige, was wir protokollieren, sofern Sie das optionale Verbindungsprotokoll nicht einschalten.
Was wir nicht protokollieren
Wir protokollieren niemals URL-Pfade, Abfragezeichenfolgen, Suchbegriffe oder Seiteninhalte. Wir zeichnen keinen Verlauf der von Ihnen besuchten Domains auf, sofern Sie (oder Ihre Organisation) nicht das optionale Verbindungsprotokoll einschalten, und selbst dann werden nur der Hostname und der zeitliche Verlauf der Verbindung gespeichert, niemals Pfade oder Inhalte. Wir erstellen keine Surfprofile und teilen keine Verkehrsdaten mit Werbetreibenden oder Analyseanbietern.
Optionales Verbindungsprotokoll & Aufbewahrung
Daten zur Byte-Zählung werden für Ihren aktuellen Abrechnungszeitraum plus einen kurzen Zeitraum zur Streitbeilegung aufbewahrt. Das optionale Verbindungsprotokoll (Zugriffsprotokoll) ist standardmäßig deaktiviert; wenn Sie oder Ihre Organisation es aktivieren, werden Metadaten auf Verbindungsebene (Host, Zeit, Dauer) für maximal 30 Tage aufbewahrt und dann gelöscht. Alle Protokolle werden in der Google Cloud in der Region Sydney gespeichert.
Identität unterstützt durch TYO ID
Die Authentifizierung für TYO Reach wird von id.tyo.com.au abgewickelt – dem eigenen Identitätsdienst von TYO –, nicht von einer Drittanbieterplattform, die wir nicht kontrollieren.
In Australien gehostete Identität
TYO ID läuft auf Google Cloud in Australien. Ihre Kontodaten durchlaufen niemals eine Identitätsplattform in den USA oder der EU. Anmeldeabläufe verwenden OAuth 2.0 mit kurzlebigen Sitzungstoken – langlebige Anmeldedaten werden niemals in der Client-App gespeichert.
MFA und TOTP
Die Multi-Faktor-Authentifizierung ist über TOTP verfügbar (zeitbasierte Einmalpasswörter – kompatibel mit jeder RFC 6238-Authentifikator-App). Team-Admins können MFA für alle Gruppenmitglieder vorschreiben; Benutzer können sich einer gruppenweit erzwungenen MFA-Richtlinie nicht entziehen.
Google- & Microsoft-Anmeldung
Teams können sich mit Google oder Microsoft anmelden. Enterprise Azure AD / OIDC-Verzeichnis-Föderation ist auf Anfrage für Organisationen verfügbar, die dies benötigen.
Wie das Gateway gebaut und betrieben wird
Das Gateway läuft auf verwalteter serverloser Infrastruktur – keine persistenten virtuellen Maschinen, kein SSH-Zugriff, keine langlebigen Geheimnisse in der Umgebung.
Google Cloud Run
Das Reach-Proxy-Gateway läuft auf Cloud Run – Googles verwalteter serverloser Container-Plattform. Cloud Run skaliert automatisch, wendet die zugrunde liegende Infrastruktursicherheit von Google an und bedeutet, dass es keine persistenten VMs gibt, die wir patchen müssen oder auf denen ein Angreifer zwischen Deployments verweilen könnte.
Kein SSH-Zugriff auf die Produktion
Es gibt keinen SSH- oder Shell-Zugriff auf das laufende Gateway. Alle Deployments erfolgen über die Deployment-Pipeline von Google Cloud. Rollbacks werden durch erneutes Deployment durchgeführt, nicht durch Konsolenzugriff.
GCP Secret Manager
Sensible Anmeldedaten – API-Schlüssel, Dienst-Token, Datenbank-Verbindungszeichenfolgen – werden im GCP Secret Manager gespeichert, nicht in Umgebungsvariablendateien oder im Code. Das Gateway ruft Geheimnisse beim Start über eine authentifizierte interne API ab.
Automatisches Plattform-Patching
Cloud Run übernimmt das OS- und Runtime-Patching automatisch. Wir pflegen die Anwendungsebene; Google pflegt die Plattform. Es gibt keine Oberfläche für ungepatchte VMs.
Eine Sicherheitslücke gefunden?
Wenn Sie ein Problem in TYO Reach gefunden haben, möchten wir davon erfahren, bevor es öffentlich bekannt gegeben wird.
Senden Sie eine Beschreibung des Problems an [email protected]. Bitte fügen Sie Folgendes bei:
- Eine klare Beschreibung der Schwachstelle und ihrer potenziellen Auswirkungen.
- Schritte zur Reproduktion (ein Proof-of-Concept hilft uns, schneller zu triagieren).
- Screenshots, Protokolle oder unterstützende Beweise.
Wir bemühen uns, alle Sicherheitsberichte innerhalb eines Werktages zu bestätigen und innerhalb von drei Werktagen nach Bestätigung des Problems einen Zeitplan für die Lösung bereitzustellen. Bitte geben Sie uns eine angemessene Zeit, um das Problem zu beheben, bevor eine öffentliche Offenlegung erfolgt.
Wir bitten Sie:
- Nicht auf Daten zuzugreifen oder diese zu ändern, die anderen Benutzern gehören.
- Keine Denial-of-Service-Tests gegen Produktionssysteme durchzuführen.
- In gutem Glauben zu handeln.
Wir betreiben derzeit kein bezahltes Bug-Bounty-Programm, aber wir werden Forscher in den Versionshinweisen mit ihrer Erlaubnis erwähnen.
Sieht Reach meine Passwörter?
Nein. Wenn Sie sich über HTTPS bei einer Website anmelden – was praktisch alle Anmeldeseiten verwenden –, läuft Ihre TLS-Sitzung über Reachs Tunnel Ende-zu-Ende zwischen Ihrem Browser und der Zielwebsite; Reach leitet nur verschlüsselte Bytes weiter und entschlüsselt sie niemals. Es ist strukturell nicht in der Lage, den Inhalt des Anmeldeformulars, einschließlich Ihres Passworts, zu sehen. Als allgemeine Regel gilt: Vermeiden Sie das Senden von Anmeldedaten über unverschlüsseltes HTTP in jedem Netzwerk.
Kann Reach meine HTTPS-Surf-Inhalte lesen?
Bei HTTPS – praktisch dem gesamten modernen Websurfen – nein. Reach fängt HTTPS-Datenverkehr weder ab noch entschlüsselt es ihn – es leitet Ihren bereits verschlüsselten Datenverkehr lediglich über einen Tunnel weiter, und Ihre TLS-Sitzung erreicht die Zielwebsite Ende-zu-Ende. Das Gateway kennt den Ziel-Hostnamen (z. B. example.com) nur, weil Ihr Browser dem Proxy mitteilt, wohin er sich verbinden soll (das übliche CONNECT-Ziel), nicht indem etwas innerhalb des verschlüsselten Handshakes analysiert wird – und es sieht niemals den URL-Pfad, die Abfragezeichenfolge oder den Seiteninhalt. Das ist bei HTTPS eine strukturelle Garantie des Tunnel-Designs, nicht nur eine Protokollierungsrichtlinie. Standardmäßig protokollieren wir Hostnamen überhaupt nicht; sie werden nur dann erfasst, wenn Sie oder Ihre Organisation das optionale Verbindungsprotokoll aktivieren (nur Hostname und zeitlicher Verlauf der Verbindung, 30 Tage aufbewahrt). Für die kleine Minderheit des unverschlüsselten HTTP-Datenverkehrs, der noch im Internet existiert, gilt diese strukturelle Garantie nicht – der lokale Proxy ist technisch in der Lage, die Anfrage zu lesen, wie jeder Klartext-Forward-Proxy, aber wir untersuchen oder speichern deren Inhalt nicht.
Wo werden meine Daten gespeichert?
Kontodaten, Messprotokolle und alle Protokolle werden in der Google Cloud in der Region Sydney gespeichert. Wir replizieren keine personenbezogenen Daten in Rechtsordnungen außerhalb Australiens, es sei denn, dies ist für den Standard-Infrastrukturbetrieb von Google erforderlich. Weitere Einzelheiten finden Sie in unserer Datenschutzerklärung.
Wie melde ich eine Schwachstelle?
Senden Sie eine E-Mail an [email protected] mit einer Beschreibung des Problems, Schritten zur Reproduktion und unterstützendem Material. Wir bemühen uns, alle Berichte innerhalb eines Werktages zu bestätigen. Bitte geben Sie uns Zeit, das Problem zu beheben, bevor eine öffentliche Offenlegung erfolgt.