La sécurité chez TYO Reach
La sécurité est fondamentale pour ce que fait Reach — vous acheminez votre trafic via notre infrastructure, vous avez donc tout à fait le droit de savoir exactement comment il est traité.
Comment votre trafic se déplace via Reach
Comprendre le chemin des données vous aide à évaluer ce que nous pouvons voir et ce que nous ne pouvons pas — et pourquoi la conception est ainsi faite.
Lorsque Reach est actif, le trafic sélectionné depuis votre appareil voyage vers la passerelle de TYO Reach via une connexion HTTPS chiffrée. La passerelle — fonctionnant sur Google Cloud Run à Sydney — transfère la requête vers le serveur de destination en votre nom. La destination voit l'adresse IP de la passerelle, pas la vôtre. Le TLS est appliqué à chaque saut : de votre appareil vers la passerelle, et de la passerelle vers la destination.
TYO Reach utilise mitmproxy comme moteur de proxy sous-jacent. "Man-in-the-middle" est une description technique de la façon dont le proxy intercepte la connexion, pas une description d'intention. Cette interception est nécessaire pour deux objectifs spécifiques :
- Authentification. Reach ajoute un en-tête
Proxy-Authorisationafin que la passerelle puisse identifier à quel compte appartient la requête et appliquer votre quota de données. - Application de la politique. Les règles de routage — quels domaines sortent via quelle passerelle — sont appliquées à cette couche.
Le proxy termine votre session TLS, inspecte les métadonnées HTTP (nom d'hôte et méthode), applique la politique et rechiffre la requête avant de la transférer. Les certificats TLS de destination sont validés normalement par la passerelle. C'est le même modèle utilisé par les passerelles de sécurité web d'entreprise.
Ce que nous journalisons — et ce que nous ne journalisons délibérément pas
Reach mesure la quantité de données que vous utilisez. Par défaut, il n'enregistre pas ce que vous en faites — un journal de connexion optionnel, désactivé sauf si vous ou votre organisation l'activez, en est la seule exception.
Ce que nous journalisons par défaut
Nous enregistrons le volume total de données (octets) transférées via votre compte par période de facturation. C'est la seule information nécessaire pour appliquer votre quota de données mensuel, et c'est la seule chose que nous journalisons sauf si vous activez le journal de connexion optionnel.
Ce que nous ne journalisons pas
Nous ne journalisons jamais les chemins d'URL, les chaînes de requête, les termes de recherche ou le contenu des pages. Nous n'enregistrons pas d'historique des domaines que vous visitez, sauf si vous (ou votre organisation) activez le journal de connexion optionnel, et même dans ce cas seuls le nom d'hôte et l'horodatage de la connexion sont stockés, jamais les chemins ni le contenu. Nous ne construisons pas de profils de navigation et ne partageons pas les données de trafic avec des annonceurs ou des fournisseurs d'analyse.
Journal de connexion optionnel & rétention
Les données de mesure du volume d'octets sont conservées pour votre période de facturation actuelle plus une courte période pour la résolution des litiges. Le journal de connexion (d'accès) optionnel est désactivé par défaut ; lorsque vous ou votre organisation l'activez, les métadonnées au niveau de la connexion (hôte, heure, durée) sont conservées pendant un maximum de 30 jours, puis supprimées. Tous les journaux sont stockés dans Google Cloud dans la région de Sydney.
Identité soutenue par TYO ID
L'authentification pour TYO Reach est gérée par id.tyo.com.au — le propre service d'identité de TYO — et non par une plateforme tierce que nous ne contrôlons pas.
Identité hébergée en Australie
TYO ID fonctionne sur Google Cloud en Australie. Vos identifiants de compte ne transitent jamais par une plateforme d'identité américaine ou européenne. Les flux de connexion utilisent OAuth 2.0 avec des jetons de session à courte durée de vie — les identifiants à longue durée de vie ne sont jamais stockés dans l'application cliente.
MFA et TOTP
L'authentification multi-facteurs est disponible via TOTP (mots de passe à usage unique basés sur le temps — compatibles avec toute application d'authentification RFC 6238). Les administrateurs d'équipe peuvent exiger le MFA pour tous les membres du groupe ; les utilisateurs ne peuvent pas refuser une politique MFA imposée par le groupe.
Connexion Google & Microsoft
Les équipes peuvent se connecter avec Google ou Microsoft. La fédération d'annuaire d'entreprise Azure AD / OIDC est disponible sur demande pour les organisations qui en ont besoin.
Comment la passerelle est construite et exploitée
La passerelle fonctionne sur une infrastructure serverless gérée — pas de machines virtuelles persistantes, pas d'accès SSH, pas de secrets à longue durée de vie dans l'environnement.
Google Cloud Run
La passerelle proxy Reach fonctionne sur Cloud Run — la plateforme de conteneurs serverless gérée de Google. Cloud Run évolue automatiquement, applique la sécurité de l'infrastructure sous-jacente de Google, et signifie qu'il n'y a pas de VM persistantes à patcher pour nous ou sur lesquelles un attaquant pourrait persister entre les déploiements.
Pas d'accès SSH à la production
Il n'y a pas d'accès SSH ou shell à la passerelle en cours d'exécution. Tous les déploiements passent par le pipeline de déploiement de Google Cloud. Les retours en arrière sont effectués via redéploiement, pas via un accès console.
GCP Secret Manager
Les identifiants sensibles — clés API, jetons de service, chaînes de connexion de base de données — sont stockés dans GCP Secret Manager, pas dans des fichiers de variables d'environnement ou du code. La passerelle récupère les secrets au démarrage via une API interne authentifiée.
Patching automatique de la plateforme
Cloud Run gère automatiquement le patching de l'OS et de l'environnement d'exécution. Nous maintenons la couche application ; Google maintient la plateforme. Il n'y a pas de surface de VM non patchée.
Vous avez trouvé une vulnérabilité de sécurité ?
Si vous avez trouvé un problème dans TYO Reach, nous voulons en entendre parler avant qu'il ne soit divulgué publiquement.
Envoyez une description du problème à [email protected]. Veuillez inclure :
- Une description claire de la vulnérabilité et son impact potentiel.
- Les étapes pour reproduire (une preuve de concept nous aide à trier plus rapidement).
- Des captures d'écran, des journaux ou toute preuve à l'appui.
Nous visons à accuser réception de tous les rapports de sécurité dans un délai d'un jour ouvrable et à fournir un calendrier de résolution dans les trois jours ouvrables suivant la confirmation du problème. Veuillez nous laisser un temps raisonnable pour corriger le problème avant toute divulgation publique.
Nous vous demandons de :
- Ne pas accéder ou modifier les données appartenant à d'autres utilisateurs.
- Ne pas effectuer de tests de déni de service contre les systèmes de production.
- Agir de bonne foi.
Nous ne gérons pas actuellement de programme de prime aux bugs payant, mais nous remercierons les chercheurs dans les notes de version avec leur permission.
Reach voit-il mes mots de passe ?
Si vous vous connectez à un site via HTTPS — ce que pratiquement toutes les pages de connexion utilisent — le contenu du formulaire de connexion, y compris votre mot de passe, est chiffré de bout en bout entre votre navigateur et le site de destination. La passerelle Reach voit le nom d'hôte de la connexion mais ne peut pas lire le contenu de la requête, y compris les champs de mot de passe. En règle générale : évitez d'envoyer des identifiants via HTTP non chiffré sur n'importe quel réseau.
Reach peut-il lire mon contenu de navigation HTTPS ?
Pour les connexions HTTPS, la passerelle voit le nom d'hôte (par ex. example.com) mais pas le chemin d'URL, la chaîne de requête ou le contenu de la page. Par défaut, nous ne journalisons pas du tout les noms d'hôte ; ils ne sont enregistrés que si vous ou votre organisation activez le journal de connexion optionnel (nom d'hôte et horodatage de la connexion uniquement, conservés pendant 30 jours). Pour la petite minorité de trafic HTTP non chiffré qui existe encore sur internet, la passerelle est techniquement capable de lire la requête, mais nous n'en inspectons ni n'en stockons le contenu.
Où mes données sont-elles stockées ?
Les données de compte, les enregistrements de mesure et tous les journaux sont stockés dans Google Cloud dans la région de Sydney. Nous ne répliquons pas les données personnelles vers des juridictions en dehors de l'Australie, sauf si cela est requis par les opérations d'infrastructure standard de Google. Voir notre Politique de confidentialité pour plus de détails.
Comment signaler une vulnérabilité ?
Envoyez un e-mail à [email protected] avec une description du problème, les étapes pour reproduire et tout matériel à l'appui. Nous visons à accuser réception de tous les rapports dans un délai d'un jour ouvrable. Veuillez nous laisser le temps de résoudre le problème avant toute divulgation publique.