Ollama facilita levantar modelos open-source con una API lista para consumir. En cloud, esa misma comodidad hace que el riesgo se dispare cuando alguien publica un endpoint “temporal” en una instancia con IP pública, sin autenticación y sin segmentación de red. Lo he visto más de una vez: el equipo solo quería una demo interna, pero el endpoint acaba indexado, usado por terceros o consumiendo GPU fuera de control.
Este post se centra en cómo securizar despliegues de Ollama en cloud cuando lo vas a operar como un servicio real: controlando quién puede invocar, desde dónde, con qué límites, y cómo evidenciarlo en auditoría. El objetivo no es “blindar por teoría”, sino eliminar los fallos que provocan shadow AI (APIs de LLMs levantadas al margen) y convertir la plataforma en algo gobernado.
Superficie de ataque real cuando Ollama se expone como API en cloud
Ollama suele ejecutarse como un servicio HTTP (por defecto en el puerto 11434) y muchas integraciones asumen conectividad directa. En cloud, el error típico es asignar una IP pública a la VM o al nodo del clúster y abrir el puerto “para probar”. Ese patrón convierte el modelo en un servicio internet-facing con una superficie de ataque similar a cualquier API pública, pero con un impacto económico y de datos mucho mayor.
Los abusos más comunes no son “hackeo sofisticado”; son uso oportunista: scrapers que detectan puertos abiertos, bots que fuerzan prompts para extraer información, y consumo automatizado para inferencia masiva (cripto-mining no, pero sí “GPU-mining” de tokens). Si el modelo tiene acceso a datos internos vía herramientas (RAG, conectores, variables de entorno, logs), el riesgo deja de ser solo coste: pasa a ser fuga de información sensible por prompt injection o por exposición indirecta.
- Shadow AI por endpoints temporales: un equipo levanta Ollama “una semana”, nadie lo registra, y queda meses accesible. Ese servicio fantasma suele carecer de rotación de credenciales, de owners claros y de trazabilidad.
- Exfiltración por prompts y respuestas: si se prueban datos reales (tickets, correos, KB interna), las respuestas pueden contener información confidencial. Sin controles, es imposible atribuir quién pidió qué.
- Denegación de servicio por consumo: una sola clave filtrada o un endpoint abierto puede saturar CPU/GPU y degradar otras cargas. En empresas, esto acaba en incidentes de disponibilidad, no en un “simple” sobrecoste.
En la práctica, cada bullet se materializa en tickets urgentes: “la demo va lenta”, “la factura de GPU se disparó”, o “seguridad pide justificar quién accedió”. La raíz suele ser la misma: se trató una API de inferencia como si fuera un servicio de laboratorio, pero se desplegó en producción (o en una VPC productiva) sin guardrails.
Arquitectura mínima segura: segmentación, gateway y servicio privado
La arquitectura que mejor aguanta auditorías y operación diaria es simple: Ollama no debe ser directamente accesible desde Internet. Se ejecuta en una red privada (subred privada o red interna del clúster), sin IP pública, y se publica mediante un API Gateway o reverse proxy gestionado con autenticación fuerte y políticas de rate limiting. El gateway es el punto de entrada controlado; Ollama es un backend privado.
La segmentación es la diferencia entre “tenemos auth” y “tenemos control”. Aunque pongas un token en cabecera, si el backend es alcanzable por rutas alternativas (peering, reglas abiertas, SG amplios, NodePorts), acabas con bypasses. En entornos corporativos, también reduce el daño cuando hay movimientos laterales: el atacante no debería poder saltar desde una VM comprometida a tu servidor de inferencia sin atravesar controles explícitos.
- Backend privado (Ollama): correr en subred privada, sin inbound desde 0.0.0.0/0. La conectividad debe venir solo desde el gateway o desde un bastión administrado para operación.
- API Gateway / reverse proxy: termina TLS, aplica autenticación/autorización, limita tasa y tamaño de payload. Es donde centralizas logs y métricas por consumidor.
- Controles de egress: si el host de Ollama puede salir libre a Internet, una mala configuración (o tooling adicional) puede filtrar datos. En empresas, se espera egress controlado (NAT con listas, firewall, o políticas de egress en K8s).
Lo importante es que cada componente tenga una responsabilidad clara: la red impide exposición accidental, el gateway controla identidad y abuso, y el backend se mantiene “sordo” hacia Internet. Esa separación te permite cambiar el modelo, escalar nodos o migrar regiones sin rehacer el perímetro.
Cómo hacerlo en la práctica con API Gateway (AWS) y un backend privado
Un enfoque operable en AWS es: API Gateway (HTTP API) como frontend, un VPC Link hacia un NLB interno, y Ollama detrás en instancias privadas o en un servicio interno. Alternativamente, ALB interno con autenticación OIDC puede servir, pero API Gateway suele dar mejores controles de cuota/ratelimit y observabilidad por API consumer.
Acciones concretas que se implementan en proyectos reales (no “nice to have”): crear el API, forzar autenticación (JWT/OIDC o IAM), limitar quién puede invocar (resource policy), y asegurar que el NLB/target group solo acepta tráfico desde el VPC Link. Si alguien intenta saltarse el gateway, no llega al backend.
- Crear autenticación OIDC/JWT en el gateway: por ejemplo con un IdP corporativo (Entra ID/Okta) para que cada llamada lleve identidad verificable. Esto evita tokens compartidos en repositorios o scripts.
- Restringir el API por Resource Policy: permitir invocación solo desde tu VPC, desde rangos corporativos o mediante un endpoint privado. Esto reduce exposición incluso si alguien descubre la URL.
- Aplicar límites (throttling/quotas) y tamaño: protege GPU/CPU y evita cargas gigantes de prompt/streaming no controlado que degradan el servicio.
Cada medida tiene un motivo operativo: OIDC permite revocar accesos por usuario/rol sin redistribuir claves; la resource policy evita que un endpoint “se vuelva público” por error; y el throttling te protege de scripts internos mal hechos (muy típico) además de abuso externo.
Ejemplo de Resource Policy (API Gateway) para restringir invocación a un VPC Endpoint (Private API):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "execute-api:/*",
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-0abc123def4567890"
}
}
},
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "execute-api:/*"
}
]
}
Validación en AWS (lo que revisaría en una revisión de seguridad): confirmar que el backend (NLB/instancia) no tiene SG con inbound desde Internet; verificar en API Gateway que el endpoint es Private (si aplica) o que la policy restringe de verdad; probar un curl desde fuera de la red permitida y confirmar 403; y revisar métricas de 4XX/5XX y throttles para detectar abuso o clientes mal integrados.
Autenticación, autorización y trazabilidad: evitar el “token compartido”
En muchos despliegues rápidos, el “control de acceso” termina siendo un token estático en una variable de entorno o, peor, ningún control porque “es interno”. En empresas, eso rompe en cuanto hay rotación de personal, equipos externos o integraciones CI/CD. Además, si el token se filtra en logs, tickets o capturas, no tienes forma de atribuir llamadas a una identidad concreta.
Para Ollama, que típicamente no trae un sistema de auth empresarial embebido, lo normal es mover ese control al gateway/proxy. Ahí puedes mapear usuarios o servicios a scopes/roles, imponer políticas por aplicación (no por persona), y registrar cada request con identificadores consistentes. La trazabilidad no es un capricho: es lo que te permite responder a “¿quién consultó el modelo con datos sensibles?” o “¿qué cliente saturó la GPU?” sin entrar en caza de brujas.
- Identidad por workload, no por humano: integraciones (apps, pipelines, bots) deben autenticarse con credenciales propias (OIDC client credentials, IAM roles, etc.). Cuando un desarrollador se va, no se rompe nada y no quedan claves huérfanas.
- Logs con correlación: incluir
request_id, identidad, ruta, latencia y tokens consumidos (si lo mides). Esto cambia la conversación con seguridad y finanzas: pasas de “nos atacan” a “este consumer excedió su cuota”. - Políticas de acceso por entorno: dev/test/prod separados de verdad. Un fallo habitual es reutilizar la misma URL/token para todo; el día que alguien prueba con datos reales en dev, ya tienes incidente.
Un anti-patrón que aparece en corporaciones es “poner VPN y ya”: sí, la VPN reduce exposición, pero no reemplaza autenticación por aplicación ni rate limiting. Además, cuando se abre acceso a terceros o a equipos distribuidos, la VPN se convierte en un bypass de gobernanza si dentro todo está plano.
Recomendaciones para entornos corporativos
Si vas a desplegar Ollama en cloud, trátalo como un servicio sensible desde el día uno: backend privado sin exposición directa, entrada única a través de un gateway con TLS, auth y límites, y segmentación que impida rutas alternativas hacia el modelo. Esto corta de raíz el patrón de “API pública temporal” que acaba en shadow AI.
La parte que más se paga en incidentes no es el modelo, sino la falta de control: tokens compartidos, ausencia de cuotas, y logs que no permiten atribución. Centralizar autenticación/autorización en el gateway y exigir identidad por workload te da revocación, auditoría y operación estable cuando el consumo crece.
Finalmente, valida lo que configuras: pruebas desde fuera de los rangos permitidos, verificación de security groups/NACL, y revisión periódica de métricas de throttling y 4XX. En entornos corporativos, “estar detrás de una VPC” no es un control suficiente si no puedes demostrar quién accede, desde dónde, y bajo qué límites.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.