Flujos de datos y límites de confianza

No puedes encontrar amenazas en un sistema que no ves. El diagrama de arquitectura habitual, con logos del proveedor de nube y flechas que van “más o menos” hacia la base de datos, sirve para explicar el despliegue, pero responde mal a la pregunta que importa en seguridad: ¿qué datos se mueven, entre quién y a través de qué fronteras? El diagrama de flujo de datosDiagrama de flujo de datosDiagrama con entidades externas, procesos, almacenes y flujos de datos con dirección; es el modelo habitual sobre el que se buscan amenazas. (DFD) responde exactamente eso, y es el modelo sobre el que se aplica STRIDE.

Los elementos de un DFD#

Un DFD tiene solo cuatro tipos de elementos y un quinto concepto que los atraviesa:

Dos detalles importan más de lo que parece. Los flujos tienen dirección porque las amenazas dependen de quién envía y quién recibe. Y los almacenes no se hablan entre sí: siempre hay un proceso en medio, aunque sea un servicio gestionado (la replicación del almacén de objetos es un proceso del proveedor).

Límites de confianza#

Un límite de confianzaLímite de confianzaFrontera donde cambia el nivel de confianza o de privilegio; todo lo que la cruza debe autenticarse, autorizarse, validarse y, normalmente, cifrarse. es una frontera donde cambia el nivel de confianza o de privilegio entre lo que hay a cada lado. Cuando un dato o una orden cruza de un lado menos confiable a otro más confiable, el receptor no puede asumir nada: tiene que autenticar al emisor, autorizar la acción, validar la entrada y, normalmente, cifrar el canal.

En una arquitectura de nube típica aparecen siempre los mismos límites:

• Internet → borde: cualquier cliente llega al CDN o al balanceador. Nada de lo que envía es de fiar.
• Borde → red privada: el tráfico ya ha pasado por WAF y TLS, pero el contenido sigue viniendo del usuario.
• Aplicación → datos: la API habla con la base de datos gestionada y el almacén de objetos usando credenciales con más privilegio que el usuario final.
• Cuenta → cuenta: roles que se asumen entre cuentas (por ejemplo, prod escribiendo en un archivo de logs centralizado).
• Tu sistema → terceros: proveedores de SMS o email, APIs de pago, webhooks entrantes.
• CI/CD → producción: el pipeline que despliega tiene, por definición, poder sobre prod.
• Humanos con privilegios → consola: administradores, accesos de emergencia, sesiones de acceso remoto.

Niveles de detalle#

Los DFD se dibujan por niveles, como un mapa con zoom:

• Diagrama de contexto (nivel 0): el sistema entero como un único proceso, rodeado de sus entidades externas. Sirve para acordar el alcance.
• Nivel 1: los procesos y almacenes principales. Es el nivel donde se hace casi todo el modelado de amenazas.
• Nivel 2 o más: el detalle de un proceso concreto (por ejemplo, el flujo de autenticación con un proveedor de identidad gestionado). Solo cuando un área lo merece.

Si el diagrama no cabe en una pantalla, probablemente estás mezclando niveles.

El DFD de Citas#

Elementos del nivel 1:

Y lo más importante, los flujos que cruzan un límite, con lo que exige cada uno:

Codificar los límites#

Un límite dibujado en el diagrama tiene que existir también en la infraestructura. El límite red privada → datos, por ejemplo, se materializa en un grupo de seguridad (o lista de control de red) que solo acepta conexiones desde la API. Así se ve con Terraform sobre AWS:

resource "aws_security_group" "rds" {
  name   = "citas-rds"
  vpc_id = aws_vpc.main.id

  ingress {
    description     = "PostgreSQL solo desde la API"
    security_groups = [aws_security_group.api.id]
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
  }
}

Y el límite CI/CD → prod, en la política de confianza de la identidad federada que asume el pipeline. En el ejemplo en AWS de abajo, sin la condición sub, cualquier repositorio de GitHub podría intentar asumir el rol.

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    }
  }
}

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:clinicas/citas:ref:refs/heads/main"
    }
  }
}

El mecanismo se llama distinto en cada nube, pero el límite y lo que hay que exigir son los mismos:

Reglas prácticas#

En resumen#

• El DFD modela datos en movimiento: entidades externas, procesos, almacenes y flujos con dirección.
• Un límite de confianza marca dónde cambia la confianza o el privilegio: red, identidad, tenant, cuenta o proceso.
• Trabaja en nivel 1; baja a nivel 2 solo donde haga falta.
• Cada flujo que cruza un límite es el primer sitio donde buscar amenazas.
• Incluye administración, CI/CD, logs y copias de seguridad, no solo el tráfico de usuarios.
• Los límites del diagrama deben existir en la infraestructura: grupos de seguridad, políticas de identidad (IAM), cuentas separadas.

Referencias#

• OWASP Threat Modeling Cheat Sheet↗
• Microsoft Threat Modeling Tool: elementos del modelo↗
• NIST SP 800-154 (borrador): Guide to Data-Centric System Threat Modeling↗
• GitHub Docs: configurar OpenID Connect en AWS↗
• Adam Shostack, Threat Modeling: Designing for Security (Wiley, 2014), capítulo 2