Cloud Native oder 3rd Party Platform? Teil 2 – Multi-Cloud-Security-Strategie entwickeln

Eine Multi-Cloud-Strategie bringt viele Vorteile und ist durch den Einsatz von 3rd-Party-Plattformen viel einfacher zu managen als eine einzige Cloud-Plattform, die man manuell konfiguriert und betreibt. Dies ist sehr relevant, wenn man bedenkt, dass eines der grössten Risiken in der Cloud die Fehlkonfigurationen sind, vor allem durch die manuelle Konfiguration und das Fehlen von Tools und Automatismen.

„Through 2020, 80% of cloud breaches will be due to customer misconfiguration, mismanaged credentials or insider theft, not cloud provider vulnerabilities.“

Gartner

Solch eine 3rd-Party-Plattform greift über API’s (Programmierschnittstellen) auf die verschiedenen Cloud-Provider zu. Man muss immer noch sicherstellen, dass die VM’s, die Container, die VPCs und die Datenbanken auch alle richtig deployed werden, damit alle Assets die korrekten Tags und Labels haben, damit die richtigen Security-Policies schon bei der Bereitstellung (Deployment) greifen.

Vereinfacht gesagt, müssen wir sicherstellen, dass die Prozesse funktionieren. Und zwar interdisziplinär, von den Entwicklern, über die Infrastruktur, Datenbanken, usw. hin zur Security.

Tönt sehr einfach, ist es aber leider nicht. Das erste Problem ist technischer Natur, denn oft sind z.Bsp. die nativen Security Groups (SG) oder Network Security Groups (NGS) nicht integriert mit der virtualisierten Firewall (NGFW). Das weitaus grössere Problem ist die Integration der Abläufe zwischen den Teams.

Nicht umsonst wird sehr viel über DevOps geschrieben. Oder über SRE’s (Site Reliability Engineering) oder über SecDevOps usw. Das sind alles verschiedene Ansätze um solche Problemstellungen zu lösen oder mindestens den Ablauf zu verbessern. Aber woher kommt diese Komplexität und wieso sollte es in der Cloud anders sein als On-Premises?

Eines der Axiome der Cloud ist, dass alles automatisiert werden soll, was automatisiert werden kann. Konkret können wir uns folgendes Szenario vorstellen:

Die Produktionsumgebung wird 1:1 in der Testumgebung gespiegelt und kann auf verschiedene Cloud Providern (Multicloud) migriert werden. Damit dies auch funktioniert, werden die Umgebungen durch Infrastructure as Code (IaC, Cloudformation, Terraform, etc.) konfiguriert und auch bereitgestellt. Durch den Einsatz von IaC können die Umgebungen umkonfiguriert und getestet werden, bis die Performance stimmt und sonstige Vorgaben erfüllt sind. Die Konfiguration wird auf einem GIT (distributed version-control) abgelegt und ermöglicht auch eine Versionierung. Diese erlaubt auch sehr schnelle und einfache Rollbacks der gesamten Umgebung im Falle eines Incidents oder von Performance-Problemen nach einer Änderung. Idealerweise sollte dies in der Testumgebung abgefangen werden, aber auch wenn die Umgebung 1:1 abgebildet wird, sind gerade Last-Tests nicht einfach und man kann das Verhalten von Produktiven Umgebungen nie zu 100% voraussehen.

Aus verschiedenen Gründen kann es von Interesse sein, einen Teil der Umgebung von einem Cloud Provider zu einem anderen zu migrieren. Durch den automatisierten Ansatz von IaC kann die bestehende Umgebung auf Azure angepasst und für den Einsatz auf AWS getestet werden. Es geht hier nicht nur um die Konfiguration der VNets die zu VPC’s (Virtual Private Clouds) werden, sondern um die Anpassung auf die nativen Elemente des Cloud Providers (Security Groups auf AWS anstatt Network Security Groups auf Azure, usw.) sowie die Anpassung der Tools (z.Bsp. Logging). Die Labels für die VM’s müssen angepasst werden, sonst greifen die SG’s und Policies nicht und schlussendlich muss die Integration mit der restlichen Infrastruktur (in diesem Beispiel auf Azure) getestet und sichergestellt werden.

Mit einem reinen DevOps Ansatz kommt man bereits sehr weit. Vor allem, wenn man selber viel Software entwickelt, ist ein interessanter Ansatz die bestehenden CI/CD Pipelines (Continuous Integration und Continuous Delivery) auch für Security-relevante Themen zu benutzen. CI/CD und DevOps ergänzen sich wunderbar (siehe Illustration) und wenn wir Security auch einbetten können, dann sind wir definitiv schon näher beim SecDevOps Ansatz.

Mit dem Buzzword “Security Shift left” ist eben genau dieses Zusammenbringen von Security und DevOps gemeint.  Als Beispiel: Wenn ein Entwickler einen Build seiner Applikation erstellt, durchläuft der Code zuerst verschiedene Tests (Unit Tests, Integration Tests, Regression Tests, System Tests, usw.) und wenn einer dieser Tests nicht erfolgreich bestanden wird, dann führt das zu einem Fail und der Entwickler muss seinen Code anpassen. Es bietet sich natürlich an, bereits während dieser Phase eben auch Security-Tests durchzuführen und den Build ebenfalls zu “failen”, wenn diese nicht bestanden werden. Das passt in den Arbeitsablauf des Entwicklers und führt zu einer sehr frühen Integration von Security in den Entwicklungsprozess, eben der oben genannte “Shift left”.

Oft definiert man die drei Pfeiler einer erfolgreichen Security-Strategie mit “People, Process und Technology”. Teil 3 dieser Mini-Serie wird sich dann unter anderem auch mit dem Aspekt “People” befassen.

Cloud Native oder 3rd Party Platform? Teil 1 – Cloud-Security-Strategie entwickeln: www.tec-bite.ch/cloud-native-oder-3rd-party-platform-teil-1-cloud-security-strategie-entwickeln/