Diagrama de red

Qué puede hablar con qué, por qué puerto, y qué control atraviesa el tráfico cada vez que cruza una frontera de confianza.

Este diagrama no es UML, y no lo disimula: UML 2.5.1 no tiene vista de red entre sus catorce tipos, y forzar una sería inventar símbolos. Lo que la notación sí permite afirmar (qué artefacto corre en qué entorno de ejecución, por qué protocolo viajan) ya está enel diagrama de despliegue. Aquí se responde la pregunta que ese no puede: el despliegue dicedónde corre cada cosa; este dice qué puede alcanzar a qué y qué lo filtra. Son las dos vistas que se usan en momentos distintos: una al diseñar, otra al operar.

Solo aparece información que ya es pública: puertos estándar, protocolos, proveedores y controles por categoría. Nunca umbrales del rate limit, nombres de reglas de detección ni rutas trampa: un diagrama de red con ese detalle deja de documentar la defensa y pasa a ser el manual para rodearla.

Zonas de confianza

0 · No confiableInternet y los terceros. Todo lo que llega de aquí se asume hostil.
1 · PerímetroEl borde: filtra, clasifica y limita antes de que exista el request.
2 · AplicaciónSolo alcanzable desde el perímetro. Nunca tiene dirección pública propia.
3 · DatosSin ruta desde Internet. Sus credenciales solo existen en el servidor.

Notación

Banda de trazo cortado - zona de confianzaUna frontera lógica, no una máquina. El punto de color y el número dicen cuánto se le concede a lo que hay dentro.
Rectángulo con «rol» - hostAlgo que origina o termina tráfico. El rol dice qué papel juega en la red, no qué código contiene.
Flecha continua en color - cruza fronteraLleva número, protocolo y puerto, y debe justificar al menos un control en la tabla de abajo. Doble punta: el tráfico vuelve por el mismo enlace.
Flecha punteada gris - dentro de la zonaTráfico que no cambia de nivel de confianza: no cruza nada, así que no exige puerto ni control.

Red de producción (codebymike.tech)

Quién puede hablar con quién. Cuatro zonas de confianza y un único camino entre Internet y los datos: todo request atraviesa el perímetro antes de existir para la aplicación, y ningún origen externo alcanza la base de datos, ni siquiera la pasarela de pagos cuando devuelve un webhook.

src/middleware.ts · src/lib/security/* · src/db/index.ts · src/lib/demo.ts

El dato que este diagrama aporta y el de despliegue no puede: la pasarela de pagos aparece dos veces a propósito. Sale del cómputo como destino de confianza baja (flujo 15) y vuelve como origen no confiable por la puerta principal (flujo 5), sujeta al mismo perímetro que cualquier visitante. Un webhook que entrara por un camino privilegiado sería una zona de confianza regalada a un tercero.

Controles por flujo

#	Enlace	Protocolo	Controles que atraviesa
1	visitante ↔ waf	HTTPS · 443/tcp	·TLS 1.3 ·HSTS con preload ·CSP en enforce sobre la respuesta
2	operador ↔ waf	HTTPS · 443/tcp	·TLS 1.3 ·cookie de sesión HttpOnly y SameSite ·noindex y no-store en toda ruta privada
3	cron → waf	HTTPS · 443/tcp	·Bearer CRON_SECRET comparado en tiempo constante
4	github → waf	HTTPS · 443/tcp	·OAuth 2.0 ·allowlist de cuentas revalidada en cada request
5	wompi-hook → waf	HTTPS · 443/tcp	·firma del evento verificada ·idempotencia por clave del pago El webhook de la pasarela entra como cualquier otro request de Internet.
6	waf → middleware	en proceso	Lo que sobrevive al filtro llega al middleware, todavía antes de la caché.
7	middleware → cache	en proceso	Un acierto de caché se sirve aquí: la respuesta sale sin tocar el cómputo.
8	middleware ↔ app	HTTPS · 443/tcp	·request ya clasificado y limitado ·ruta canónica sin prefijo de idioma ·sesión de admin o de portal exigida por ruta
9	app → turso	libSQL sobre TLS · 443/tcp	·credencial solo de servidor ·clientId de la sesión siempre en el WHERE del portal
10	app → turso-demo	libSQL sobre TLS · 443/tcp	·pase HMAC de corta vida ·solo GET y HEAD ·base distinta de la de producción
11	app → blob	HTTPS · 443/tcp	·token de escritura solo de servidor
12	app → redis	HTTPS · 443/tcp	·token de solo lectura para el público ·TTL corto sobre todo el estado vivo
13	app → wompi	HTTPS · 443/tcp	·idempotencyKey por cobro ·máquina de estados de pago del lado propio
14	app → ntfy	HTTPS · 443/tcp	·tópico privado ·no-op silencioso si falta la credencial
15	app → resend	HTTPS · 443/tcp	·clave de API solo de servidor ·no-op silencioso si falta la credencial