Tema 10
Las arquitecturas distribuidas dependen de material sensible para funcionar: contraseñas, tokens, claves privadas, certificados, credenciales de servicio y secretos temporales. Si ese material se expone o se administra sin disciplina, toda la postura de seguridad del sistema se debilita, incluso cuando el resto del diseño parece correcto.
Una aplicación distribuida suele necesitar múltiples secretos para operar: credenciales hacia bases de datos, claves para firmar tokens, certificados para TLS, tokens de acceso a APIs, secretos de terceros, material para cifrado y credenciales administrativas de plataforma. La cantidad crece a medida que el sistema gana servicios, entornos y automatización.
Ese crecimiento hace que la gestión de secretos deje de ser un detalle operativo y pase a ser un problema arquitectónico. Cuando los secretos se copian manualmente, se guardan en archivos, se comparten entre servicios o se dejan durar indefinidamente, el riesgo se acumula rápidamente.
Una estrategia madura debe cubrir todo el ciclo de vida: generación, almacenamiento, distribución, uso, rotación, revocación y auditoría.
Un secreto es cualquier dato cuya divulgación o uso indebido habilita acceso, suplantación, descifrado o control no autorizado sobre un recurso. No se limita a contraseñas.
Aunque suelen mencionarse juntos, no son exactamente lo mismo. Entender la diferencia ayuda a modelar mejor almacenamiento, rotación y responsabilidades.
| Elemento | Qué es | Riesgo principal |
|---|---|---|
| Secreto | Dato sensible que habilita acceso o uso privilegiado | Fuga o reutilización indebida |
| Clave criptográfica | Material usado para cifrar, descifrar o firmar | Compromiso de confidencialidad o integridad |
| Certificado | Documento que asocia identidad con una clave pública | Suplantación o confianza mal delegada si se gestiona mal |
Muchos incidentes graves no requieren una vulnerabilidad sofisticada. Basta con encontrar una credencial expuesta en un repositorio, una variable de entorno mal protegida o una clave que nunca se rotó.
Una práctica madura suele apoyarse en un secret manager o vault central, capaz de almacenar material sensible, controlar acceso, emitir secretos dinámicos y registrar operaciones. El objetivo no es solo guardar secretos "en otro lado", sino gestionar su ciclo de vida bajo políticas y auditoría.
Un buen gestor de secretos ayuda a:
Tan importante como dónde se guarda un secreto es cómo llega al proceso que lo necesita. Una mala inyección puede exponerlo en logs, variables heredadas, capas de imagen o artefactos temporales.
Algunas estrategias comunes son:
Cada enfoque tiene tradeoffs, pero todos deben minimizar persistencia y exposición innecesaria.
Siempre que el ecosistema lo permite, conviene preferir credenciales temporales y generadas dinámicamente en lugar de secretos estáticos de larga vida. Esto reduce la ventana de abuso y simplifica revocación frente a incidentes.
Por ejemplo:
Rotar un secreto significa reemplazarlo por uno nuevo sin perder control del sistema. En ambientes distribuidos esto debe pensarse desde el diseño, porque muchos componentes pueden depender del mismo material y no siempre se actualizan al mismo ritmo.
Una rotación segura requiere:
Las claves criptográficas merecen un tratamiento especial. No son solo credenciales de acceso; sostienen confidencialidad, firma digital y verificación de identidad. Su compromiso puede invalidar controles enteros del sistema.
Por eso conviene diferenciar:
Los certificados permiten asociar una identidad a una clave pública y son fundamentales para TLS, mTLS y autenticación de workloads. Su gestión requiere disciplina, porque el vencimiento o la mala emisión pueden interrumpir el sistema o habilitar suplantaciones.
En la práctica hay que controlar:
No conviene reutilizar los mismos secretos entre desarrollo, testing y producción. Tampoco entre dominios o servicios sin necesidad real. Compartir material sensible más allá de su contexto multiplica impacto cuando algo falla.
La gestión de secretos también debe ser observable. Si no puede saberse qué identidad accedió a un secreto, cuándo se rotó o qué certificado estuvo activo en cierto período, responder incidentes se vuelve mucho más difícil.
Conviene registrar al menos:
La seguridad de microservicios depende tanto de sus políticas como del material sensible que las hace posibles. Una buena gestión de secretos, claves y certificados reduce superficie de ataque, mejora trazabilidad y permite responder mejor ante compromisos o rotaciones inevitables. Sin esa disciplina, la arquitectura acumula deuda silenciosa hasta que aparece el incidente.
En el próximo tema estudiaremos cifrado en tránsito y en reposo en arquitecturas distribuidas para ver cómo proteger datos y comunicaciones más allá del manejo de identidades y secretos.