Ob S3-Buckets mit offenen Schreibrechten, EC2-Snapshots mit versehentlich veröffentlichten Zugangsdaten oder IAM-Rollen ohne Multifaktor-Authentifizierung: Viele Schwachstellen in AWS entstehen nicht durch Zero-Day-Angriffe, sondern durch Konfigurationsmängel. Genau dort setzt Prowler [1] an. Das Open-Source-Tool [2] prüft systematisch auf Verstöße gegen Sicherheitsstandards, visualisiert Risiken und lässt sich dabei präzise auf individuelle Anforderungen zuschneiden.

Die Software ist kein Analysetool mit Blackbox-Charakter, sondern ein CLI-basiertes Framework für nachvollziehbare Security-Audits auf Kommandozeilenebene. Die Checks orientieren sich an Best Practices und Benchmarks wie CIS, NIST, PCI-DSS und liefern sofort verwertbare Ergebnisse für AWS, Azure, GCP, Kubernetes und Microsoft 365. Ein Fokus liegt auf AWS, denn dort ist die Prüfbreite am größten und die Integration mit cloudeigenen Diensten wie dem Security Hub oder GuardDuty am weitesten entwickelt.

Wer Prowler lokal nutzen will, installiert es via Python-Paketmanager in Linux, zum Beispiel auf Ubuntu, oder mit Brew:

Alternativ bietet sich die Nutzung des Docker-Containers an:

Für die Authentifizierung greift das Werkzeug auf bestehende AWS-CLI-Profile zurück. Um alle Prüfungen nutzen zu können, benötigt das Profil mindestens die Managed Policies "SecurityAudit" und "ViewOnlyAccess".

Zusätzlich wird eine Inline-Policy empfohlen, die spezifische Leserechte für weniger standardisierte Ressourcen freischaltet. Diese Erweiterung findet sich unter "permissions/prowler-additions-policy. json" im offiziellen Repository.

Ein Basis-Audit über alle Regionen eines Accounts erfolgt mit dem Befehl

Ein entsprechendes Profil legen Sie über das AWS-CLI mit dem Kommando

an. Daraufhin fragt das Tool nach insgesamt vier Angaben:

- AWS Access Key ID: die Schlüssel-ID des IAM-Benutzers oder einer Rolle mit ausreichenden Berechtigungen

- AWS Secret Access Key: das zugehörige geheime Zugangstoken

- Default region name: der Name der Region, beispielsweise "eu-central-1"

- Default output format: optionale Angabe, etwa "json"

Das Profil wird in der Datei "~/.aws/credentials" beziehungsweise"~/.aws/config" gespeichert. Anschließend rufen Sie Prowler wie eben gezeigt damit auf. Neben den erwähnten Managed Policies "SecurityAudit" und "ViewOnlyAccess" benötigt das IAM-Konto zusätzlich die Inline-Policy aus dem Prowler-Repository unter "permissions/prowler-additions-policy.json", um alle Checks ausführen zu können. Mit obigem Aufruf werden alle konfigurierten Checks durchlaufen und die Ergebnisse landen im Verzeichnis "output/". Neben CSV und HTML erzeugt Prowler standardkonforme JSON-Dateien im OCSF- oder ASFF-Format. Letzteres dient der direkten Übergabe an den AWS Security Hub – dazu später noch mehr:

Die HTML-Ausgabe bietet eine klare Übersicht mit Filtermöglichkeiten nach Compliancestandards, Schweregrad und betroffenen Ressourcen. Die Checks lassen sich auf einzelne Services, Regionen oder Prüfgruppen einschränken.

Mit dem Befehl prowler aws --services s3 ec2 iam führen Sie gezielt Sicherheitsprüfungen für die drei angegebenen AWS-Dienste Amazon S3, EC2 und IAM durch. Das bedeutet, Prowler beschränkt den Scan auf diese Services und überprüft deren Konfiguration auf sicherheitsrelevante Schwachstellen, Richtlinienverletzungen und potenzielle Risiken. Sie erhalten so einen fokussierten Sicherheitsreport, ohne andere Dienste zu analysieren. Eine Liste aller verfügbaren Checks lassen Sie sich zum Beispiel mit prowler aws --list-checks ausgeben.

Mit dem folgenden Kommando führen Sie gezielt drei konkrete Checks aus, die sich auf zentrale Aspekte der IAM- und ACM-Sicherheit konzentrieren:

