Saas-Apps und verborgene Sicherheitslücken, die Unternehmen oft übersehen
Hinter der Bequemlichkeit von SaaS-Anwendungen verbirgt sich ein verborgenes Labyrinth von Sicherheitsrisiken, die Ihnen möglicherweise nicht bewusst sind. Während SaaS-Apps zunehmend jede Ecke der Geschäftstätigkeit durchdringen, bringen sie nicht nur leistungsstarke Tools mit sich, sondern auch subtile, oft übersehene Sicherheitslücken. Gartner warnt: „Bis 2025 werden 99 % der Cloud-Sicherheitsvorfälle auf den Kunden zurückzuführen sein.“ Dieser Blog beleuchtet die weniger offensichtlichen, aber hochriskanten Sicherheitsherausforderungen in SaaS-Umgebungen.
Die Statistiken zu SaaS
Der SaaS-Markt in Deutschland weist beeindruckende Wachstumsprognosen von 18,54 % von 2024 bis 2029 auf. Unternehmen setzen weiterhin auf SaaS-Anwendungen, da diese Plattformen flexiblen, abonnementsbasierten Zugang zu wichtigen Geschäftstools ohne die Überkopfkosten einer lokalen Infrastruktur bieten.
Doch auf der Kehrseite dieses Optimismus gibt es zunehmende Sicherheitsbedenken. Ein aktueller Bericht aus dem Jahr 2024 ergab, dass 31 Prozent der Organisationen in den letzten 12 Monaten eine SaaS-Datenpanne erlebten – ein Anstieg um 5 Prozent solcher Vorfälle. Eine weitere interessante Erkenntnis aus einer separaten Umfrage ist, dass 34 % der Befragten zugaben, nicht zu wissen, wie viele SaaS-Apps in ihrem Unternehmen eingesetzt werden.
Verborgene Sicherheitslücken bei SaaS-Anwendungen
Shadow-IT und unautorisierte SaaS-Integrationen
Shadow-IT umfasst die Nutzung von SaaS-Tools durch Mitarbeiter, ohne vorher eine spezifische Genehmigung von der IT-Abteilung einzuholen. Um die Häufigkeit dieses Risikotyps in den Kontext zu setzen, nutzen 67 % der Mitarbeiter in Fortune-1000-Unternehmen nicht genehmigte SaaS-Anwendungen.
Es gibt viele Gründe, warum ein Mitarbeiter eine SaaS-App verwenden könnte, ohne die IT vorher zu fragen. Einer davon ist einfache Bequemlichkeit – zum Beispiel könnte jemand es praktischer finden, Dokumente auf Google Drive hochzuladen, anstatt die genehmigten Dateiübertragungs-Tools des Unternehmens zu verwenden. Manchmal sind sich Mitarbeiter einfach der potenziellen Sicherheitsrisiken nicht bewusst und gehen davon aus, dass frei zugängliche Tools harmlos sind.
Was auch immer die zugrunde liegenden Motivationen sind, die Risiken sind entscheidend, um sie zu identifizieren:
- Ohne IT-Aufsicht könnten Mitarbeiter sensible Informationen (z. B. Kundendaten, proprietäre Dateien) in Drittanbieter-SaaS-Apps speichern, die nicht Ihren Sicherheitsstandards entsprechen. Wenn diese Apps schwache Datenverschlüsselung verwenden oder auf gemeinsam genutzte Infrastruktur angewiesen sind, werden sie anfällig für unbefugten Zugriff oder sogar Datenpannen.
- Nicht autorisierte SaaS-Apps fehlen Überwachungen für verdächtige Anmeldeversuche, Datenexfiltration oder ungewöhnliche Zugriffsmuster. Ohne diese Warnungen kann die IT nicht erkennen, wann böswillige Akteure versuchen, auf sensible Informationen zuzugreifen oder dies bereits getan haben.
- Nicht autorisierte Apps könnten Daten in Regionen speichern, die nicht der DSGVO oder anderen regionalen Datenschutzstandards entsprechen. Dies kann zu versehentlicher Nichteinhaltung führen und Ihr Unternehmen rechtlichen Sanktionen aussetzen.
- Die IT hat keine Möglichkeit, Richtlinien durchzusetzen, wie etwa die Multi-Faktor-Authentifizierung (MFA) auf diesen Plattformen. Da es weiterhin üblich ist, dass Menschen Passwörter wiederverwenden oder schwache Passwörter erstellen, sind diese Konten einem höheren Risiko ausgesetzt.
Potenzielle Lösungen umfassen den Einsatz von Cloud-Access-Security-Brokern (CASBs) und Lösungen für Sicherheitsinformationen und Ereignismanagement (SIEM), um nicht genehmigte Apps im Netzwerk zu erkennen. Regelmäßige Schulungen können zudem die Risiken von Shadow-IT hervorheben, und strikte Richtlinien können die Nutzung nicht autorisierter Apps entmutigen.
Schwächen beim Identitäts- und Zugriffsmanagement (IAM)
Viele SaaS-Apps haben standardmäßige IAM-Einstellungen, die möglicherweise nicht den Sicherheitsanforderungen entsprechen. Wenn Unternehmen SaaS-Apps schnell bereitstellen, um dringende Anforderungen zu erfüllen oder den Bedarf an Remote-Arbeit zu decken, lassen IT-Teams möglicherweise die standardmäßigen IAM-Einstellungen aktiv, um Zeit zu sparen. Manchmal nehmen Unternehmen an, dass die standardmäßigen IAM-Einstellungen der SaaS-Anbieter sicher sind, insbesondere bei bekannten Anbietern.
Allerdings sind diese Standardeinstellungen oft auf Bequemlichkeit statt auf strikte Sicherheit ausgelegt, was versteckte SaaS-Sicherheitsrisiken schafft wie:
- Überprivilegierte Konten, bei denen Benutzer standardmäßig umfangreiche Berechtigungen erhalten und so übermäßigen Zugriff auf sensible Ressourcen erlangen.
- Viele SaaS-Anwendungen stellen Daten und Funktionen über APIs bereit, die häufig durch Benutzerkonten oder Dienstkonten mit spezifischen Berechtigungen authentifiziert werden. Wenn IAM-Richtlinien für den API-Zugriff lax sind, können Angreifer diese Endpunkte ausnutzen, um auf sensible Daten zuzugreifen oder Berechtigungen zu erweitern.
- SaaS-Apps, die keine föderierte Identitätsverwaltung unterstützen, machen es schwierig, zentralisierte Richtlinien durchzusetzen und Benutzeraktivitäten zu verfolgen, insbesondere bei zunehmender SaaS-Nutzung.
Strategien zur Risikominderung umfassen die Nutzung rollenbasierter Zugriffskontrollen, um die minimal notwendigen Berechtigungen basierend auf den Rollen der Benutzer zuzuweisen, MFA für alle SaaS-Apps obligatorisch zu machen und die Verwaltung mit einem Anbieter zu zentralisieren (z. B. Okta, Azure AD), der mit Ihren SaaS-Plattformen integriert ist.
Eingebettete Drittanbieter-Integrationen mit nicht überprüften Berechtigungen
Viele SaaS-Apps integrieren Drittanbieter-Tools, um Funktionalität zu erweitern und Arbeitsabläufe zu optimieren, doch jede Integration bringt potenziell zusätzliche, oft versteckte Berechtigungen mit sich, die unkontrolliert bleiben könnten. Diese Berechtigungen könnten den Zugriff auf sensible Bereiche wie Kontakte, Dateien oder Kommunikation gewähren, ohne volle Transparenz.
Zum Beispiel integrieren HR- und Gehaltsabrechnungsplattformen wie Workday oder ADP oft Finanzsoftware wie QuickBooks oder NetSuite, um Gehaltsabrechnungen und Ausgabennachverfolgung zu optimieren. Diese Integration könnte den Zugriff auf Mitarbeiter-PII und Gehaltsdaten erfordern, die in beiden Systemen gespeichert und für Gehaltsabrechnungsberichte, Rückerstattungen und Prüfungen verwendet werden. Unkontrollierte Datenbewegungen können zu versehentlichen Datenlecks führen, wenn eine Integration Gehaltsdaten unbefugten Parteien offenlegt.
SaaS-Apps fordern oft während der Einrichtung der Integration breiten Zugriff (ähnlich wie viele Apps auf Ihrem Telefon mehrere Berechtigungen anfordern, die Sie möglicherweise nicht für erforderlich halten), da davon ausgegangen wird, dass Benutzer maximale Funktionalität wünschen. Unternehmen überprüfen diese Berechtigungen jedoch selten erneut, was Lücken hinterlässt.
Um dieses SaaS-Sicherheitsrisiko zu reduzieren, machen Sie es zur Routine, die Berechtigungen aller Drittanbieter-Integrationen zu überprüfen und zu prüfen. Konzentrieren Sie sich insbesondere auf Hochrisiko-Apps, die mit sensiblen Daten umgehen. Außerdem sollten Sie Überwachungen für API-Aufrufe und Datenzugriffsprotokolle zwischen SaaS-Anwendungen einrichten.
Tests zur Erkennung von SaaS-Anwendungsrisiken
Diese Quellen von SaaS-Sicherheitsrisiken sind oft heimtückisch und bleiben monatelang unbemerkt. Um sie aufzuspüren, sollten Sie einen externen Penetrationstest-Dienste in Betracht ziehen. In diesen Tests führt ein Team von Sicherheitsexperten umfassende Bewertungen Ihrer IT-Infrastruktur durch und simuliert Angriffe aus der realen Welt, um versteckte SaaS-Sicherheitslücken aufzudecken, die sonst unentdeckt geblieben wären.
DIESEC’s Penetrationstests decken das gesamte Spektrum der Penetrationstesttypen ab. Wir können gezielt Ihre Cloud-Umgebung untersuchen und ihre Sicherheit stärken, indem wir schwer auffindbare Lücken und Schwachstellen in SaaS-Konfigurationen aufdecken.