Proteger la infraestructura y el acceso

El rate limiting cuenta las peticiones de cada cliente, identificado por su IP, su usuario o su clave de API, y rechaza las que superan el límite con un 429 Too Many Requests y una cabecera Retry-After que indica cuándo puede volver a intentarlo.

Hay varios algoritmos. La ventana fija cuenta por minutos de reloj y es muy simple, pero permite ráfagas dobles en el cambio de minuto. La ventana deslizante mira siempre los últimos 60 segundos y lo evita. El token bucket (cubo de fichas) da a cada cliente un cubo que se rellena a ritmo constante; cada petición gasta una ficha, así que admite ráfagas cortas sin superar la media.

Un WAF (Web Application Firewall) se coloca delante de tu aplicación y compara cada petición con un conjunto de reglas: patrones de inyección SQL, de XSS, intentos de leer archivos del sistema, herramientas de escaneo conocidas. Trabaja en la capa de aplicación, así que entiende de URLs, cabeceras y cuerpos, no solo de IPs y puertos.

El conjunto de reglas abierto más usado es el OWASP Core Rule Set (CRS), compatible con motores como ModSecurity o Coraza, y en el que se basan muchos WAF comerciales. Suma una puntuación de anomalía por cada indicio y bloquea cuando supera un umbral; su nivel de «paranoia» decide cuántas reglas aplica.

Todo WAF tiene dos modos: detección, en el que solo registra lo que habría bloqueado, y bloqueo, en el que rechaza la petición.

Si tu tráfico ya pasa por Cloudflare, como viste en el módulo de cloud, su WAF filtra las peticiones antes de que lleguen a tu servidor. Tiene tres piezas. Las reglas gestionadas: conjuntos que mantiene Cloudflare, incluida su versión del OWASP Core Rule Set, y que se actualizan cuando aparece una vulnerabilidad sonada.

Las reglas personalizadas: expresiones sobre la petición (ruta, método, país, IP, cabeceras) con una acción, como bloquear, registrar o mostrar un desafío que los navegadores reales superan y los bots no. Y las reglas de rate limiting: cuentan peticiones por IP u otras características en un periodo y actúan al superar el límite.

Un ataque DDoS (denegación de servicio distribuida) usa miles de máquinas, a menudo dispositivos infectados, para saturarte. Los volumétricos atacan las capas 3 y 4 (red y transporte): inundaciones de paquetes UDP o de inicios de conexión TCP que llenan tu conexión antes de llegar a tu aplicación. Los de capa 7 envían peticiones HTTP que parecen normales, pero en tal cantidad, o tan caras de procesar, que agotan tu servidor.

Contra los volumétricos no hay servidor que valga: hace falta una red más grande que el ataque. Los proveedores de protección, como Cloudflare, AWS Shield o Google Cloud Armor, usan anycast: anuncian la misma IP desde muchos centros de datos, así que el tráfico de cada atacante llega al más cercano y el ataque se reparte y se absorbe por todo el mundo. Los de capa 7 se frenan con rate limiting, desafíos y reglas del WAF.

En RBAC (Role-Based Access Control) defines roles como «lector», «editor» o «administrador», cada uno con una lista de permisos, y asignas uno o varios roles a cada usuario. Para saber si alguien puede borrar un artículo, miras si alguno de sus roles tiene ese permiso.

Es fácil de entender, de auditar y de explicar: «los editores pueden publicar». Por eso es el modelo de casi todos los paneles de administración, de los grupos de Microsoft Entra ID o de los roles de una base de datos.

En ABAC (Attribute-Based Access Control), la decisión sale de una política que combina atributos: del usuario (departamento, nivel), del recurso (propietario, confidencialidad), de la acción y del contexto (hora, red, dispositivo). Por ejemplo: «un médico puede ver un historial si es de su hospital y está de guardia».

Es mucho más expresivo que RBAC y evita la explosión de roles. En AWS, IAM permite políticas que comparan etiquetas del usuario y del recurso, y existen motores dedicados, como Open Policy Agent o Cedar, que evalúan políticas escritas aparte del código.

El modelo clásico es un castillo con foso: fuera todo es hostil, dentro todo es de confianza, y la VPN es el puente levadizo. El problema es que, si un atacante entra con un portátil robado o una contraseña filtrada, se mueve a sus anchas por la red interna.

Zero Trust elimina esa confianza implícita. Cada acceso a cada aplicación se verifica por separado, combinando la identidad (quién eres, con MFA), el dispositivo (si es de la empresa, si está actualizado y cifrado) y el contexto (desde dónde, a qué hora, con qué riesgo). Y cada acceso concede solo lo mínimo necesario.