Habr AI revela cómo un puerto abierto en una plataforma LLM expuso claves de API e infraestructura

Una historia de una auditoría de una gran plataforma RAG demuestra una conclusión incómoda para el mercado de IA: los incidentes más costosos a menudo comienzan no con un ataque "inteligente" al modelo, sino con un simple error de infraestructura. El equipo pasó dos semanas buscando vulnerabilidades complejas, pero finalmente obtuvo acceso a claves y servicios internos en solo minutos.

Cómo Encontraron el Acceso

Los auditores probaron un servicio con decenas de miles de usuarios e inicialmente siguieron el camino esperado para una pila LLM: verificaron SSRF en combinación con LangChain, intentaron inyecciones de prompts, analizaron el procesamiento HTTP y buscaron vulnerabilidades de deserialización. La lógica es comprensible: estas son exactamente las áreas que generalmente se discuten cuando se habla de seguridad de RAG, agentes y aplicaciones LLM. Pero ninguna de las largas cadenas de ataques produjo resultados.

El descubrimiento crítico apareció no en la aplicación, sino en el nivel de infraestructura mal asegurada.

"Hicimos un curl a un puerto abierto — y obtuvimos todas las claves en

5 minutos."

Esta frase captura bien el contraste principal. Mientras que la industria teme ataques exóticos en la orquestación de modelos, los sistemas reales de producción a menudo tienen interfaces abiertas donde se pueden ver configs, variables de entorno, URLs internos y tokens para APIs externas. Si tales secretos están junto a claves funcionales, comprometer un servicio rápidamente se convierte en comprometer toda la plataforma.

Por Qué Sucede Esto

Las plataformas LLM rara vez existen como un único servidor con un modelo. Típicamente, consisten en microservicios: puerta de enlace de API, orquestrador de cadenas, base de datos vectorial, almacenamiento de archivos, colas, paneles de administración internos, proveedores de embeddings, logging, monitoreo y facturación. Cada nuevo componente añade redes, secretos, roles y puntos de integración. Como resultado, un equipo puede tener una interfaz de usuario bien configurada y autorización básica, pero puertos internos mal aislados, paneles de depuración o contenedores con acceso privilegiado.

El problema se agrava por el hecho de que las startups de IA a menudo piensan en amenazas a nivel del modelo. Discuten extensamente jailbreaks, fugas de prompts de sistema, alucinaciones y protección del contexto RAG, pero posponen la higiene clásica de DevSecOps. Sin embargo, es precisamente esta higiene la que determina si un atacante puede alcanzar secretos, infraestructura en la nube o claves de API por valor de cientos de miles de dólares. Si un servicio interno escucha la red innecesariamente y los secretos están disponibles para un proceso "por si acaso", el LLM ya no es el problema principal — simplemente aumenta el costo de las consecuencias.

Dónde Ocurren los Errores con Más Frecuencia

El material es útil porque devuelve la conversación sobre seguridad de servicios de IA a preguntas fundamentales de disciplina de ingeniería. Incluso si la aplicación se construye alrededor de una cadena compleja de recuperación, agentes y múltiples modelos, un atacante casi siempre buscará el camino más barato. Y este camino a menudo pasa por errores antiguos y familiares que cualquier equipo que trabaje con infraestructura en la nube y contenedores conoce.

• Puertos internos abiertos y servicios sin ACL estricto
• Secretos en variables de entorno, logs o configuraciones accesibles a servicios vecinos
• Permisos excesivos para contenedores, runners y cuentas de servicio
• Falta de segmentación entre la capa RAG, panel de administración e infraestructura en la nube
• Enfoque en inyección de prompts ignorando la higiene de red

Para un producto, esto significa que las auditorías de seguridad no pueden reducirse a red teaming de prompts. Necesita un inventario de todos los componentes alrededor del modelo: qué servicios están expuestos externamente, qué claves están disponibles para cada contenedor, dónde están habilitadas las interfaces de depuración, cómo se restringe el tráfico entrante y saliente, quién tiene acceso a logs y snapshots del entorno. Sin esto, incluso la protección de calidad de la capa de aplicación deja la infraestructura vulnerable, y cualquier compromiso se transforma de un bug local en un incidente a gran escala con fugas de datos, pérdida de presupuesto y acceso comprometido a los proveedores.

Qué Significa Esto

La conclusión principal es simple: un producto de IA debe protegerse no como "magia LLM especial", sino como una plataforma crítica ordinaria con secretos costosos y un gran radio de impacto. Si la infraestructura básica no está asegurada, ninguna conversación sobre ataques complejos al modelo ayudará — una puerta abierta resultará ser más importante que toda tu arquitectura de IA.