Kontakt
Telefon & 24/7-Notfall-Hotline+49 2932 465265-0 E-Mailinfo@rootsektor.deMo–Fr 08:00–17:00 Uhr · außerhalb der Geschäftszeiten: 24/7-Notfall-Hotline
Pentest-Angebot anfordern Notfall meldenSecurity Services
Ihre Verantwortung in der Cloud – unabhängig geprüft.
AWS sichert die Infrastruktur, Sie sichern alles, was Sie darauf konfigurieren. Mit unserem AWS Security Review prüfen wir Ihre AWS-Accounts auf zu weitreichende IAM-Berechtigungen, öffentlich erreichbare Daten, offene Netzwerkzugänge und Lücken in der Protokollierung – und liefern Ihnen eine priorisierte Roadmap zur Härtung.
Definition
Ein AWS Security Review ist eine unabhängige Sicherheitsüberprüfung Ihrer Umgebung bei Amazon Web Services: Wir nehmen Einstellung für Einstellung unter die Lupe – vom Aufbau der Accounts über Identitäten und Berechtigungen, Datenspeicher und Netzwerke bis zu Verschlüsselung, Protokollierung und Erkennung. Entscheidend ist nicht jede Abweichung für sich, sondern die Frage, welche Einstellungen Ihre Daten und Workloads tatsächlich gefährden. Als Maßstab dienen der CIS AWS Foundations Benchmark, die Security-Säule des AWS Well-Architected Framework und die AWS Foundational Security Best Practices.
Im Mittelpunkt steht das Modell der geteilten Verantwortung: AWS ist für die Sicherheit „der“ Cloud zuständig – Rechenzentren, Hardware und Virtualisierung. Für die Sicherheit „in“ der Cloud sind Sie verantwortlich: wer worauf zugreifen darf, welche Buckets öffentlich sind, welche Ports offen stehen und ob verdächtige Aktivitäten überhaupt protokolliert werden.
Risiken entstehen dabei selten durch eine einzelne Fehlentscheidung, sondern durch Tempo und Wachstum. Teams legen Accounts und Ressourcen per Konsole oder Infrastructure as Code an, Rollen erhalten „vorübergehend“ Vollzugriff, Zugriffsschlüssel bleiben jahrelang gültig. Jede Abweichung ist für sich klein – zusammen ergeben sie Angriffspfade, über die ein einzelner geleakter Schlüssel zur Übernahme ganzer Accounts führen kann.
Der Review schafft Klarheit und Nachweisbarkeit: Er zeigt, wo Ihre Umgebung von bewährten Sicherheitsvorgaben abweicht, und belegt gegenüber Auditoren, Kunden und Versicherern, dass Sie die Anforderungen aus DSGVO (Art. 32), ISO/IEC 27001:2022 oder NIS2 an eine sichere Cloud-Nutzung ernst nehmen. Auf Wunsch prüfen wir auch, ob Ihre Daten wie vorgesehen in EU-Regionen wie Frankfurt verbleiben.
Unser Vorgehen
Für den Review stellen Sie uns eine dedizierte IAM-Rolle mit rein lesenden Rechten bereit, etwa auf Basis der AWS-verwalteten Richtlinien „SecurityAudit“ und „ViewOnlyAccess“. Der Zugriff erfolgt über temporäre Anmeldedaten – dauerhafte Zugriffsschlüssel sind nicht nötig. Nutzen Sie AWS Organizations, beziehen wir alle vereinbarten Mitgliedskonten und Regionen ein.
Zunächst erfassen wir die Konfiguration automatisiert und gleichen sie mit dem CIS AWS Foundations Benchmark und den Empfehlungen von AWS ab. Anschließend bewertet unser Prüfteam die Ergebnisse manuell: Es analysiert IAM-Richtlinien und Vertrauensbeziehungen, sucht nach Wegen zur Rechteausweitung und prüft, welche Ressourcen tatsächlich aus dem Internet erreichbar sind.
Das Ergebnis ist keine Scannerliste, sondern eine bewertete Auswahl: Welche Befunde sind in Ihrem Kontext kritisch, welche Abweichungen sind bewusst akzeptiert, und welche Maßnahmen bringen den größten Sicherheitsgewinn? Setzen Sie Infrastructure as Code ein, berücksichtigen wir das in unseren Empfehlungen – damit Korrekturen dauerhaft in Ihren Terraform- oder CloudFormation-Vorlagen landen und nicht beim nächsten Deployment überschrieben werden.
Typische Schwachstellen
Platzhalter wie „Action: *“ und „Resource: *“, unnötig breite Rollen und fehlende Permissions Boundaries geben Benutzern und Workloads mehr Rechte als nötig. Schon einzelne Berechtigungen wie iam:CreatePolicyVersion oder iam:AttachRolePolicy können für eine Rechteausweitung bis zum Administrator genügen.
IAM-Benutzer mit statischen Access Keys, die seit Jahren nicht rotiert wurden, landen in Git-Repositories, CI/CD-Variablen oder auf Entwicklerrechnern. Ein einziger geleakter Schlüssel reicht Angreifern als Einstieg.
Root-Benutzer ohne MFA, mit eigenen Zugriffsschlüsseln oder im täglichen Einsatz sind ein erhebliches Risiko. Wer den Root-Benutzer kontrolliert, kontrolliert den gesamten Account.
Bucket-Policies mit „Principal: *“, deaktiviertes Block Public Access oder öffentlich geteilte EBS- und RDS-Snapshots machen Kundendaten, Backups und Quellcode öffentlich abrufbar.
SSH, RDP oder Datenbankports, die für 0.0.0.0/0 freigegeben sind, setzen Instanzen direkt dem Internet aus. Fehlt eine saubere Segmentierung der VPCs, kann sich ein Angreifer nach dem ersten erfolgreichen Zugriff ungehindert ausbreiten.
Erlauben Instanzen noch den älteren Metadatendienst IMDSv1, genügt eine SSRF-Lücke, um temporäre Rollen-Anmeldedaten abzugreifen. Passwörter und API-Schlüssel in Lambda-Umgebungsvariablen, User Data oder Vorlagen statt im Secrets Manager verschärfen das Risiko.
Ohne organisationsweiten CloudTrail über alle Regionen fehlen im Ernstfall wichtige Spuren. Laufen GuardDuty, AWS Config oder Security Hub nur in einzelnen Accounts, entstehen blinde Flecken, in denen verdächtige API-Aufrufe und Änderungen niemandem auffallen.
Produktion, Entwicklung und Logs im selben Account, Workloads im Management-Account, fehlende Service Control Policies und Backups ohne Löschschutz vergrößern den Schaden eines Vorfalls – bis hin zum Totalverlust durch Ransomware.
Mögliche Prüfschwerpunkte
Die folgenden Schwerpunkte sind Varianten nach Bedarf, keine festen Pakete. Im Scoping stimmen wir den Umfang auf Ihre Accounts, Workloads und Ziele ab.
Kompakt
Die wichtigsten Sicherheitsgrundlagen einzelner AWS-Accounts – kompakt geprüft.
Multi-Account
Für Umgebungen mit AWS Organizations, Control Tower oder vielen Workload-Accounts.
Assumed Breach
Für erhöhten Schutzbedarf – der Review wird um aktive Tests aus Sicht eines Angreifers ergänzt.
Ablauf
Planbar und transparent wie alle unsere Security Services – und ohne Eingriff in Ihren laufenden Betrieb.
Wir klären Accounts, Regionen, Workloads und Ziele – etwa die Vorbereitung auf ein Audit, eine Kundenanforderung oder die Härtung nach einer Migration.
Werktags innerhalb von 24 Stunden nach dem Scoping erhalten Sie ein Festpreisangebot für den vereinbarten Umfang – ohne versteckte Kosten.
Sie stellen eine Prüfrolle mit lesenden Rechten bereit. Eine Anleitung für die Einrichtung erhalten Sie von uns.
Automatisierte Erhebung über alle vereinbarten Accounts und Regionen, gefolgt von manueller Bewertung, Angriffspfadanalyse und Abgleich mit den Benchmarks.
Priorisierter Bericht mit Management Summary, betroffenen Ressourcen und konkreten Maßnahmen – auf Wunsch mit gemeinsamer Ergebnisbesprechung.
Nach der Umsetzung prüfen wir die behobenen Befunde kostenlos erneut und stellen Ihnen eine Prüfbescheinigung aus.
Ergebnisbericht
Wir dokumentieren jeden Befund mit betroffenem Account, Region und Ressource, einer Risikobewertung und einer konkreten Handlungsempfehlung. Die Management Summary ordnet die Ergebnisse für Geschäftsführung und IT-Leitung ein; der technische Teil liefert Ihrem Cloud-Team alle Details für die Umsetzung.
Ob ein einzelner Account oder eine gewachsene Organisation mit vielen Workloads: Wir prüfen Ihre AWS-Umgebung und zeigen Ihnen, wo Sie ansetzen sollten.
FAQ
Ihre Frage ist nicht dabei? Rufen Sie uns an: +49 2932 465265-0 oder schreiben Sie an info@rootsektor.de.
Ja. Für eine Reihe freigegebener Dienste – darunter EC2, RDS, Lambda und API Gateway – dürfen Kunden Sicherheitsprüfungen und Penetrationstests ohne vorherige Genehmigung durchführen. Ausgenommen sind unter anderem Denial-of-Service-Tests, für die eigene Regeln gelten. Für einen rein lesenden Konfigurationsreview spielen diese Regeln ohnehin keine Rolle. Da AWS die Liste und die Regeln gelegentlich anpasst, gleichen wir aktive Tests vorab mit der jeweils gültigen Fassung ab.
Ausschließlich lesende Rechte. In der Regel genügt eine IAM-Rolle mit den AWS-verwalteten Richtlinien „SecurityAudit“ und „ViewOnlyAccess“, die wir über temporäre Anmeldedaten nutzen. Schreibrechte oder den Root-Benutzer benötigen wir nicht, und auf Inhalte Ihrer Buckets oder Datenbanken greifen wir für den Review nicht zu.
Der Review prüft die Konfiguration Ihrer AWS-Umgebung systematisch und von innen. Ein Cloud-Penetrationstest greift Ihre Anwendungen und Dienste dagegen aktiv an und weist nach, welche Schwachstellen tatsächlich ausnutzbar sind. Beide Verfahren ergänzen sich; welche Kombination für Sie sinnvoll ist, klären wir im Scoping.
Ja. Auf Wunsch beziehen wir Amazon EKS und ECS, Lambda-Funktionen, API Gateway und die zugehörigen IAM-Rollen ein. Bei Kubernetes betrachten wir zusätzlich Cluster-Zugriffe, die Zuordnung von IAM-Rollen zu Pods und die Erreichbarkeit der Cluster-Endpunkte.
Ja, mit unserem Microsoft 365 & Azure Security Review. In Multi-Cloud-Umgebungen stimmen wir beide Prüfungen aufeinander ab, damit Vertrauensbeziehungen zwischen den Plattformen – etwa eine Föderation über Entra ID oder gemeinsam genutzte Identitäten – nicht übersehen werden.
Der Aufwand hängt von der Anzahl der Accounts, Regionen und Workloads ab. Einzelne Accounts lassen sich häufig in wenigen Prüftagen bewerten, große Organisationen benötigen entsprechend mehr Zeit. Den genauen Umfang und Zeitplan legen wir im Festpreisangebot fest.
Cloud-Umgebungen ändern sich mit jedem Deployment. Wir empfehlen einen Review mindestens jährlich sowie nach größeren Änderungen wie Migrationen, neuen Accounts oder Produkt-Launches. Zwischen den Reviews helfen Ihnen AWS Config, Security Hub und GuardDuty bei der laufenden Überwachung – deren Konfiguration bewerten wir im Review ebenfalls.
Wir betrachten Konfigurationsdaten wie Richtlinien, Rollen und Einstellungen, keine Geschäftsdaten. Ergebnisse und Unterlagen behandeln wir streng vertraulich; den Prüfzugang sollten Sie befristen und nach dem Review entfernen. Auf Wunsch unterzeichnen wir vorab eine Vertraulichkeitsvereinbarung.
Nennen Sie uns die Anzahl Ihrer Accounts, die genutzten Regionen und Ihre wichtigsten Workloads. Wir schlagen einen passenden Prüfumfang vor und erstellen Ihnen ein Festpreisangebot.
This page is also available in English.