viele verschiedene Dienste. Diese sind erst einmal einfach zu nutzen, erfordern jedoch immer auch eine individuelle Sicherheitsbetrachtung. So kann, selbst wenn der Kunde abgeschottete Netze in der Cloud erzeugt hat, ein PaaS- oder SaaS-Dienst diese Vorgabe umgehen, da dieser Dienst ggf. direkt über öffentliche Endpunkte kommuniziert und explizit ein privater Service-Endpunkt definiert werden muss. Ein weiteres Problem sind die notwendigen Berechtigungen und Zugriffsbeschränkungen auf verschiedenen Ebenen. Speziell über die Jahre können so schnell komplexe Berechtigungsstrukturen entstehen, die nur noch schwer zu kontrollieren sind. Weiterhin können auch Dienste technische Rollen bekommen (z. B. Berechtigungen an einer virtuellen Maschine), die, sofern nicht ausreichend limitiert, im Falle eines Angriffs ausgenützt werden können.
Grundsätzlich sind auch die auf der Cloud-Ebene genutzten Lösungen zur Isolation von unterschiedlichen Kunden ein möglicher Schwachpunkt. Logische Fehler in der Programmierung des Hypervisors oder Fehler auf Hardwareebene (z. B. in der CPU oder im Speicher) können die Daten eines Kunden offenlegen. Dieses Problem existiert auch schon in klassischen Virtualisierungslösungen auf der Ebene der Hypervisoren, es wird jedoch durch den faktisch beliebigen Benutzerkreis eines Cloud-Anbieters weiter verstärkt.
Für viele Cloud-Kunden ändert sich zudem etwas im Hinblick auf die Transparenz der Sicherheitsmaßnahmen. Während im klassischen Umfeld oder auch beim Outsourcer meist ein erweitertes Audit-Recht besteht, ist dies bei einem großen Cloud-Anbieter nicht der Fall. Hier muss der Kunde sich allein auf Testate und Zertifikate wie z. B. ISO27001/ISO27017, ISAE3402 oder Ähnliches verlassen. Eine eigene Prüfung, z. B. vor Ort in einem Rechenzentrum des Cloud-Anbieters, ist aufgrund der dort vorliegenden strengen Sicherheitsvorkehrungen und Zugangsbeschränkungen typischerweise nicht möglich. Komplexität der Infrastruktur, verteilt auf verschiedene Standorte und der jeweiligen Cloud-Organisation, vereinfachen diese Prüfung durch die typischen Dienstleister zudem nicht.
Um diesen Bedrohungen zu begegnen, sind eine sorgfältige Planung und klare Strukturen insbesondere beim Identitäts- und Zugriffsmanagement notwendig. Ebenfalls hilfreich sind Systeme zur Erstellung kurzlebiger Zugangsinformationen oder Just-in-Time Access. Durch geeignete Policies, welche die Nutzung von Diensten limitieren (z. B. auf spezifische Regionen) und Sicherheitsvorgaben überprüfen, können Abweichungen von der Sicherheitskonfiguration verhindert bzw. erkannt werden. Die daran angehängte Sicherheitsüberwachung inklusive einer schnellen (automatisierten) Reaktion muss Sicherheitsprobleme zeitnah adressieren. Diese und andere Bausteine bilden so eine sichere Gesamtarchitektur in der Cloud. Hierbei sollte der Kunde immer das Ziel einer kontinuierlichen Sicherheit im Auge haben. Durch sicheres Design, die sichere Implementierung und eine kontinuierliche Überwachung der Sicherheit kann dies auch erreicht werden. Wesentliche Schlüsselelemente sind Automatisierung und agile Prozesse.
Auch wenn der Cloud-Anbieter grundsätzlich Schwachstellen in den unterliegenden Komponenten adressiert, kann es für einzelne, kritische Systeme sinnvoll sein, diese auf besonders abgesicherten, dedizierten Instanzen zu betreiben. Dies bietet insbesondere Schutz gegen Schwachstellen in der Compute Hardware (z. B. CPU).
4.3 Vertrauen in den Cloud Provider
Eine weitere Bedrohung ist der Cloud-Anbieter selbst bzw. die Jurisdiktion, welcher er unterliegt. Dadurch kann ggf. ein Zugriff auf Daten durch staatliche Stellen erfolgen, auch wenn der Kunde diesen nicht unmittelbar unterliegt und der Kunde darüber gegebenenfalls auch nicht unterrichtet wird bzw. werden darf. Ein weiterer möglicher Aspekt ist Wirtschaftsspionage. Auch wenn der Cloud-Anbieter zahlreiche Maßnahmen wie Verschlüsselung oder Ähnliches als Schutzmaßnahmen anbietet, sind diese meist nur eingeschränkt wirksam als Schutz gegen den Cloud-Anbieter selbst. Dies ist einerseits darin begründet, dass der Cloud-Anbieter die Hardware, auf welchen die Datenverarbeitung erfolgt, kontrolliert und anderseits auch das Benutzermanagement, welche alle Zugriffe auf Systeme und Komponenten, inkl. der Key-Management-Systeme, kontrolliert. Dieses Bedrohungsszenario ist insbesondere für Cloud-Kunden, die in einem regulierten/staatlichen Umfeld agieren, problematisch. Es kann aber auch für andere Kunden, die einen Zugriff durch staatliche Stellen aus wirtschaftlichen Gründen unterbinden wollen, relevant sein.
Bei den von Cloud-Anbietern genutzten Komponenten, wie z. B. Key-Management-Systemen, Identity- und Access-Management-Systemen, aber auch Systeme-Management-Systemen, handelt es sich meist um Eigenentwicklungen. Dies gilt oft auch für die eingesetzte Hardware, z. B. Verschlüsselungsmechanismen im Provider-eigenen Storage-Controller. Eine Prüfung der Qualität dieser Komponenten aus IT-Security-Sicht findet daher meist auch nur eingeschränkt statt. Für den Kunden selbst ist dies am Ende eine Blackbox: Er muss dem Cloud-Anbieter letztlich vertrauen.
Die grundsätzliche Bedrohung kann daher technisch nicht abschließend adressiert werden. Auch wenn Ansätze wie homomorphe oder proxy-basierte Verschlüsselung eine Lösung versprechen, sind diese für den breiten und universellen Einsatz zurzeit nicht geeignet. Die vom Cloud Provider angebotenen Verschlüsselungsoptionen, sowohl auf Storage- als auch auf Compute-Ebene, können das Problem abmildern. Durch eine reine Nutzung von IaaS, einer Substitution von Cloud Provider Tools durch eigene Tools sowie einer Verschlüsselung auf Betriebssystemebene, mit eigenem Key-Management-Service, kann ein Zugriff auf das System und dessen Daten weitestmöglich ausgeschlossen werden. Vollständig ist dieser Schutz jedoch nicht, und der Kunde erkauft sich dies in der Regel mit Komfortverlust und höheren Kosten.
Weitere mögliche Ansätze sind hybride Cloud-Modelle, bei welchen besonders schützenswerte Daten weiterhin im eigenen Rechenzentrum vorgehalten werden, wie auch die Nutzung von Instanzen mit Confidential-Compute-Fähigkeiten. Da der Anbieter aber die Hardware und das IAM-System kontrolliert, ist ultimativ kein vollständiger Schutz möglich. Hier zeigt sich einmal mehr, dass eine Analyse, wie in 2.1 aufgeführt, zwingend notwendig ist.
Der integrierte Ansatz bei der Migration in die Cloud: Security by Default
Christian Lechner und Andreas Schindler
1 Einführung
In Zeiten fortschreitender Digitalisierung verlagert sich die Wertschöpfung in Unternehmen weiter in den virtuellen Raum. Damit wird das Thema IT-Sicherheit immer bedeutender. Die Relevanz von IT-Risiken steigt für Unternehmen jeder Größenordnung und unabhängig vom Geschäftsmodell. Unternehmen beschäftigen sich heute mit der Frage, wie Geschäftsprozesse der Zukunft aussehen und sicher sind vor Angriffen, ob von außen oder immer öfter von innen.
Unabhängig vom Projektthema – ob Cloud-Migration oder New Work – muss das Ziel sein, immer die IT-Sicherheit von Beginn an mit zu betrachten. Die Mehrzahl der Unternehmen hat verstanden, dass Cyberangriffe keine Eintagsfliegen sind und jedes Unternehmen treffen. Gerade in Cloud-Projekten nehmen wir in unserer täglichen Arbeit bei Kunden oft Bedenken und Vorbehalte wahr. Ängste aber sind unbegründet, die Cloud ist keine „Böse“.
Was kann passieren, wenn Unternehmen auf eigene Faust entlang eines IT-Sicherheits-Frameworks wie zum Beispiel NIST loslegen? Oft entstehen Flickenteppiche, deren Komplexität kaum noch zu managen ist. Deshalb entwickeln wir mit unseren Kunden eine vollständig integrierte Sicherheitsarchitektur, die dem Leitgedanken „Security by Default“ folgt. Damit sind Unternehmen, die den Schritt in die Cloud gehen, auf der sicheren Seite.
2 Hacks and Attacks: Cloud versus On-Premises
Hacker
