Deep Dive zur Echtzeit-Inventarisierung

Schon früh bei FireMon (genauer gesagt, bevor wir zu FireMon wurden) stellten wir fest, dass der Versuch, die Cloud-Konten von Kunden (einschließlich Subscriptions/Projekten) live zu bewerten, ... problematisch war. Bei einer derart hohen Anzahl von Bewertungen wären schnell Service-Limits erreicht worden, und die internen API-Aufrufe eines Kunden hätten gestört werden können. Dabei ist zu bedenken, dass wir damit vor etwa 7 Jahren begonnen haben, noch bevor es CSPM überhaupt gab, und alle dieselben Erfahrungen machten.

Die erste Lösung, auf die wir kamen, bestand darin, Konfigurationsdaten einmalig zu erfassen, in unser eigenes Inventar einzuspeisen und unsere Bewertungen dann dort durchzuführen. So konnten wir unsere API-Aufrufe auf das reduzieren, was zum Abruf der Metadaten notwendig war. Anschließend konnten wir mehrere Bewertungen auf Basis desselben Datensatzes ausführen. Eine Zeit lang funktionierte dieser Ansatz gut. Wir führten weiterhin zeitgesteuerte Konfigurationsscans durch, konnten sie aber gleichmäßiger verteilen und so optimieren, dass eine Überlastung durch API-Aufrufe minimiert wurde. Allerdings brachte dieser Ansatz eigene Probleme mit sich. Was, wenn sich zwischen unserem Scan und dem Zeitpunkt, an dem jemand die Meldung schließlich bearbeitete, etwas geändert hatte? Zudem stieß das vollständige Durchsuchen eines AWS-Dienstes nach allen Ressourcen dieses Dienstes nach wie vor an API-Limits, die sich nach Dienst und Region richten.

Wir haben uns zwei Herausforderungen gestellt, um diese Situation besser zu bewältigen. Erstens wollten wir das Inventar in Echtzeit aktualisieren, um Spitzen bei API-Aufrufen an einen bestimmten Dienst zu reduzieren und sicherzustellen, dass Kunden nie mit veralteten Daten arbeiten. Zweitens wollten wir eine Historie vorhalten, damit Kunden und Ermittler zurückblicken und genau sehen können, was sich geändert hat und wie. Auf die technische Architektur gehen wir später ein; sie unterscheidet sich je nach Cloud-Plattform leicht. Kurz gesagt: Durch die direkte Anbindung an den Event-Stream des Cloud-Anbieters konnten wir Änderungs-API-Aufrufe erkennen, die betroffenen Ressourcen extrahieren, unser Inventar in Echtzeit aktualisieren und alle unsere Bewertungen für einen bestimmten Inventartyp gleichzeitig auslösen.

Auch wenn wir dies weiterhin durch einen zeitgesteuerten Durchlauf einmal täglich bzw. außerhalb der Geschäftszeiten ergänzen, hat die Umstellung auf Echtzeit viele Probleme gelöst und einige interessante Vorteile hervorgebracht. Dazu zählen:

• Kunden stoßen nie auf veraltete Daten; alles in der Plattform sollte weitgehend der tatsächlich laufenden Konfiguration bzw. dem tatsächlichen Zustand entsprechen.
• Da wir die API-Aufrufe überwachen, können wir feststellen, wer diese Aufrufe getätigt hat. Damit verfügen wir plötzlich über eine vollständige Identitätszuordnung in unserem Inventar.
• Es lässt sich leicht bestimmen, was sich bei einer Änderung geändert hat – das ergibt eine umfassende Änderungsverfolgung.
• Wir können alle Prüfungen und Bewertungen in Echtzeit ausführen, sobald Änderungen auftreten. Dazu gehört auch das SCHLIESSEN von Problemen, wenn jemand sie extern behebt – nicht nur das Erkennen neuer Probleme.

Fertig. Ein vollständiges, echtzeitfähiges, änderungsverfolgtes, identitätszugeordnetes historisches Inventar! Ja, etwas wie AWS Config bietet diese Funktionalität nativ innerhalb des Cloud-Anbieters. Abgesehen von der Kosteneffizienz sind unser Inventar und unsere Bewertungen jedoch eng integriert, decken mehrere Cloud-Deployments und -Anbieter ab und bieten einige recht beeindruckende Funktionen, etwa umfassende Suchmöglichkeiten.

Am besten erleben Sie das in unserer 90-sekündigen Videotour! Und hier einige zentrale Screenshots:

Hauptseite mit einer Fülle wichtiger Daten in einer einzigen Ansicht:

Hier die Ansicht der Änderungshistorie, die Änderungen mit vollständigen Details und Zuordnung darstellt. Sie bietet zudem nützliche Funktionen wie zugehörige Ereignisse, verknüpfte Ressourcen, Ausnahmen und eine Historie der bestandenen/nicht bestandenen Prüfergebnisse für die Ressource:

Diese Historienansicht verfolgt Änderungen chronologisch mit einem Diagramm, das Aktivitätstrends darstellt. Ein Klick auf die Zeitleiste springt zum jeweiligen Datum:

Mussten Sie schon einmal wissen, welche kurzlebige Cloud-Ressource zu einem bestimmten Zeitpunkt Inhaberin der in den Logs aufgetauchten IP-Adresse war? Incident Responder lieben diese Funktion ...

Und das war der kurze Überblick. In künftigen Beiträgen geben wir tiefere Einblicke in die Architektur und darin, wie wir dies für Multi-Cloud-Umgebungen umsetzen.