Seguridad en TYO Reach
La seguridad es fundamental para lo que hace Reach: estás enrutando tu tráfico a través de nuestra infraestructura, por lo que tienes todo el derecho a saber exactamente cómo se maneja.
Cómo se mueve tu tráfico a través de Reach
Entender la ruta de los datos te ayuda a evaluar lo que podemos y no podemos ver, y por qué el diseño es como es.
Cuando Reach está activo, la aplicación cliente ejecuta un pequeño proxy local (HTTP CONNECT y SOCKS5) al que se conecta tu navegador. Para HTTPS, cuando tu navegador abre una conexión, el proxy local devuelve "200 Connection Established" y retransmite los bytes originales, aún cifrados, a la puerta de enlace de TYO Reach — que se ejecuta en infraestructura de nube gestionada en tu región seleccionada — a través de un túnel autenticado; la puerta de enlace retransmite esos mismos bytes al servidor de destino. La sesión TLS original de tu navegador se ejecuta de extremo a extremo hasta el sitio de destino a través de ese túnel — Reach es una tubería, no un punto final. Nunca ve texto plano, nunca genera ni presenta un certificado sustituto, y no instala ninguna CA raíz en tu dispositivo. El destino ve la dirección IP de la puerta de enlace, no la tuya.
Lo que se autentica es el propio túnel, no tu tráfico: el cliente envía un encabezado X-Reach-Key al abrir el túnel con la puerta de enlace, para que esta pueda identificar tu cuenta y aplicar tu límite de datos. La aplicación de políticas (qué dominios salen a través de qué puerta de enlace) y la medición se realizan a partir de metadatos de conexión — el host de destino que tu navegador le pide a la puerta de enlace que alcance, y el recuento de bytes —, nunca leyendo contenido descifrado.
Lo que registramos y lo que deliberadamente no registramos
Reach mide cuántos datos usas. De forma predeterminada, no registra lo que haces con ellos; un registro de conexiones opcional, desactivado a menos que tú o tu organización lo habilitéis, es la única excepción.
Lo que registramos de forma predeterminada
Registramos el volumen total de datos (bytes) transferidos a través de tu cuenta por período de facturación. Esta es la única información necesaria para aplicar tu límite mensual de datos, y es lo único que registramos a menos que actives el registro de conexiones opcional.
Lo que no registramos
No registramos rutas de URL, cadenas de consulta, términos de búsqueda ni contenido de páginas, nunca. No registramos un historial de los dominios que visitas a menos que tú (o tu organización) activéis el registro de conexiones opcional, e incluso entonces solo se almacenan el nombre de host y la hora de la conexión, nunca las rutas ni el contenido. No creamos perfiles de navegación ni compartimos datos de tráfico con anunciantes o proveedores de análisis.
Registro de conexiones opcional y retención
Los datos de medición de conteo de bytes se conservan durante tu período de facturación actual más un breve período adicional para la resolución de disputas. El registro de conexiones (acceso) opcional está desactivado de forma predeterminada; cuando tú o tu organización lo habilitáis, los metadatos a nivel de conexión (host, hora, duración) se conservan durante un máximo de 30 días y luego se eliminan. Todos los registros se almacenan en Google Cloud en la región de Sídney.
Identidad respaldada por TYO ID
La autenticación para TYO Reach es manejada por id.tyo.com.au, el propio servicio de identidad de TYO, no por una plataforma de terceros que no controlamos.
Identidad alojada en Australia
TYO ID se ejecuta en Google Cloud en Australia. Tus credenciales de cuenta nunca transitan por una plataforma de identidad de EE. UU. o la UE. Los flujos de inicio de sesión utilizan OAuth 2.0 con tokens de sesión de corta duración; las credenciales de larga duración nunca se almacenan en la aplicación cliente.
MFA y TOTP
La autenticación multifactor está disponible a través de TOTP (contraseñas de un solo uso basadas en tiempo, compatibles con cualquier aplicación de autenticación RFC 6238). Los administradores de equipo pueden requerir MFA para todos los miembros del grupo; los usuarios no pueden optar por no participar en una política de MFA aplicada por el grupo.
Inicio de sesión con Google y Microsoft
Los equipos pueden iniciar sesión con Google o Microsoft. La federación de directorios empresarial Azure AD / OIDC está disponible bajo petición para organizaciones que la necesiten.
Cómo se construye y opera la puerta de enlace
La puerta de enlace se ejecuta en una infraestructura sin servidor gestionada: sin máquinas virtuales persistentes, sin acceso SSH, sin secretos de larga duración en el entorno.
Google Cloud Run
La puerta de enlace proxy de Reach se ejecuta en Cloud Run, la plataforma de contenedores sin servidor gestionada de Google. Cloud Run escala automáticamente, aplica la seguridad de la infraestructura subyacente de Google y significa que no hay máquinas virtuales persistentes para que nosotros las parchemos o para que un atacante persista entre implementaciones.
Sin acceso SSH a producción
No hay acceso SSH o shell a la puerta de enlace en ejecución. Todas las implementaciones pasan por la canalización de implementación de Google Cloud. Las reversiones se realizan mediante la reimplementación, no mediante el acceso a la consola.
GCP Secret Manager
Las credenciales sensibles (claves API, tokens de servicio, cadenas de conexión de bases de datos) se almacenan en GCP Secret Manager, no en archivos de variables de entorno o código. La puerta de enlace recupera los secretos al inicio a través de una API interna autenticada.
Parcheo automático de la plataforma
Cloud Run maneja el parcheo del SO y del tiempo de ejecución automáticamente. Nosotros mantenemos la capa de aplicación; Google mantiene la plataforma. No hay una superficie de máquina virtual sin parches.
¿Encontraste una vulnerabilidad de seguridad?
Si has encontrado un problema en TYO Reach, queremos saberlo antes de que se divulgue públicamente.
Envía una descripción del problema a [email protected]. Por favor, incluye:
- Una descripción clara de la vulnerabilidad y su impacto potencial.
- Pasos para reproducir (una prueba de concepto nos ayuda a clasificar más rápido).
- Capturas de pantalla, registros o cualquier evidencia de respaldo.
Nuestro objetivo es reconocer todos los informes de seguridad dentro de un día hábil y proporcionar un cronograma de resolución dentro de los tres días hábiles posteriores a la confirmación del problema. Por favor, danos un tiempo razonable para solucionar el problema antes de cualquier divulgación pública.
Te pedimos que:
- No accedas ni modifiques datos pertenecientes a otros usuarios.
- No realices pruebas de denegación de servicio contra sistemas de producción.
- Actúes de buena fe.
Actualmente no ejecutamos un programa de recompensas por errores pagado, pero reconoceremos a los investigadores en las notas de la versión con su permiso.
¿Reach ve mis contraseñas?
No. Si estás iniciando sesión en un sitio a través de HTTPS (que utilizan prácticamente todas las páginas de inicio de sesión), tu sesión TLS se ejecuta de extremo a extremo entre tu navegador y el sitio de destino a través del túnel de Reach; Reach solo retransmite bytes cifrados y nunca los descifra. Es estructuralmente incapaz de ver el contenido del formulario de inicio de sesión, incluida tu contraseña. Como regla general: evita enviar credenciales a través de HTTP no cifrado en cualquier red.
¿Puede Reach leer mi contenido de navegación HTTPS?
Para HTTPS — prácticamente toda la navegación moderna —, no. Reach no intercepta ni descifra el tráfico HTTPS — retransmite tu tráfico, ya cifrado, a través de un túnel, y tu sesión TLS llega de extremo a extremo hasta el sitio de destino. La puerta de enlace conoce el nombre de host de destino (por ejemplo, example.com) únicamente porque tu navegador le indica al proxy adónde conectarse (el destino CONNECT estándar), no analizando nada dentro del protocolo de enlace cifrado — y nunca ve la ruta de la URL, la cadena de consulta o el contenido de la página. Esto es una garantía estructural del diseño del túnel para HTTPS, no solo una política de registro. De forma predeterminada, no registramos nombres de host en absoluto; solo se registran si tú o tu organización habilitáis el registro de conexiones opcional (únicamente el nombre de host y la hora de la conexión, conservados durante 30 días). Para la pequeña minoría de tráfico HTTP no cifrado que aún existe en internet, esa garantía estructural no aplica — el proxy local es técnicamente capaz de leer la solicitud, igual que cualquier proxy de reenvío en texto plano, pero no inspeccionamos ni almacenamos su contenido.
¿Dónde se almacenan mis datos?
Los datos de la cuenta, los registros de medición y cualquier registro se almacenan en Google Cloud en la región de Sídney. No replicamos datos personales a jurisdicciones fuera de Australia, excepto según lo requerido por las operaciones de infraestructura estándar de Google. Consulta nuestra Política de Privacidad para obtener todos los detalles.
¿Cómo informo de una vulnerabilidad?
Envía un correo electrónico a [email protected] con una descripción del problema, los pasos para reproducir y cualquier material de respaldo. Nuestro objetivo es reconocer todos los informes dentro de un día hábil. Por favor, danos tiempo para abordar el problema antes de la divulgación pública.