Lat construye aplicaciones vulnerables a propósito y enseña a atacarlas: identidades con permisos de más, funciones expuestas sin control, depósitos de archivos abiertos, credenciales que se filtran, escalada de privilegios. Después muestra la corrección. Cubre las tres nubes grandes, que es su virtud comercial y su límite técnico.
Qué saqué de él
La regla que me quedó cabe en una línea: los permisos de un componente son el tamaño del daño que puede causar. No importa cuán bien escrito esté el código; si la identidad con la que corre puede leer todos los depósitos de la cuenta, un solo fallo alcanza para todo. Desde que lo leí, cuando reviso un despliegue, lo primero que miro no es el código sino qué puede hacer la identidad que lo ejecuta, y lo segundo es si alguien lo comprobó alguna vez.
La segunda cosa es más concreta y más frecuente de lo que parece: los depósitos de archivos con documentos de la empresa. Cualquier proyecto que ponga IA sobre documentos propios termina guardando contratos, facturas y correos en un depósito de nube, y ese depósito es exactamente el objeto que el libro enseña a explotar en un capítulo entero. Es la pieza menos vistosa del proyecto y la que más veces está mal.
La tercera: los registros de auditoría solo sirven si alguien los mira. El libro dedica páginas a rastrear un ataque en los registros, y la conclusión inversa es la útil: si nadie tiene la tarea de mirarlos, están ahí para la autopsia, no para la defensa.
Qué dejé fuera
Los laboratorios en sí, que son largos y cuestan dinero real en una cuenta de nube. Y hay que decirlo: cubrir tres proveedores hace que cada uno reciba un tercio de la profundidad, y las pantallas de las consolas cambian más rápido de lo que se imprime un libro. La parte que no caduca es el razonamiento sobre identidades y radios de daño.