Oft sind Cloud Migrationen gar keine Migrationen und es gibt vielmals auch noch gar keine klare Cloud-Strategie, geschweige denn eine Cloud-Security-Strategie. Cloud-Projekte entstehen oftmals aus dem Business heraus (Stichwort Shadow IT) und berücksichtigen die Security marginal oder gar nicht. Das erste Cloudprojekt könnte eine SaaS App sein, vom Business getrieben, eventuell eine HR-Applikation oder ein Sales-Tool. IT erfährt von dieser Applikation erst (und nur) weil sie an das bestehende SSO (Single-Sign-On) angebunden werden sollte. Die Security-Abteilung oder der CISO werden die Applikation erst nach der Inbetriebnahme testen können. Dadurch wird ein gefährliches Einfallstor für potenzielle Angreifer geschaffen.

Cloud Native oder 3rd Party Platform Teil 1
Was wir unter Cloud verstehen.

Warum nicht einfach Azure und Co? Sieht doch gut aus!

Wenn es um O365 oder andere Microsoft-Lösungen geht, dann werden doch oft die Security-Optionen von Microsoft Azure mit eingebaut. Dabei gibt es viele gute Optionen, wie z.B. der Azure Conditional Access, den man mit einer Mobile-Device-Management-Lösung (wie z.B. Intune) erweitern kann.

Das ist zwar eine gute Lösung, aber kaum eine Strategie. Wer versucht seine Cloud oder Cloud-Security-Strategie rund um ein Tool oder einen Cloudanbieter zu bauen, der wird sich früher oder später in einer Sackgasse wiederfinden – der Lock-In-Effekt ist vorprogrammiert.


Strategische Partnerschaft: bietet Sicherheit aber keine Flexibilität

Oft wird einer der drei grossen Cloud Provider als strategisch definiert und man baut dann die restliche Cloud-Strategie auf den Services dieses Providers auf. Es gibt verschiedene Gründe, wieso man diesen Cloud-Provider wählt, evtl. ist man bereits mit ihm vertraut oder er bietet aktuell die beste Palette an Services, die das Business braucht oder er hat gewisse Services, die man aktuell nur bei ihm bekommt. Wie gesagt, Gründe gibt es bestimmt genug.

Aber auch mit einer klaren Strategie weiss man nicht wie die Offerings der drei Grossen in 5 Jahren aussehen werden. Und die Rate, mit der neue Services in der Cloud angeboten werden, ist aktuell sehr hoch. 5 Monate genügen oft schon, um die Wettbewerbslandschaft in der Cloud völlig neu aussehen zu lassen, geschweige denn 5 Jahre.


Dem Lock-In entkommen mit Multi-Cloud und Hybrid Cloud

Ein Ausweg aus diesem Dilemma, ist diese Volatilität von Anfang an mit einzuberechnen und die Cloud-Architektur so zu bauen, dass man mit solchen Veränderungen gut umgehen kann. Konkret heisst dass, Multi-Cloud und Hybride Cloud von Anfang an miteinbeziehen. Damit baut man sich nicht in eine Ecke und kann gegebenenfalls den Cloud-Provider wechseln oder zusätzliche Services in einem anderen Cloud Provider hinzufügen.


Cloud-Security-Strategie flexibel aufbauen – so geht’s

Der Aufbau einer flexiblen Cloud-Security-Strategie kann on-premises beginnen. Mit der Containerisierung von Applikationen und dem Einsatz von Kubernetes schafft man eine sehr portable Struktur, mit der man schnell in die Cloud migrieren kann, und dann eben auch von einem Cloud Provider zu einem anderen wechseln, wenn nötig oder erwünscht. Mann kann mit Kubernetes auch hybride Konstrukte bauen, wobei ein Teil der Applikationen oder Services on-premises bleiben und andere Teile in die Cloud migriert werden. Der Treiber hinter solch einem Szenario kann finanzieller Natur sein (flexibel auf gute Angebote bei einem anderen Cloud Provider reagieren), mehr Resilienz bringen (nicht jeder Cloud Provider ist global gleich gut verteilt und in gewissen Ländern  ist man mit A besser bedient als mit B, siehe als Beispiel China).

Man muss aber nicht unbedingt Container einsetzen, hybride Multi-Cloud-Architektur funktioniert auch mit klassischen Ansätzen und dem Einsatz von VPCs (Virtual Private Clouds, AWS, GCP) und VNets (Virtual Networks, Azure).


Wichtige Grundsätze für Management, API und Policies – Continous Compliance

Unabhängig von der Ausprägung gibt es gewisse Grundsätze, die man von Anfang an miteinbeziehen sollte. Wenn es um das Management dieser Multi-Cloud-Umgebungen geht, dann sollte man eine Plattform einsetzen, die Cloud-Provider-übergreifend funktioniert. Das ist durch den Einsatz von API’s sehr gut machbar und bringt eine gewisse Unabhängigkeit vom individuellen Cloud Provider. Dies gilt umso mehr auch für Security, für Visibilität und für die kontinuierliche Compliance (Continuous Compliance). Heisst das also, dass man die Security-Featueres der Cloud Provider links liegen lässt? Nein, überhaupt nicht. Es geht eher um das Managen dieser Features. Eine Plattform konfiguriert die Einstellungen auf den verschiedenen Clouds und gibt einen Gesamtüberblick, z.B. über die Security Policies. Die Policies sollten auf allen Clouds wahrscheinlich gleich (oder sehr ähnlich) aussehen. Solch eine Policy-Unification manuell zu erstellen wäre äusserst zeitaufwendig, komplex und würde früher oder später dazu führen, dass man solch ein Vorhaben entweder aufgibt oder anfängt, solche Abgleiche selber zu automatisieren (mit Skripten und APIs). Oder man setzt eben von Anfang an eine Continuous-Compliance-Plattform ein.

Das Gleiche gilt auch für Netzwerk-, User- und Applikations-Visibilität. Man will ja nicht nur wissen, welche Applikationen und Services innerhalb eines Cloud-Providers miteinander kommunizieren, sondern diese eben auch Cloud-Übergreifend visualisieren können. Eine Hybride Cloud ist ja auch nur eine Multi-Cloud. Anstatt ganz in den Public-Clouds zu sitzen, ist ein Teil eben in einer Private-Cloud angesiedelt. Dementsprechend gilt auch das gleiche Konzept für Hybride Clouds.


Vorschau auf den nächsten Post

So viel mal zum strategischen Aufbau einer Multi-Cloud und Hybrid-Cloud-Umgebung. Im zweiten Teil meiner Post-Serie zu Cloud Security werde ich im Detail auf das Operationalisieren solcher Konstrukte eingehen.


Links

Womit ich mich bei AVANTEC im Cloud Security Bereich beschäftige: www.avantec.ch/themen/cloud-security/