Dabei prüft Prowler, ob IAM Access Analyzer aktiviert ist (accessanalyzer_enabled), ob auslaufende ACM-Zertifikate existieren (acm_certificates_expiration_ check) und ob für das Root-Konto Multifaktor-Authentifizierung aktiviert wurde (iam_root_mfa_enabled). Diese Checks adressieren typische Schwachstellen in AWS-Konten, lassen sich separat validieren und liefern einen fokussierten Bericht zu besonders kritischen Konfigurationen. Noch komfortabler funktioniert die Selektion über eine JSON-Checkdatei. Eine solche JSON-Checkdatei mit drei anderen sicherheitsrelevanten Prüfungen, die häufige Schwachstellen in AWS-Umgebungen adressieren, könnte so aussehen:

Diese Datei sorgt dafür, dass Prowler gezielt drei kritische Prüfungen durchführt: "s3_ bucket_public_access" erkennt S3-Buckets, die ohne Einschränkungen öffentlich zugänglich sind. Diese Fehlkonfiguration gehört zu den häufigsten Ursachen für Datenlecks in AWS-Umgebungen. "ec2_ instance_port_ssh_exposed_to_internet" prüft, ob EC2-Instanzen SSH-Zugriff über die gesamte IPv4-Fläche (0.0.0.0/0) erlauben. Ein offener Port 22 stellt ein unmittelbares Einfallstor für Brute-Force- oder Exploit-Versuche dar. "cloudtrail_multi_region_enabled" schließlich stellt sicher, dass AWS CloudTrail in allen Regionen aktiv ist. Ohne diese Einstellung bleiben sicherheitsrelevante Aktivitäten in Regionen unter dem Radar, die standardmäßig nicht genutzt werden, aber dennoch angreifbar sein können. Solche gezielten Prüfprofile lassen sich direkt mit folgendem Befehl aufrufen:

Damit erhalten Sie fokussierte Ergebnisse zu besonders sicherheitskritischen Bereichen, ohne den kompletten Prüfkatalog durchlaufen zu müssen. Wer regelmäßig wiederkehrende Checks benötigt, kombiniert solche Profile mit einem Zeitplaner, etwa über AWS Systems Manager oder lokale Cronjobs.

Bei Bedarf lässt sich die Analyse auf einzelne Regionen beschränken:

Das reduziert Laufzeit und Kosten, insbesondere, wenn Sie eine Weiterverarbeitung über den Security Hub anstoßen wollen. Für Multi-Account-Setups mit mehreren CLI-Profilen lassen sich Scans auch skriptgesteuert durchführen:

Mit dieser Schleife führen Sie automatisierte Sicherheitsprüfungen für mehrere AWS-Konten durch, indem Prowler nacheinander mit verschiedenen CLI-Profilen aufgerufen wird. Die drei Profilnamen "audit-prod", "audit-dev" und "audit-test" stehen dabei exemplarisch für unterschiedliche Umgebungen wie Produktion, Entwicklung und Test. Für jedes dieser Profile startet ein separater Scan und die Ergebnisse landen in einem dedizierten Ordner, benannt nach dem jeweiligen Profil (zum Beispiel "./audit-audit-prod"). Das erleichtert die strukturierte Auswertung und Archivierung der Resultate, insbesondere in Multi-Account-Umgebungen mit rollenbasierter Zugriffskontrolle und getrennter Verantwortlichkeit. Voraussetzung ist, dass für jedes genannte Profil ein entsprechender Eintrag in der AWS-CLI-Konfiguration existiert.

In Umgebungen mit mehreren AWS-Accounts bietet Prowler die Möglichkeit, komplette Organisationseinheiten zentral zu prüfen. Wenn Sie über ein Managementkonto verfügen, lässt sich der Scan auf sämtliche untergeordnete Accounts ausweiten. Voraussetzung ist eine zentrale Rolle mit Cross-Account-Rechten, die im Prowler-Repository als CloudFormation-Vorlage bereitsteht. Die Prüfung erfolgt dann wahlweise sequenziell oder parallel, wobei sich die Ergebnisse in separaten Unterverzeichnissen speichern lassen. Typisch ist ein automatisierter Durchlauf mit separater Reportspeicherung pro Account und optionalem Versand an den Security Hub. Für größere Organisationen mit hunderten Konten schafft diese Methode eine konsolidierte Sicherheitsübersicht ohne manuelle Auswertung einzelner Profile. Ein Beispiel:

