System Design
Explica cómo incorporar clasificación, minimización, acceso, amenazas, cifrado, retención, auditoría y eliminación desde las primeras decisiones del sistema.
Seguridad desde el diseño significa comprender qué se protege, de quién, en qué límites y con qué controles. No consiste en añadir autenticación al final ni en enumerar paquetes.
Un diseño seguro parte de activos, amenazas y confianza. Cada control debe responder a un riesgo concreto y asumir que otros controles pueden fallar.
activo
→ amenaza
→ vector de ataque
→ consecuencia
→ control preventivo
→ detección
→ respuesta y recuperaciónUn sistema puede funcionar correctamente para usuarios legítimos y aun así permitir que un atacante lea datos de otro tenant, abuse de una integración o reutilice una credencial. Seguridad analiza comportamientos no deseados y fallos deliberados.
Antes de elegir controles, identifica:
Los objetivos clásicos son confidencialidad, integridad y disponibilidad, junto con autenticidad, trazabilidad y privacidad.
Un trust boundary aparece cuando cambia quién controla el código, la identidad, la red o el dato.
navegador → API pública
API → base de datos
API → proveedor de pagos
worker → broker
administrador → panel privilegiadoCada cruce requiere validar entrada, identidad, autorización y expectativas del contrato.
Confirma quién es el actor. Puede usar sesiones, tokens, certificados o identidad de workload.
Decide qué puede hacer ese actor sobre un recurso específico.
usuario autenticado
≠ puede editar cualquier pedidoLa autorización debe validarse en servidor para cada operación sensible.
Asigna permisos a roles. Es simple, pero puede crecer en combinaciones rígidas.
Usa atributos de actor, recurso y contexto. Es flexible, pero más difícil de auditar.
Comprueba que el recurso pertenezca al tenant o usuario autorizado. Es esencial contra acceso horizontal.
Un manager puede tener permiso para cancelar, pero el pedido entregado puede no ser cancelable. Autorización y validez del negocio son controles diferentes.
Actor: cashier del tenant A
Operación: consultar orderId X
Controles:
1. token válido
2. usuario activo
3. rol permite lectura
4. order.tenant_id = actor.tenant_id
5. sucursal accesible para el actor
6. campos sensibles filtrados
7. acceso auditado cuando correspondaConfiar solo en un tenantId enviado por el cliente permitiría cambiarlo manualmente.
STRIDE ayuda a preguntar:
No es una lista para marcar; se aplica a flujos y límites concretos.
Activo: pedidos de otros tenants
Amenaza: lectura horizontal
Vector: GET /orders/{id} con ID ajeno
Consecuencia: fuga de datos
Mitigación: consulta por id + tenant autorizado, pruebas de autorización, IDs no enumerables
Limitación: un bug en otra ruta aún puede filtrar datos
Defensa adicional: RLS o constraints de acceso, auditoría, alertasTLS protege comunicación, pero no corrige autorización ni endpoints mal diseñados.
Cifrado de discos o columnas reduce exposición ante ciertos escenarios. Las claves y permisos son parte del control.
Se almacenan con funciones adaptativas de hash y salt, nunca cifradas para recuperarlas.
Deben residir en un gestor apropiado, rotarse y limitarse por entorno y servicio. No deben aparecer en repositorios, logs ni imágenes.
Recopila solo lo necesario para un propósito definido.
No reutilices datos para otro propósito sin evaluación.
Define cuándo se elimina o anonimiza.
Diseña cómo una persona consulta, corrige o elimina cuando corresponda.
Conoce dónde se replica el dato: base, eventos, logs, analítica, cachés y backups.
Toda entrada externa es no confiable. Valida:
La protección contra injection depende de consultas parametrizadas y APIs seguras, no de intentar limpiar cadenas manualmente.
Rutas que validan autenticación pero no ownership.
Datos interpretados como SQL, comandos o plantillas.
El servidor realiza solicitudes a destinos controlados por el atacante. Usa allowlists, resolución segura y aislamiento de red.
Una solicitud firmada se reutiliza. Usa expiración, nonce o idempotencia según el caso.
Credenciales filtradas se prueban masivamente. Mitiga con MFA, rate limits, detección y protección de cuentas.
Tokens, documentos, tarjetas o payloads completos quedan accesibles a operadores y sistemas externos.
Ningún control es perfecto. Para una operación administrativa:
MFA
+ sesión corta
+ autorización por recurso
+ red restringida
+ auditoría
+ alertas
+ aprobación adicional para cambios críticosLa combinación reduce impacto si uno falla.
Un registro de auditoría útil incluye:
Debe ser resistente a modificación y evitar almacenar datos sensibles innecesarios.
Seguridad también protege capacidad. Rate limits, cuotas, colas, límites de concurrencia y load shedding impiden que una identidad o flujo agote recursos compartidos.
La validación debe considerar revocación o sesiones de duración adecuada.
Los permisos cacheados pueden quedar obsoletos. Define invalidación y tolerancia.
Puede reintroducir credenciales o datos que debían eliminarse. Diseña rotación y procedimientos de privacidad.
Zero trust implica autenticar y autorizar entre workloads relevantes, no confiar por estar “dentro de la red”.
Un reporte puede saltarse restricciones aplicadas en UI. La autorización debe vivir en la fuente o servicio.
admin global para todo.Más controles añaden latencia, fricción y operación. La decisión debe basarse en riesgo. El objetivo no es eliminar todo riesgo, sino reducirlo a un nivel aceptado con controles proporcionales.
tenantId del body no protege aislamiento?Rendimiento y capacidad convierte demanda, recursos y límites en estimaciones y pruebas medibles.