Was bedeutet Cloud Access Security Broker?
Ein CASB stellt Sicherheits- und Governance-Kontrollen zwischen Nutzenden und Cloud-Diensten bereit. Je nach Architektur arbeitet er inline im Datenverkehr, über APIs gegen Cloud-Plattformen oder kombiniert beide Verfahren.
Das Problem: SaaS wächst schneller als Governance und Dateninventar
Fachbereiche führen Cloud-Dienste ein, persönliche und geschäftliche Mandanten werden parallel verwendet und sensible Dateien verlassen kontrollierte Ablagen. Eine reine App-Liste zeigt dieses Risiko, liefert aber noch keine sinnvolle Entscheidung.
Zu aggressive Blockierungen verlagern Arbeit in Schattenprozesse. Zu breite Freigaben ignorieren dagegen Uploads, externe Freigaben, OAuth-Verknüpfungen und Datenbewegungen zwischen verwalteten und privaten Instanzen.
Mitarbeitende dürfen einen Cloud-Speicher geschäftlich nutzen, sollen aber keine vertraulichen Dokumente in private Konten hochladen. Dafür müssen App, Tenant, Nutzeraktion, Datenklasse und Ausnahmeprozess gemeinsam erkannt werden.
CASB-Kontrollen nach Sicht und Aktion trennen
Inline- und API-basierte Verfahren beantworten unterschiedliche Fragen.
Discovery
Cloud-App-Nutzung, Risiko, Volumen und Nutzergruppen sichtbar machen.
Inline Control
Anmeldung, Upload, Download, Teilen und weitere Aktionen während der Sitzung steuern.
API Control
Daten, Freigaben und Konfigurationen direkt in angebundenen SaaS-Diensten prüfen.
Tenant Control
Geschäftliche und persönliche Instanzen desselben Dienstes unterscheiden.
Data Security
DLP, Klassifizierung und Kontext mit App-Aktionen verbinden.
Governance
App-Owner, Freigabe, Ausnahme, Review und Incident-Prozess festlegen.
Was muss vor einer Entscheidung geprüft werden?
- Welche SaaS-Dienste und Mandanten werden tatsächlich genutzt?
- Welche Nutzeraktionen erzeugen ein relevantes Risiko?
- Welche Datenklassen müssen erkannt werden?
- Reicht Inline-Sicht oder ist eine API-Anbindung erforderlich?
- Wer bewertet neue Apps und genehmigt Ausnahmen?
- Wie werden False Positives und Geschäftsunterbrechungen behandelt?
Abgrenzung: CASB ersetzt keine SaaS-Konfigurationshärtung, Vertragsprüfung oder vollständige Daten-Governance. API-Zugriffe und unterstützte Aktionen unterscheiden sich je Dienst und Lizenz.
Wie SourcingBlox CASB vom Risiko her einführt
Wir starten mit wenigen priorisierten Apps, Datenklassen und Nutzeraktionen.
SaaS & Risk Discovery
Apps, Mandanten, Datenbewegungen, Owner und Geschäftsbedarf erfassen.
Control Design
Inline-, API-, Tenant- und DLP-Kontrollen pro Use Case entwerfen und testen.
Governance
Onboarding, App-Bewertung, Ausnahmen, Incidents und regelmäßige Reviews etablieren.
Typische Fehler
- CASB nur als Shadow-IT-Liste behandeln.
- Private und geschäftliche Mandanten nicht unterscheiden.
- Alle riskanten Apps pauschal blockieren.
- API-Berechtigungen und Betriebsverantwortung nicht prüfen.
Häufige Fragen
Was ist der Unterschied zwischen Inline- und API-CASB?
Inline-Kontrollen bewerten laufende Sitzungen und Aktionen. API-Kontrollen prüfen unterstützte Daten und Konfigurationen direkt innerhalb angebundener Cloud-Dienste.
Kann CASB persönliche SaaS-Konten unterscheiden?
Je nach Dienst, Datenpfad, Lizenz und unterstützter Tenant-Control-Funktion kann eine Unterscheidung möglich sein. Sie muss technisch getestet werden.
Braucht CASB immer DLP?
Nicht für jede App-Erkennung. Für inhaltsbezogene Entscheidungen ist eine abgestimmte Datenklassifizierung jedoch zentral.
SaaS-Risiken in kontrollierbare Use Cases übersetzen.
Wir verbinden Discovery, Datenklassen, Nutzeraktionen und einen tragfähigen Governance-Prozess.
Verwandte Inhalte
Quellen und weiterführende Informationen
Unterstützte SaaS-Dienste, Aktionen und API-Berechtigungen sind vor Umsetzung aktuell zu verifizieren.