Die heute größte Angriffsfläche is your cloud.
Prüfung von Konfiguration, Identität und Segmentierung in AWS, Azure und GCP. Die meisten Cloud-Vorfälle beginnen nicht mit einem Fehler des Anbieters, sondern mit einer zu weit gefassten Berechtigung, einer ungewollt exponierten Ressource oder einem vergessenen Geheimnis.
In der Cloud liegt der Fehler selten beim Anbieter
Das Modell der geteilten Verantwortung teilt die Arbeit: Der Anbieter sichert die Infrastruktur, die Konfiguration liegt bei Ihnen. Vorfälle geschehen in Ihrer Hälfte — ein Bucket, der für einen Test bequem geöffnet wurde, eine Rolle, die in der Eile Administrationsrechte bekam, ein Netz ohne Segmentierung, weil der Termin drückte. Nichts davon erscheint in einem Scan als Schwachstelle; es erscheint als Konfigurationsentscheidung, die niemand erneut geprüft hat.
- Eine vorübergehend erteilte Berechtigung wird fast nie zurückgenommen.
- Eine außerhalb des Standardprozesses erstellte Ressource erbt die Schutzmaßnahmen dieses Prozesses nicht.
- Geheimnisse in Umgebungsvariablen und Repositorien bleiben der kürzeste Weg hinein.
- Ohne Segmentierung erreicht ein einziges Standbein Konten und Umgebungen, die getrennt sein sollten.
What's included
Der folgende Umfang ist der Standard für ein typisches Engagement. Alles lässt sich im Scoping anpassen, kostenfrei.
- Weit gefasste Richtlinien und Platzhalter in Aktionen und Ressourcen
- Annehmbare Rollen und Ketten zur Rechteausweitung
- Langlebige Zugriffsschlüssel und Rotation
- Föderation, Identitätsanbieter und Sitzungen
- Dienstkonten und Berechtigungen von Workloads
- Trennung von Administration und Betrieb
- Öffentliche Exposition von Objekten und Containern
- Verschlüsselung im Ruhezustand und Schlüsselverwaltung
- Zugriffsrichtlinien und kontenübergreifende Freigaben
- Versionierung, Aufbewahrung und Löschschutz
- Sicherungen und Wiederherstellungstests
- Sensible Daten außerhalb des vorgesehenen Speichers
- Eingangsregeln, die zum gesamten Internet offen sind
- Segmentierung zwischen Umgebungen und Konten
- Lastverteiler, Gateways und Datenverkehrsterminierung
- Von außen erreichbare Verwaltungsdienste
- Private Anbindung und Netz-Peering
- Container- und Orchestrierungsfläche
- Aktive Prüfspur in allen Regionen
- Aufbewahrung und Schutz der Protokolle selbst
- Abdeckung der Ereignisse der Steuerungsebene
- Alarm bei sensiblen Berechtigungsänderungen
- Zentralisierung in einem separaten Konto
- Anbindung an die bestehende Überwachung
- IAM, Rollen, Richtlinien und Identitätsföderation
- VPC, Sicherheitsgruppen, NACL, Peering und öffentliche Exposition
- S3, RDS, DynamoDB, Blob Storage und Cloud Storage
- EC2, Lambda, ECS, EKS, AKS und GKE
- CloudTrail, AWS Config, Microsoft Sentinel und Security Command Center
- Identitätsanbieter und föderiertes SSO
Modalities
adjustable to scopeKonfigurationsprüfung
Systematische Durchsicht der Umgebung aus einer Prüfrolle: Identität, Netz, Speicher, Protokollierung und Datenschutz, abgeglichen mit der Dokumentation des Anbieters und mit öffentlichen Referenzen.
Pfadprüfung
Statt Konfiguration aufzulisten, starten wir von einer plausiblen Position — Anwendungszugangsdaten, kompromittierter Container, gewöhnlicher Nutzer — und ermitteln, wie weit sie in der Umgebung reicht.
Laufende Prüfung und Infrastruktur als Code
Analyse der Vorlagen und Module, aus denen die Umgebung entsteht, ergänzt um einen wiederkehrenden Prüfzyklus. Eine Korrektur an der Quelle verhindert, dass dieselbe Abweichung mit jedem neuen Konto, Projekt oder Rollout zurückkehrt.
Wann eine Cloud-Umgebung geprüft werden sollte
Cloud-Konfiguration ändert sich täglich und durch viele Hände. Manche Momente bündeln das Risiko stärker als andere.
Eine in Eile verschobene Umgebung trägt meist weit gefasste Rechte mit sich, die zur Freigabe der Umstellung erteilt wurden — mit dem Versprechen, sie später zu straffen, das selten eingelöst wird.
Jedes Team legte eines an, jedes Projekt öffnete ein weiteres. Ohne zentralen Standard laufen die Schutzmaßnahmen auseinander und niemand hat den Überblick.
Auffällige Ausgaben sind mal Verschwendung, mal eine Ressource, die jemand erstellt hat, der das gar nicht dürfte. Es lohnt zu wissen, welches von beidem.
Nachweise über Cloud-Kontrollen sind inzwischen fester Bestandteil der meisten Fragebögen. Besser, Sie finden die Lücke vor der prüfenden Stelle.
How we conduct it
[pipeline]Bestandsaufnahme der Umgebung
Wir beginnen mit dem Vorhandenen: Konten, Abonnements, Projekte, aktive Regionen und genutzte Ressourcen. Eine Cloud-Umgebung ist fast immer größer, als die Dokumentation vermuten lässt, und die im Inventar fehlende Ressource ist meist die ungeschützte.
Analyse von Identität und Berechtigungen
Wir kartieren, wer was tun kann, einschließlich dessen, was über Vererbung und Rollenannahme möglich ist. Nicht die geschriebene Richtlinie zählt, sondern die effektive Berechtigung — und die fällt meist deutlich weiter aus, als die vergebende Stelle annimmt.
Konfigurationsprüfung
Speicher, Netz, Verschlüsselung, Protokollierung, Sicherungen und verwaltete Dienste werden mit der Anbieterdokumentation und öffentlichen Referenzen für sichere Konfiguration abgeglichen; jede Abweichung wird notiert, samt Begründung, warum sie in dieser Umgebung zählt.
Reichweitenprüfung
Wir simulieren realistische Ausgangspositionen und messen deren Reichweite: Was liest eine Anwendungsberechtigung, was erreicht ein kompromittierter Container, ist der Übergang von einer Umgebung in eine andere möglich. Das unterscheidet eine Liste von Abweichungen von einem nachgewiesenen Risiko.
Bewertung von Protokoll und Alarm
Wir prüfen, ob die ausgeführten Handlungen Spuren hinterlassen haben, ob diese Spuren gegen Löschen geschützt sind und ob sensible Berechtigungsänderungen einen Alarm auslösen. Eine Umgebung ohne verlässliche Spur lässt sich nach einem Vorfall nicht untersuchen.
Bericht und Behebungsplan
Abweichungen werden nach Ursache gruppiert, nicht nach Ressource: Zehn Punkte aus derselben Richtlinie sind eine Korrektur, nicht zehn. Jede Gruppe erhält anwendbare Hinweise und einen Vorschlag, wie die Wiederkehr an der Quelle verhindert wird.
Öffentliche Referenzen hinter der Arbeit
Die Prüfung stützt sich auf die Dokumentation der Anbieter selbst und auf offene Konfigurationsreferenzen. Damit ist jeder Punkt unabhängig überprüfbar.
- CIS Benchmarks
- Die Konfigurations-Basislinien für AWS, Azure und GCP liefern eine sachliche, Punkt für Punkt prüfbare Referenz für den Zustand der Umgebung.
- Well-Architected (Sicherheitssäule)
- Die Architekturunterlagen der Anbieter beschreiben deren eigene empfohlene Praxis, was jede Diskussion über die Herkunft einer Empfehlung erübrigt.
- Modell der geteilten Verantwortung
- Es legt klar fest, wo die Verantwortung des Anbieters endet und Ihre beginnt — genau die Grenze, an der die meisten Vorfälle entstehen.
- MITRE ATT&CK for Cloud
- Die cloudspezifische Matrix benennt Techniken zu Identitätsmissbrauch, Persistenz und Datensammlung und dient der Bewertung der Erkennungsabdeckung.
- NIST SP 800-53
- Der Kontrollkatalog ist die Brücke zwischen technischem Befund und der Sprache, die Governance und Revision bereits sprechen.
- Geringstmögliche Rechte
- Keine Norm, sondern das Kriterium der Berechtigungsanalyse: Jede Identität sollte nur das Nötige erreichen, und jede Abweichung braucht eine ausdrückliche Begründung.
- Azure Security Benchmark
- Microsofts eigene Basislinie für Azure, sinnvoll, wenn die Umgebung überwiegend Azure ist und die Prüfung diese Referenz erwartet.
- CSA Cloud Controls Matrix
- Die Matrix der Cloud Security Alliance ordnet die Sicherheitsdomänen der Cloud und verweist auf andere Normen — hilfreich, wenn der Kundenfragebogen lang ist.
- ISO/IEC 27017 und 27018
- Die Normen speziell zur Cloud-Sicherheit und zu personenbezogenen Daten in der Cloud, in Unternehmensverträgen häufig zitiert.
- Zuordnung zu DSGVO und PCI-DSS
- Verarbeitet die Umgebung personenbezogene oder Karteninhaberdaten, wird jeder Befund zusätzlich der entsprechenden Anforderung zugeordnet und dient so unmittelbar als Nachweis.
Deliverables
dual view · NDAInventar des Vorhandenen
Die tatsächliche Liste von Konten, Projekten, Regionen und aktiven Ressourcen. Für viele Teams ist das die erste nützliche Lieferung, weil sie Umgebungen zutage fördert, an die sich niemand erinnerte.
Karte der effektiven Berechtigungen
Wer in der Praxis was erreicht, einschließlich indirekter Wege über Vererbung und Rollenannahme. Das überrascht meist mehr als die Konfigurationsliste.
Nach Ursache gruppierte Abweichungen
Die Befunde nach gemeinsamer Ursache geordnet, jeweils mit öffentlicher Referenz. Die Ursache zu beheben schließt mehrere Punkte auf einmal und verhindert die Wiederkehr.
Nachgewiesene Pfade
Für die wichtigsten Risiken der konkrete Weg: wo er beginnt, was er erreicht und warum das zählt. Das macht aus einer Konfigurationsabweichung ein verständliches Risiko.
Bewertung von Spur und Erkennung
Was von den ausgeführten Handlungen aufgezeichnet wurde, was abgeschaltet war und welche sensiblen Änderungen heute unbemerkt blieben.
Priorisierter Behebungsplan
Eine Arbeitsreihenfolge, die Risiko und Aufwand abwägt und trennt, was sich in der Konfiguration lösen lässt, von dem, was in der Infrastruktur als Code geändert werden muss, damit es nicht zurückkehrt.
Frequently asked
Nein. Die Prüfung läuft über ein Prüfprofil mit reinem Lesezugriff, das alle drei Anbieter nativ bereitstellen. Für die Reichweitenprüfung vereinbaren wir gesondert spezifische, begrenzte Zugangsdaten mit schriftlich festgelegtem Umfang und Zeitraum.
Es ergänzt sie, statt sie zu ersetzen. Posture-Werkzeuge decken Menge ab und verfolgen Abweichungen fortlaufend, was wertvoll ist. Was sie nicht leisten, ist das Verketten von Berechtigungen, um zu zeigen, dass Anwendungszugangsdaten Daten erreichen, die isoliert sein sollten — und genau dieser Nachweis verändert Prioritäten.
Ja. Gemischte Umgebungen sind der Normalfall, und der Vergleich zwischen Anbietern legt oft ungleichen Schutz offen: derselbe Ressourcentyp beim einen abgesichert, beim anderen exponiert, weil verschiedene Teams ihn aufgebaut haben.
Die Orchestrierung gehört zum Umfang: Rollen und Zuweisungen, Sicherheitskontext der Container, Netzrichtlinien zwischen Diensten, Exposition der Steuerungsebene, Verwaltung von Geheimnissen und die Verbindung zwischen Cluster-Identität und Cloud-Identität — ein häufiger Weg zur Rechteausweitung.
Mindestens die Umgebung, die die Produktion bedient. Entwicklungs- und Testkonten lohnen die Aufnahme, wenn sie einen Netz- oder Identitätspfad in die Produktion haben — häufiger als angenommen, und genau dort ist der Schutz meist am lockersten.
Indem an der Quelle korrigiert wird. Entsteht die Umgebung aus Infrastruktur als Code, wandert die Korrektur ins Modul und gilt für jeden künftigen Rollout. Der Bericht gibt für jede Gruppe von Abweichungen an, ob sie an der Ressource oder in der erzeugenden Vorlage zu behandeln ist.
Ja. Jeder Punkt trägt die zugehörige öffentliche Referenz und den Nachweis der beobachteten Konfiguration, in einer Form, die eine prüfende Person unabhängig nachvollziehen kann, ohne die Analyse zu wiederholen.