Tema 4
En una arquitectura distribuida los riesgos no aparecen solo en el código. También aparecen en los flujos entre servicios, en las identidades técnicas, en los pipelines, en la configuración y en los límites de confianza. El threat modeling permite anticipar estos problemas antes de que lleguen a producción.
Cuando un sistema crece, también crece la cantidad de decisiones que pueden introducir riesgo. En arquitecturas distribuidas esto ocurre con especial intensidad, porque una funcionalidad de negocio suele atravesar múltiples servicios, APIs, colas, bases de datos, secretos, identidades técnicas y componentes de infraestructura.
Esperar a que una auditoría o un incidente revele esos riesgos es una estrategia débil. El threat modeling busca adelantarse: obliga a pensar cómo funciona el sistema, qué activos son valiosos, quién podría atacarlos, por dónde podría hacerlo y qué consecuencias tendría ese ataque.
No se trata de adivinar el futuro con precisión absoluta. Se trata de tomar mejores decisiones de arquitectura y seguridad antes de construir, desplegar o exponer componentes que luego serán costosos de corregir.
El threat modeling es una práctica sistemática para identificar amenazas sobre un sistema a partir de su diseño, sus flujos y sus activos. Su propósito es detectar riesgos relevantes de forma temprana y traducirlos en decisiones concretas de mitigación.
En términos prácticos, el threat modeling responde preguntas como estas:
En un monolito muchos riesgos pueden verse dentro de una misma base de código. En una arquitectura distribuida, gran parte del riesgo aparece en los bordes entre componentes: autenticación entre servicios, contratos de API, eventos, secretos, despliegues, privilegios de runtime y confianza implícita entre partes.
Eso hace que el modelado de amenazas sea particularmente valioso, porque obliga a representar el sistema como un conjunto de relaciones y no solo como piezas aisladas. Si esos vínculos no se entienden, los controles suelen quedar incompletos o mal ubicados.
Un activo es cualquier elemento que el sistema necesita proteger porque su compromiso afecta al negocio, a los usuarios o a la operación. No todos los activos son datos; también pueden ser capacidades, identidades o procesos de entrega.
| Tipo de activo | Ejemplos | Por qué importa |
|---|---|---|
| Datos | Información personal, pagos, tokens, secretos | Su exposición o alteración puede causar fraude o incumplimiento |
| Servicios | API de pagos, autenticación, facturación | Su indisponibilidad o abuso afecta procesos críticos |
| Infraestructura | Clústeres, colas, gateways, pipelines | Su compromiso puede impactar a múltiples dominios |
| Identidades | Cuentas técnicas, certificados, roles | Permiten acceso y movimiento lateral si son abusadas |
| Procesos | Despliegue, publicación de artefactos, rotación de secretos | Un fallo en ellos puede comprometer todo el ciclo de vida |
No todas las amenazas vienen del mismo lugar. Para modelar bien hace falta pensar qué actores pueden interactuar con el sistema y con qué motivación, capacidad o nivel de acceso.
En microservicios, un actor relevante puede ser un componente interno comprometido. Eso cambia por completo la forma de pensar la confianza.
La superficie de ataque es el conjunto de puntos por los cuales un actor puede interactuar con el sistema de manera no deseada. En arquitecturas distribuidas esta superficie suele ser mucho más amplia de lo que parece a simple vista.
Un trust boundary es un punto donde cambia el nivel de confianza o el contexto de seguridad. En términos prácticos, es un borde donde el sistema debería dejar de asumir continuidad implícita y volver a autenticar, validar o restringir.
Ejemplos típicos de trust boundaries son:
Marcar estos límites ayuda a decidir dónde deben existir controles de autenticación, autorización, cifrado, validación de entrada y auditoría.
El threat modeling no se hace solo mirando componentes. También requiere observar cómo fluye la información entre ellos. Muchas vulnerabilidades nacen en esos recorridos: datos que cambian de formato, mensajes que cruzan varios servicios, credenciales que se propagan o eventos que disparan acciones sensibles.
Por eso conviene dibujar flujos simples que muestren:
Uno de los marcos más conocidos para threat modeling es STRIDE. No resuelve el análisis por sí solo, pero ayuda a ordenar el pensamiento alrededor de categorías típicas de amenaza.
| Categoría | Qué busca detectar | Ejemplo en microservicios |
|---|---|---|
| Spoofing | Suplantación de identidad | Un servicio falso se hace pasar por otro |
| Tampering | Alteración indebida | Mensajes o configuraciones modificadas |
| Repudiation | Negación de acciones | Falta de trazabilidad en operaciones sensibles |
| Information Disclosure | Exposición de información | Logs con secretos o APIs que filtran datos de más |
| Denial of Service | Interrupción o degradación | Saturación de una API o encadenamiento de timeouts |
| Elevation of Privilege | Escalada de privilegios | Un servicio obtiene acceso a recursos que no debería |
El valor del modelado aparece cuando se hacen preguntas concretas sobre el diseño. Algunas de las más útiles son:
No todas las amenazas identificadas merecen la misma atención. Un threat model útil necesita priorización. Para eso se suele considerar impacto, probabilidad, detectabilidad y costo de mitigación.
En la práctica conviene priorizar primero los riesgos que:
El resultado del threat modeling no debería ser una lista abstracta de preocupaciones. Debería convertirse en decisiones concretas de arquitectura, implementación o plataforma.
| Riesgo detectado | Mitigación posible | Tipo de control |
|---|---|---|
| Suplantación entre servicios | mTLS, identidad de workload, validación mutua | Preventivo |
| Exposición excesiva de datos | Contratos mínimos, redacción de logs, autorización contextual | Preventivo |
| Falta de trazabilidad | Auditoría, correlation IDs, logs estructurados | Detectivo |
| Abuso de cuentas técnicas | Least privilege, rotación, secretos dinámicos | Preventivo |
| Caídas por dependencia remota | Timeouts, retries controlados, circuit breakers | Resiliencia |
Lo ideal es hacerlo temprano, cuando todavía es barato cambiar el diseño. Pero también conviene repetirlo cada vez que cambia algo importante en la arquitectura.
Supongamos un flujo donde un usuario crea una orden, el servicio de órdenes llama al de pagos, luego se publica un evento y finalmente logística recibe la confirmación. Un threat model razonable debería revisar:
Modelar amenazas no elimina el riesgo, pero mejora radicalmente la calidad de las decisiones. En arquitecturas distribuidas esto es especialmente importante porque la complejidad se reparte entre componentes, contratos, identidades y flujos. Si esos elementos no se analizan antes, los controles suelen llegar tarde o quedar mal ubicados.
En el próximo tema abordaremos los principios de Zero Trust aplicados a microservicios para transformar este análisis en una postura de confianza mínima y verificación explícita.