Maßgeschneiderte Überwachung mit benutzerdefinierten AWS-Konfigurationsregeln

Bei FloQast sind wir immer auf der Suche nach neuen Wegen, um die Transparenz unserer Umgebungen zu erhöhen und Möglichkeiten zur Verbesserung der Sicherheit zu finden. Zu diesem Zweck haben wir im Juni 2022 eine Überwachung für AWS EC2-Instanzen implementiert, die nicht zugelassene Amazon-Maschinenabbilder verwenden. Neben der Möglichkeit, Anomalien zu erkennen, benötigten wir eine Lösung, die es uns ermöglicht:

• Bewertung von Konfigurationen mit einem hohen Maß an Flexibilität
• Zuverlässige Auslösung der Auswertung bei Ressourcenänderungen
• Zentrale Verwaltung von Konfigurationen über mehrere Umgebungen hinweg
• Warnung bei Entdeckungen
• Flexibilität und Verlässlichkeit

Die naheliegendste Lösung hierfür wäre die Nutzung von AWS Config, aber wird das funktionieren? AWS bietet tatsächlich eine Standardregeloption für genehmigte AMIs, aber sie ist auf eine Liste von 10 IDs beschränkt. Was ist, wenn Sie die Liste erweitern und Images auf der Grundlage von Attributen außer der ID bewerten möchten? Glücklicherweise unterstützt Config benutzerdefinierte Lambda-Regeln, mit denen die Auswertungslogik so ausgefeilt wie nötig sein kann. Config erkennt Ressourcen und zeichnet Konfigurationselemente für Änderungen auf, womit die ersten beiden Anforderungen erfüllt sind.

Zentrale Verwaltung

Eine zentrale Verwaltung kann durch die Kombination von AWS Config mit AWS Organizations erreicht werden. Indem ein Konto als delegierter Administrator für Config bestimmt wird, können Regeln in Mitgliedskonten ohne zusätzlichen Aufwand definiert und aktualisiert werden. Das Aktivieren delegierter Admin-Berechtigungen erfordert nur wenige Befehle. Es kann sogar verlangt werden, dass das Bewertungslambda im delegierten Administratorkonto liegt. Dies bedeutet, dass wir auch kontoübergreifende Rollen einrichten müssen, damit das Lambda Daten aus den Mitgliedskonten abfragen und das Auswertungsergebnis zurückgeben kann.

Das ist großartig, denn wenn wir die Regellogik ändern müssen, gibt es nur ein Lambda, das aktualisiert werden muss. Außerdem können wir so sicher sein, dass die Regellogik nicht von einem potenziell gefährdeten privilegierten Benutzer in einem Mitgliedskonto aktualisiert werden kann.

Alarmierung

Die Alarmierung bei Erkennungen ist der Punkt, an dem es interessant wird. Unser ursprüngliches Ziel war die Integration von Warnmeldungen in unseren AWS Vulnerability Management-Prozess, der auf AWS SecurityHub basiert. Wenn es möglich wäre, alles in SecurityHub zu integrieren, könnten unsere vorhandenen Tools SecHub nach den relevanten Ergebnissen abfragen und den Rest erledigen (Spoiler Alert: AWS bietet dies jetzt nativ an, aber dazu kommen wir später). Auf den ersten Blick scheint es einfach zu sein, da Config die Option enthält, Regelbewertungen von Organisationskonten zu aggregieren. Durch die Einrichtung der Aggregation sind die Daten anderer Konten jedoch nur über die Konsole aus einer einzigen Quelle zugänglich. Die Möglichkeit, in der Konsole zwischen Konten zu wechseln, ist großartig, aber die Endpunkte, die dies ermöglichen, werden den Benutzern nicht zur Verfügung gestellt.

Wir haben versucht, einen EventBridge-Bus einzurichten, um Config-Ereignisse für die Regeln zu sammeln, an denen wir interessiert sind, aber Config sendet eigentlich keine Ereignisse für Auswertungen, die von anderen Konten aggregiert werden. Es wäre möglich, in jedem Konto einen EventBridge-Bus einzurichten und alle Ereignisse an das Verwaltungskonto weiterzuleiten, aber das wird unübersichtlich und steht im Widerspruch zu unserem Ziel der zentralen Verwaltung. Wir haben auch die Verwendung des SNS-Themas Config untersucht, aber es gibt keine Möglichkeit, effizient nach einer bestimmten Regel zu filtern, da die SNS-Nachrichtenattribute von Config nicht konfiguriert werden können.

Endgültige Architektur

Nach einigen Versuchen wurde klar, dass die beste Lösung darin bestand, den Mittelsmann auszuschalten. Der Evaluierungs-Lambda erhält bereits alles, was er braucht, um einen Alarm zu senden. Warum also nicht ein Protokoll in einen S3-Bucket schreiben, das von unserem SIEM aufgenommen wird, und an Config zurückmelden? Wir würden zwar die automatischen Aktualisierungen des Ressourcenstatus von Config verpassen, aber wir hätten eine zuverlässige Möglichkeit, über Probleme informiert zu werden.

Am Ende entschieden wir uns für den Lambda-Ansatz mit zwei Ausgängen, aber Tage später entdeckten wir, dass AWS Funktionen zur nativen Integration von Config und SecHub hinzugefügt hatte. Es ist schön, der Zeit voraus zu sein, aber eine solche Ankündigung zu sehen, ist unter den gegebenen Umständen definitiv bittersüß. SecHub ist möglicherweise nicht für jedes Unternehmen geeignet, sodass der Lambda-Ansatz für einige Anwendungen immer noch nützlich sein könnte.

Im Einklang mit den informellen Konventionen bei FloQast wurde dieses Tool per Backronym als Italic oder "Image Trust Allow-List Inspection Controller:in" bezeichnet. In Zukunft werden wir es möglicherweise erweitern, um mehr Regeln hinzuzufügen und mehr Ressourcentypen abzudecken, aber im Moment erfüllt es effektiv den beabsichtigten Zweck der Überwachung auf nicht autorisierte Bilder.

Trevr Fernald

Trevr ist Sicherheitsingenieur bei FloQast mit einer Leidenschaft für Automatisierung und Problemlösung. Außerhalb der Arbeit liest er gerne, spielt Gitarre und fährt Ski.