Mit diesem Befehl starten Sie eine organisationsweite Sicherheitsprüfung über alle AWS-Konten Ihrer Organisation hinweg. Das Managementkonto wird über das Profil "master-profile" angesprochen. Über die Option "--org-role" geben Sie eine IAM-Rolle an, die berechtigt ist, in den untergeordneten Accounts temporär übernommen zu werden. Diese Rolle muss in allen geprüften Accounts vorhanden sein und Cross-Account-Zugriff erlauben. Die Ergebnisse jeder Kontoprüfung speichert Prowler im Verzeichnis "./org-audit", strukturiert nach Account-ID. Sie erhalten dadurch vollständige Berichte pro Mitgliedskonto und können zentrale Auswertungen oder Sicherheitsmaßnahmen gezielt ableiten.

Neben dem CLI bietet Prowler seit Version 5 ein lokal hostbares Dashboard. Die Installation erfolgt zum Beispiel mit Docker Compose:

Danach steht das GUI unter "http://localhost:3000 bereit". Nach Anmeldung lassen sich dort Scans starten, Ergebnisse vergleichen und Complianceberichte exportieren. Die Oberfläche basiert auf Next.js, das Backend auf Django und PostgreSQL. Für produktive Umgebungen empfiehlt sich ein separates Deployment samt RBAC-Härtung und HTTPS-Verschlüsselung.

Prowler lässt sich nicht nur lokal ausführen, sondern auch als vollständig gemanagte Lösung nutzen. Mit dem "Prowler Managed Service" steht ein Dienst bereit, der tägliche Audits über mehrere Cloud-anbieter hinweg automatisiert, Ergebnisse zentral speichert und über eine konsolidierte Weboberfläche zugänglich macht. Das umfasst AWS, Azure, GCP und Kubernetes – inklusive Complianceauswertungen, Risikoeinstufungen und kontextbezogener Empfehlungen.

Der Dienst unterstützt auch rollenbasiertes Berechtigungsmanagement (RBAC), API-Zugriff und zentrale Visualisierung über Dashboards. In hybriden Szenarien lässt sich der Managed Service mit lokalen Prowler-Instanzen synchronisieren.

Prowler erlaubt umfangreiche Anpassungen auf Config-Ebene, etwa die Verlängerung der maximalen Log-Retention-Zeit:

Diese Einstellung definiert, dass CloudWatch-Loggruppen mindestens 500 Tage aufbewahrt werden sollen. Die Parameter dazu landen in einer benutzerdefinierten Konfigurationsdatei, meist im INI-Format, die Sie beim Start übergeben:

Diese Konfigurationsdatei ersetzt nicht die CLI-Argumente, sondern ergänzt sie. Sie beeinflusst das Verhalten einzelner Checks, zum Beispiel Grenzwerte, Portdefinitionen oder Schwellenwerte für veraltete Ressourcen. Wer eigene Metriken definieren will, zum Beispiel andere Schwellen für inaktive Zugriffsschlüssel oder spezifische Warnungen bei IAM-Konfigurationen, passt sie zentral in dieser Datei an.

Damit eignet sich Prowler nicht nur für Standard-Audits, sondern auch für Umgebungen mit spezifischen Governance-Vorgaben. Die Standardkonfigurationsdatei liegt nach der Installation im Verzeichnis des Tools und kann als Vorlage dupliziert und angepasst werden. Die Übergabe einer eigenen Datei hebt die Standardwerte auf und ermöglicht eine maßgeschneiderte Prüfung, ohne einzelne Checks verändern zu müssen.

Über das "Prowler Hub"-Modul können Sie außerdem eigene Prüfregeln verfassen, zum Beispiel zur Überwachung kundenspezifischer IAM-Namensschemata oder zum Abklopfen selbstentwickelter Lambdas auf Environment-Variablen mit sensitiven Werten. Jede benutzerdefinierte Regel wird dokumentiert, versioniert und lässt sich mit Metainformationen wie Schweregrad, Referenz, Remediation-Link und Risikobeschreibung versehen.

Der Hub fungiert dabei als zentrales Repository für Sicherheitsrichtlinien und stellt die Verbindung zwischen individuellen Prüfregeln, bestehenden Frameworks und dem Prowler-Kern her. Sie können dort eigene Security-Standards definieren, bestehende Regeln aus der Community übernehmen oder angepasste Benchmarks für verschiedene Clouddienste entwickeln. Dabei profitieren Sie von klar dokumentierten JSON-Strukturen und einem offenen Format, das vollständig ohne Vendor-Lock-in auskommt.

