Software Architect · Módulo 16
Security no es el último gate antes del release. Es un conjunto de decisiones arquitectónicas sobre confianza, permisos y límites.
Threat modeling · least privilege · authn · authz · audit
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.
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.
- ¿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?