Approfondimento sull'inventario in tempo reale

Agli inizi di FireMon (in realtà, prima ancora che diventassimo FireMon), ci siamo resi conto che tentare di valutare in tempo reale gli account cloud dei clienti (incluse sottoscrizioni/progetti) era... problematico. Eseguire un numero così elevato di valutazioni avrebbe rapidamente raggiunto i limiti dei servizi e avrebbe potuto interferire con le chiamate API interne di un cliente. Si tenga presente che abbiamo iniziato a farlo circa 7 anni fa, prima ancora che esistesse il CSPM, e che tutti stavano imparando le stesse lezioni.

La prima soluzione che abbiamo individuato è stata raccogliere i dati di configurazione una sola volta, inserirli nel nostro inventario ed eseguire lì le nostre valutazioni. Questo ci ha permesso di ridurre le chiamate API al minimo necessario per recuperare i metadati. Potevamo quindi eseguire più valutazioni sullo stesso insieme di dati. Per un certo periodo questo approccio ha funzionato bene. Continuavamo a effettuare scansioni di configurazione a intervalli di tempo, ma potevamo distribuirle in modo più uniforme e ottimizzarle per ridurre al minimo il sovraccarico di chiamate API. Tuttavia, anche questo approccio presentava una serie di problemi. Cosa succedeva se qualcosa cambiava tra la nostra scansione e il momento in cui qualcuno interveniva finalmente per gestire l'avviso? Inoltre, una scansione completa di un servizio AWS per tutte le risorse di quel servizio avrebbe comunque messo sotto pressione i limiti delle API, che dipendono dal servizio e dalla regione.

Ci siamo posti due sfide per affrontare meglio questa situazione. In primo luogo, puntavamo ad aggiornare l'inventario in tempo reale per ridurre i picchi di chiamate API verso un determinato servizio e garantire che i clienti non lavorassero mai con dati obsoleti. In secondo luogo, puntavamo a conservare uno storico, in modo che clienti e investigatori potessero risalire a ciò che era cambiato e al modo in cui era cambiato. Approfondiremo l'architettura tecnica più avanti; essa varia leggermente per ciascuna piattaforma cloud. In breve, collegandoci direttamente al flusso di eventi del provider cloud, potevamo identificare le chiamate API di modifica, estrarre le risorse coinvolte, aggiornare il nostro inventario in tempo reale e attivare simultaneamente tutte le nostre valutazioni per un determinato tipo di inventario.

Pur continuando a supportare questa modalità con una scansione temporizzata una volta al giorno / fuori orario, il passaggio al tempo reale ha risolto molti problemi e ha prodotto alcuni vantaggi interessanti. Tra questi:

• I clienti non si imbattono mai in dati obsoleti; tutto ciò che si trova nella piattaforma dovrebbe corrispondere fedelmente alla configurazione/allo stato effettivamente in esecuzione.
• Monitorando le chiamate API, possiamo identificare chi le ha effettuate. Di colpo, disponiamo di una completa attribuzione delle identità nel nostro inventario.
• Diventa semplice individuare con precisione ciò che cambia nel momento in cui le modifiche vengono apportate, con un tracciamento completo delle modifiche.
• Possiamo eseguire tutti i controlli e le valutazioni in tempo reale man mano che si verificano le modifiche. Questo include la RISOLUZIONE dei problemi quando qualcuno li corregge esternamente, non solo l'individuazione di nuovi problemi.

Ecco fatto. Un inventario storico completo, in tempo reale, con tracciamento delle modifiche e attribuzione delle identità. Sì, una soluzione come AWS Config offre nativamente questa funzionalità all'interno del provider cloud. Tuttavia, oltre a essere conveniente in termini di costi, il nostro inventario e le nostre valutazioni sono strettamente integrati, coprono più deployment e provider cloud e offrono funzionalità piuttosto notevoli, come ricerche complete.

Il modo migliore per rendersene conto è il nostro video tour di 90 secondi! Ed ecco alcune schermate chiave:

Pagina principale, che mostra un'ampia quantità di dati importanti in un'unica vista:

Ecco la vista dello storico delle modifiche, che presenta le modifiche con dettagli completi e attribuzione. Offre inoltre funzionalità utili come eventi correlati, risorse associate, esenzioni e uno storico dei risultati superati/non superati per la risorsa:

Questa vista Storico traccia le modifiche in ordine cronologico con un grafico che illustra gli andamenti dell'attività. Facendo clic sulla timeline si passa a quella data:

Vi è mai capitato di dover sapere quale risorsa cloud effimera possedeva l'indirizzo IP comparso nei log in un preciso momento? Questa funzione piace molto agli incident responder...

E questa è la panoramica rapida. Nei prossimi articoli forniremo maggiori dettagli sull'architettura e su come gestiamo tutto ciò negli ambienti multi-cloud.