Auf den Punkt: Cloud-ASM erweitert klassisches Attack Surface Management um interne Cloud-Telemetrie und Identitätsbeziehungen, um dynamische, produktübergreifende Cloud-Angriffsflächen kontinuierlich sichtbar zu machen.
Mit dem Umzug in Public-Cloud-Umgebungen verändert sich die Angriffsfläche vieler Unternehmen von einem klar umrissenen Perimeter zu einer sich ständig wandelnden Sammlung aus Diensten, Identitäten, APIs und Konfigurationen. Cloud Attack Surface Management (Cloud-ASM) soll Sicherheitsteams dabei helfen, diese dynamische Umgebung sichtbar und beherrschbar zu machen.
Klassische Security-Tools wurden für statische IT-Umgebungen konzipiert und stoßen an ihre Grenzen, wenn sich Cloud-Ressourcen produkt- und plattformübergreifend laufend ändern. Dave Shackleford von Voodoo Security beschreibt in seinem Beitrag für ComputerWeekly, warum immer mehr Sicherheitsteams deshalb auf Cloud-ASM als Alternative zu älteren Werkzeugen setzen. Die Ansätze erweitern die Prinzipien des klassischen Angriffsflächenmanagements auf Cloud-native Umgebungen und sollen alle exponierten Elemente in SaaS- und IaaS-Landschaften erkennen, überwachen und absichern – unabhängig davon, ob die Exposition beabsichtigt war oder nicht.
Technisch korreliert Cloud-ASM dafür Cloud-Anbieter-APIs, DNS-Einträge, Zugriffsrichtlinien, IP-Bereiche, SaaS-Integrationen und Identitätsbeziehungen, um die gesamte Cloud-Präsenz eines Unternehmens abzubilden. Der zentrale Unterschied zu älteren externen Scannern, die lediglich von außen nach innen blicken: Cloud-ASM verknüpft externe Sichtbarkeit mit interner Cloud-Telemetrie und liefert so ein vollständigeres Bild dessen, was ein Angreifer tatsächlich ausnutzen könnte. Moderne Plattformen setzen dabei auf Automatisierung, graphbasierte Analysen und teils KI-gestützte Anomalieerkennung, um mit wachsenden oder sich verändernden Umgebungen Schritt zu halten.
Als Kernfunktionen leistungsfähiger Cloud-ASM-Plattformen nennt der Beitrag: kontinuierliche Erkennung von Cloud-Assets (öffentliche Endpunkte, APIs, Speicherdienste, VMs, serverlose Funktionen, Identitätsobjekte samt Metadaten); externe Expositionskartierung, also die Sicht eines Angreifers auf offene Ports, durchgesickerte DNS-Einträge, Zertifikatszuordnungen sowie cloud-spezifische Risiken wie öffentliche S3-Buckets oder anonyme IAM-Rollen; Erkennung von Fehlkonfigurationen anhand von Frameworks wie BSI, CIS und NIST oder Anbieter-Best-Practices; Sichtbarkeit von Identitäten und Zugriffsflächen mit Zuordnung von Rollen, Vertrauensbeziehungen und übermäßig freizügigen Richtlinien; Bewusstsein für SaaS- und Drittanbieter-Integrationen über OAuth-Beziehungen, Dienstprinzipale, API-Schlüssel und Cloud-übergreifende Vertrauensgrenzen; sowie Risikopriorisierung nach Ausnutzbarkeit, Auswirkungsradius und geschäftlicher Relevanz.
Zum Unterschied gegenüber traditionellem Attack Surface Management führt Shackleford aus, dass klassische Plattformen sich vor allem auf exponierte öffentliche Ressourcen und externe Perimeter-Elemente wie Domains, Zertifikate, IP-Adressen und internetbasierte Dienste konzentrieren. Sie helfen Sicherheits- und Betriebsteams zu verstehen, auf welche Online-Dienste ein Angreifer potenziell zugreifen könnte. Cloud-ASM geht darüber hinaus, indem es zusätzlich interne Cloud-Telemetrie und Identitätsbeziehungen einbezieht – der Originaltext bricht an dieser Stelle ab, ohne die weiteren Unterschiede im Detail auszuführen.
Für Praktiker in Security-Teams liefert der Beitrag damit eine Orientierung, welche Funktionsbausteine bei der Evaluierung von Cloud-ASM-Lösungen relevant sind: von der Asset-Erkennung über Fehlkonfigurationsprüfungen bis zur Identitäts- und Risikopriorisierung. Wer bereits Frameworks wie CIS oder NIST für Cloud-Härtung einsetzt, kann diese als Referenzpunkt für die Bewertung einer Cloud-ASM-Implementierung nutzen.
Quelle: www.computerweekly.com · Erschienen 7. Mai 2026
Lumi AI News — KI-assistierte Kuratierung gemaess Art. 50 EU AI Act. Paraphrase und Klassifikation durch Lumi News Pipeline v1.8.2.