ATALAIALos diagramas de arquitectura suelen dibujarse para explicar cómo funciona un sistema. Es útil, pero no es la pregunta que hace una revisión de seguridad. Una revisión pregunta dónde cambia la confianza: dónde una petición de alguien a quien no controlas llega a algo que te importa.
La buena noticia es que puedes responder esa pregunta en una sola página. El diagrama no tiene que ser bonito ni completo. Tiene que mostrar los límites y cada flecha que los cruza.
Qué cuenta como frontera de confianza
Una frontera de confianza es cualquier punto donde los datos o el control pasan entre dos partes que tienen privilegios distintos o que controlan personas distintas. Algunas son obvias, como el borde de internet. Muchas no lo son:
- Entre el navegador y tu API, porque el navegador pertenece al usuario.
- Entre tenants dentro de la misma base de datos, porque un cliente no debe leer a otro.
- Entre tu servicio y un webhook de terceros, porque quien envía es otra persona.
- Entre el runner de CI y producción, porque el runner ejecuta código de las pull requests.
- Entre una herramienta de soporte y los datos de clientes, porque el acceso del personal es un privilegio en sí mismo.
- Entre un agente de IA y las herramientas que puede llamar, porque el prompt puede venir de contenido no confiable.
Si solo dibujas el primero, la revisión solo encontrará problemas en el primero.
Cinco tipos de caja
Mantén la notación pequeña. Usamos cinco formas, que se corresponden aproximadamente con los elementos de un diagrama de flujo de datos clásico:
| Forma | Medios | Ejemplo |
|---|---|---|
| Persona | Un actor humano | Cliente, admin, agente de soporte |
| Caja | Algo que gestionas tú | API, worker, panel de administración |
| Cilindro | Algo que guarda datos | Base de datos, bucket, cola |
| Cloud | Algo que no gestionas tú | Proveedor de pagos, proveedor de identidad, API SaaS |
| Línea discontinua | Una frontera de confianza | Borde de internet, límite de tenant, de CI a prod |
Las flechas muestran el flujo de datos y apuntan en la dirección en que viaja la petición. Etiqueta cada flecha con el protocolo y lo que transporta: HTTPS, JSON, invoice ids. Esa etiqueta es lo que convierte el dibujo en algo que se puede revisar.
Anatomía de una frontera pasada por alto
La mayoría de los hallazgos de revisión siguen la misma forma. Existe una frontera, nadie la dibujó, así que nadie hizo las preguntas que la acompañan. Un ejemplo habitual es un panel de admin interno que se dio por seguro porque está «dentro»:
- SuposiciónEl panel de administración es interno, así que se salta las comprobaciones de autorización por objeto.
- ExposiciónEs accesible desde la red corporativa o una VPN que comparten muchas personas y dispositivos.
- Punto de apoyoSe compromete un portátil de un empleado o una credencial compartida.
- ImpactoEl atacante lee o edita cualquier registro de cliente a través de una herramienta que confiaba en su ubicación de red.
Dibujar una línea discontinua entre "staff" y "panel de admin" obliga a plantear la pregunta que el diseño se saltó: ¿cómo sabe este servicio quién llama y qué puede tocar?
Las preguntas para cada flecha que cruza
Una vez dibujadas las fronteras, ve flecha por flecha. Para cada flecha que cruza una línea discontinua, escribe respuestas cortas a estas preguntas. STRIDE es una buena lista de apoyo aquí:
- Spoofing. ¿Cómo se autentica quien llama? ¿Token, mTLS, firma, nada?
- Tampering. ¿Se valida la entrada en el lado receptor, y no solo en el emisor?
- Repudio. ¿Se registra la llamada con quién la hizo?
- Divulgación de información. ¿Contiene la respuesta más de lo que debería ver quien llama?
- Denegación de servicio. ¿Hay un límite de frecuencia, tamaño o coste?
- Elevación de privilegios. ¿Puede quien llama alcanzar acciones por encima de su rol?
Las respuestas en blanco son tu lista de hallazgos. En la práctica, las celdas vacías se concentran en dos o tres flechas, y ahí es donde debe ir el tiempo de revisión.
Mantener la página al día
Un diagrama dibujado una vez para una revisión se queda obsoleto en un trimestre. Dos hábitos lo mantienen honesto:
- Guárdalo como código. Un formato de texto como Mermaid o PlantUML en el repositorio hace que los cambios aparezcan en las pull requests junto al código que los provocó.
- Átalo al cambio. Una nueva integración externa, un nuevo almacén de datos o un nuevo rol son motivo para actualizar la página. Ponlo en la plantilla de pull request.
Un pequeño esquema en Mermaid basta para empezar:
flowchart LR
user([Customer]) -->|HTTPS, JSON| api[API]
subgraph tenant [Tenant boundary]
api -->|SQL, row-level filter| db[(Postgres)]
end
psp((Payment provider)) -->|Signed webhook| api
ci[CI runner] -.->|Deploy token| apiCompruébalo en 10 minutos
- Abre tu diagrama de arquitectura actual. Cuenta las líneas discontinuas. Si no hay ninguna, empieza por ahí.
- Añade una frontera para las herramientas internas, para CI hacia producción y para cada callback de terceros.
- Elige las tres flechas que cruzan el límite más sensible y responde a las seis preguntas.
- Cualquier respuesta en blanco se convierte en un ticket, o en un tema para una sesión de revisión de arquitectura.
Dónde encaja en la línea
En la torre (en desarrollo):