concepto
etapa: design
2 min de lectura
Principios de arquitectura de seguridad
Un arquitecto de seguridad diseña los controles una vez, como patrones, para que cientos de equipos los hereden. El oficio es un pequeño conjunto de principios aplicados de forma consistente en nube, red, identidad y datos.
threat modeling (STRIDE)architecture decision records (ADR)SABSA / TOGAF (optional)reference architectures and landing zonesNIST SP 800-207 (zero trust)C4 diagrams
Principios centrales
- : cada identidad y carga de trabajo recibe solo el acceso que su tarea necesita, durante el tiempo que lo necesite.
- : varias capas independientes, para que una falla no sea una brecha.
- : nunca confiar por la ubicación en la red; autenticar y autorizar cada solicitud, usando identidad, dispositivo y contexto, y asumir que la brecha ya ocurrió.
- Seguro por defecto: el camino fácil es el camino seguro; las opciones inseguras requieren un esfuerzo explícito.
- Separación de funciones y de entornos: ninguna persona ni compromiso aislado debería poder hacerlo todo.
- Minimizar la y el : exponer menos, segmentar más y limitar lo que una falla puede alcanzar.
- Fallar cerrado y mantenerlo simple: la complejidad es enemiga de la seguridad.
De los principios a los patrones
Los principios no escalan por sí solos; los patrones sí. Una landing zone da a cada nueva cuenta de nube el mismo logging, la misma línea base de red y los mismos guardrails. Un servicio de identidad estándar da a cada aplicación autenticación y autorización. Un camino pavimentado (paved path) para los pipelines lleva las verificaciones de seguridad. El entregable del arquitecto son estos bloques reutilizables, más la guía sobre cuándo usarlos y un proceso para las excepciones.
Registrar las decisiones
Escriba las decisiones significativas con su contexto y sus trade-offs. Los registros breves de decisión de arquitectura mantienen el razonamiento fácil de encontrar cuando el equipo cambia.
# ADR-0012: La autenticación entre servicios usa identidad de workload (mTLS)
Estado: aceptado Fecha: 2026-10-02 Responsable: security-architecture
## Contexto
Los servicios se llaman entre sí dentro del clúster. Hoy el único control es una lista de permitidos de red; un pod comprometido puede llamar a cualquier cosa.
## Decisión
Cada servicio recibe una identidad de workload y TLS mutuo a través de la malla. Las políticas de autorización indican qué servicio puede llamar a qué endpoint. Por defecto se deniega.
## Consecuencias
+ El compromiso de un servicio ya no otorga acceso de red a todos.
+ Las llamadas son atribuibles en los logs.
- Los equipos deben definir sus llamadores permitidos; la malla agrega complejidad operativa.
## Alternativas consideradas
Solo políticas de red (rechazada: sin identidad, difícil de auditar); claves de API compartidas (rechazada: sin rotación, sin atribución).Trabajar con los equipos
- Revise los diseños temprano, cuando cambiar es barato; use modelado de amenazas en sistemas nuevos y cambios importantes.
- Dé a los equipos patrones de autoservicio y guardrails en lugar de colas de aprobación que los frenan.
- Explique el riesgo detrás de cada requisito; las reglas sin motivo terminan eludidas.
- Dé seguimiento a las excepciones con responsables y fechas de vencimiento, y devuelva las excepciones recurrentes al patrón.
- Mida la adopción de los patrones: una arquitectura de referencia que nadie usa no protege a nadie.
conexiones en el mapa
- Marcos y estándares de seguridadse implementa mediantePrincipios de arquitectura de seguridad
- Principios de arquitectura de seguridadvuelve automática la evidenciaCumplimiento en la práctica: controles, evidencias y auditorías
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- Zero-trust - modelo de confianzacloudsecel principio y la implementación en la nube
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…