Zero trust

Durante décadas, la seguridad corporativa se pareció a un castillo: murallas gruesas (firewalls, VPN) y, dentro, confianza. Si estabas en la red de la oficina o conectado a la VPN, eras «de los nuestros». Ese modelo tenía sentido cuando las aplicaciones vivían en un centro de datos propio y la gente trabajaba en la oficina. Hoy los datos están en SaaS y en varias cuentas cloud, la gente trabaja desde cualquier sitio y los atacantes entran con credenciales robadas. El castillo ya no tiene muralla, y lo que queda dentro sigue confiando en cualquiera que consiga entrar.

Qué es zero trust#

Zero trust es un modelo de seguridad que elimina la confianza implícita basada en la ubicación de red. Su lema es «nunca confíes, verifica siempre»: cada acceso a cada recurso se autentica y se autoriza en el momento, con la mejor información disponible sobre quién pide, desde qué dispositivo y en qué contexto, como si la petición viniera de una red hostil.

El término lo popularizó John Kindervag en Forrester (2010). Google lo llevó a la práctica con BeyondCorp, publicado en 2014, para que sus empleados trabajaran sin VPN. En 2020, NIST lo formalizó en la SP 800-207. Detrás hay una premisa incómoda pero realista: asume que ya te han comprometido y diseña para que eso no se propague.

Del perímetro a zero trust: verificar cada petición

Principios · Acceso

Paso 1 de 7Perímetro

Modelo perimetral (castillo y foso): una VPN o un firewall separa «fuera» de «dentro», y todo lo que está dentro se considera de confianza.

Por qué falla el perímetro#

Una sola comprobación, en la entrada. Superada la VPN, la red interna rara vez vuelve a preguntar quién eres.
El movimiento lateral es barato. Desde el primer equipo comprometido, el atacante alcanza servicios internos que «no necesitaban» autenticación porque solo eran accesibles desde dentro.
El perímetro se disolvió. SaaS, varias nubes, móviles, proveedores con acceso remoto: no hay un «dentro» que defender.
La propia puerta es un objetivo. Los appliances de VPN expuestos a Internet son uno de los vectores de acceso inicial más explotados de los últimos años.

La arquitectura según NIST SP 800-207#

NIST separa la decisión de la aplicación:

Policy Engine (PE): decide si se concede el acceso, a partir de la política y de señales externas.
Policy Administrator (PA): ejecuta la decisión. Establece o corta la sesión y entrega credenciales o tokens.
PE + PA forman el Policy Decision Point (PDP).
Policy Enforcement Point (PEP): el componente que está en el camino de la petición y la permite o la bloquea según lo que diga el PDP.

El PE se alimenta de fuentes como el proveedor de identidad, el inventario y el estado de los dispositivos, la inteligencia de amenazas, los logs de actividad y las políticas de acceso a datos. La norma resume la filosofía en siete principios, que puedes leer así:

Todo lo que guarda datos o presta servicio es un recurso que proteger, también los SaaS y los dispositivos personales.
Toda comunicación se protege igual, esté donde esté: estar en la red interna no da confianza.
El acceso se concede por recurso y por sesión, con el mínimo privilegio.
La decisión es dinámica: identidad, aplicación, estado del dispositivo, comportamiento y entorno.
Se monitoriza la postura de seguridad de todos los activos, propios o asociados.
La autenticación y la autorización son estrictas y se reevalúan continuamente, no solo al iniciar sesión.
Se recoge toda la telemetría posible para mejorar las políticas.

Las señales de cada decisión#

Señal	Qué se evalúa	En Citas
Identidad	Usuario, grupos, fuerza de la autenticación (MFA)	Proveedor de identidad gestionado para clínicas; SSO corporativo para el equipo
Dispositivo	Gestionado, cifrado, parcheado, con EDR	Señal de un proveedor de confianza de dispositivos (EDR/MDM) consultado por el PEP
Contexto	Hora, ubicación, comportamiento, nivel de riesgo	Detección de riesgo del proveedor de identidad, horarios de soporte
Recurso	Sensibilidad de lo que se pide	Notas de citas y PII: requisitos más estrictos que el calendario público

El modelo de madurez de CISA#

El Zero Trust Maturity Model de CISA (v2.0, 2023) organiza el camino en cinco pilares: identidad, dispositivos, redes, aplicaciones y cargas de trabajo, y datos. Tres capacidades los atraviesan todos: visibilidad y analítica, automatización y orquestación, y gobierno. Cada pilar avanza por cuatro etapas: tradicional, inicial, avanzado y óptimo. Lo útil del modelo es que hace explícito que zero trust es un camino gradual, no un interruptor.

Zero trust aplicado a Citas#

Las nubes públicas ya traen una pieza muy zero trust de serie: cada llamada a su plano de control se autentica y autoriza por separado, venga de donde venga (en AWS, firmada con SigV4 y evaluada contra IAM; en Azure, contra Entra ID y RBAC; en Google Cloud, contra IAM). Que una petición salga «desde dentro de la red privada» no le da ningún permiso. El reto es llevar esa misma disciplina a tus aplicaciones y a tu red. Los ejemplos de abajo son concretos —usamos AWS como nube de referencia—, pero el patrón es el mismo en cualquier proveedor.

La API de Citas no confía en nada por venir del balanceador de carga: valida el token firmado (JWT) del proveedor de identidad en cada petición. Comprueba la firma contra las claves públicas del emisor, el emisor, la caducidad, el tipo de token y el cliente. Después autoriza por recurso: un token válido de la clínica A nunca debe abrir una cita de la clínica B. Aquí el proveedor de identidad gestionado es Cognito, pero la mecánica (verificar firma + reclamaciones, luego autorizar) es idéntica con cualquier IdP que emita JWT:

