Defensa en profundidad

En 2019, un atacante sacó de la nube (en este caso, AWS) los datos de más de 100 millones de clientes de Capital One. No hubo un único fallo: un WAF mal configurado permitió una petición SSRF, esa petición alcanzó el servicio de metadatos de la instancia, las credenciales obtenidas pertenecían a un rol con permisos de lectura sobre demasiados almacenes de objetos, y la exfiltración no se detectó hasta meses después, por un aviso externo. Cada capa tenía un agujero, y los agujeros estaban alineados. La defensa en profundidadDefensa en profundidadEstrategia de apilar controles independientes y de distinto tipo para que, si uno falla, otro detenga, detecte o contenga el ataque. busca justo lo contrario: que los agujeros no se alineen.

La idea#

NIST la define como una estrategia que integra personas, tecnología y operaciones para establecer barreras variadas a lo largo de múltiples capas de la organización. La metáfora viene de la estrategia militar: en lugar de una sola muralla, varias líneas sucesivas que retrasan al enemigo y te dan tiempo para reaccionar. La NSA la llevó a la seguridad de la información a principios de los 2000, con tres ejes: personas, tecnología y operaciones.

Hay dos ideas clave:

1. Asume que cada capa va a fallar. No porque esté mal hecha, sino porque ningún control es perfecto: los WAF tienen evasiones, las reglas de red tienen excepciones y la gente hace clic en enlaces.
2. Las capas deben fallar por motivos distintos. Dos filtros que se saltan con el mismo truco cuentan como una sola capa.

Las capas de Citas#

Así se reparten los controles de la app de referencia, descritos por lo que hacen, desde Internet hasta el dato:

Cada capa recibe un nombre distinto en cada nube, pero el control es el mismo:

La identidad no es “una capa más” en línea: es transversal. En la nube, quien tenga una credencial de administrador habla directamente con la API del proveedor y se salta el WAF, los grupos de seguridad y la aplicación. Por eso la identidad necesita sus propias capas: MFA, barreras a nivel de organización que prohíben lo peligroso aunque la política lo permita, y detección sobre los registros de auditoría.

Un ejemplo en código: dos capas distintas para la misma amenaza#

Contra la inyección SQL, el WAF filtra por patrones en el borde. Pero la capa que de verdad la elimina es la aplicación:

// Si el WAF no reconoce el payload, esta línea es explotable
const r = await db.query(
  `SELECT * FROM citas WHERE paciente = '${req.query.nombre}'`,
);

// El payload viaja como dato, nunca como SQL. Y solo ve su clínica.
const r = await db.query(
  'SELECT * FROM citas WHERE paciente = $1 AND clinica_id = $2',
  [req.query.nombre, req.user.clinicaId],
);

Y si también fallara la aplicación, la capa de datos acota el daño: el usuario con el que conecta la API no puede leer otras tablas ni borrar nada.

En la red, el balanceador no debería aceptar tráfico que no venga del CDN. Si no, el WAF del borde se puede rodear yendo directamente al balanceador. El control concreto es una regla del grupo de seguridad que solo admite el puerto 443 desde los rangos del CDN (en AWS, la managed prefix list de CloudFront; en Azure, una restricción de servicio de Front Door; en Google Cloud, política que exige pasar por Cloud Armor), de modo que no haya una puerta trasera al origen.

En identidad, una barrera a nivel de organización impide que nadie apague el registro de auditoría, ni siquiera un administrador de la cuenta de producción. Así se ve la forma de la política, como ejemplo en AWS (una service control policy que niega las acciones de parada del trail):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtegerCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail",
        "cloudtrail:PutEventSelectors"
      ],
      "Resource": "*"
    }
  ]
}

Prevenir, detectar, corregir#

Las capas no solo bloquean. Un diseño equilibrado mezcla tres tipos de control:

• Preventivos: impiden que ocurra (WAF, grupos de seguridad, control de acceso por identidad, consultas parametrizadas).
• Detectivos: avisan cuando ocurre o ha ocurrido (registros de auditoría, detección de amenazas gestionada, alarmas sobre los logs del WAF).
• Correctivos: devuelven el sistema a un estado bueno (restaurar un backup, revocar credenciales, añadir una regla al WAF tras un incidente).

Si todas tus capas son preventivas, el día que el atacante las atraviese no te enterarás. La animación lo muestra: la prevención falla dos veces, la detección avisa, una capa posterior detiene el ataque y un control correctivo cierra la primera brecha.

Anti-patrones#

• Capas correlacionadas: dos WAF con reglas parecidas, o tres servicios que usan la misma credencial. Fallan juntos.
• Capas sin dueño: un control que nadie monitoriza ni prueba es una suposición, no una capa.
• Más capas siempre es mejor: cada capa añade latencia, coste, complejidad y alertas. Una capa que genera 500 alertas al día acaba ignorada, y eso es peor que no tenerla.
• La oscuridad como capa: cambiar el puerto de SSH o esconder /admin en una ruta rara puede reducir el ruido, pero no cuenta como control.

Cómo diseñarla para un flujo concreto#

Flujo: ...

| Capa           | Control | Tipo (P/D/C) | ¿Qué pasa si falla? |
| -------------- | ------- | ------------ | ------------------- |
| Edge           |         |              |                     |
| Red            |         |              |                     |
| Cómputo        |         |              |                     |
| Aplicación     |         |              |                     |
| Datos          |         |              |                     |
| Identidad      |         |              |                     |
| Monitorización |         |              |                     |

En resumen#

• Defensa en profundidad significa varias barreras independientes entre el atacante y el activo, porque cualquier capa puede fallar.
• Las capas valen si fallan por motivos distintos. Las correlacionadas cuentan como una.
• Mezcla controles preventivos, detectivos y correctivos: la detección es lo que te salva cuando la prevención falla.
• En la nube, la identidad es transversal: una credencial poderosa se salta la red, así que protégela con MFA, barreras a nivel de organización y monitorización.
• Evita la cáscara de huevo, las capas sin dueño y añadir capas que solo generan ruido.

Referencias#

• NIST CSRC Glossary: Defense-in-depth↗
• AWS Well-Architected, Security Pillar: Apply security at all layers↗
• AWS: Restrict access to Application Load Balancers using the CloudFront managed prefix list↗
• AWS Organizations: Service control policies↗
• OWASP: SQL Injection Prevention Cheat Sheet↗