Las dos primeras partes de esta serie describieron el flujo de software del login de Gmail (Parte 1) y la infraestructura de Borg, Spanner y TrueTime que lo hace posible (Parte 2). Esta tercera parte cierra con los dos sistemas que más diferencian el login de Gmail de cualquier sistema de autenticación convencional:
Dapper, el sistema de distributed tracing que permite a los ingenieros de Google observar, en tiempo real, qué pasa en cada milisegundo de cada login a través de decenas de servicios distribuidos.
El Risk Engine — el sistema que evalúa docenas de señales en tiempo real para decidir si el login actual lo está haciendo el dueño de la cuenta, un bot, o alguien con credenciales robadas.
👉🏼Fuentes: Authentication at Scale - Google Research · Dapper paper - Google Research
El problema de la observabilidad a escala de Google
Cuando un login de Gmail tarda más de lo esperado, ¿cómo sabes en cuál de las 8 capas ocurrió la latencia? ¿Fue el Edge Proxy que tardó en terminar TLS? ¿El Auth Service que tuvo un cache miss y fue a Spanner? ¿El Risk Engine que evaluó demasiadas señales? ¿La red entre servicios?
En un sistema monolítico, agregar un profiler al proceso te da la respuesta. En un sistema distribuido donde cada request toca decenas de servicios corriendo en cientos de máquinas diferentes, esa pregunta es extremadamente difícil de responder sin infraestructura específica de observabilidad.
Ese es el problema que Dapper resolvió para Google en 2010 y cuyas ideas se convirtieron en OpenTelemetry, el estándar open-source de observabilidad que usamos hoy.
Dapper: el modelo mental de un login como árbol de spans
Dapper modela cada request de usuario como un árbol de spans. Un span es una unidad de trabajo con un tiempo de inicio, un tiempo de fin, y metadatos sobre qué hizo esa unidad de trabajo.
Para el login de Gmail, el árbol de spans se ve así:
login_request — total: 342ms
├── edge_proxy.tls_termination — 12ms
├── edge_proxy.request_validation — 3ms
├── auth_service.credential_check — 89ms
│ ├── cache.lookup_user — 4ms (cache HIT)
│ └── auth_service.password_verify — 85ms
├── risk_engine.evaluate — 134ms
│ ├── risk_engine.geo_check — 8ms
│ ├── risk_engine.device_fingerprint — 22ms
│ ├── risk_engine.behavior_model — 91ms
│ └── risk_engine.network_reputation — 13ms
├── token_service.generate — 67ms
│ ├── spanner.write_session — 45ms
│ └── cache.write_session — 22ms
└── edge_proxy.response — 37ms
Este árbol tiene tres propiedades fundamentales:
Cada span tiene un trace ID global único el mismo ID que el Edge Proxy inyectó en el header del request en la Parte 1. Todos los servicios que participan en el login usan ese ID para asociar sus spans al árbol correcto, incluso si están corriendo en máquinas físicamente diferentes.
Cada span tiene un parent ID que indica qué span lo invocó. Esto es lo que permite reconstruir la estructura de árbol a partir de spans individuales recolectados de diferentes servicios.
Los spans son anotables los ingenieros pueden agregar metadata libre al span: qué usuario estaba siendo autenticado (anonimizado), qué tipo de device, si hubo un cache hit o miss, el risk score calculado. Esta información aparece en el dashboard de Dapper y es fundamental para el debugging.
Cómo Dapper recolecta los datos sin afectar el performance
El challenge técnico de Dapper es que debe tener overhead mínimo no puede añadir latencia significativa al login mientras lo está midiendo. La solución es un modelo de sampling: Dapper no traza cada login, sino una fracción estadísticamente representativa.
En producción, Dapper traza aproximadamente 1 de cada 1,024 requests. Dado que Gmail procesa millones de logins, incluso esa fracción produce miles de trazas por segundo suficientes para detectar tendencias, anomalías de latencia y degradaciones de servicio con alta confianza estadística.
Los datos de traza se escriben en logs locales en cada máquina (sin bloquear el thread principal del request), y un daemon de Dapper los recolecta asincrónicamente y los envía a los repositorios centrales de Bigtable para análisis.
El impacto en el debugging real
El paper de Dapper documenta cómo el equipo de Gmail usó el sistema para identificar que una librería de serialización común estaba generando más llamadas RPC de las necesarias en ciertos flujos de login. Sin Dapper, ese bug habría sido casi imposible de localizar la latencia adicional se distribuía entre decenas de servicios en cantidades demasiado pequeñas para ser detectables individualmente. Con Dapper, el árbol de spans mostró exactamente dónde se acumulaban los microsegundos.
OpenTelemetry el estándar de observabilidad que usamos en Ab4cus con Sentry y Pino es la implementación open-source de las mismas ideas. Traces, spans, trace IDs propagados entre servicios, sampling configurable todo viene del diseño original de Dapper.
El Risk Engine: la ciencia detrás de "¿eres tú?"
El Risk Engine es el sistema más sofisticado del stack de autenticación de Gmail. Su función es responder una pregunta aparentemente simple en menos de 100 milisegundos: dado todo lo que sabemos sobre este usuario y este intento de login, ¿cuál es la probabilidad de que sea el dueño de la cuenta?
Las señales que evalúa
El paper de Authentication at Scale de Google describe las categorías de señales que el Risk Engine combina:
Señales geoespaciales: el sistema mantiene un historial de las ubicaciones geográficas desde donde el usuario ha iniciado sesión. Una IP en Bogotá para un usuario que siempre inicia sesión desde Bogotá tiene riesgo bajo. La misma cuenta apareciendo desde Kyiv 20 minutos después de un login desde Bogotá es físicamente imposible viaje imposible. El sistema detecta este patrón automáticamente.
Device fingerprint: el navegador tiene características únicas User-Agent, resolución de pantalla, fonts instaladas, extensiones activas (detectables por timing de carga), versión exacta del engine de JavaScript. Un login desde un dispositivo nunca visto antes para esa cuenta tiene más riesgo que uno desde el laptop principal del usuario.
Señales conductuales: el Risk Engine también evalúa "cómo" escribe el usuario velocidad de escritura, timing entre teclas, patrones de corrección de errores, movimiento del mouse antes de hacer clic en "Iniciar sesión". Estos patrones son suficientemente únicos para contribuir a la identidad del usuario. Los bots que hacen credential stuffing tienen patrones de typing completamente diferentes a los humanos.
Reputación de red: ¿la IP de origen pertenece a un datacenter? ¿A una red de VPN conocida? ¿A un proveedor de proxies? ¿Tiene historial de envío de spam? Las IPs de datacenters generan más sospecha porque los usuarios legítimos raramente inician sesión desde servidores.
Historial de la cuenta: ¿cuántos intentos fallidos recientes? ¿La cuenta fue reportada por phishing? ¿Hay actividad sospechosa en los últimos minutos (múltiples logins desde diferentes IPs casi simultáneamente)?
El modelo de scoring
Todas estas señales se combinan en un modelo de machine learning que produce un score de riesgo entre 0 y 1. El paper documenta que el modelo es entrenado continuamente con datos de logins confirmados como legítimos o fraudulentos la retroalimentación del usuario (reportes de "alguien más inició sesión en mi cuenta") es una señal de entrenamiento valiosa.
El score determina la acción:
| Risk Score | Acción del sistema | Experiencia del usuario |
|---|---|---|
| 0.0 – 0.2 | Login directo | Sin fricción — acceso inmediato |
| 0.2 – 0.5 | 2FA opcional solicitado | Se pide verificación adicional sugerida |
| 0.5 – 0.75 | 2FA obligatorio | Debe verificar por SMS, app o llave física |
| 0.75 – 0.9 | Challenge adicional | CAPTCHA + verificación por email/SMS alternativo |
| 0.9 – 1.0 | Bloqueo + alerta | Login bloqueado, notificación al usuario |
El tercer factor implícito
El paper de Authentication at Scale lo describe con una distinción elegante: si el 2FA tradicional comprende "algo que sabes" (password) y "algo que tienes" (el teléfono), el Risk Engine agrega "en algún lugar donde estás" y "de alguna manera como te comportas". Es un tercer factor implícito que el usuario no percibe no hay un paso adicional en el flujo de login pero que el sistema evalúa en cada autenticación.
Las opciones de segundo factor: la jerarquía de seguridad
Cuando el Risk Engine decide que se requiere un segundo factor, el Auth Service ofrece las opciones disponibles según lo que el usuario tiene configurado. El paper documenta la jerarquía de seguridad real de cada opción:
Security Key (FIDO2/WebAuthn): el segundo factor más seguro. Una llave física USB o NFC que el usuario conecta al dispositivo. La verificación está atada criptográficamente al dominio — es físicamente imposible de phishear porque la llave verifica que está hablando con accounts.google.com real, no con una página falsa.
Google Authenticator / TOTP: un código de 6 dígitos que cambia cada 30 segundos, generado por una app en el teléfono. Más seguro que SMS porque no puede ser interceptado en la red. Vulnerable a phishing en tiempo real (un atacante puede pedirte el código mientras lo ingresas en su página falsa).
SMS / llamada telefónica: el menos seguro de los segundos factores disponibles. Vulnerable a SIM swapping un atacante que logra convencer a la operadora de transferir tu número puede recibir los SMS. Google desaconseja activamente este método para cuentas de alto riesgo.
Google Prompt: una notificación push al teléfono del usuario que muestra la ubicación del login y pide confirmación. Más seguro que SMS porque el teléfono debe estar desbloqueado y el usuario debe verificar activamente los detalles del login antes de aprobar.
Privacy-Enhanced Client Certificates: el futuro que ya existe
El paper documenta un mecanismo más sofisticado que la mayoría de sistemas de autenticación no implementan: client certificates con privacy enhancement. En este modelo, el dispositivo del usuario tiene una clave privada que usa en nombre del usuario para autenticarse ante los servidores de Google, sin que la clave nunca abandone el dispositivo.
El enhancement de privacidad viene de que el sistema puede verificar que el dispositivo tiene credenciales válidas sin revelar cuál dispositivo específico está siendo usado previniendo tracking de comportamiento entre sesiones. Es el mismo principio de las Passkeys modernas (FIDO2), que Google empezó a desplegar masivamente a partir de 2023.
La lección final: la observabilidad es seguridad
El insight más importante de esta serie es uno que rara vez se menciona en los textos de arquitectura: Dapper y el Risk Engine no son sistemas separados del sistema de autenticación son parte integral de él.
Sin Dapper, los ingenieros de Google no podrían detectar cuándo una degradación de latencia en el Risk Engine está causando timeouts que hacen que el Auth Service falle al score seguro. Sin el Risk Engine, el Auth Service sería un sistema de verificación de passwords útil, pero insuficiente para proteger cuentas a escala de Gmail.
La observabilidad no es un afterthought. Es la infraestructura que hace que el sistema sea debuggeable, mejorable y seguro en producción. En Ab4cus implementamos Sentry para error tracking, Pino para logging estructurado, y OpenTelemetry para distributed tracing en todos nuestros proyectos por exactamente esta razón.
La serie completa
- Parte 1: El flujo de software — las 8 capas del login de Gmail
- Parte 2: Borg, Spanner y TrueTime — la infraestructura de Google
- Parte 3: Dapper y el Risk Engine (este artículo)
💣Calcular el costo de un sistema con observabilidad enterprise
De los datos a la estrategia: cómo la analítica impulsa el crecimiento
0 Comentarios