Verschiedene Modelle – verschiedene GefahrenSo ist die Cloud wirklich sicher

Unternehmen benötigen aktuelle Ansätze, um eine optimale Sicherheit ihrer Cloud-Lösungen zu gewährleisten. Dabei besitzen verschiedene Cloud-Modelle unterschiedliche Risiken und erfordern deswegen auch andere Security-Maßnahmen.

Laut einer aktuellen Studie des Cyentia-Instituts weisen Unternehmen, die vier verschiedene Cloud-Anbieter nutzen, nur ein Viertel der Sicherheitsrisiken auf – im Vergleich zur Einbindung nur eines Providers. Mit acht verschiedenen Clouds sinkt die Gefahr auf ein Achtel. Dieser Zusammenhang gilt zwar nur bis zu einer bestimmten Anzahl an Providern, weil eine hohe Diversifizierung in der Multi-Cloud wieder zu mehr Risiken führt. Doch grundsätzlich zeigt sich, dass die Nutzung mehrerer Provider das Sicherheitsniveau erhöht.

Trotzdem sollten Unternehmen nicht von einem reinen Automatismus ausgehen, sondern sich die Einsatzszenarien und die Reife der Cloud-Angebote beim Thema Sicherheit sehr genau ansehen. So bergen zum Beispiel verschiedene Cloud-Bereitstellungsmodelle unterschiedliche Risiken:

• Software-as-a-Service (SaaS) umfasst per Cloud bereitgestellte Anwendungen. Beispiele sind Office 365, Dropbox, Gmail, Adobe Creative Cloud, Google G Suite, DocuSign und Shopify. Der Anbieter verwaltet einen Großteil der Infrastruktur. Unternehmenskunden sind nur für Logins und Daten verantwortlich. Zu den größten Gefahren gehören Phishing, Diebstahl von Anmeldedaten und deren Verwendung für andere Dienste. Schutz bieten Lösungen wie Multi-Faktor-Authentifizierung, Abhärtung der Anwendungskonfiguration und Verschlüsselung von Daten im Ruhezustand.
• Platform-as-a-Service (PaaS) stellt eine Plattform für Anwendungen bereit. Beispiele hierfür sind AWS S3-Buckets, Azure SQL-Datenbank, Force.com, OpenShift und Heroku. Der Anbieter verwaltet die Plattform-Infrastruktur. Die Kunden erstellen und betreiben die Anwendungen. Zudem sind sie für Logins und Daten verantwortlich. Zusätzlich zu den SaaS-Gefahren durch Zugriffsattacken muss die Anwendung selbst gegen Angriffe geschützt werden. In diesem Modell sind APIs und Service-Schnittstellen abzusichern. Dies funktioniert über das Rechte-Management für Nutzer und Rollen, sichere API-Gateways, Web App Security, Web Application Firewalls, Bot-Scraper und alle referenzierten SaaS-Kontrollen.
• Infrastructure-as-a-Service (IaaS) dient zum Aufbau virtueller Maschinen, Netzwerke und anderer Computer-Infrastrukturen. Beispiele hierfür sind AWS EC2, Linode, Rackspace, Microsoft Azure und Google Compute Engine. Der Anbieter verwaltet die Infrastruktur unterhalb des Betriebssystems. Der Kunde erstellt und betreibt alles von der Maschine aufwärts. Er ist also für Betriebssysteme, Netzwerk, Server sowie Plattformen und Software verantwortlich. Zusätzlich zu den Bedrohungen für SaaS und PaaS sind vor allem ausgenutzte Software-Schwachstellen in Betriebssystemen und Infrastrukturen sowie Netzwerkangriffe zu beachten. Dies erfordert eine Härtung der virtualisierten Server, Netzwerke und Service-Infrastrukturen. Zudem sind strenges Patching und Systemhärtung sowie Netzwerk-Kontrollen nötig.
• On-Premises bezeichnet den traditionellen Server im Rack, ob im eigenen Rechenzentrum oder in Colocation. Unternehmen sind hier praktisch für alles verantwortlich. Physische Sicherheit, inklusive Stromversorgung und Klimaanlage, ist in der Regel gewährleistet. Zu beachten sind hier Netzwerkkonnektivität und Zuverlässigkeit sowie das Ressourcenmanagement. Neben den oben genannten Gefahren für SaaS, PaaS und IaaS müssen Unternehmen auch Bedrohungen für Netzwerke, physische Standorte und Hardware beachten.

Bei Hybrid Clouds sind diese Sicherheitsmaßnahmen miteinander zu kombinieren und aufeinander abzustimmen. Hier besteht eine zusätzliche Herausforderung darin, die Security-Strategie zu vereinheitlichen. Sonst muss das Unternehmen verschiedene Kontrollen in verschiedenen Modellen und Umgebungen überwachen und konfigurieren, wodurch sich die Komplexität und die Gefahr von Sicherheitslücken erhöhen.

Das strategische Ziel und ein umfassender Security-Ansatz zeigen, wo entsprechende Trainings und Werkzeuge nötig sind. Dabei sollten Unternehmen auch einige Punkte beachten, um die Cloud-Security zu erhöhen. Dabei geht es zuerst um die technischen Fähigkeiten:

• Ausgeprägtes Verständnis der Cloud-Technologie, einschließlich der Einsatzmodelle,
• Know-how über Betriebsarten und Grenzen der damit verbundenen Kontrollen,
• umfassendes Service-Portfolio-Management, inklusive Nachverfolgung von Umgebung, Anwendungen, eingesetzten Plattformen und laufenden IT-Projekten sowie
• die Risikobewertung und Bedrohungsmodellierung, einschließlich möglicher Auswirkungen von Vorfällen und Ausfällen für jeden wichtigen Dienst.

Ein zweiter Aspekt ist im Umfeld der Zugriffskontrollen zu nennen:

• definierte Identitäten und Zugriffe für Nutzer, Dienste, Server und Netzwerke,
• definierte Prozesse zur Korrektur fehlerhafter, veralteter, doppelter oder übermäßiger Nutzer- und Rollenberechtigungen,
• Prozesse zum Festlegen und Ändern von Zugriffskontrollregeln für alle Datenspeicher, Dienste und Anwendungen,
• automatisierte Sperrung des Zugriffs auf alle APIs, Logins, Schnittstellen und Dateiübertragungen bei Bedarf und
• zentralisierte, standardisierte Verwaltung von Verschlüsselung und Authentifizierung.

Aber auch die Transparenz im kompletten Szenario ist wichtig. Sie basiert auf den folgenden Punkten:

• definierte und überwachte Entwicklungs-Pipeline zur Produktion,
• Inventarisierung aller Cloud-Service-Objekte, Datenelemente und Kontrollregeln,
• Erkennung von Konfigurationsänderungen und Überprüfung von Kontrolländerungen sowie
• detaillierte Protokollierung und Erkennung von Anomalien.

Aufgrund der vielschichtigen rechtlichen Vorgaben oder aufgrund von brancheneigenen Vorschriften ist auch die Einhaltung sicherer Standards ein wichtiges Kriterium:

• Nutzung sicherer Standards wie zertifizierte Bibliotheken, Frameworks, Umgebungen und Konfigurationen,
• Audit Remediation und Einsatz von Hybrid Cloud Governance Tools,
• automatisierte Korrektur (oder Löschung) nicht konformer Instanzen und Konten sowie
• die automatisierte Konfiguration neuer Instanzen, einschließlich Abhärtung nach aktuellem Standard.

Roman Borovits ist Senior Systems Engineer bei F5 Networks.

F5 Networks