Zero Trust: la red deja de ser una credencial

Empieza un nivel distinto a los anteriores. Hasta aquí has aprendido a construir: isolates, bindings, almacenamiento, colas, agentes. Ahora toca la pregunta que ninguna de esas piezas responde por sí sola, y es quién tiene derecho a poner en marcha todo ese aparato. Durante treinta años la industria contestó con una palabra que parecía técnica y era geográfica: dentro. Dentro del cortafuegos, dentro de la VPN, dentro del rango privado. Zero Trust no es un producto ni una casilla que se activa; es la retirada formal de esa respuesta y la obligación de sustituirla por otra que se pueda demostrar en cada petición. Verás qué se rompió exactamente, qué axiomas ocupan el hueco y por qué el borde de Cloudflare resulta ser, casi por accidente topológico, el lugar donde la nueva respuesta se puede aplicar sin coste añadido.

La hipótesis que nadie escribió

El modelo clásico se dibujaba como un castillo: un foso de cortafuegos, un puente levadizo de VPN y, tras cruzarlo, un patio donde todo el mundo circula. Ese patio tiene un nombre técnico en la literatura, zona de confianza implícita, y la palabra importante es la segunda. La confianza nunca se concedió de forma explícita a nadie; se derivó de una propiedad de la topología. Quien consiguiera una dirección dentro del rango heredaba, sin más trámite, los permisos que el rango llevaba asociados.

Esa derivación era un salto lógico que jamás se justificó. Una dirección IP es una afirmación sobre el encaminamiento de paquetes: dice por dónde volverá la respuesta. No dice quién teclea, ni desde qué máquina, ni si esa máquina tiene el disco cifrado, ni si la sesión sigue perteneciendo a la misma persona que la abrió. Convertir un dato de transporte en una credencial de autorización fue una comodidad de ingeniería que funcionó mientras la oficina y la red coincidían.

Dos cosas la rompieron a la vez. La primera, que el dentro dejó de ser un sitio: aplicaciones en SaaS, portátiles en casas ajenas, contratistas, móviles, integraciones con terceros. La segunda, y más grave, que el primer movimiento de cualquier atacante consiste precisamente en entrar. Basta una credencial pescada por correo para que el intruso aparezca del lado bueno del foso, y a partir de ahí el modelo no vuelve a hacerle ni una pregunta. El desplazamiento lateral no es un fallo del modelo de perímetro; es su comportamiento previsto aplicado a la persona equivocada.

Hay un tercer defecto, menos comentado y más estructural: la granularidad. Una VPN concede acceso a una red, no a una aplicación. La unidad que quieres proteger es el recurso, y la unidad que el mecanismo sabe manejar es el segmento. Esa asimetría obliga a conceder siempre de más, y el exceso concedido es exactamente la superficie por la que se propaga un incidente. El Foro Jericho ya nombró el problema en 2004 y lo llamó desperimetrización; BeyondCorp lo convirtió en arquitectura una década después, tras un incidente que atravesó el patio de una de las redes mejor defendidas del planeta.

Conviene además notar que el modelo de perímetro no solo concede de más, sino que concede en silencio. Cuando el acceso se deriva de la topología, no existe ningún momento en el que alguien decida conceder algo, y por tanto no existe ningún registro de esa concesión. Un intruso que se mueve por el patio no genera eventos de autorización porque no está siendo autorizado por nadie: está circulando. La ausencia de decisión explícita es también ausencia de auditoría, y esa es la razón por la que los tiempos medios de detección en incidentes de red plana se miden históricamente en meses y no en horas.

Y hay un cuarto defecto que se vuelve visible solo cuando el sistema envejece: la reversibilidad asimétrica. Abrir un rango es una operación de un minuto que resuelve un problema urgente; cerrarlo requiere saber quién dependía de él, y esa información nunca se escribió. Las reglas de un cortafuegos corporativo crecen de forma monótona por la misma razón que crecen las dependencias de un proyecto viejo, y al cabo de una década describen la historia de la organización mejor que su arquitectura.

Los axiomas que ocupan el hueco

Retirar la hipótesis obliga a poner algo en su lugar, y ese algo está formalizado en NIST SP 800-207. Conviene leerlo no como una lista de buenas prácticas sino como un conjunto de axiomas, porque cada uno cierra una de las puertas que el modelo anterior dejaba abiertas.

