SaaS Security Posture Management: Was das ist und was zu prüfen ist
SaaS Security Posture Management (SSPM) bezeichnet die Praxis, die Sicherheitskonfiguration jeder von Ihrer Organisation genutzten SaaS-Anwendung fortlaufend zu überprüfen — Freigabestandards, Admin-Einstellungen, OAuth-Berechtigungen und Benutzerzugriffe — statt anzunehmen, dass eine App am Tag ihrer Einrichtung sicher ist und es auch bleibt. Das ist deshalb wichtig, weil die meisten SaaS-Datenexpositionen nicht aus einem Netzwerkeinbruch entstehen, sondern daraus, dass sich eine Einstellung unbemerkt verschiebt.
Dieser Leitfaden behandelt, was SSPM tatsächlich prüft, wie man das manuell App für App macht, und wo dieser manuelle Ansatz an seine Grenzen stößt.
Was prüft SaaS Security Posture Management tatsächlich?
Über die SaaS-Apps hinweg, die ein typisches Unternehmen einsetzt, deckt ein SSPM-Prüfumfang im Allgemeinen Folgendes ab:
- Authentifizierungsanforderungen — ob MFA erzwungen wird und für wen.
- Freigabestandards — ob Dateien, Kanäle oder Datensätze standardmäßig öffentlich, organisationsweit oder privat sind.
- OAuth-App-Berechtigungen — welche Drittanbieter-Apps autorisiert wurden und mit welchen Scopes.
- Admin-Rollen-Wildwuchs — wie viele Personen Super-Admin- oder Owner-Rollen innehaben und ob das mehr ist, als die Organisation benötigt.
- Veraltete oder verwaiste Konten — ehemalige Mitarbeitende oder ungenutzte Dienstkonten, die weiterhin über Zugriff verfügen.
- Gast- und externer Zugriff — welche externen Identitäten auf interne Daten zugreifen können und über welchen Kanal.
Jeder dieser Punkte ist eine reale, überprüfbare Einstellung innerhalb der App selbst, keine abstrakte Idee — SSPM ist die Disziplin, all das über jede verbundene App hinweg nach einem festen Zeitplan zu prüfen, statt einmal hinzuschauen und dann weiterzuziehen.
Wie prüft man SaaS-Sicherheitslage manuell, App für App?
Jede größere SaaS-Plattform stellt ihre eigene Version dieser Informationen bereit, an einem eigenen Ort, in einem eigenen Format:
- Google Workspace: Admin-Konsole → Sicherheit → Sicherheits-Dashboard sowie Sicherheit → Zugriffs- und Datenkontrolle → API-Steuerung für Freigabe- und App-Zugriffseinstellungen.
- Microsoft 365: das Microsoft Entra Admin Center und der Secure Score von Microsoft 365 Defender, der die mandantenweite Konfiguration gegen Microsofts eigene Baseline bewertet.
- Slack: Einstellungen & Verwaltung → Apps verwalten für die Überprüfung installierter Apps sowie die Workspace-Sicherheitseinstellungen für 2FA und Slack-Connect-Steuerungen.
- GitHub: die Übersicht Settings → Security overview einer Organisation für die Durchsetzung der Zwei-Faktor-Authentifizierung sowie Settings → Third-party Access für die OAuth-App-Richtlinie.
Das manuell zu tun bedeutet, jede Konsole nacheinander zu öffnen, dieselbe gedankliche Checkliste anzuwenden — Auth, Freigaben, Apps, Rollen, veraltete Zugriffe, externe Reichweite — und festzuhalten, was man findet, weil keine dieser Konsolen weiß, dass die anderen existieren.
Warum ist es schwierig, manuelle, App-für-App-Prüfungen der Sicherheitslage aufrechtzuerhalten?
Vier Faktoren erschweren speziell einen manuellen Prozess:
- Die Sicherheitslage verändert sich fortlaufend. Jede Freigabe, jeder neue Admin, jede neu autorisierte App verändert das Bild in dem Moment, in dem es passiert. Eine Überprüfung vom letzten Quartal beschreibt einen Arbeitsbereich, der so nicht mehr existiert.
- Nichts wird zwischen Apps vereinheitlicht. „MFA erzwungen" in Google Workspace und „Sicherheitsstandards aktiviert" in Microsoft Entra sind dieselbe zugrunde liegende Kontrolle, nur anders formuliert und konfiguriert — es gibt keine gemeinsame Sprache, bis jemand sie von Hand herstellt.
- Jede Konsole zeigt einen unterschiedlichen Detailgrad. Manche zeigen den Berechtigungsverlauf pro Nutzer, andere nur aggregierte Zahlen. Eine manuelle Überprüfung ist immer nur so vollständig wie die am wenigsten detaillierte Konsole in Ihrem Stack.
- Eine einzelne App kann ihre eigenen Einstellungen über mehrere Bildschirme verteilen. Allein Google Workspace platziert Freigabestandards unter Sicherheit → Freigabeeinstellungen, OAuth-App-Zugriff unter Sicherheit → API-Steuerung und eine mandantenweite Risikozusammenfassung unter Sicherheit → Sicherheits-Dashboard — drei getrennte Bildschirme für eine einzige Anwendung, noch bevor ein zweites SaaS-Tool überhaupt ins Bild kommt.
Worin unterscheidet sich SSPM von einer Compliance-Checkliste oder einem einmaligen Audit?
Ein Compliance-Audit beantwortet die Frage „waren wir am Tag der Prüfung korrekt konfiguriert." SSPM beantwortet die Frage „sind wir gerade jetzt korrekt konfiguriert, und waren wir es vor fünf Minuten" — der Unterschied liegt zwischen einer Momentaufnahme und einem fortlaufenden Zustand. Eine Organisation kann im März ein SOC-2-Audit bestehen und im April einen öffentlichen Freigabelink erstellen, den das Audit nie wieder zu Gesicht bekommt. Posture Management ist die Entscheidung, auch nach Abschluss des Audits weiter hinzuschauen — kein Ersatz für das Audit selbst. Die meisten Organisationen, die es einführen, prüfen die Kernkategorien fortlaufend und gehen die vollständige Checkliste in einem festen Rhythmus durch — wöchentlich für externe Freigaben und OAuth-Berechtigungen, da sich diese ständig ändern, und monatlich für Admin-Rollen und veraltete Konten, die sich langsamer verändern.
Was kann eine manuelle Prüfung pro App nicht leisten, und wie beantwortet 8200.dev das?
Eine manuelle Durchsicht zeigt Ihnen die Einstellungen zum Zeitpunkt Ihrer Betrachtung. Sie sagt Ihnen nicht, welche der Befunde tatsächlich am wichtigsten sind, wie sich das Bild entwickelt, oder erfasst die Einstellung, die sich am Tag nach Abschluss Ihrer Prüfung ändert. 8200.devs Posture Guard zieht dieselben Prüfkategorien — Freigaben, OAuth-Berechtigungen, Admin-Rollen, veraltete Zugriffe, externe Reichweite — aus jeder verbundenen Quelle in eine einzige, normalisierte und fortlaufend neu geprüfte Ansicht und ordnet Befunde nach tatsächlichem Risiko (Sensibilität mal Zugriffsbreite mal Zugriffsebene) statt als flache Liste. Jeder Connector läuft standardmäßig schreibgeschützt: Befunde und Empfehlungen sind der Standardmodus, und jede Änderung an einer verbundenen Quelle erfolgt nur, wenn die Organisation Auto-Remediate für diese spezifische Regel aktiviert und den Schreibzugriff dafür separat gewährt — hier agiert nichts von selbst.
Beginnen Sie mit dem Google-Workspace-Connector oder durchsuchen Sie die vollständige Connector-Liste und erfahren Sie, wie Bewertung und Richtlinienstufen End-to-End funktionieren.
Verwandte Leitfäden
- So sehen Sie, welche KI-Tools Zugriff auf Ihren Google Workspace haben
Der genaue Pfad in der Google Admin-Konsole, um KI-Tools mit OAuth-Zugriff auf Ihren Google Workspace aufzulisten – und was er nicht zeigen kann.
- So auditieren Sie Drittanbieter-OAuth-Apps in Slack, GitHub und Microsoft 365
Die genauen Admin-Bildschirme zur Überprüfung autorisierter OAuth-Apps in Slack, GitHub und Microsoft 365 – und was jede Plattform zeigen kann und was nicht.
- Wie Sie sehen, welche Apps Zugriff auf Ihr Microsoft 365 haben
Der genaue Weg im Microsoft Entra Admin Center, um alle Apps mit Zugriff auf Ihren Microsoft-365-Tenant aufzulisten, und der Unterschied zwischen Admin- und Benutzereinwilligung.