Tema 14
La mensajería asíncrona ayuda a desacoplar servicios y absorber carga, pero también abre una superficie de ataque propia. Brokers, colas, topics, consumidores y productores introducen nuevos riesgos de exposición, duplicación, manipulación y pérdida de trazabilidad que deben tratarse explícitamente.
Cuando una arquitectura adopta colas, topics o eventos, gana desacople temporal y capacidad de absorber trabajo sin depender de respuestas inmediatas. Eso suele mejorar escalabilidad y resiliencia, pero también hace que el flujo sea menos visible y más difícil de razonar si no existen límites y controles claros.
En una arquitectura basada en mensajería no solo importan los servicios. También importan el broker, los canales, las suscripciones, las políticas de retención, los productores, los consumidores y las reglas de procesamiento. Cada uno puede convertirse en punto de exposición o de abuso.
Por eso la seguridad en este contexto no consiste únicamente en cifrar el canal. También exige controlar quién publica, quién consume, qué datos viajan, qué ocurre con duplicaciones y cómo se detecta un comportamiento anómalo.
En una llamada síncrona suele ser más fácil seguir quién invocó a quién y con qué respuesta terminó el flujo. En mensajería, los componentes se desacoplan en el tiempo y a veces también en el conocimiento directo del destino. Eso trae ventajas, pero dificulta control y observabilidad.
Un mensaje puede:
| Activo | Por qué importa | Riesgo si se compromete |
|---|---|---|
| Broker o clúster | Centraliza tráfico y entrega mensajes | Interrupción, desvío o lectura no autorizada |
| Topics y colas | Canales lógicos de comunicación | Consumo indebido o publicación maliciosa |
| Mensajes | Transportan datos y hechos del negocio | Exposición, duplicación o manipulación |
| Productores y consumidores | Generan y procesan información crítica | Abuso interno o permisos excesivos |
Ni los productores ni los consumidores deberían operar por confianza implícita. Cada identidad que publica o consume mensajes necesita autenticarse y recibir permisos específicos sobre los canales que realmente usa.
Esto implica responder preguntas como:
Un mensaje no debería transportar más información de la necesaria. Incluir datos sensibles innecesarios en eventos o colas suele ser tentador porque simplifica a corto plazo el consumo, pero amplía exposición y dificulta gobierno de datos.
Una práctica madura busca:
Además del cifrado del canal, en algunos escenarios interesa reforzar la integridad o autenticidad del mensaje mismo. Esto puede ser importante cuando los mensajes atraviesan intermediarios, quedan retenidos o son consumidos por varios actores en tiempos distintos.
La idea central es poder confiar en que:
En sistemas basados en mensajería la duplicación no es una excepción rara. Puede aparecer por reintentos, confirmaciones perdidas o reentrega del broker. Por eso los consumidores deben diseñarse suponiendo que ciertos mensajes podrían procesarse más de una vez.
La defensa principal aquí es una combinación de:
Cuando un mensaje falla repetidamente, no conviene dejarlo rebotando indefinidamente sin control. Las dead letter queues o mecanismos equivalentes ayudan a aislar mensajes problemáticos para análisis posterior.
Esto mejora resiliencia, pero también seguridad, porque permite:
Muchos brokers permiten retener mensajes y reconsumir historial. Esta capacidad es valiosa para recuperación o nuevos consumidores, pero también abre preguntas de seguridad. Un replay no controlado puede reactivar operaciones ya cerradas, exponer datos históricos sensibles o reproducir mensajes en un contexto que ya no corresponde.
Por eso conviene definir:
No todas las capacidades deberían compartir los mismos canales o el mismo nivel de visibilidad. Un diseño maduro separa dominios, productores y consumidores de manera que el compromiso o saturación de una parte no afecte innecesariamente a las demás.
Esto puede reflejarse en:
En mensajería la trazabilidad es más difícil que en un flujo request-response clásico. Por eso conviene incorporar identificadores de correlación, metadatos mínimos útiles y registros consistentes que permitan reconstruir:
Un broker también puede ser objetivo de abuso o de mal diseño. Productores sin límites, consumidores lentos, mensajes demasiado grandes o retención excesiva pueden degradarlo seriamente. Cuando el broker es compartido por muchos dominios, este problema se multiplica.
Conviene controlar:
La mensajería puede ser una gran aliada para desacoplar y escalar, pero solo cuando se diseña con controles de identidad, límites de acceso, integridad del mensaje y trazabilidad suficiente. En caso contrario, el sistema gana flexibilidad a costa de perder control y comprensión sobre sus propios flujos. La arquitectura madura busca exactamente lo contrario: más desacople sin resignar evidencia ni seguridad.
En el próximo tema estudiaremos contenedores seguros: imágenes, privilegios, namespaces y hardening para bajar al plano de ejecución donde corren estos servicios.