Cloud-Umgebungen prüfen
AWS, Azure, Google Cloud, Kubernetes und die Vorlagen, aus denen sie entstehen. Der häufigste Befund ist eine Rolle, die mehr darf als gedacht.
Konfiguration statt Software
In der Cloud liegen die Befunde selten in einer verwundbaren Version. Sie liegen in einer Berechtigung, die zu weit gefasst ist, in einem Speicher ohne Zugriffsschutz, in einer Regel, die von überall zulässt.
Deshalb prüfen wir mit gültigen Zugängen und aus mehreren Blickwinkeln: von außen, als angemeldeter Benutzer und als kompromittierter Dienst. Erst der dritte Blickwinkel zeigt, wie weit ein Angreifer nach dem ersten Schritt kommt.
Eine Rolle, die über Mandanten hinweg reicht
Drei Mandanten, sauber getrennt, jeder mit eigenen Daten. Dazwischen eine Rolle, die für die Automatisierung angelegt wurde und deren Rechte nie eingeschränkt wurden. Wer sie übernimmt, erreicht den Speicher aller drei.
Solche Rollen entstehen im Aufbau, wenn etwas funktionieren muss und die Einschränkung später nachgezogen werden soll. Sie fallen im Betrieb nicht auf, weil nichts kaputtgeht. In einem Schwachstellenscanner stehen sie auch nicht.
Wir prüfen Berechtigungen deshalb entlang der Frage, was mit einer übernommenen Identität erreichbar wäre. Nicht entlang der Frage, was in der Richtlinie steht.
Konten, Dienste, Container
Der Schwerpunkt hängt davon ab, was Sie betreiben. Bei einer Anwendung in Containern liegt er anders als bei einer Landing Zone mit vielen Konten.
Konten und Berechtigungen
IAM in AWS, Entra ID und Rollen in Azure, Dienstkonten in der Google Cloud. Wer darf was, wer darf Rechte vergeben und welche Identität ist an mehr als einer Stelle gültig.
Dienste und Daten
Speicher und ihre Freigaben, Datenbanken und ihre Verschlüsselung, Netzwerkregeln, Funktionen und Schnittstellen, Schlüsselverwaltung. Dazu die Protokollierung: Was würde ein Angriff hinterlassen.
Container und Vorlagen
Kubernetes mit Rechtevergabe, Netzwerkregeln und Absicherung der Knoten, dazu die Vorlagen aus Terraform oder Bicep. Ein Fehler in der Vorlage verteilt sich auf jede Umgebung, die daraus entsteht.
Wie ein Cloud-Test abläuft
Eine einzelne Anwendung in einem Konto liegt bei fünf Tagen, eine Landing Zone mit mehreren Konten und Umgebungen deutlich darüber.
Umfang und Zugänge
Welche Konten, welche Abonnements, welche Projekte. Wir brauchen Zugänge für die Blickwinkel, die geprüft werden sollen: angemeldeter Benutzer und, wo möglich, eine Identität, die ein kompromittierter Dienst hätte.
Bestand aufnehmen
Konten, Rollen, Richtlinien, Speicher, Netzregeln und die Vorlagen, aus denen sie entstanden sind. Dazu die Protokollierung: Was würde ein Angriff hinterlassen.
Wege verfolgen
Was ist mit einer übernommenen Identität erreichbar und wo endet das. Diese Frage entscheidet, ob ein Vorfall eine Anwendung betrifft oder die ganze Umgebung.
Bericht und Nachtest
Jeder Befund mit dem Aufruf, der ihn zeigt, und einem Weg zur Behebung, der zu Ihrer Umgebung passt. Auf Wunsch die Gegenprobe.
Häufige Fragen zu Cloud-Pentests
Die Prüfung Ihrer Cloud-Umgebung auf Berechtigungen, Konfiguration und Datenzugriffe, mit gültigen Zugängen und aus mehreren Blickwinkeln: von außen, als angemeldeter Benutzer und als kompromittierter Dienst.
Der dritte Blickwinkel ist der wichtige. Er beantwortet, wie weit jemand nach dem ersten Schritt kommt. Genau dort entscheidet sich, ob ein Vorfall eine Anwendung betrifft oder die ganze Umgebung.
In der Cloud liegen die Befunde selten in einer verwundbaren Version. Sie liegen in einer Rolle mit zu weiten Rechten, einem Speicher ohne Zugriffsschutz, einer Netzregel, die von überall zulässt.
Deshalb prüfen wir Berechtigungen entlang der Frage, was mit einer übernommenen Identität erreichbar wäre. Nicht entlang dessen, was in der Richtlinie steht.
AWS, Microsoft Azure und Google Cloud. Bei AWS liegt der Schwerpunkt auf IAM, S3, EC2 mit Security Groups, Lambda und API Gateway, RDS und CloudTrail. Bei Azure auf Entra ID, Storage Accounts, virtuellen Maschinen mit Network Security Groups, Functions, SQL und Cosmos DB sowie Key Vault. Bei Google Cloud auf IAM und Dienstkonten, Storage Buckets und den zugehörigen Diensten.
Für die üblichen Prüfungen an Ihren eigenen Ressourcen ist bei AWS, Azure und Google keine gesonderte Freigabe mehr nötig. Ausgenommen bleiben Tests, die die Plattform selbst belasten, etwa Lastangriffe. Die Abgrenzung halten wir im Auftrag fest.
Der Aufwand richtet sich nach Zahl der Konten, Dienste und Rollen. Eine einzelne Anwendung in einem Konto liegt bei fünf Tagen, eine Landing Zone mit vielen Konten und mehreren Umgebungen deutlich darüber.
Rollen mit mehr Rechten als nötig, oft aus der Aufbauphase. Speicher, dessen Freigabe weiter reicht als gedacht. Netzregeln, die einmal für einen Test geöffnet wurden. Zugangsdaten in Vorlagen und Umgebungsvariablen. Und Protokollierung, die zwar läuft, aber nicht das aufzeichnet, was ein Angriff hinterlassen würde.
Ja. Rechtevergabe im Cluster, Netzwerkregeln zwischen Diensten, Absicherung der Knoten, Umgang mit Geheimnissen und die Frage, was ein übernommener Container erreicht. Dazu die Bilder selbst und ihre Herkunft.
Ja und das lohnt sich. Eine Pipeline hat oft mehr Rechte als jeder Mensch im Unternehmen. Geprüft werden Zugriffe auf das Repository, hinterlegte Geheimnisse, die Rechte des Laufzeitkontos und die Frage, wer eine Änderung auslösen kann.
Dazu die Vorlagen aus Terraform oder Bicep: Ein Fehler dort verteilt sich auf jede Umgebung, die daraus entsteht.
Jeder Befund kommt mit einem Weg zur Behebung, der zu Ihrer Umgebung passt, nicht mit einem Verweis auf eine Herstellerseite. Bei Rückfragen stehen wir zur Verfügung und der Nachtest prüft dieselben Befunde erneut.
Zertifizierungen und Mitgliedschaften.
Sprechen Sie mit uns.
Ein erstes Gespräch dauert in der Regel 30 Minuten. Wir schauen uns Ihre Ausgangslage an und sagen offen, ob wir der passende Partner sind.