Microsoft 365 Pentest: Die ultimative Checkliste
25/10/2026
Pentest-Anbieter auswählen: Der ultimative Leitfaden
25/10/2026AWS-Pentest: Der ultimative Sicherheitscheck
Ein AWS-Pentest prüft, ob Angreifer über öffentlich erreichbare Anwendungen, falsch konfigurierte Berechtigungen oder unsichere Cloud-Ressourcen an sensible Daten gelangen können. Offene Ports allein reichen als Prüfkriterium nicht aus: In Amazon Web Services (AWS) entstehen Risiken häufig durch das Zusammenspiel von IAM-Rollen, Speicherfreigaben, Netzwerkregeln und Workloads. Dieser Leitfaden zeigt acht zentrale Prüfbereiche und erklärt, wie Unternehmen einen AWS-Pentest sinnvoll vorbereiten.
Was wird bei einem AWS-Pentest getestet?
Ein AWS-Pentest ist eine autorisierte, technisch nachvollziehbare Sicherheitsprüfung einer definierten Cloud-Umgebung. Je nach Auftrag kombiniert er Konfigurationsanalysen mit kontrollierten Tests von Anwendungen und Angriffspfaden. Im Mittelpunkt steht die Frage: Welche Rechte und Daten könnte ein Angreifer nach einem realistischen Einstieg tatsächlich erreichen?
Das AWS-Regelwerk für Penetrationstests unterscheidet ausdrücklich zwischen Tests an eigenen Ressourcen und Angriffen auf die Infrastruktur des Cloud-Anbieters. Für bestimmte aufgeführte Dienste, darunter EC2, CloudFront, API Gateway, Lambda und RDS, ist kein vorheriger AWS-Genehmigungsantrag erforderlich. Das bedeutet jedoch nicht, dass jede Testmethode erlaubt ist: DoS, bestimmte Übernahmeszenarien und weitere Aktivitäten sind untersagt; Command-and-Control-Tests benötigen eine vorherige Genehmigung. Für nicht aufgeführte Dienste muss das Vorgehen mit AWS geklärt werden.
Die 8 wichtigsten Prüfbereiche im AWS-Pentest
1. IAM: Rollen, Richtlinien und Rechteausweitung
AWS Identity and Access Management (IAM) regelt, wer welche Aktionen ausführen darf. Im Prüfungsfokus stehen überprivilegierte Rollen, unklare Vertrauensbeziehungen und Kombinationen von Berechtigungen, die eine Rechteausweitung ermöglichen könnten. Eine Rolle mit weitreichenden Verwaltungsrechten ist nicht automatisch eine Schwachstelle; kritisch wird sie, wenn sie von einer ungeeigneten Identität übernommen werden kann.
Eine sinnvolle Prüfung untersucht deshalb nicht nur einzelne Policies, sondern deren effektive Berechtigungen im Zusammenspiel mit Resource Policies, Permission Boundaries und gegebenenfalls Service Control Policies. Für die erste Bewertung sind IAM Access Analyzer und eine autorisierte Konfigurationsanalyse hilfreich. Aktive Rechteausweitung erfolgt ausschließlich mit vereinbarten Testidentitäten.
2. Öffentlich erreichbare Cloud-Ressourcen
Internetfähige Anwendungen benötigen erreichbare Endpunkte. Nicht jede öffentliche IP-Adresse ist deshalb ein Befund. Geprüft wird vielmehr, ob EC2-Instanzen, Load Balancer, Administrationsschnittstellen und Testumgebungen unnötig exponiert sind und ob die angebotenen Dienste angemessen abgesichert wurden.
Besonders relevant sind Management-Zugänge, veraltete Anwendungen und versehentlich veröffentlichte Entwicklungsumgebungen. Der Test sollte zwischen beabsichtigter Erreichbarkeit, vermeidbarer Angriffsfläche und nachgewiesener Ausnutzbarkeit unterscheiden. Ein offener Port allein belegt noch keinen erfolgreichen Angriff.
3. S3-Buckets und ungewollte Datenfreigaben
Amazon S3 speichert häufig Backups, Dokumente, Exportdateien und Anwendungsdaten. Die Prüfung betrachtet Bucket Policies, Block Public Access, Access Points sowie kontoübergreifende Freigaben. Dabei ist zu klären, welche Zugriffe geschäftlich notwendig sind und welche nicht.
Der IAM Access Analyzer für S3 kann öffentliche und kontoübergreifende Zugriffe auf unterstützte Ressourcen sichtbar machen. Eine öffentliche Berechtigung muss im Kontext des konkreten Anwendungsfalls bewertet werden. Der Nachweis sollte möglichst über Testobjekte oder Berechtigungsanalysen erfolgen – nicht durch massenhaften Abruf produktiver Kundendaten. Die von AWS untersagte Übernahme von S3-Buckets gehört nicht zum regulären Testumfang.
4. Netzwerke: Security Groups, Routing und Segmentierung
In AWS wird Netzwerksegmentierung unter anderem über VPCs, Subnetze, Routing, Security Groups und Network ACLs umgesetzt. Ein Pentest untersucht, ob vorgesehene Grenzen auch aus den vereinbarten Testpositionen wirksam sind. Das betrifft beispielsweise den Übergang von einem öffentlichen Webserver zu internen Datenbanken oder administrativen Systemen.
Die zentrale Frage lautet nicht nur, ob eine Regel existiert, sondern welche Verbindung tatsächlich möglich ist. Ein gezielter Test kombiniert die Soll-Kommunikationsmatrix mit kontrollierten Verbindungsversuchen und berücksichtigt dabei Peering, Transit Gateways und hybride Netzverbindungen, soweit sie im Scope liegen.
5. EC2, Container und Workload-Identitäten
Auch eine korrekt konfigurierte Cloud-Plattform schützt keine unsichere Anwendung automatisch. Bei EC2, ECS oder Fargate können ungepatchte Dienste, fehlerhafte Container-Konfigurationen, unsicher gespeicherte Zugangsdaten und zu großzügige Workload-Rollen relevant sein.
Ein praxisnahes Szenario untersucht, was nach einer kompromittierten Anwendung passieren könnte: Kann der Workload auf sensible Daten zugreifen? Sind die ihm zugewiesenen AWS-Berechtigungen auf das notwendige Minimum begrenzt? Solche Angriffsketten sind oft aussagekräftiger als eine isolierte Liste von Softwareversionen.
6. APIs und serverlose Funktionen
API Gateway und Lambda bilden häufig die Grundlage von Kundenportalen und internen Integrationen. Zu den typischen Prüffragen gehören fehlerhafte Authentifizierung, unzureichende Objektberechtigungen, mangelhafte Eingabevalidierung und überprivilegierte Ausführungsrollen.
Ein API-Pentest muss sowohl die Anwendungsebene als auch die Cloud-Berechtigungen berücksichtigen. Ein Endpunkt kann technisch gut abgesichert erscheinen und dennoch Daten eines anderen Mandanten ausgeben. Umgekehrt kann eine fehlerhaft konfigurierte Lambda-Rolle den möglichen Schaden eines Anwendungsfehlers deutlich vergrößern.
7. Secrets, Schlüssel und Vertrauensbeziehungen
Zugangsdaten können in Umgebungsvariablen, Konfigurationsdateien, Container-Images, Build-Artefakten oder Quellcode landen. Untersucht wird, ob Geheimnisse unnötig offengelegt werden und ob ihre Berechtigungen, Rotation und Nutzung zum Schutzbedarf passen.
Zusätzlich verdienen Cross-Account-Rollen Aufmerksamkeit. Solche Vertrauensstellungen sind für Unternehmen mit mehreren AWS-Konten oft notwendig, sollten aber auf eindeutig autorisierte Identitäten und passende Bedingungen beschränkt sein. Ein Fehlgriff bei einer Trust Policy kann mehrere Konten betreffen.
8. CloudTrail, Erkennung und Nachvollziehbarkeit
Ein Sicherheitsvorfall ist besonders problematisch, wenn wichtige Aktionen nicht nachvollzogen werden können. Deshalb sollte geprüft werden, ob relevante Verwaltungsaktionen und benötigte Datenzugriffe protokolliert, geschützt und ausgewertet werden.
Ein wichtiges Detail: CloudTrail-Datenereignisse, etwa für S3-Objektzugriffe, sind bei Trails und Event Data Stores nicht standardmäßig aktiviert. Ihre Erfassung muss gezielt konfiguriert werden und kann zusätzliche Kosten verursachen. Ein Pentest kann mit vereinbarten Testaktionen untersuchen, ob relevante Ereignisse tatsächlich erkennbar sind; ein vollständiger Detection-Test sollte ausdrücklich beauftragt werden.
Beispiel: Wie aus kleinen Cloud-Fehlern ein Angriffspfad wird
Ein hypothetisches Szenario: Ein öffentlich erreichbarer Dienst enthält eine ausnutzbare Anwendungsschwachstelle. Die Anwendung läuft mit einer IAM-Rolle, die mehr Zugriffsrechte besitzt als für ihre Aufgabe erforderlich. Nach dem initialen Zugriff könnte ein Angreifer daher möglicherweise interne Daten abrufen oder weitere Ressourcen ansprechen.
Entscheidend ist, dass die Schwachstellen im Zusammenhang bewertet werden. Eine zu großzügige Rolle allein ist noch kein nachgewiesener Datenabfluss. Erst ein autorisierter technischer Nachweis zeigt, ob der beschriebene Pfad tatsächlich funktioniert. Dieses Beispiel ist kein realer Kundenfall.
Wie läuft ein professioneller AWS-Pentest ab?
1. Scoping und Freigabe
Vor dem Test werden AWS-Konten, Regionen, Ressourcen, Anwendungen und Testmethoden festgelegt. Bei mehreren Konten gehören auch AWS Organizations und die Eigentümer der betroffenen Workloads zur Abstimmung. Die aktuellen AWS-Testregeln und mögliche Drittanbieter-Abhängigkeiten müssen berücksichtigt werden.
2. Bestandsaufnahme und Konfigurationsprüfung
Eine autorisierte Bestandsaufnahme identifiziert relevante Ressourcen, IAM-Beziehungen und Netzwerkpfade. Für Konfigurationsprüfungen werden möglichst lesende, zweckgebundene Berechtigungen eingesetzt. Aktive Prüfungen erhalten separate Freigaben und geeignete Testkonten.
3. Kontrollierte technische Verifikation
Ausgewählte Hypothesen werden nachvollziehbar überprüft: Ist ein Dienst tatsächlich unerlaubt erreichbar? Kann eine Testrolle auf ein nicht vorgesehenes Testobjekt zugreifen? Lassen sich Rechte über einen vereinbarten Pfad erweitern? Produktive Daten und Betriebsstabilität haben Vorrang vor spektakulären Exploits.
4. Bericht und Retest
Ein guter Bericht enthält Management Summary, geprüfte Ressourcen, Einschränkungen, reproduzierbare Nachweise, Risikobewertung und priorisierte Maßnahmen. Nach der Behebung kann ein Retest bestätigen, ob die konkreten Angriffspfade geschlossen wurden.
Was sollten Unternehmen vor dem AWS-Pentest vorbereiten?
- Liste der betroffenen AWS-Konten, Regionen und geschäftskritischen Anwendungen.
- Architekturübersicht mit VPCs, Schnittstellen, Identitäten und relevanten Cross-Account-Beziehungen.
- Geeignete Testrollen und Testdaten statt pauschaler Administratorzugänge.
- Benannte Ansprechpartner, Testfenster, Abbruchkriterien und Regeln für produktive Systeme.
- Schriftliche Autorisierung und dokumentierte Prüfung der aktuellen AWS-Richtlinien.
Wie groß der notwendige Aufwand ist, hängt von Anzahl und Komplexität der Konten, Dienste und Angriffsszenarien ab. Informationen zur allgemeinen Kalkulation finden Sie bei yatesh unter Penetrationstest-Kosten.
Fazit: AWS-Sicherheit endet nicht bei der Cloud-Konfiguration
Ein wirksamer AWS-Pentest betrachtet Identitäten, Anwendungen, Daten und Netzwerkgrenzen gemeinsam. Er zeigt, welche Fehlkonfigurationen tatsächlich ausnutzbar sind, wie weit ein Angreifer gelangen könnte und welche Maßnahmen das Risiko am wirksamsten reduzieren.
Sie möchten die Sicherheit Ihrer AWS-Umgebung prüfen lassen? yatesh unterstützt Unternehmen bei der Eingrenzung des Scopes und der Untersuchung relevanter Cloud-Angriffspfade. Informieren Sie sich über unsere Pentest-Leistungen oder sprechen Sie mit uns über Ihre Anforderungen.
