Bei FloQast sind wir immer auf der Suche nach neuen Wegen, um die Sichtbarkeit unserer Umgebungen zu erhöhen und Möglichkeiten für Sicherheitsverbesserungen zu finden. Zu diesem Zweck haben wir im Juni 2022 die Überwachung von AWS EC2-Instances mithilfe nicht genehmigter Amazon-Maschinen-Images implementiert. Wir konnten nicht nur Auffälligkeiten erkennen, sondern brauchten auch eine Lösung, die uns Folgendes ermöglicht:
- Evaluieren Sie Konfigurationen mit einem hohen Maß an Flexibilität
- Zuverlässige Triggerauswertung bei Ressourcenänderungen
- Zentrales Management von Konfigurationen in mehreren Umgebungen
- Warnung bei Erkennungen
- Flexibilität und Zuverlässigkeit
Die natürliche Wahl hierfür wäre die Nutzung von AWS Config, aber wird es funktionieren? AWS bietet tatsächlich eine Standardregeloption für zugelassene AMIs, aber es ist auf eine Liste von 10 IDs beschränkt. Was ist, wenn Sie in der Lage sein möchten, die Liste zu erweitern und Bilder neben der ID anhand von Attributen auszuwerten? Zum Glück, Config unterstützt benutzerdefinierte Lambda-Regeln, die es ermöglichen, die Bewertungslogik so ausgefeilt wie nötig zu gestalten. Config erkennt Ressourcen und zeichnet Konfigurationselemente für Änderungen auf, sodass dies unsere ersten beiden Anforderungen erfüllt.
Zentrales Management
Eine zentrale Verwaltung kann durch die Kombination von AWS Config mit AWS Organizations erreicht werden. Indem Sie ein Konto als delegierten Administrator für Config festlegen, können Regeln in Mitgliedskonten ohne zusätzlichen Aufwand definiert und aktualisiert werden. Für die Aktivierung delegierter Administratorberechtigungen sind nur wenige Befehle erforderlich. Wir können sogar verlangen, dass sich das Bewertungs-Lambda im delegierten Admin-Konto befindet. Dies bedeutet, dass wir auch kontoübergreifende Rollen einrichten müssen, damit das Lambda Daten von den Mitgliedskonten abfragen und das Bewertungsergebnis zurückgeben kann.
Das ist großartig, denn wenn wir die Regellogik ändern müssen, muss nur ein Lambda aktualisiert werden. Es gibt uns auch die Gewissheit, dass die Regellogik nicht von einem potenziell kompromittierten privilegierten Benutzer in einem Mitgliedskonto aktualisiert werden kann.
Alarmierend
Interessant wird es, wenn man bei Erkennungen alarmiert. Unser ursprüngliches Ziel war es, Warnmeldungen in unseren AWS-Schwachstellenmanagement-Prozess zu integrieren, der auf AWS SecurityHub basiert. Wenn es möglich wäre, alles in SecurityHub zu integrieren, wären unsere vorhandenen Tools in der Lage, SecHub nach den relevanten Ergebnissen abzufragen und den Rest zu erledigen (Spoiler-Alert: AWS bietet dies jetzt nativ an, aber darauf kommen wir später zurück). Auf den ersten Blick scheint es einfach zu sein, da Config die Option bietet, Regelauswertungen von Organisationskonten zu aggregieren. Durch das Einrichten der Aggregation sind die Daten anderer Konten jedoch nicht von einer einzigen Quelle aus zugänglich, außer über die Konsole. Die Möglichkeit, in der Konsole zwischen Konten zu wechseln, ist großartig, aber die Endpunkte, die dies ermöglichen, werden 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 waren, aber Config gibt eigentlich keine Ereignisse für Auswertungen aus, die von anderen Konten aggregiert werden. Es wäre möglich, in jedem Konto einen Event-Bus einzurichten und sie alle zum Verwaltungskonto weiterzuleiten, aber das wird chaotisch und widerspricht unserem zentralen Managementziel. Wir haben auch die Verwendung des Config SNS-Themas 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 einigem Ausprobieren wurde klar, dass die beste Lösung darin bestand, den Mittelsmann auszuschalten. Das Evaluierungs-Lambda erhält bereits alles, was es benötigt, um eine Warnung senden zu können. Warum also nicht ein Protokoll in einen S3-Bucket schreiben lassen, um von unserem SIEM aufgenommen zu werden, und es an Config zurückmelden? Wir würden zwar die automatischen Ressourcenstatus-Updates 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 stellten wir fest, dass AWS Funktionen hinzufügte Integrieren Sie Config und SecHub nativ. Es ist schön, seiner Zeit voraus gewesen zu sein, aber eine solche Ankündigung zu sehen, ist unter diesen Umständen definitiv bittersüß. SecHub ist möglicherweise nicht für jedes Unternehmen geeignet, daher könnte der Lambda-Ansatz für einige Anwendungen dennoch nützlich sein.
In Übereinstimmung mit den informellen Konventionen, die bei FloqAST eingeführt wurden, wurde dieses Tool als Backonym benannt Kursiv, oder „Image Trust Allow-List Inspection Controller“. In Zukunft werden wir es vielleicht erweitern, um weitere Regeln hinzuzufügen und mehr Ressourcentypen abzudecken, aber im Moment erfüllt es effektiv seinen Zweck, die Überwachung auf nicht autorisierte Bilder.