IT-Onlinemagazin
„Bereits ohne SAP-Systeme ist ein Cloud-Betrieb komplex. Die sichere Konfiguration aller Komponenten ist eine zusätzliche Ebene für die Systemsicherheit. Kann ein Angreifer Schwachstellen in der Konfiguration ausnutzen und Zugriffsrechte auf die Cloud erhalten und ausweiten, dann geraten auch die Systeme dort in Reichweite für den Angreifer“, sagt Thomas Werth, Geschäftsführer werth IT.
In seinem Gastbeitrag erläutert er, wie die Cloud eigentlich funktioniert, welche Rolle Docker, Kubernetes und Container spielen, und wie diese von SAP und Hyperscalern genutzt werden. In einem weiteren Beitrag werden wir erfahren, wie ein Cyberangriff auf die Cloud ablaufen kann.
Ist eine Cloud-Umgebung überhaupt sicher?
Ein SAP-System in der Cloud zu betreiben, etabliert sich vermehrt als valide Option für den SAP-Betrieb. Es klingt alles so schön einfach und sicher soll es ja auch sein. Kann man das blind glauben? Was macht eigentlich Sicherheit in der Cloud aus? Reicht es aus, wenn das System selbst sicher ist?
Mir drängt sich da noch eine weitere Frage auf, um überhaupt etwas zur Sicherheit sagen zu können:
Wie funktioniert eigentlich die Cloud?
DevOps und Cloud gehen für mich Hand in Hand. Ohne DevOps wäre der Betrieb einer Cloud gar nicht möglich. Stark vereinfacht ist DevOps die Transformation der Serverlandschaft in „Software“. Man beschreibt seine Dienste und Server in Konfigurationsdateien und die DevOps Werkzeuge „generieren“ dann die dort beschriebenen Systeme. Schrauben ziehen in einem Rack, Betriebssystem installieren, passende Pakete suchen – all das gehört seit DevOps zur die „alten Zeit“.
Auf dieser Basis ist es möglich in der Cloud hunderte oder sogar zigtausende Systeme zu orchestrieren. Wie genau funktioniert das denn jetzt wieder?
Docker
Nähern wir uns dem Thema mal in einer Vereinfachung ohne zu tiefe Details. Docker hat einen enormen Siegeszug hinter sich. Das nicht ohne Grund. Ist man mit Docker doch in der Lage, quasi einen Dienst zu isolieren. Man braucht einen Webserver? Kein Problem „Nimm einen Docker Container“. Egal ob nginx oder Apache, es gibt vorgefertigte aktuelle Container. Doch auch selbst einen passenden Docker zu erstellen ist nicht viel mehr als eine Konfigurationsdatei zu schreiben. Hier wählt man ein Basis-Image. Gibt Anweisungen zur Erstellung der Web-Server Konfiguration und verweist auf ein Verzeichnis, in dem die Webseiten liegen (idealerweise als mount außerhalb des Dockers). Abgerundet wird die Konfiguration durch ein Init-Skript, das über ENVIROMENT Variablen die individuelle Konfiguration setzt (wie den Domain-Namen).
Software-defined infrastructure
Kurzum mit Docker sind Dienste nicht mehr fest im System verankert, sondern isolierte „Container“-Baukästen, die individuell nach Bedarf zusammengesetzt werden können. Die Kombination aus einem Webserver Container und einem Datenbank Container ersetzt das klassische System, auf dem alles direkt installiert wurde.
Dies ist ein wesentlicher Kern der Idee von Infrastruktur als Code. Es ist von der Idee her so „einfach“: Eine Beschreibung der Komponenten und wann diese „laufen“ sollen sowie den Namen der Maschine und welche Pakete zu installieren sind – fertig. Den Rest erledigen die Werkzeuge und erschaffen die Infrastruktur. Auf Basis der Beschreibung werden die Systeme in der definierten Anzahl erschaffen. Abweichungen (Systemausfälle, Zusätzliche Systeme oder wenige aufgrund der aktuellen Last,…) werden automatisch korrigiert. Firewall-Konfigurationen, Änderungen an IP-Adressen, mehr Speicherplatz – alles auf Knopfdruck. Das ist DevOps, die Magie hinter der Cloud.
Kubernetes und Docker-Container
Terraform ist eines der bekanntesten Werkzeuge für diese Aufgabe und wird von vielen Cloud-Providern wie AWS unterstützt. Es wird eingesetzt, um die „Server“ in der Cloud zu erstellen und zu steuern. Dazu zählen ssh-keys, Firewall-Regeln, „Hardware-Ausstattung“, Anzahl der Systeme und mehr. Es kann auch die Docker-Container auf den Servern installieren. Doch möchte man tausende solcher Container verwalten, ist dieser spezielle Punkt bei Kubernetes besser gelöst als „nur“ Terraform zu nutzen.
Kubernetes ist Spezialist für Docker-Container. Egal ob die laufenden Container durch eine neue Version ersetzt werden sollen oder ein Load-Balancer die Zugriffe verteilen soll oder die Anzahl aufgrund hoher Last verdoppelt werden soll. Das alles macht Kubernetes mit „links“. Um dies zu ermöglichen, bündelt Kubernetes „Server“ in Kubernetes Cluster. Mehrere Container werden für den gemeinsamen Nutzungszweck in „Pods“ als eine Einheit zusammengefasst. Diese Pods leben virtuell auf einem „Node“.
Deployment
Früher war dies das „Blech“ auf dem Server letztlich lief. Mit einem „Deployment“ wird dann beschrieben, wie viele Pods wann und wo laufen sollen und wie die Replikationsstrategie aussehen soll. Bei den Deployments ist das „Update“ ein herausragendes Feature. Man kann live seine Systeme updaten und Kubernetes sorgt dafür, dass während des Updates keine Downtime entsteht und am Ende alle Pods auf der neuen Version sind. Für Load-Balancing lassen sich verschiedene Pods mit demselben Dienst zu „Services“ zusammenfassen.
Bisher spielt die Musik aber nur „in“ dem jeweiligen Kubernetes Cluster, für Zugriff von außen muss noch ein „NodePort“ erstellt werden, damit wird der Dienst dann nach außen geöffnet. Soweit doch schon ein wenig Komplex, trotz unserer sehr hohen Flughöhe. Die Zugriffsberechtigungen der Systeme untereinander werden über Rollen und Policies definiert. Dies variiert je nach Cloud-Anbieter und kommt als weitere Komplexitätsschicht zusätzlich hinzu.
Dies alles ist der Kern hinter der Mammut-Aufgabe, eine Cloud zu betreiben.
Wie funktioniert SAP-Hosting in der Cloud?
Sehen wir uns mal an, wie Amazon das SAP-Hosting umgesetzt hat. In einem Blog-Eintrag wird das SAP-Hosting vorgestellt. Terraform ist dabei ein wesentliches Element zur Erzeugung der Infrastruktur und auch Dev-Ops ist gern gesehen. Es stehen verschiedene Instanzen („virtuelle Hardware“ mit Maßgabe von Speicher und CPU) als Grundgerüst für ein SAP-System zur Auswahl. Individuelle Installations-Dateien sind über S3 Buckets (Key/Value Ablagesystem) verfügbar. Berechtigungen lassen sich über IAM-Rollen für Systeme und Administratoren steuern.
Zusätzliche Werkzeuge wie Cloudwatch (Monitoring) oder auch Backup-Tools sind optional.
Der DevOps-Ansatz „Infrastruktur als Code“ wird über eine AWS API unterstützt und damit lässt sich die SAP-Infrastruktur in der Cloud automatisiert vom Kunden steuern. Für Terraform stellt Amazon sogar eigene Module bereit, die für die Verwendung mit SAP-Systemen (HANA, Netweaver) ausgelegt sind. Diese Module sind sogar in die Terraform Registry integriert und stehen allen Nutzern zur Verfügung.
Grundlegend entspricht dies dem allgemeinen Cloud-Ansatz, nur wird hier komplett auf den Einsatz von Docker und damit auch Kubernetes für den SAP-Anwendungsfall verzichtet. Das ist auch nachvollziehbar, da ein SAP-System nicht in einen Docker-Container passt. Ebenso sind die Vorteile von Kubernetes nicht voll und ganz ausspielbar. Wer hat schon tausende SAP-Systeme oder fährt mal eben ein paar zusätzliche Systeme hoch, weil „zu viele“ User damit arbeiten?
Was bietet SAP zusätzlich?
SAP selbst bietet auch Hosting in der Cloud an und greift dabei auf die etablierten Anbieter wie Amazon, Microsoft und Google zurück. Als Mehrwert bietet SAP nach eigener Darstellung verschiedene Sicherheitsmaßnahmen.
Zugriffsschutz ist auf verschiedenen Ebenen vorhanden. Dennoch sieht man an dem Schaubild, dass SAP-Mitarbeiter als Cloud Administratoren auf jede private Cloud zugreifen können. Das muss natürlich auch sein, da SAP letztlich die Systeme betreibt. Nennen wir es mal wertungsneutral den SAP Master Zugriff.
Zero-Trust-Ansatz bei SAP
Zudem betont SAP seinen Zero-Trust-Ansatz, in dem die unterschiedlichen Schichten keine Vertrauensstellung besitzen.
Dies ist ein sehr lobenswerter Ansatz, da gerade Vertrauensstellungen gerne mal ausgenutzt werden. Man denke nur an Social Engineering oder die RFC-Trust Destinations der SAP-Systeme. Der Boden, auf dem alles steht, ist der externe Cloud-Anbieter. Von Amazon haben wir erfahren, dass Terraform alles für ein SAP-System aus dem Hut zaubern kann. Sogar beliebige Installationsdateien über S3 Buckets und die individuellen Berechtigungen über die IAM Rollen.
Was passiert wohl, wenn jemand sich hier Zugriff verschaffen kann und beliebig Berechtigungen vergeben kann oder Skripte editiert? Was, wenn er die AWS Policies anpasst und somit faktisch die Firewall-Regeln neu schreibt? Wie hoch bleibt der Schutz durch den Zero-Trust für die restlichen Komponenten? Das sieht jedenfalls nach dem ersten Ansatzpunkt für einen Angreifer aus.
SAP nutzt Docker und Kubernetes
Das Schaubild zeigt, dass SAP auch Verwendung für Docker und Kubernetes hat:
Da sind sicher einige Funktionen, die auch aus Security-Sicht nützlich sind. Doch Docker und Kubernetes als Security-Feature darzustellen, ist sportlich. Natürlich nutzt man nicht den Default Namespace und auch keine privilegierten Container. Ein solcher Container kann im Handumdrehen als Root auf das „hostende“ System zugreifen. Doch auch nicht privilegierte Container sind nicht automatisch hoch sicher.
Wesentlich wichtiger ist jedoch der Schutz von Kubernetes. Wird Kubernetes zum Angriffsziel, kann das gesamte Königreich fallen – mit allen SAP-Systemen darin. Auch wenn diese gar nicht von Kubernetes verwaltet werden. Sicherheitsfeatures kannte Kubernetes beim ersten Release gar nicht, nicht einmal Authentifizierung. Das wurde erst zwei Jahre nach dem ersten Release nachgereicht. Das macht ja Hoffnung — die Frage ist nur wem?
Im nächsten Gastbeitrag von Thomas Werth lesen Sie, was bei einem Cyber-Angriff auf die Cloud passiert.
