# 16. Seguridad Cómo incorporar security a la arquitectura: threat modeling, least privilege, authn/authz, secrets, audit y secure defaults. - **Author:** Fedor Chishchin - **Level:** advanced - **Reading time:** ~25 minutos de lectura - **Published:** 2026-05-23 - **Source:** https://fedorthinks.com/es/learn/software-architect-16-security --- ## 1. La idea central La seguridad empieza con una pregunta: ¿en quién confiamos, por qué y qué pasa si esa confianza se rompe? ### Authn y authz son cosas distintas > El pasaporte demuestra quién sos. La entrada demuestra que tenés permiso de pasar a la sala. No son el mismo documento. Authentication responde "¿quién es?". Authorization responde "¿qué puede hacer?". El error frecuente es verificar correctamente la identity y olvidarse de chequear el acceso al recurso concreto. El arquitecto tiene que definir el modelo de permisos: RBAC, ABAC, ownership-based access, tenant isolation, service-to-service permissions. Lo más importante: la authorization vive al nivel de la acción de negocio — no sólo del endpoint. ### Least privilege achica el blast radius > La llave del departamento no debería abrir todo el barrio. Si te la roban, el daño tiene que estar acotado. Cada usuario, servicio, token y job debería tener los permisos mínimos que necesita. Los secrets no viven en el código. El acceso a producción está restringido, logueado y revisado periódicamente. Una security architecture no se mide sólo por la probabilidad de un ataque — se mide por el blast radius: qué puede hacer realmente un atacante una vez que comprometió un componente. ## 2. Ejemplo y antiejemplo Un buen modelo de seguridad hace que el camino seguro sea el más fácil para el desarrollador. ### Ejemplo: tenant isolation en el repository > En un edificio de oficinas, cada inquilino tiene su propia puerta con llave — no un cartel que dice "por favor, no entren". Todos los accesos a datos pasan por un repository que exige `tenantId` desde un trusted context. Los query builders inyectan el tenant predicate automáticamente y los integration tests verifican que la lectura cross-tenant es imposible. Es mejor que pedirle a cada desarrollador que se acuerde del filtro a mano. ### Antiejemplo: un admin flag en el JWT, sin chequeo de recurso > Una credencial de "personal" no te habilita a abrir la caja fuerte, la contaduría y el data center. La API chequea `isAdmin=true` y ahí termina — sin verificar workspace, role scope ni ownership del recurso. Un token concentra demasiado poder. Si se filtra, el daño es máximo. La authorization tiene que ser contextual: sujeto, acción, recurso, tenant, condiciones. #### Autoevaluación - ¿Dónde están los trust boundaries del sistema? - ¿Qué pasa si se filtra un service token? - ¿Dónde se chequea la authorization a nivel de recurso? - ¿Qué acciones terminan en el audit log? Próximo módulo: [Observabilidad](./software-architect-17-observability).