Análisis a fondo del inventario en tiempo real

Al principio en FireMon (bueno, antes de que nos convirtiéramos en FireMon), nos dimos cuenta de que intentar evaluar en vivo las cuentas cloud de los clientes (incluyendo suscripciones/proyectos) era... problemático. Ejecutar esa cantidad de evaluaciones alcanzaría rápidamente los límites del servicio y podría interrumpir las llamadas internas a la API de un cliente. Tenga en cuenta que comenzamos a hacer esto hace unos 7 años, antes de que existiera siquiera el CSPM, y todos estábamos aprendiendo las mismas lecciones.

La primera solución que se nos ocurrió fue recopilar los datos de configuración una sola vez, incorporarlos a nuestro propio inventario y luego realizar allí nuestras evaluaciones. Esto nos permitió reducir nuestras llamadas a la API únicamente a las necesarias para obtener los metadatos. Después, podíamos ejecutar múltiples evaluaciones basadas en el mismo conjunto de datos. Durante un tiempo, este enfoque funcionó bien. Seguíamos realizando escaneos de configuración basados en tiempo, pero podíamos distribuirlos de manera más uniforme y optimizarlos para minimizar la sobrecarga de llamadas a la API. Sin embargo, este enfoque tenía sus propios problemas. ¿Qué pasaba si algo cambiaba entre nuestro escaneo y el momento en que alguien finalmente entraba a gestionar la alerta? Además, recorrer un servicio completo de AWS en busca de todos los recursos de ese servicio seguía tensionando los límites de la API, que se basan en el servicio y la región.

Nos planteamos dos desafíos para abordar mejor esta situación. Primero, buscábamos actualizar el inventario en tiempo real para reducir los picos de llamadas a la API hacia un servicio determinado y garantizar que los clientes nunca trabajaran con datos desactualizados. Segundo, buscábamos mantener un historial para que los clientes y los investigadores pudieran revisar con exactitud qué cambió y cómo cambió. Profundizaremos en la arquitectura técnica más adelante, y esta varía ligeramente para cada plataforma cloud. En resumen, al conectarnos directamente al flujo de eventos del proveedor cloud, pudimos identificar las llamadas a la API de cambio, extraer los recursos involucrados, actualizar nuestro inventario en tiempo real y activar simultáneamente todas nuestras evaluaciones para un tipo de inventario determinado.

Si bien seguimos complementando esto con un barrido basado en tiempo una vez al día/fuera del horario laboral, la transición al tiempo real resolvió muchos problemas y produjo algunos beneficios interesantes. Estos beneficios incluyen:

• Los clientes nunca se encuentran con datos obsoletos; todo en la plataforma debería coincidir estrechamente con la configuración/el estado real en ejecución.
• Como monitoreamos las llamadas a la API, podemos identificar quién realizó esas llamadas. De pronto, contamos con una atribución de identidad completa en nuestro inventario.
• Resulta sencillo precisar qué cambió a medida que se realizan los cambios, lo que proporciona un seguimiento integral de cambios.
• Podemos ejecutar todas las verificaciones y evaluaciones en tiempo real a medida que ocurren los cambios. Esto incluye RESOLVER problemas cuando alguien los corrige externamente, no solo identificar problemas nuevos.

Listo. ¡Un inventario histórico completo en tiempo real, con seguimiento de cambios y atribución de identidad! Sí, algo como AWS Config ofrece esta funcionalidad de forma nativa dentro del proveedor cloud. Sin embargo, además de ser rentable, nuestro inventario y nuestras evaluaciones están estrechamente integrados, abarcan múltiples implementaciones y proveedores cloud, y ofrecen capacidades bastante impresionantes, como funciones de búsqueda integrales.

¡La mejor manera de experimentarlo es a través de nuestro recorrido en video de 90 segundos! Y aquí hay algunas capturas de pantalla clave:

Página principal, que muestra una gran cantidad de datos importantes en una sola vista:

Esta es la vista del historial de cambios, que presenta los cambios con todos los detalles y la atribución. También cuenta con funciones útiles como eventos relacionados, recursos asociados, exenciones y un historial de hallazgos aprobados/reprobados para el recurso:

Esta vista de historial rastrea los cambios cronológicamente con un gráfico que representa las tendencias de actividad. Al hacer clic en la línea de tiempo se salta a esa fecha:

¿Alguna vez ha necesitado saber qué recurso cloud efímero era propietario de la dirección IP que apareció en los registros en un momento específico? A los equipos de respuesta a incidentes les encanta esta función...

Y esa es la descripción general rápida. En próximas publicaciones, ofreceremos más detalles sobre la arquitectura y sobre cómo gestionamos esto en entornos multi-cloud.