Tema 21
En microservicios, los datos dejan de vivir detrás de una única aplicación y pasan a distribuirse entre múltiples dominios, bases, caches, eventos y réplicas. Esa distribución mejora autonomía, pero también obliga a pensar ownership, consistencia, privacidad y acceso de forma mucho más explícita.
Uno de los cambios más profundos al pasar a microservicios no está en la red ni en los despliegues, sino en los datos. Lo que antes podía vivir en una base central bajo una sola aplicación ahora se reparte entre múltiples servicios que evolucionan a ritmos distintos y toman decisiones sobre información parcial.
Eso trae beneficios claros: mejor alineación con dominios, despliegues más independientes y menor acoplamiento estructural. Pero también abre preguntas difíciles: quién es dueño del dato, qué servicios pueden leerlo, cómo se mantiene consistencia razonable, cómo se protege privacidad y qué pasa cuando varios componentes necesitan una visión parcial del mismo hecho.
La gestión de datos en arquitecturas seguras no consiste solo en cifrar bases. Consiste en diseñar límites, accesos y flujos de información para que el sistema pueda operar sin convertir cada servicio en una puerta lateral hacia el resto del dominio.
Uno de los principios más importantes en microservicios es que cada servicio debería ser dueño de sus datos o, al menos, de su modelo de acceso y actualización. Esto permite independencia evolutiva y reduce el acoplamiento interno.
Cuando el ownership está claro:
La segregación puede implementarse de distintas maneras: bases separadas, esquemas separados, colecciones separadas o controles de acceso fuertes sobre un mismo motor. La clave no es la forma exacta, sino que el límite del dato acompañe el límite del servicio.
| Modelo | Ventaja | Riesgo si se usa mal |
|---|---|---|
| Base separada | Aislamiento fuerte y ownership claro | Mayor complejidad operativa si se fragmenta sin criterio |
| Schema o namespace separado | Separación razonable con menor costo | Tentación de hacer accesos cruzados directos |
| Motor compartido con ACL fuerte | Pragmatismo en ciertos contextos | Contaminación de límites y permisos demasiado amplios |
Compartir una misma base de datos entre múltiples servicios suele parecer eficiente al principio, pero a menudo destruye la independencia que la arquitectura quería ganar. Cuando varios servicios leen y escriben directamente sobre las mismas tablas, el modelo de dominio se vuelve opaco y el control de acceso se complica.
Además, desde el punto de vista de seguridad:
Cuando los datos se distribuyen entre servicios distintos, la consistencia ya no puede asumirse como instantánea y global. Muchas veces hay que convivir con consistencia eventual, compensaciones o sincronizaciones asíncronas.
Esto no es un defecto en sí mismo, pero obliga a explicitar:
La consistencia también tiene implicancias de seguridad. Un dato desactualizado puede producir decisiones de autorización incorrectas, mostrar información ya revocada o mantener privilegios que deberían haberse retirado.
Por eso conviene identificar flujos donde la frescura del dato es crítica, por ejemplo:
Uno de los principios más útiles para seguridad y privacidad es la minimización: almacenar, procesar y compartir solo lo necesario. En microservicios esto es clave, porque los datos tienden a multiplicarse en caches, eventos, réplicas y vistas derivadas.
Minimizar significa preguntarse:
La privacidad no se resuelve únicamente con cifrado o políticas externas. También depende de cómo se distribuye la información entre servicios. Si datos personales o sensibles se replican innecesariamente entre dominios, la exposición crece aunque todo esté "funcionando" correctamente.
Una arquitectura más madura tiende a:
Muchas veces un servicio no necesita acceder al dato fuente completo, sino solo a una vista derivada o a un subconjunto. Diseñar proyecciones o modelos de lectura específicos puede reducir exposición sin romper la autonomía del sistema.
Esto ayuda a evitar accesos directos innecesarios a bases o dominios que deberían permanecer encapsulados.
La seguridad de los datos también depende de cuánto tiempo se conservan y en cuántos lugares quedan copiados. Un sistema distribuido tiende a dejar rastros: eventos históricos, backups, caches, colas, índices, logs y material derivado.
Por eso conviene gobernar:
No siempre alcanza con saber qué servicio existe. También hay que poder responder qué servicio accedió a qué tipo de dato, cuándo y con qué propósito operativo. Esto es especialmente importante en dominios con información personal, financiera o regulada.
Una auditoría útil debería poder reconstruir:
La gestión de datos en arquitecturas seguras exige mucho más que una base bien cifrada. Exige ownership claro, acceso mínimo, segregación coherente, consistencia entendida y gobierno sobre privacidad y retención. Cuando estas decisiones se toman bien, el sistema gana autonomía sin perder control. Cuando se toman mal, la arquitectura se llena de copias, permisos amplios y zonas grises difíciles de defender.
En el próximo tema estudiaremos patrones de resiliencia, continuidad operativa y recuperación ante fallos para cerrar el recorrido desde los datos hacia la supervivencia del sistema frente a incidentes y degradaciones severas.