Software Architecture
Explica cómo integrar seguridad en límites, identidad, autorización, datos, secretos, dependencias y operación mediante threat modeling y defensa en profundidad.
La seguridad arquitectónica no consiste en añadir autenticación al final. Consiste en diseñar límites, identidades, permisos, datos y operaciones de forma que un fallo o un abuso no otorgue más acceso del necesario ni destruya la capacidad de investigar lo ocurrido.
La seguridad es un atributo transversal. Afecta:
Una arquitectura segura no supone que todos los controles funcionarán siempre. Aplica defensa en profundidad para que la falla de una capa no entregue el sistema completo.
identidad
→ autenticación
→ autorización
→ validación de contexto
→ acceso al recurso
→ auditoría
→ monitoreo y respuestaCada paso responde una pregunta distinta. Saber quién es una persona no implica que pueda consultar cualquier tenant. Validar un token no demuestra que una operación sea legítima. Registrar un evento no impide el ataque, pero puede permitir detectarlo y reconstruirlo.
Las funciones de una aplicación describen caminos permitidos. La seguridad estudia caminos no permitidos y formas de abusar de los permitidos.
En DomiSys, un usuario válido podría intentar:
También existen amenazas sin un usuario autenticado:
La arquitectura debe limitar qué tan lejos puede llegar cada amenaza.
El threat modeling comienza entendiendo el sistema, no enumerando vulnerabilidades al azar.
Aquello que necesita protección: credenciales, datos personales, inventario, dinero, configuraciones, disponibilidad, reputación y evidencia de auditoría.
Usuarios legítimos, administradores, servicios internos, proveedores, atacantes externos y actores internos abusivos. Un actor puede ser legítimo y aun así intentar una acción indebida.
Puntos donde cambia el nivel de confianza o autoridad:
Qué información cruza cada frontera, en qué dirección, con qué identidad y mediante qué contrato.
cliente móvil
↓ token + tenant solicitado
API pública
↓ identidad validada + tenant autorizado
caso de uso
↓ consulta scoped
repositorio
↓ SQL parametrizado
base de datosEl punto crítico es que el tenant autorizado no debe derivarse ciegamente del cuerpo de la solicitud. Debe asociarse con la identidad y los permisos comprobados.
No intentes modelar todo con el mismo nivel de detalle. Empieza por flujos con dinero, datos sensibles, privilegios, integraciones y efectos irreversibles.
Ejemplos:
El diagrama debe mostrar procesos, almacenes, actores, protocolos y límites de confianza. Un diagrama demasiado abstracto oculta dónde se valida identidad o dónde se persiste un secreto.
STRIDE ofrece una lista de comprobación:
STRIDE no calcula el riesgo ni reemplaza el conocimiento del dominio. Ayuda a no olvidar categorías.
Una amenaza frecuente con impacto moderado puede ser más prioritaria que un ataque extremo poco plausible. Considera también detectabilidad y alcance.
Cada control debe vincularse con una amenaza concreta. “Usar JWT” no es una mitigación completa si no se definen expiración, audiencia, firma, revocación y autorización.
Ningún control elimina todo riesgo. Deben quedar claras las limitaciones y las señales que obligarían a revisar la decisión.
La autenticación confirma una identidad. La arquitectura debe definir:
Tokens largos en local storage, sesiones eternas o refresh tokens sin rotación amplían el impacto de una filtración.
En una aplicación web, cookies HttpOnly, Secure y una política SameSite adecuada pueden reducir exposición a scripts, pero no sustituyen protección CSRF, validación de origen ni defensa contra XSS.
La autorización responde si una identidad puede realizar una acción concreta sobre un recurso concreto en un contexto concreto.
usuario autenticado
+ rol o capacidades
+ tenant autorizado
+ ownership del recurso
+ estado del recurso
+ política de negocio
= decisión de autorizaciónAsigna permisos mediante roles. Es comprensible, pero puede producir roles enormes o excepciones difíciles.
Usa atributos de actor, recurso y contexto. Es flexible, pero requiere políticas observables y pruebas rigurosas.
Representan acciones concretas, como orders.refund o inventory.adjust. Pueden combinarse con roles para evitar condicionales dispersos.
La autorización debe estar cerca de la capacidad y repetirse en el servidor. Ocultar un botón solo mejora la experiencia; no protege el recurso.
Requisitos:
Un diseño débil comprueba solo role === "admin" en el controlador.
Un diseño más robusto:
type RefundContext = {
actorId: string;
tenantId: string;
branchId: string;
permissions: Set<string>;
};
async function refundSale(
context: RefundContext,
input: RefundSaleInput,
) {
if (!context.permissions.has("sales.refund")) {
throw new ForbiddenError();
}
const sale = await salesRepository.findById({
tenantId: context.tenantId,
branchId: context.branchId,
saleId: input.saleId,
});
if (!sale) throw new SaleNotFoundError();
sale.refund({
amount: input.amount,
reason: input.reason,
approvedBy: input.approvedBy,
});
await unitOfWork.commit(sale);
}El flujo protege en varias capas:
En producción también se necesitarían idempotencia, límites, aprobación verificable y protección de datos sensibles en logs.
Valida en cada límite de confianza:
Las queries deben parametrizarse. Los templates deben escapar salida según contexto. Los comandos externos no deben construirse concatenando entrada. Los archivos necesitan validación de tipo, tamaño, nombre, contenido y destino.
Validar un DTO no garantiza seguridad de dominio. Un monto positivo todavía puede exceder la venta. Un tenantId con formato UUID todavía puede pertenecer a otro usuario.
Los secretos no deben estar en código, imágenes, logs ni variables visibles para clientes.
Un sistema de gestión de secretos debe permitir:
No inventes criptografía. Utiliza protocolos y bibliotecas maduras. El cifrado en reposo protege ciertos escenarios, pero no impide que una aplicación comprometida lea datos mediante permisos legítimos. Por eso se combina con segmentación, control de acceso, monitoreo y minimización de datos.
Para impedir acceso entre tenants pueden coexistir:
Una capa puede detener un error que atravesó otra.
Seguridad también incluye mantener el servicio utilizable.
Controles relevantes:
Limitar solo por IP puede castigar redes compartidas y permitir que un atacante distribuido evada la protección.
El sistema hereda riesgo de dependencias, builds, imágenes y pipelines.
Diseña:
Una dependencia vulnerable no siempre es explotable en el sistema, pero debe evaluarse con contexto y trazabilidad.
Una auditoría útil registra:
No debe registrar contraseñas, tokens ni secretos. Los eventos críticos necesitan protección frente a manipulación y retención acorde al riesgo.
La detección debe conectar señales con acciones: múltiples denegaciones, exportaciones masivas, elevaciones de rol, accesos desde ubicaciones anómalas o fallos de firma.
El cliente puede manipularse. Todo control crítico debe ejecutarse en una frontera confiable.
Un token válido solo demuestra identidad, no acceso al recurso solicitado.
admin termina significando todo. Divide permisos y aplica aprobación para operaciones de alto impacto.
Leer todos los tenants y luego filtrar en memoria aumenta riesgo de fuga y costo. El scope debe formar parte de la consulta.
Los logs suelen tener más lectores y retención que la base principal. Redacta y minimiza.
Un componente comprometido puede moverse lateralmente. Usa identidades de workload, mínimo privilegio y segmentación.
Una política no está verificada porque exista en un documento. Debe demostrarse en código, configuración y operación.
Multi-tenancy y diseño de SaaS profundiza en el aislamiento, la configuración, la capacidad y la evolución de múltiples clientes sobre una misma plataforma.