La quinta fila de la tabla lleva un signo de barra que conviene leer bien: identidad, postura y origen no son alternativas sino sumandos, y el valor de una decisión está en cuántos de esos sumandos puedes exigir a la vez sin que el usuario legítimo lo note.

El axioma que más cuesta interiorizar es el tercero, porque introduce el tiempo. Si el acceso se concede por sesión, entonces la confianza no es un estado que se adquiere una vez, sino una magnitud que caduca y hay que renovar. De ahí salen, como consecuencias y no como decisiones de producto, la duración de sesión configurable, la reautenticación ante acciones sensibles y la reevaluación de la postura del dispositivo mientras la sesión sigue viva.

El cuarto axioma es el que separa Zero Trust de un simple inicio de sesión delante de cada aplicación. Una política dinámica no pregunta solo quién eres: pregunta desde qué dispositivo, con qué método de autenticación, desde qué país, con qué versión del sistema operativo, dentro de qué grupo del directorio y en qué momento. Cada una de esas dimensiones es una señal independiente, y el valor de la decisión crece de forma no lineal con el número de señales que puedes correlacionar sin fricción para el usuario legítimo.

La independencia de las señales es la propiedad que hace que la suma valga más que las partes. Una contraseña robada rompe una dimensión; un dispositivo comprometido rompe otra; un país imposible rompe una tercera. Exigir varias a la vez obliga al atacante a resolver problemas de naturaleza distinta con herramientas distintas, y ese cambio de naturaleza es lo que encarece el ataque de verdad, mucho más que subir el número de caracteres de un secreto. Añadir una segunda señal correlacionada con la primera, en cambio, no aporta casi nada, y ese es el error de diseño que se comete al pedir dos factores que en el fondo dependen del mismo dispositivo.

El quinto axioma, el de la observación continua, es el que suele quedar sin implementar y el que sostiene a los otros cuatro. Sin telemetría no puedes saber qué políticas se aplican de verdad, cuáles no ha disparado nadie en seis meses, quién accede a qué con qué frecuencia ni cuánto tardó una revocación en surtir efecto. Una arquitectura Zero Trust sin registro no es una arquitectura menos madura: es una arquitectura de la que no se puede afirmar nada, que es la posición exacta de la que se intentaba salir.

El punto de decisión y el punto de aplicación

La arquitectura reconoce dos piezas que a menudo se confunden. El punto de decisión evalúa la política y emite un veredicto. El punto de aplicación es el que ejecuta ese veredicto sobre el flujo real, dejando pasar o cortando. La calidad de un despliegue Zero Trust no depende de lo sofisticada que sea la política, sino de una propiedad mucho más humilde del punto de aplicación: ser inevitable.

flowchart LR
U[peticion del usuario] --> B[borde de Cloudflare]
B --> P[punto de aplicacion]
P --> D[punto de decision]
D --> I[proveedor de identidad]
D --> S[postura del dispositivo]
I --> D
S --> D
D --> P
P --> W[invocacion del Worker]
P --> X[pagina de bloqueo]

Esa exigencia explica por qué las arquitecturas que colocan el control dentro de cada aplicación fracasan tan a menudo sin que nadie llegue a notarlo. No fracasan porque el control sea peor, sino porque su cobertura depende de que todas las aplicaciones lo implementen, todas correctamente y todas para siempre. Basta con un servicio nuevo, un extremo de depuración o un despliegue de urgencia para que la garantía global caiga al nivel del componente más descuidado, y ese componente nunca es el que estabas mirando.

Aquí es donde la topología de Cloudflare deja de ser un detalle de infraestructura y pasa a ser el argumento central. El proxy inverso que termina tu conexión TLS en el centro de datos más cercano al usuario ya estaba en el camino crítico por otras razones: mitigar denegación de servicio, servir caché, aplicar reglas. Colocar ahí el punto de aplicación no añade un salto de red, no añade una latencia nueva y no introduce un componente que pueda caerse por su cuenta. Es la diferencia entre poner un control en la puerta que todo el mundo cruza y construir una puerta nueva esperando que la gente la use.

