Defensa en profundidad, mínimo privilegio y fallo seguro

1Por qué importa

En f01-superficie-confianza dibujaste dónde están las fronteras. La consecuencia incómoda de ese dibujo es que, tarde o temprano, alguna se va a cruzar. No porque el equipo sea malo: porque una frontera es un trozo de código o de configuración y todo el código tiene defectos. La pregunta útil deja de ser “¿se puede cruzar?” y pasa a ser “¿qué pasa el minuto después de que se cruce?”.

Esa pregunta es exactamente la que separa un incidente de una anécdota. Una inyección de comandos en un proceso que corre como root, sin restricciones y con credenciales de despliegue en el entorno, es una pérdida total. La misma inyección en un proceso sin capacidades, con el sistema de archivos en solo lectura, sin credenciales y que solo alcanza a un servicio, es un ticket. El exploit es idéntico. Lo que cambia es todo lo que había detrás.

Los tres principios de esta lección son la respuesta a ese minuto después. Defensa en profundidad asegura que quede algo detrás. Mínimo privilegio reduce lo que ese “algo” concede si también cae. Fallo seguro impide que la forma más barata de saltarse un control sea provocarle un error. Y hay un cuarto que los sostiene: secure defaults, que es lo que decide el resultado cuando nadie configuró nada, que es el estado real de la mayoría de los sistemas.

2Conceptos

3Explicación profunda

La frase “defensa en profundidad” se usa casi siempre mal. Poner dos comprobaciones del mismo tipo no es profundidad: es redundancia. La prueba que distingue una cosa de la otra cabe en una pregunta: ¿existe una causa única capaz de tumbar las dos a la vez? Si la respuesta es sí, tienes una capa contada dos veces.

Los ejemplos son incómodos porque son frecuentes. Autenticación en el proxy y autenticación en la aplicación, ambas resolviendo el token contra el mismo servicio de identidad: si ese servicio se cae o se compromete, caen las dos. Cifrado en tránsito y cifrado en reposo gestionados por el mismo sistema de claves: una clave filtrada anula ambos. Un cortafuegos de red y una lista de direcciones permitidas en la aplicación, las dos alimentadas por el mismo encabezado reenviado que ya viste que puede falsear el cliente. En los tres casos, el segundo control aporta menos de lo que su presencia sugiere, y la sugerencia es la parte peligrosa: el equipo se relaja.

Las capas que sí funcionan tienden a ser de naturaleza distinta: una de red, una de identidad, una de datos, una de ejecución. En el laboratorio, que la red interna no tenga salida y que un contenedor no tenga capacidades del kernel son controles que no comparten ni implementación ni administrador ni modo de fallo. Ahí hay profundidad de verdad.

El mínimo privilegio se enseña como un eje y son tres. El primero es la identidad: quién eres. El segundo es el alcance: sobre qué objetos, y con qué verbos. El tercero, el que casi todo el mundo olvida, es el tiempo: durante cuánto. Un permiso de administrador concedido “para el despliegue del jueves” y nunca retirado es el defecto más común de cualquier auditoría de accesos, y no se detecta mirando la lista de permisos —donde todo parece justificado— sino mirando la fecha en que se concedieron.

Aplicado a procesos, el mínimo privilegio tiene una versión muy concreta y muy medible en contenedores. Un contenedor por defecto no es una caja sellada: arranca como root dentro de su namespace, con un conjunto de capacidades del kernel que le permiten cambiar propietarios de ficheros, abrir sockets en crudo y algunas cosas más, y con el sistema de archivos escribible. Cada una de esas concesiones es un permiso que alguien te dio sin que lo pidieras. La forma correcta de decidir cuáles necesitas es empírica: quítalas todas y devuelve solo las que la aplicación reclame al romperse.

El fallo seguro es el principio que más dinero cuesta cuando se ignora, porque el camino de error es el camino menos probado de cualquier sistema. Tiene tres patrones típicos. El primero: una excepción capturada de forma amplia cuyo catch devuelve permiso concedido para “no romper la experiencia”. El segundo: un valor por defecto permisivo cuando un dato falta —el clásico rol = usuario.rol o "admin" escrito al revés por prisa—. El tercero, el más sutil: una comprobación que solo se aplica a lo que coincide con un patrón, de modo que todo lo que no coincide pasa sin revisar. Los tres tienen la misma forma: la ausencia de una respuesta se interpreta como un sí.

Aquí toca el contraejemplo honesto, porque “fallo seguro siempre” es falso. Una puerta de cámara acorazada debe quedarse cerrada si se va la luz; una puerta de emergencia debe abrirse. Cuando lo que está en juego es la vida o la continuidad de algo crítico, fallar abierto puede ser la decisión correcta. Lo que no es aceptable es que esa decisión se tome sola, por descuido, dentro de un catch. La regla es: cerrado por defecto; abierto solo donde alguien lo escribió, lo firmó y lo puso a producir una alerta.

4Ejemplo sencillo

# Un banco. Cuatro capas, y ninguna comparte modo de fallo.

capa 1   puerta con horario           control de acceso fisico
capa 2   camara y grabacion           deteccion, no prevencion
capa 3   camara acorazada con clave   control de acceso al activo
capa 4   apertura con retardo         gana tiempo aunque caigan 1, 2 y 3

