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, reist ausgewählter Datenverkehr von Ihrem Gerät über eine verschlüsselte HTTPS-Verbindung zum Gateway von TYO Reach. Das Gateway – das auf Google Cloud Run in Sydney läuft – leitet die Anfrage in Ihrem Namen an den Zielserver weiter. Das Ziel sieht die IP-Adresse des Gateways, nicht Ihre. TLS wird bei jedem Hop erzwungen: von Ihrem Gerät zum Gateway und vom Gateway zum Ziel.
TYO Reach verwendet mitmproxy als zugrunde liegende Proxy-Engine. "Man-in-the-Middle" ist eine technische Beschreibung dafür, wie der Proxy die Verbindung abfängt, keine Beschreibung der Absicht. Dieses Abfangen ist für zwei spezifische Zwecke erforderlich:
- Authentifizierung. Reach fügt einen
Proxy-Authorisation-Header hinzu, damit das Gateway identifizieren kann, zu welchem Konto die Anfrage gehört, und Ihr Datenkontingent durchsetzen kann. - Richtliniendurchsetzung. Routing-Regeln – welche Domains über welches Gateway ausgehen – werden auf dieser Ebene angewendet.
Der Proxy beendet Ihre TLS-Sitzung, inspiziert die HTTP-Metadaten (Hostname und Methode), wendet die Richtlinie an und verschlüsselt die Anfrage erneut, bevor er sie weiterleitet. Ziel-TLS-Zertifikate werden vom Gateway normal validiert. Dies ist das gleiche Modell, das von Web-Sicherheits-Gateways in Unternehmen verwendet wird.
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?
Wenn Sie sich über HTTPS bei einer Website anmelden – was praktisch alle Anmeldeseiten verwenden –, ist der Inhalt des Anmeldeformulars, einschließlich Ihres Passworts, Ende-zu-Ende zwischen Ihrem Browser und der Zielwebsite verschlüsselt. Das Reach-Gateway sieht den Hostnamen der Verbindung, kann aber den Inhalt der Anfrage, einschließlich Passwortfeldern, nicht lesen. 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-Verbindungen sieht das Gateway den Hostnamen (z. B. example.com), aber nicht den URL-Pfad, die Abfragezeichenfolge oder den Seiteninhalt. 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, ist das Gateway technisch in der Lage, die Anfrage zu lesen, 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.