De la exigencia de inevitabilidad sale el corolario más práctico de toda la lección, y el que más despliegues rompe en la vida real. Cualquier camino que alcance tu cómputo sin atravesar el punto de aplicación anula la política entera, por buena que sea. El dominio workers.dev que dejaste activo mientras probabas, la IP del origen que responde sin pasar por el proxy, un service binding desde otro Worker que entra por detrás: los tres son la misma clase de agujero, y ninguno aparece en la pantalla donde configuraste las reglas.

Conviene por tanto empezar cualquier despliegue por el inventario de caminos, y no por la política. La pregunta no es qué reglas quiero, sino por cuántas puertas se llega hoy a esto que quiero proteger.

La última fila merece atención porque introduce una asimetría que se olvida constantemente. Un manejador scheduled, un consumidor de cola o una alarma de objeto durable ejecutan tu código sin que haya ninguna petición HTTP de por medio, y por tanto sin que exista nada que un punto de aplicación pudiera inspeccionar. Toda la autorización de esos caminos vive necesariamente dentro, y conviene tenerlo presente antes de escribir en un manejador programado una operación que jamás dejarías escribir a un usuario.

npx wrangler deployments list
npx wrangler triggers deploy

Esos dos comandos, leídos con la pregunta correcta, son una auditoría: el primero te dice qué está desplegado y el segundo qué disparadores lo despiertan. Cualquier disparador que no reconozcas es un camino que no habías contado, y todo camino no contado es un camino sin política.

Qué cambia delante de tu aplicación

Cuando el punto de aplicación vive en el borde, la petición que incumple la política deja de existir antes de convertirse en trabajo. No se crea un isolate, no se consume un milisegundo de CPU, no se lee de D1, no se gasta una neurona de inferencia. La seguridad deja de ser un coste que se añade y se convierte en una propiedad que resta coste, y esa inversión de signo es la que hace sostenible aplicarla a todo y no solo a lo importante.

Esa inversión de signo tiene además un efecto sobre la resistencia a la denegación de servicio que no es evidente al principio. En una arquitectura donde la autenticación vive dentro de la aplicación, cada intento no autenticado consume recursos de la aplicación, de modo que el atacante puede agotarte sin llegar a entrar nunca. Cuando la decisión ocurre en el borde, ese consumo desaparece del lado caro y se queda en una infraestructura dimensionada para absorberlo. Es la misma idea que la lección cuatro llevará hasta el final con el WAF, aplicada aquí a la identidad.

Queda una precisión que se pasa por alto con una frecuencia alarmante, y que va a sostener las cuatro lecciones siguientes. Zero Trust delante de tu aplicación resuelve la autenticación, no la autorización. El borde te dirá con firma criptográfica que quien llama es una persona concreta de un grupo concreto desde un dispositivo que cumple; no te dirá si esa persona puede borrar la factura número catorce. La primera pregunta sale de tu aplicación y sube al borde; la segunda se queda dentro, pegada a tu modelo de datos, y sigue siendo enteramente tuya.

Y una segunda precisión, de la que trata entera la lección tres: que el borde haya verificado no autoriza a tu Worker a creer sin comprobar. La defensa en profundidad exige que el código que recibe la petición valide la aserción que le llega en lugar de limitarse a leerla, porque el día que alguien abra un camino alternativo hacia tu cómputo, la única línea de defensa que quedará en pie será la que escribiste tú.

Merece la pena anticipar también el efecto que este reparto tiene sobre tu modelo de datos, porque es el que más código ahorra. Cuando la autenticación sube al borde, tu aplicación deja de necesitar tabla de contraseñas, flujo de recuperación, verificación de correo, gestión de sesiones, expiración de cookies y todo el conjunto de trampas asociadas. Lo que queda dentro es una tabla de sujetos con sus capacidades, y esa tabla es pequeña, aburrida y fácil de razonar. La mayor parte del código de autenticación que has escrito en tu vida no era necesario: era el peaje de tener la frontera en el sitio equivocado.

Queda una advertencia de calendario. Ninguna organización pasa de perímetro a Zero Trust en un despliegue; se pasa aplicación por aplicación, y durante ese tránsito conviven los dos modelos. El riesgo del periodo intermedio no es técnico sino de razonamiento: mientras haya una sola aplicación que confíe en el rango de la oficina, la garantía global de todas las demás sigue estando acotada por la de esa. La migración no produce beneficios proporcionales al porcentaje migrado, sino que los concentra al final, cuando desaparece la última excepción. Saberlo de antemano evita el desánimo del segundo trimestre.