Ein Penetrationstest – kurz Pentest oder Ethical Hacking – ist ein autorisierter, simulierter Angriff auf ein IT-System, eine Anwendung oder eine Infrastruktur mit dem Ziel, Sicherheitslücken zu identifizieren, bevor echte Angreifer sie ausnutzen können. Im Unterschied zu automatisierten Schwachstellenscans kombiniert ein Penetrationstest automatisierte Tools mit manueller Kreativität und Expertise: Ethical Hacker denken wie Angreifer und suchen aktiv nach Wegen, Systeme zu kompromittieren.
Penetrationstests sind für Automatisierungsinfrastrukturen besonders wertvoll, weil sie systemische Sicherheitsprobleme aufdecken, die automatisierte Scanner übersehen: Logikfehler in Workflows, Kombination von einzeln harmlosen Schwachstellen zu gefährlichen Angriffsvektoren, oder Sicherheitsprobleme in der Interaktion zwischen Systemen. Ein jährlicher Penetrationstest ist für ISO-27001-zertifizierte Unternehmen und für viele Unternehmenskunden-Anforderungen obligatorisch.
Pentesting-Phasen
1 Scoping & Planung: Was darf getestet werden? Welche Systeme sind im Scope? Zeitfenster, Eskalationsprozesse, Legal Basis (schriftlicher Auftrag)
2 Reconnaissance: Informationen über das Zielsystem sammeln – öffentliche Daten, Subdomain-Enumeration, Technologie-Fingerprinting
3 Scanning: Automatisierte Schwachstellenscans, Port-Scans, Service-Identifikation – erste Kandidaten für Schwachstellen identifizieren
4 Exploitation: Gefundene Schwachstellen aktiv ausnutzen – beweisen, dass eine Lücke wirklich ausnutzbar ist, nicht nur theoretisch existiert
5 Post-Exploitation: Wie weit kann ein Angreifer nach initialem Zugriff vordringen? Laterale Bewegung, Privilege Escalation, Datenzugriff
6 Reporting: Strukturierter Bericht mit allen Findings, Schweregrad-Bewertung, reproduzierbaren Beweisen und priorisierten Empfehlungen
Praxisbeispiel
Ein Automationsdienstleister beauftragt einen jährlichen Penetrationstest seiner n8n-Infrastruktur. Scope: n8n-Instanz, PostgreSQL-Datenbank, AWS-Umgebung, alle öffentlich erreichbaren APIs. Findings: Critical (1): veraltete n8n-Version mit bekannter RCE-Schwachstelle (Remote Code Execution) – sofort gepatcht. High (2): S3-Bucket mit Backup-Daten öffentlich lesbar (falsche ACL-Konfiguration) – sofort gesperrt. Medium (3): API-Endpunkt ohne Rate-Limiting anfällig für Brute-Force-Angriffe. Low (2): TLS-Konfiguration akzeptiert ältere Cipher-Suites. Informational (4): Mehrere Informationslecks in Fehlermeldungen. Reaktion: Critical und High innerhalb von 24 Stunden behoben. Medium und Low in der nächsten Sprint-Planung priorisiert. Wichtigste Erkenntnis: Die RCE-Schwachstelle war 3 Monate alt – der Pentest hat verhindert, dass ein echter Angreifer sie findet.