import { CognitoJwtVerifier } from 'aws-jwt-verify';

const verifier = CognitoJwtVerifier.create({
  userPoolId: process.env.USER_POOL_ID!,
  tokenUse: 'access',
  clientId: process.env.APP_CLIENT_ID!,
});

export async function requireUser(req, res, next) {
  try {
    const token = (req.headers.authorization ?? '').replace(/^Bearer /, '');
    req.user = await verifier.verify(token); // firma, iss, exp, token_use, client_id
    next();
  } catch {
    res.status(401).end();
  }
}

// Autorización por recurso: autenticado no significa autorizado.
export async function requireSameClinic(req, res, next) {
  const cita = await citas.findById(req.params.id);
  const clinica = await clinicaDeUsuario(req.user.sub);
  if (!cita || cita.clinicId !== clinica) return res.status(404).end();
  next();
}

La herramienta interna citas-admin no se publica tras una VPN. Un proxy de acceso con reconocimiento de identidad actúa como PEP: evalúa cada petición con datos de identidad (del SSO corporativo u otro IdP OIDC) y de estado del dispositivo (de un proveedor de confianza como Jamf o CrowdStrike), con políticas declarativas. Además, registra cada intento. En AWS esta pieza es Verified Access, que escribe las políticas en Cedar; Azure lo cubre con Entra ID + Conditional Access y Google Cloud con Identity-Aware Proxy + Access Context Manager:

permit(principal, action, resource)
when {
  context.idc.groups has "<id-del-grupo-soporte-citas>"
  && context.idc.user.email.verified == true
  && context.jamf.risk == "LOW"
};

idc y jamf son los nombres de referencia que asignas a cada proveedor de confianza. Para administrar la propia nube (consola y CLI), el equipo entra por SSO con identidades federadas (en AWS, IAM Identity Center) con MFA resistente a phishing y sesiones cortas, nunca con usuarios y claves de acceso permanentes.

Dentro de la red privada, la confianza tampoco se regala por IP. La base de datos gestionada solo acepta conexiones del grupo de seguridad de la API, no de todo el rango de la red. Si se pide más, se añade autenticación entre servicios: una malla de servicios con identidad (en AWS, políticas de VPC Lattice con llamadas firmadas y evaluadas contra IAM), mTLS, o autenticación por identidad en la base de datos con tokens de corta duración en lugar de contraseñas estáticas. El ejemplo de abajo está en Terraform para AWS, pero la idea —referenciar una identidad, no un rango de red— es universal:

Confía en todo el rango de red

Confía en una identidad concreta

resource "aws_vpc_security_group_ingress_rule" "rds" {
  security_group_id = aws_security_group.rds.id
  cidr_ipv4         = "10.0.0.0/16"
  ip_protocol       = "tcp"
  from_port         = 5432
  to_port           = 5432
}

resource "aws_vpc_security_group_ingress_rule" "rds" {
  security_group_id            = aws_security_group.rds.id
  referenced_security_group_id = aws_security_group.api.id
  ip_protocol                  = "tcp"
  from_port                    = 5432
  to_port                      = 5432
}

Trampas habituales#

Cómo empezar sin morir en el intento#

Inventario

Identidades (personas y máquinas), dispositivos, aplicaciones, datos y los flujos entre ellos. No puedes verificar lo que no conoces.
Identidad fuerte primero

SSO y MFA resistente a phishing para todo el equipo; credenciales temporales para servicios y CI/CD. Combina zero trust con mínimo privilegio.
Un recurso crítico, un PEP

Elige una aplicación sensible (en Citas, citas-admin), ponle delante un punto de aplicación con política de identidad y dispositivo, y retira el acceso por VPN.
Microsegmentación

Reglas de grupo de seguridad que referencian otros grupos (una identidad, no un rango de IP) y autenticación entre servicios para los flujos que cruzan un límite de confianza.
Telemetría y mejora continua

Registra cada decisión (los logs del proxy de acceso y los registros de auditoría de la nube) y úsala para ajustar las políticas y detectar abusos.

Tu turno

Explica zero trust con un ejemplo de tu trabajo actual

Busca en tu entorno un acceso que hoy se conceda por estar «dentro»: una VPN, una regla que permite todo el rango de la red privada, un servicio interno sin autenticación, una base de datos accesible desde cualquier equipo de la oficina.

¿Qué se comprueba hoy, y cuándo? ¿Solo al conectarse o en cada petición?
¿Qué pasaría si un portátil de esa red se viera comprometido? ¿Hasta dónde podría llegar el atacante?
¿Qué señales deberían evaluarse: identidad, MFA, dispositivo, contexto, sensibilidad del recurso?
¿Dónde pondrías el PEP y qué sería lo primero que cambiarías?

Campo	Tu respuesta
Acceso analizado
Hoy se confía en…
Si un equipo interno cae…
Señales a verificar
Dónde se aplica (PEP)
Primer paso

Reto

El grupo de seguridad de la base de datos de Citas permite el puerto 5432 desde 10.0.0.0/16. ¿Por qué choca con zero trust y cómo lo corriges?

▸Mostrar solución

Porque concede acceso por ubicación de red: cualquier carga comprometida dentro de la red privada (un worker, una instancia de pruebas olvidada) puede intentar conectar con la base de datos. Lo correcto es permitir solo el grupo de seguridad de la API, la identidad concreta que lo necesita. Si quieres ir más allá, añade autenticación por identidad en la base de datos o credenciales por servicio en un gestor de secretos.