Tema 6
En microservicios gran parte de la seguridad depende de cómo se diseñan los contratos entre componentes. Una API insegura, una llamada gRPC mal validada o un evento demasiado expuesto pueden convertir una arquitectura técnicamente correcta en un sistema frágil y difícil de proteger.
Cuando un sistema se distribuye, los contratos entre componentes se vuelven parte central de la arquitectura. Ya no alcanza con que cada servicio funcione internamente. También debe quedar claro cómo expone su funcionalidad, qué acepta, qué devuelve, qué errores comunica y qué garantías ofrece.
Esto es especialmente importante desde el punto de vista de seguridad. Muchas vulnerabilidades no aparecen en la lógica interna, sino en la frontera de entrada: parámetros no validados, recursos sobreexpuestos, tokens mal interpretados, contratos ambiguos, errores demasiado verbosos o eventos que difunden más información de la necesaria.
En este tema trabajaremos tres estilos frecuentes de comunicación: APIs REST, gRPC y mensajería asíncrona. Cada uno tiene ventajas particulares, pero también riesgos específicos que deben modelarse y controlarse.
Un error frecuente es pensar primero en el controlador, el endpoint o el handler y recién después en el contrato que realmente se quiere exponer. En arquitecturas seguras conviene invertir esa lógica: el contrato debe diseñarse conscientemente, porque define superficie de ataque, expectativas de clientes y límites de negocio.
Un buen contrato debería responder al menos estas preguntas:
Aunque REST, gRPC y mensajería difieren en forma, comparten principios de seguridad bastante estables.
REST es uno de los estilos más difundidos para comunicación entre clientes y servicios. Su facilidad de adopción lo vuelve útil, pero también hace que con frecuencia se expongan APIs excesivamente permisivas o poco consistentes.
Algunos puntos clave en APIs REST seguras son:
| Riesgo | Cómo aparece | Mitigación típica |
|---|---|---|
| Exceso de datos | Respuestas que incluyen campos innecesarios o sensibles | Diseño de DTOs mínimos y filtrado explícito |
| Inyección o entrada maliciosa | Parámetros sin validación semántica | Validación rigurosa y saneamiento contextual |
| Autorización rota | La API autentica, pero no valida acceso al recurso concreto | Autorización por recurso, acción y contexto |
| Errores verbosos | Mensajes que exponen stack traces o detalles internos | Manejo controlado de errores y logging interno separado |
| Abuso por volumen | Falta de límites, cuotas o rate limiting | Controles de consumo y protección frente a abuso |
gRPC suele usarse para comunicación interna de baja latencia y contratos bien tipados. Su modelo basado en Protobuf aporta claridad estructural, pero no elimina riesgos de seguridad. Un contrato fuertemente tipado también puede ser demasiado amplio, demasiado permisivo o insuficientemente autenticado.
En gRPC conviene prestar especial atención a:
Como gRPC se usa frecuentemente en redes internas, a veces se cae en una falsa sensación de seguridad. Eso lleva a omitir verificaciones importantes.
La mensajería asíncrona ofrece desacoplamiento y resiliencia, pero también introduce desafíos particulares. Cuando un servicio publica un evento o envía un mensaje, no controla del todo quién lo consumirá, cuándo lo hará ni cuántas veces será reprocesado.
Por eso el diseño seguro de eventos y mensajes debe considerar:
No todo mensaje representa lo mismo. Un evento de negocio comunica algo que ya ocurrió. Un comando pide que otro componente ejecute una acción. Mezclar ambos conceptos suele generar ambigüedad operativa y también problemas de seguridad.
Cuando los mensajes no expresan bien su intención, resulta más difícil validar si quien publica está autorizado, si el contenido es coherente y si el consumidor debería actuar automáticamente o no.
La validación no es una sola capa. Existe una validación estructural y una validación de negocio. Ambas son necesarias.
| Tipo de validación | Qué controla | Ejemplo |
|---|---|---|
| Estructural | Formato, tipos, longitud, presencia de campos | UUID válido, fecha válida, tamaño máximo permitido |
| Semántica | Coherencia del contenido con reglas de negocio | No permitir cancelar una orden ya facturada |
| Contextual | Relación entre identidad, recurso y acción | Ese servicio puede actualizar solo sus propios recursos |
Validar solo formato no es suficiente. Muchos abusos llegan con payloads perfectamente válidos desde el punto de vista técnico.
En sistemas distribuidos no basta con autenticar al usuario inicial. También hay que decidir cómo se propaga, transforma o representa esa identidad a medida que la solicitud atraviesa distintos componentes.
Un contrato seguro no debería limitarse a validar que la identidad exista. Debe revisar si esa identidad puede hacer exactamente eso sobre ese recurso concreto. Este principio aplica igual para una llamada REST, una invocación gRPC o un consumidor de eventos.
Si esta verificación se omite, es común terminar con servicios autenticados pero con permisos excesivos, lo que facilita exfiltración, abuso funcional y escalada lateral.
Los contratos evolucionan. Cambiar una API, un schema Protobuf o un payload de evento sin estrategia puede romper consumidores o abrir comportamientos inseguros.
En mensajería y en algunas APIs, una misma operación puede ejecutarse más de una vez: por retries, duplicación de mensajes o reintentos del cliente. Si la operación no es idempotente cuando debería serlo, aparecen inconsistencias y oportunidades de abuso.
Diseñar idempotencia ayuda tanto a resiliencia como a seguridad, porque evita efectos colaterales no deseados ante reenvíos, repeticiones o manipulaciones de flujo.
Los errores son parte del contrato. Un sistema seguro debe comunicar al cliente o consumidor el estado necesario para operar sin revelar detalles internos sensibles.
Diseñar contratos seguros significa pensar la comunicación como una frontera crítica y no como un simple detalle de integración. Cada API, cada método gRPC y cada mensaje debería expresar una intención clara, aceptar solo lo necesario y operar con identidad, validación y autorización explícitas.
En el próximo tema estudiaremos API Gateway, rate limiting, validación y protección perimetral para ver cómo centralizar y reforzar parte de estos controles en el borde de entrada del sistema.