Cloud Intelligence™
Detección de anomalías de costos en la nube: lecciones de incidentes reales
El equipo de DoiT analizó seis meses de incidentes de seguridad en toda nuestra base de clientes. La causa raíz rara vez fue algo novedoso: casi siempre fue una credencial que alguien olvidó proteger.
Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.
Escrito en conjunto por los equipos de Customer Success y Forward Deployed Engineering de DoiT
About Kendall Wondergem
Senior Director of Customer and Partner Success at DoiT, leading teams that deliver continuous value and exceptional customer experience through our products and services. Over 20 years of experience in management consulting, SaaS, startups, and the cloud.
My personal pageTL;DR: En los últimos seis meses, los equipos de DoiT trabajaron en un número creciente de incidentes de seguridad en toda nuestra base de clientes y en los principales proveedores de nube. La gran mayoría se remonta a una sola cosa: una credencial filtrada o sin restricciones, generalmente una API key o una clave de acceso de IAM, guardada en algún lugar donde no debía estar. Algunos incidentes se detectaron de inmediato, gracias a DoiT Cloud Intelligence™ Real-Time Anomaly Detection y a notificaciones configuradas correctamente para llegar a la persona indicada del lado del cliente en el momento indicado. Cuando esto falló, los clientes vieron picos de gasto de hasta cientos de miles de dólares antes de que alguien se diera cuenta. En este artículo desglosamos lo que vimos, cuánto costó y las acciones que tú y tu equipo deberían tomar hoy mismo para prevenir estos ataques y detectar incidentes en minutos, no en días.
Si ejecutas workloads en la nube pública, has escuchado o vivido exactamente esta pesadilla: una clave se pega en un repositorio público, se incrusta en una app móvil o queda en un pipeline de CI que nadie ha auditado en un año. Días después, alguien de finanzas pregunta por qué la factura de la nube tiene un cero de más. No es hipotético. Es, por mucho, el incidente de seguridad más común al que respondemos.
Reunimos los datos de incidentes que nuestros Forward Deployed Engineers registraron durante los últimos seis meses para ver qué patrones se repetían en una base de clientes amplia y variada. Esto no es un informe de proveedor que advierte sobre ataques teóricos. Esto es lo que está llegando a nuestra cola de trabajo, y queremos ayudarte a evitar la misma situación en tu negocio.
Patrones de incidentes de seguridad en la nube: GCP vs. AWS
Los incidentes en Google Cloud se debieron casi por completo a una sola cosa: la explosión del uso de la API de Gemini y de Vertex AI durante el último año, y lo fácil que resultó dejar una API key sin restricciones mientras se construía a toda velocidad. Publicamos en el blog la solución al abuso de API keys de Gemini aquí. Los incidentes en AWS siguieron un patrón más tradicional: claves de IAM filtradas que se convertían en abuso de cómputo, además de un puñado de tomas de control de cuentas completas. En ambas plataformas, la causa raíz casi nunca fue una vulnerabilidad de la plataforma. Casi siempre fue algo que un humano hizo, o dejó de hacer, con una credencial.
Incidentes de seguridad en GCP: las API keys filtradas son la causa n.° 1
| Causa raíz | Porcentaje |
|---|---|
| API keys filtradas o sin restricciones (Gemini, Vertex, AI Studio) | 77% |
| Clave de cuenta de servicio filtrada usada para minería de criptomonedas o flotas no autorizadas de Compute Engine | 19% |
| Secuestro de sesión o de administrador que derivó en manipulación de facturación o bloqueo de administradores | 2% |
| Exfiltración de datos a través de una cuenta de servicio comprometida | 2% |
La primera fila concentra casi todo. El 77% de los incidentes de GCP que vimos en los últimos seis meses se redujo a una API key, normalmente una clave de navegador de Firebase o una clave de Maps/Gemini incrustada en código del lado del cliente, sin restricción de referrer HTTP, sin restricción de IP y sin límites de alcance por API. Los atacantes escanean repositorios públicos y bundles de frontend expuestos buscando exactamente este patrón, y una vez que encuentran una clave que funciona, apuntan scripts automatizados a la Generative Language API y los dejan correr. Hemos visto incidentes que van desde unos pocos cientos de dólares hasta más de $200,000 en cargos no autorizados de Gemini, generados en cuestión de horas.
El segundo grupo, las claves de cuentas de servicio filtradas, se desarrolla distinto pero empieza igual: una clave de larga duración guardada en un repo de GitHub, una configuración de CI/CD o la laptop de un desarrollador. Una vez que un atacante la tiene, no acumula facturas de API: levanta cómputo. En un caso en el que trabajamos, una clave de cuenta de servicio de GitLab CI filtrada le permitió a un atacante lanzar más de 10,500 VMs de minería de criptomonedas en un solo proyecto de GCP de un día para otro. Y las solicitudes de reembolso al proveedor de nube no siempre se aprueban. Esa es la parte que vale la pena asimilar: los proveedores de nube se están volviendo más estrictos con los créditos por "gasto descontrolado", especialmente en incidentes repetidos o prevenibles. La contención y la prevención importan más que antes, porque la red de seguridad de una disputa de facturación ya no está garantizada.
Incidentes de seguridad en AWS: claves de IAM filtradas y toma de control de cuentas
| Causa raíz | Porcentaje |
|---|---|
| Clave de acceso de IAM filtrada o sin restricciones (máquinas de desarrollo, CI/CD, código) que derivó en uso no autorizado de EC2, ECS, Fargate o Bedrock | 56% |
| Toma de control de la cuenta root o de una sesión de administrador que derivó en manipulación de facturación o bloqueo de administradores | 15% |
| Workload o aplicación comprometida (servicio expuesto, política de confianza mal configurada) que derivó en movimiento lateral o exfiltración de secretos | 15% |
| Abuso de plataforma mediante cuentas de clientes comprometidas, phishing o spam enviado a través de Amazon SES | 7% |
| Ataque DDoS o de capa de red sin compromiso de credenciales | 7% |
El panorama en AWS se parece a lo que vemos en GCP: las credenciales filtradas representan más de la mitad de todo. Las claves de acceso de IAM filtradas desde máquinas de desarrolladores o pipelines de CI se convierten en flotas no autorizadas de EC2 o Fargate ejecutando mineros de criptomonedas o, cada vez más, en llamadas no autorizadas a la API de Bedrock que acumulan cargos por inferencia de modelos.
Los casos de toma de control de la cuenta root son los que más deberían preocupar a los líderes de seguridad, porque son los más difíciles de revertir. En un incidente, un atacante restableció la contraseña de la cuenta root de AWS de un cliente, registró su propio dispositivo de MFA y dejó completamente fuera a los administradores legítimos. Desde ahí, ejecutó llamadas a gran escala a la API de Bedrock que generaron más de $500,000 en cargos antes de que se recuperara la cuenta. La recuperación requirió trabajar directamente con AWS para volver a verificar la propiedad y reconstruir el acceso desde cero. Ninguna alerta de detección de anomalías llega lo suficientemente rápido si las personas que normalmente responderían no pueden entrar a la cuenta.
También vimos un grupo más pequeño, pero real, de compromisos a nivel de workload: un balanceador de carga expuesto a internet dejando un pod al descubierto, una política de confianza OIDC mal configurada y un atacante moviéndose lateralmente para exfiltrar miles de secretos de Secrets Manager. Estos casos tienen menos que ver con una sola clave filtrada y más con la deuda acumulada de una configuración de red e IAM demasiado permisiva.
Compromiso de identidad: phishing, abuso de OAuth y toma de control de cuentas
Los incidentes restantes siguieron un patrón distinto, pero relacionado: campañas de phishing que recolectaron credenciales, que luego se usaron para secuestrar cuentas y enviar spam a través de una identidad de remitente comprometida, o para pivotar hacia herramientas de terceros conectadas vía OAuth. La cuenta de Workspace comprometida de un cliente se usó para agregar vínculos de administrador no autorizados a su cuenta de Google Ads y acumular cerca de $50,000 en gasto publicitario fraudulento. En otro caso, el inicio de sesión de un empleado se usó para otorgar acceso OAuth a herramientas de terceros, lo que resultó en compras no autorizadas.
El hilo común en todas las plataformas: el punto débil no fue la infraestructura del proveedor de nube. Fue la identidad.
La factura es el humo, no el fuego
Es tentador tratar un pico de costos como el problema. Sin embargo, ese pico suele ser el primer síntoma visible de una credencial comprometida. Si arreglas la factura, atacas el síntoma. Si mejoras la higiene de credenciales y te tomas en serio la detección de anomalías, atacas la causa raíz.
Por eso nuestra recomendación tiene dos mitades que deben funcionar juntas: una revisión de postura que cierre las brechas antes de que se exploten, y un monitoreo que detecte la explotación rápidamente si de todos modos alguna brecha se escapa.
Cómo prevenir incidentes de seguridad en la nube: cerrar la brecha
La recomendación de DoiT tiene dos partes:
Paso 1: revisa tu postura de seguridad en la nube
La mayoría de los incidentes anteriores se podía prevenir con prácticas que aparecen en cualquier revisión estándar de postura de seguridad en la nube: restringir las API keys a referrers o rangos de IP específicos, rotar y retirar claves de cuentas de servicio de larga duración, pasar de credenciales estáticas a federación de identidades de workloads o tokens de corta duración siempre que sea posible, exigir MFA y límites de duración de sesión en el proveedor de identidad, y controlar quién puede crear o usar vinculaciones de IAM con nivel de propietario. Nada de esto es exótico. Es el trabajo aburrido y poco glamoroso de la higiene de accesos, y es exactamente el trabajo que sigue apareciendo como faltante en incidente tras incidente.
Paso 2: configura la detección de anomalías de costos en la nube y las notificaciones
DoiT Cloud Intelligence™ Real-Time Anomaly Detection (disponible en nuestros niveles Enhanced y Enterprise) está diseñada exactamente para la brecha que aparece en casi todos los incidentes de este conjunto de datos: el tiempo que pasa entre que algo sale mal y alguien se entera. La mayoría de las herramientas basadas en facturación detecta un pico de gasto horas o días después de que ocurrió, porque lee exportaciones que se actualizan con retraso. Real-Time Anomaly Detection lee directamente los datos de uso en tiempo de ejecución, combinados con los patrones históricos de gasto, y puede marcar actividad inusual en minutos, no en días. Cada alerta incluye una puntuación de severidad y un desglose generado por IA del servicio, SKU y recurso afectados, para que tu equipo no empiece la investigación desde cero.
Para los clientes de nuestro nivel Essentials, nuestra detección de anomalías en la nube lista para usar puede y debe configurarse igualmente, con las notificaciones adecuadas para identificar y marcar anomalías. Para actualizar a Real-Time Anomaly Detection, contacta a tu Account Manager de DoiT o envía un ticket vía Expert Inquiry en la consola de DoiT.
Para sacarle el máximo provecho a tu detección de anomalías:
- Confirma que las notificaciones de detección de anomalías estén configuradas para las personas correctas, por los canales correctos y en el momento correcto. Las notificaciones de anomalías de costos requieren el permiso de Cloud Analytics y, por defecto, llegan a Admins, Power Users, Finance Users y Standard Users, pero vale la pena verificar quién de tu equipo realmente las tiene configuradas, y que entiendan la importancia de responder rápido a las notificaciones.
- No te quedes con el umbral de severidad predeterminado. Si tu organización ejecuta workloads de alta velocidad (CI/CD, inferencia de GenAI, flotas con autoescalado), ajusta tu cadencia de revisión para que una anomalía de severidad media a las 2 a. m. se revise antes de la mañana.
- Apóyate en tu Customer Success Manager de DoiT para configurar (o validar) tu detección y notificaciones. Los CSMs de DoiT están encantados de ayudar y pueden ser los ojos expertos que necesitas para asegurarte de que todo esté bien configurado.
- Configura notificaciones para picos de gasto y uso de nuevos SKUs. La detección y notificación de anomalías por nuevo SKU está subutilizada, pero es clave: te avisa en el momento en que tu organización empieza a usar un servicio o SKU que nunca antes había usado, que es exactamente lo que ocurre cuando un atacante con una clave robada empieza a llamar a la Generative Language API o a ejecutar inferencia en Bedrock por primera vez. Un nuevo SKU legítimo aparece de vez en cuando, cuando tu equipo lanza algo nuevo. Uno inexplicable que aparece en un momento inesperado merece una revisión inmediata.
- Considera configurar notificaciones por agotamiento de cuotas o uso de créditos. Aunque está pensada para otro tipo de falla, completa el panorama de comportamientos inesperados en tu gasto.
- Evalúa el uso de automatizaciones. Configura DoiT Cloud Intelligence™ CloudFlow para que se ejecute con disparadores de anomalías de costos. Puedes automatizar tareas de mitigación de incidentes como publicar en Slack, crear tickets o ejecutar pasos de remediación. ¿No sabes por dónde empezar? Tu Customer Success Manager de DoiT puede coordinar una sesión de trabajo con un Forward Deployed Engineer de DoiT para crear tus CloudFlows.
Para más información sobre cómo configurar la detección de anomalías y las notificaciones, consulta la documentación de ayuda de DoiT sobre detección de anomalías y notificaciones, o contacta a tu Customer Success Manager de DoiT.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
Obtén ayuda experta con la detección de anomalías de costos en la nube
Si eres cliente de nuestros niveles Enhanced o Enterprise, contacta a tu Customer Success Manager o Account Manager de DoiT para agendar una revisión de postura de seguridad y/o configurar una estrategia robusta de detección y respuesta a anomalías. ¿No sabes quién es tu CSM/AM? Inicia sesión en DoiT Cloud Intelligence™, haz clic en el ícono de engranaje en la parte superior derecha y selecciona "Account Managers".
Si eres cliente de nuestro nivel Essentials, envía un ticket vía la consola (ve al menú y selecciona "Get expert advice") y un Customer Success Manager puede ayudarte a configurar o revisar tu configuración de anomalías y notificaciones, además de compartirte más detalles sobre una revisión de postura de seguridad autoguiada o dirigida por DoiT.
Checklist de respuesta a incidentes de seguridad en la nube
Si algo ocurre en tu entorno, este es el orden de operaciones que recomendamos con base en nuestra experiencia con incidentes contenidos rápidamente:
- Revoca la credencial primero. Elimina o rota de inmediato la API key o la clave de acceso de IAM comprometida. No esperes a entender por completo el radio de impacto antes de hacerlo. Cada hora que sigue activa significa más gasto y más exposición.
- Detén la hemorragia a nivel de recursos. Da de baja las VMs, instancias o flotas de cómputo maliciosas que el atacante levantó. Si el gasto sube más rápido de lo que puedes eliminar recursos con seguridad, desvincular la cuenta de facturación del proyecto afectado es un freno de emergencia legítimo.
- Preserva los logs antes de limpiar todo. Los logs de auditoría y los VPC Flow Logs son lo que tu proveedor de nube y tu propio equipo necesitarán después, tanto para el análisis de causa raíz como para cualquier disputa de facturación. Rotar todas las credenciales y borrar todos los recursos antes de que alguien haya extraído los logs dificulta mucho la investigación.
- Abre un caso con tu proveedor de nube. Para gasto no autorizado, la mayoría de los proveedores tiene un proceso para disputar cargos vinculados a un compromiso confirmado. Sé realista con las probabilidades: los proveedores se han vuelto más estrictos con estos créditos, especialmente en incidentes recurrentes o prevenibles, así que no des por hecha una solicitud de crédito.
- Involucra a DoiT. Envía un ticket vía la consola (ve al menú y selecciona "Get expert advice") o escribe a tu Customer Success Manager. Cuanto antes nos involucres, más podremos ayudarte con la guía de contención, el escalamiento con el proveedor y con asegurarnos de que la misma brecha no se vuelva a abrir.
- Cierra la brecha una vez contenido el incidente. Un incidente es un catalizador. Úsalo para agendar esa revisión de postura que llevas tiempo posponiendo.
Preguntas frecuentes
¿Qué es la detección de anomalías de costos en la nube?
La detección de anomalías de costos en la nube es un monitoreo que marca patrones inusuales de gasto o uso — un SKU nuevo, un pico inesperado, un servicio desconocido — en el momento en que ocurren, en lugar de esperar a que la factura mensual los revele. DoiT Cloud Intelligence™ Real-Time Anomaly Detection lee directamente los datos de uso en tiempo de ejecución, por lo que puede marcar actividad en minutos, en vez de las horas o días que tardan las herramientas basadas en exportaciones de facturación.
¿Qué pasa si se filtra una API key?
Una vez que una API key sin restricciones de referrer HTTP, IP o alcance queda expuesta — en un repo público, una app móvil o una configuración de CI —, los atacantes suelen encontrarla en cuestión de horas mediante escaneo automatizado y de inmediato apuntan scripts a APIs facturables como la Generative Language API o Bedrock. En los incidentes que registramos, esto fue desde unos pocos cientos de dólares hasta más de $200,000 en cargos no autorizados generados en cuestión de horas.
¿Cómo ocurre la toma de control de una cuenta en la nube?
La mayoría de las tomas de control que vemos empieza con una credencial obtenida por phishing o reutilizada, no con una vulnerabilidad de la plataforma. Un atacante restablece una contraseña, registra su propio dispositivo de MFA y deja fuera al administrador legítimo; luego usa ese acceso para acumular cargos de cómputo o de inferencia de modelos, o para manipular la facturación. Es el tipo de incidente más difícil de revertir, porque las personas que normalmente responderían no pueden entrar a la cuenta.
¿AWS o Google Cloud reembolsan los cargos no autorizados por una credencial filtrada?
No automáticamente, y no siempre. Ambos proveedores tienen un proceso de disputa para cargos vinculados a un compromiso confirmado, pero se han vuelto más estrictos al aprobar créditos, especialmente en incidentes recurrentes o prevenibles. Considera el reembolso como algo posible, no garantizado: la prevención y la contención rápida importan más que la red de seguridad de una disputa de facturación.
¿Qué es lo primero que debes hacer si sospechas de una credencial filtrada?
Rota o elimina la clave comprometida de inmediato, antes de haber dimensionado por completo el radio de impacto: cada hora que sigue activa es más exposición. Luego detén la hemorragia a nivel de recursos (da de baja el cómputo malicioso o desvincula la facturación como freno de emergencia) y preserva los logs de auditoría antes de limpiar nada, ya que los necesitarás para el análisis de causa raíz y cualquier disputa de facturación.
¿Qué tan rápido puede la detección de anomalías de costos detectar una clave comprometida?
Con detección en tiempo real ajustada para alertar sobre uso de nuevos SKUs y picos de gasto con puntuación de severidad, los equipos pueden detectar una clave comprometida a los pocos minutos de su primer uso. La detección de anomalías estándar que depende de exportaciones de facturación suele tener un retraso de horas a días, que es exactamente la ventana que convirtió incidentes pequeños de nuestros datos en incidentes de seis cifras.