Für den produktiven Einsatz empfiehlt sich die Integration des Hubs in Ihre Versionsverwaltung. So behalten Sie den Überblick über Änderungen an den Prüfkatalogen, testen neue Regeln unabhängig vom Hauptsystem und sichern gleichzeitig die Nachvollziehbarkeit. Prowler lädt die Inhalte des Hubs bei jedem Scan dynamisch und ermöglicht so ein flexibles, revisionssicheres Regelmanagement, das auf Ihre Anforderungen zugeschnitten ist.

Im CI/CD-Kontext lässt sich Prowler als Build-Step integrieren. In Verbindung mit dem neuen Modul "Prowler Fixer" sind sogar automatische Remediations möglich. Eine typische Kombination in GitLab CI sieht so aus:

Dieser Befehl findet typischerweise in einem CI/CD-Workflow Verwendung und führt zwei aufeinanderfolgende Schritte aus. Im ersten Schritt scannt Prowler die AWS-Umgebung, wobei ausschließlich die Sicherheitsprüfungen aus der Datei "checks.json" ausgeführt werden. Diese Datei enthält eine Liste von Check-IDs, die Sie gezielt definieren. Der Parameter "--output-folder ./results" sorgt dafür, dass alle Scanergebnisse, darunter CSV-, JSON- und HTML-Berichte, im Verzeichnis "results" gespeichert werden.

Im zweiten Schritt geben Sie mit dem Befehl cat ./results/html-report.html den HTML-Bericht direkt in der Konsole aus. Das eignet sich vor allem für automatisierte Pipelines, bei denen Sie das Ergebnis als Artefakt speichern oder an nachgelagerte Schritte übergeben wollen. In Verbindung mit CI/CD-Systemen wie GitLab oder Jenkins lässt sich so ein kontinuierlicher Sicherheitsprüfprozess abbilden.

Ergebnisse können Sie per Webhook an Security-Information-Plattformen wie Splunk oder Elastic weitergeben, sofern das JSON im OCSF-Format vorliegt. Das spart Integrationsarbeit und verbessert die Nachvollziehbarkeit.

Neben dem bekannten Kommandomodus unterstützt Prowler seit Version 5 auch das Scannen von GitHub-Repositories auf Sicherheitsrisiken. Dabei werden unter anderem öffentlich zugängliche Secrets, fehlende Branch-Protection-Regeln oder ungeschützte Repository-Einstellungen erkannt. Die Authentifizierung erfolgt über Personal Access Token, OAuth oder GitHub-App-Zugänge. Auch Microsoft-365-Umgebungen lassen sich inzwischen prüfen, etwa auf mangelhafte Richtlinien zur Authentifizierung oder zu weit gefasste Zugriffsrechte in Exchange Online.

Für Infrastructure-as-Code (IaC) bietet Prowler eine dedizierte Scan-Engine auf Basis von Checkov, mit dem Sie Terraform-, CloudFormation- oder Kubernetes-Manifestdateien analysieren können, noch bevor sie in die Cloud gelangen. Damit integriert sich Prowler auch in rein lokale Entwicklungsumgebungen und sichert den Shift-left-Ansatz in DevSecOps-Pipelines ab.

Im Rahmen praktischer Audits finden sich regelmäßig dieselben Fehlkonfigurationen, zum Beispiel:

- S3-Buckets mit öffentlichen Leserechten

- IAM-User ohne MFA

- EC2-Instanzen mit offenen Ports in 0.0.0.0/0

- Fehlende CloudTrail-Konfiguration

- Lambda-Funktionen mit sensiblen Umgebungsvariablen

- Rollen mit deutlich zu weit gefassten Berechtigungen

- Veraltete KMS-Policies

Um diese Schwachstellen gezielt zu beheben, kann Prowler mithilfe des Fixer-Moduls ausgewählte Findings direkt und automatisiert beheben. Dabei lässt sich

jede unterstützte Prüfung durch eine vordefinierte Remediation-Logik ergänzen. Ein fehlender CloudTrail in der Region "us-east-1" lässt sich so zum Beispiel mit dem folgenden Befehl nicht nur erkennen, sondern auch unmittelbar beheben:

Prowler erstellt in diesem Fall automatisch eine neue CloudTrail-Konfiguration mit den empfohlenen Einstellungen. Das funktioniert aber nur, wenn ausreichende IAM-Berechtigungen vorhanden sind. Eine weitere häufige Maßnahme ist die Aktivierung von GuardDuty, die über den Fixer ebenfalls automatisiert werden kann:

Prowler prüft hierbei, ob der Dienst aktiv ist, und schaltet ihn bei Bedarf ein. Diese Automatisierungen lassen sich auch CI/CD-gestützt ausführen oder über Infrastructure-as-Code-Prozesse kontrollieren. Dabei kann Fixer statt aktiver Änderungen auch Pull-Requests erzeugen oder Terraform-Dateien modifizieren. Unternehmen mit hohem Automatisierungsgrad profitieren dadurch von einem schnellen Feedbackzyklus zwischen Analyse, Befund und Absicherung.

Fixer arbeitet direkt auf API-Ebene, greift also unmittelbar auf die AWS-Ressourcen zu. Standardmäßig werden aber nur risikoarme Änderungen unterstützt, zum Beispiel das erwähnte Aktivieren von GuardDuty, das Erzwingen sicherer Passwortregeln oder das Setzen fehlender CloudTrail-Parameter. Individuelle Anpassungen sind möglich, da jede Remediation in Python geschrieben ist und sich bei Bedarf modifizieren lässt.

So integrieren Sie eigene Sicherheitsrichtlinien direkt in den Prüf- und Härtungsablauf, ohne externe Tools verwenden zu müssen. Auch die Kombination mit Infrastructure-as-Code ist vorgesehen. Statt live zu verändern, lässt sich alternativ ein Pull Request erzeugen, der die gewünschten Änderungen über GitOps bereitstellt.

Prowler kann die Ergebnisse seiner Sicherheitsprüfungen direkt an den AWS Security Hub übergeben. Der Security Hub fungiert als zentrales Konsolidierungs- und Analysewerkzeug für sicherheitsrelevante Ereignisse in einer AWS-Organisation. Sobald ein Scan abgeschlossen ist, lassen sich die Findings mit dem Befehl

in das ASFF-Format (AWS Security Finding Format) konvertieren und automatisch übermitteln. Der Security Hub empfängt diese Informationen regionsübergreifend und ordnet sie den jeweiligen Accounts zu. Sie als Administrator sehen dadurch auf einen Blick, in welchem Konto, welcher Region und welcher Ressource ein Problem erkannt wurde. Für Multi-Account-Umgebungen mit Organisationsstruktur bietet der Security Hub eine einheitliche Oberfläche zur Priorisierung, Kategorisierung und Nachverfolgung von Schwachstellen. Zudem lassen sich Alerts automatisieren, zum Beispiel über EventBridge-Regeln oder Playbooks für den AWS Systems Manager, um abgestimmte Reaktionen auf kritische Befunde auszulösen.

Dort erscheinen die erkannten Schwachstellen nach wenigen Minuten mit Referenz auf die betroffenen Ressourcen. Durch manuelle Annotation oder Playbooks im AWS Systems Manager lassen sich dann Maßnahmen ableiten. Prowler beherrscht seit Version 5 auch die Analyse von Bedrohungsmustern über AWS CloudTrail. Mit dem Parameter "--categories threat-detection" aktivieren Sie Prüfungen, die typische Angriffsindikatoren in den Protokollen erkennen. Beispiele sind ungewöhnliche API-Aufrufe, plötzliche Rechteeskalationen oder Aktivitäten in inaktiven Regionen. Das Tool wertet dabei standardisierte Ereignisse aus den letzten 24 Stunden aus, lässt sich bei Bedarf aber an andere Zeiträume anpassen. Voraussetzung ist, dass CloudTrail in allen geprüften Regionen aktiv ist. Die Ergebnisse lassen sich gezielt nach Schweregrad oder Ressourcentyp filtern und helfen dabei, kompromittierte Identitäten oder missbrauchte Dienste frühzeitig zu identifizieren.

Ob als CLI-Werkzeug im Terminal, als Dashboard im Browser oder als Managed Service für unternehmensweite Compliance: Prowler deckt unterschiedlichste Anwendungsszenarien ab. Mit anpassbaren Checks, Reporting in Standardformaten, direkter Integration in CI/CD-Pipelines und umfangreicher Unterstützung für Multi-Account-Umgebungen bietet das Tool eine Mischung aus Flexibilität, Automatisierung und Transparenz. Gerade für IT-Administratoren, die Verantwortung für die Sicherheit komplexer Cloudstrukturen tragen, liefert das Werkzeug eine gute Grundlage für revisionssichere, nachvollziehbare und kontinuierlich verbesserbare Audits.