Microsoft hat eine neue Threat Matrix für Cloud-Webanwendungen veröffentlicht. Sie ordnet Angriffstechniken auf Web Apps und serverlose Plattformen in MITRE-ATT&CK-Taktiken ein und zeigt, wo Verteidiger Sichtbarkeit, Härtung und Reaktion zusammenführen sollten. Für kleinere Unternehmen zählt das jetzt, weil viele Fachanwendungen heute in Azure App Service, Functions, SaaS-Integrationen oder ähnlichen verwalteten Umgebungen laufen, während Identitäten, Deployment-Pipelines und verbundene Datenquellen oft getrennt betrachtet werden.
Was Microsoft veröffentlicht hat
Microsoft beschreibt Cloud-Webanwendungen als Anwendungen, die Code in einer verwalteten Umgebung ausführen, eng mit Cloud-Ressourcen verbunden sind und häufig direkt aus dem Internet erreichbar sind. Die Matrix überträgt diese Umgebung in bekannte Angriffstaktiken: von Resource Development und Initial Access über Execution, Persistence, Privilege Escalation, Credential Access, Discovery und Lateral Movement bis Collection und Impact. Der praktische Wert liegt nicht in einer neuen Produktfunktion, sondern in einer gemeinsamen Prüfliste für Betrieb, Entwicklung und Sicherheit. Sie hilft, technische Einzelbefunde in eine nachvollziehbare Angriffskette einzuordnen.
Wichtig ist dabei die Perspektive auf verwaltete Dienste. Microsoft nennt Beispiele wie Azure App Service, serverlose Funktionen, Container-Registries, Deployment-Slots, Site Extensions, Speicher, Datenbanken und Identity-Endpunkte. Genau dort entstehen Übergänge, die in klassischen Webserver-Prüfungen leicht untergehen: Wer darf deployen, welche Identität läuft im Hintergrund, welche Secrets liegen in Variablen, und welche Datenquellen sind aus dem App-Kontext erreichbar?
Warum das KMU betrifft
Auch Unternehmen mit 10 bis 250 Arbeitsplätzen betreiben heute Webportale, Automatisierungen, Kundenformulare, Schnittstellen oder interne Apps. Die Technik ist oft schlank aufgebaut, aber die Berechtigungen dahinter sind es nicht immer. Ein kompromittierter Web-App-Kontext kann laut Microsoft auf Datenbanken, Speicher, Deployment-Zugänge, Workload-Identitäten oder angeschlossene Dienste zugreifen.
- Eine gelöschte Cloud-App mit verbleibendem DNS-Eintrag kann Subdomain-Takeover-Risiken erzeugen.
- Deployment-Zugangsdaten können je nach Konfiguration Zugriff auf Dateien, SCM-Schnittstellen oder Befehlsausführung eröffnen.
- Workload-Identitäten und Umgebungsvariablen können Zugriff auf weitere Cloud-Ressourcen ermöglichen.
- Zu ausführliche Logs können Zugangsdaten, personenbezogene Daten oder technische Details preisgeben.
Frist und Dringlichkeit
Microsoft nennt für die Matrix kein Abschaltdatum und keine feste Umstellungsfrist. Die Dringlichkeit entsteht deshalb aus der laufenden Angriffsfläche: Internetexponierte Anwendungen, automatische Deployments und verbundene Cloud-Ressourcen ändern sich schnell. Wer die Matrix nutzt, sollte daraus keine einmalige Audit-Übung machen, sondern eine kurzfristige Bestandsaufnahme ableiten und danach regelmäßige Kontrollen festlegen. Für ReByteIT passt das in ein Microsoft Security Assessment, ohne daraus Lizenz- oder Compliance-Beratung zu machen.
Worauf die Matrix den Blick lenkt
Der wichtigste Punkt ist die Verbindung mehrerer Ebenen. Microsoft warnt davor, Anwendung und Cloud-Plattform getrennt zu untersuchen. Ein Angriff kann im Quellcode beginnen, über eine Pipeline produktiv werden, eine verwaltete Identität nutzen und anschließend Daten in angebundenen Ressourcen sammeln. Sichtbarkeit muss daher über App-Verhalten, Identitäten, Ressourcen, Repositories und Logs reichen.
Microsoft Defender und Defender XDR können solche Untersuchungen unterstützen, wenn E-Mail-, Endpunkt-, Identitäts-, SaaS- und Cloud-Signale sauber angebunden sind. Microsoft nennt außerdem Defender for Cloud als Baustein für Cloud Resource Posture und Workload-Aktivität. Entscheidend bleibt aber die Konfiguration: Ohne zentrale Logs, Least Privilege und geschützte Deployments bleibt auch ein gutes Werkzeug blind.
Für die Praxis heißt das: Nicht nur die Anwendung selbst ist Prüfgegenstand, sondern auch das, was sie verändern, lesen oder automatisch auslösen kann. Eine scheinbar kleine Function mit Schreibrecht auf Speicher, eine alte Deployment-Credential oder ein nicht entfernter Preview-Slot kann ausreichen, um aus einem Einzelvorfall einen Cloud-Vorfall zu machen. Besonders wichtig ist die gemeinsame Auswertung durch Betrieb und Sicherheitsverantwortliche, damit technische Findings nicht zwischen Anwendung, Plattform und Identität verloren gehen.
Was Unternehmen jetzt prüfen sollten
Aus der Matrix lassen sich konkrete, überschaubare Prüfschritte ableiten. Sie beginnen nicht mit einem großen Projekt, sondern mit den Anwendungen, die öffentlich erreichbar sind oder besonders viele Berechtigungen besitzen.
- Öffentliche App-Endpunkte, Admin-Oberflächen, Kudu-/SCM-Zugänge und alte DNS-Einträge inventarisieren.
- Repository-, Registry- und Pipeline-Rechte auf Least Privilege und getrennte Freigaben prüfen.
- Secrets aus Code, Konfiguration und Logs entfernen und Workload-Identitäten eng begrenzen.
- Sicherheitsrelevante Logs zentral schützen und Änderungen an Logging-Konfigurationen überwachen.
- Quotas, Kostenwarnungen, Backups und Wiederherstellungstests gegen Datenzerstörung und Denial-of-Wallet prüfen.
Offizielle Microsoft-Quellen
- Microsoft Security Blog: Threat matrix: Mapping threats across cloud web applications
- Microsoft Threat Matrix for Cloud Web Applications
Wenn Sie Cloud-Webanwendungen, Identitäten und verbundene Microsoft-365-Dienste gemeinsam betrachten möchten, prüfen wir die wichtigsten Signale, Berechtigungen und Härtungsmaßnahmen im Rahmen eines Microsoft Security Assessments – sprechen Sie uns an.
Was bedeutet das für Ihre Umgebung?
Ordnen Sie das Thema im Kontext Ihrer Microsoft-365-Umgebung ein und legen Sie einen sinnvollen nächsten Schritt fest.
Sie sprechen direkt mit Sebastian Kerssen – seit 2014 im Microsoft-Umfeld, mit persönlicher Beratung und direktem Ansprechpartner.