# Minimo privilegio, en el mismo banco

cajero    abre su caja, no la camara            alcance
director  abre la camara, en horario de oficina alcance + tiempo
tecnico   entra acompanado, un dia concreto     identidad + tiempo

# Fallo seguro y su contraejemplo, puerta contra puerta

se va la luz  ->  camara acorazada  se queda CERRADA   fallo seguro
se va la luz  ->  puerta de incendios se ABRE          fallo abierto,
                                                       y es lo correcto

Fíjate en la capa 2. Una cámara no impide ningún robo; solo lo registra. Y sin embargo es una capa legítima, porque cambia el cálculo del atacante y porque es la única que sigue funcionando cuando las otras ya han fallado. Las capas de detección cuentan, siempre que alguien mire lo que graban.

5Ejemplo técnico

El servicio app del lab-00-base es un nginx que sirve un fichero estático montado en solo lectura. Es lo más inofensivo que hay en el laboratorio, y aun así arranca con más privilegio del que necesita. Mide primero, antes de opinar:

Tres hechos: el proceso principal es root, tiene un conjunto de capacidades del kernel que nadie pidió, y puede escribir en cualquier parte de su sistema de archivos. Ninguno de los tres hace falta para servir un HTML. Cada uno es un multiplicador del impacto de cualquier fallo futuro en esa imagen.

Ahora la otra mitad, el fallo seguro, en el fichero conf/proxy.conf. La directiva location / reenvía absolutamente todo a la aplicación. Es un default permisivo: la regla de fábrica dice “sí” y para decir “no” hay que escribir algo. La versión con secure defaults invierte la carga:

# permisivo por defecto: todo pasa, y lo que no quieras hay que ir negandolo
location / {
    proxy_pass http://app/;
}

# restrictivo por defecto: nada pasa salvo lo declarado
location / {
    return 404;                       # nota: 404, no 403
}
location = / {
    proxy_pass http://app/;
}
location ^~ /estatico/ {
    proxy_pass http://app/estatico/;
}

El detalle del 404 frente al 403 importa y es el mismo que aparecía en el registro de riesgos de la primera lección: un 403 confirma que el recurso existe. Denegar por defecto y además no confirmar la existencia son dos decisiones distintas, y las dos son gratis en el momento de escribir la configuración.

6Diagrama

flowchart TD
    AT[ataque] --> C1[1 red interna sin salida]
    C1 --> C2[2 lista de origen por encabezado]
    C2 --> C3[3 autorizacion por objeto]
    C3 --> C4[4 sin capacidades solo lectura]
    CC{{causa comun: encabezado reenviado}} --> C1
    CC --> C2

7Código

Primero el fallo abierto, en su forma más común y más inocente. Este código se escribe con buena intención, pasa la revisión y funciona perfectamente durante meses, hasta el día en que el servicio de permisos tarda de más:

# MAL: el camino de error concede el acceso
def puede_ver_factura(usuario, factura_id):
    try:
        permisos = servicio_permisos.consultar(usuario)
    except Exception:                # captura amplia: tapa hasta los fallos ajenos
        return True                  # "para no romper la experiencia"
    return factura_id in permisos.facturas

La versión con fallo seguro cambia tres cosas, y ninguna es el return:

# BIEN: deniega, distingue el porque, y hace ruido
def puede_ver_factura(usuario, factura_id):
    try:
        permisos = servicio_permisos.consultar(usuario, timeout=2)
    except TiempoAgotado:            #  1. excepcion concreta, no Exception
        metricas.incr("autz.indisponible")  #  2. un fallo silencioso no es un fallo seguro
        raise ServicioNoDisponible()  #  3. 503, no 200 con contenido vacio
    return factura_id in permisos.facturas

El punto 3 es el que más discusión genera. Devolver una lista vacía en vez de un error “deniega”, sí, pero deniega en silencio y con aspecto de respuesta correcta: el usuario ve una pantalla sin facturas y llama a soporte, y nadie relaciona eso con el servicio de permisos. Denegar sin decir que has denegado es una avería, no un control.

Y ahora el mínimo privilegio, en el único formato que aquí se puede comprobar ejecutando. Este fragmento sustituye al servicio app del laboratorio:

# docker-compose.yml — servicio app con el privilegio recortado
  app:
    image: nginx:1.27-alpine
    volumes:
      - ./app:/usr/share/nginx/html:ro
    networks:
      - lab_interna
    read_only: true              # nada persiste dentro del contenedor
    tmpfs:                        # salvo lo que nginx necesita en memoria
      - /var/cache/nginx
      - /var/run
      - /tmp
    cap_drop:
      - ALL                       # se quitan TODAS y se devuelven las que rompan
    cap_add:
      - CHOWN
      - SETUID
      - SETGID
      - NET_BIND_SERVICE          # abrir el 80, que es puerto privilegiado
    security_opt:
      - no-new-privileges:true    # ningun setuid podra escalar desde aqui
    restart: unless-stopped

Ese bloque no es una receta para copiar sin pensar: la lista de cap_add depende de la imagen. Lo que sí se puede copiar es el método: empezar por ALL en cap_drop, arrancar, leer el error, devolver una capacidad, repetir. Cinco minutos de bucle y tienes un privilegio justificado línea por línea, que es algo que casi ningún despliegue puede enseñar.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos