Für native Cloud-Anwendungen, die sich aus verteilten Mikroservices zusammensetzen, greifen klassische Sicherheitskonzepte nur noch bedingt. Denn anders als bei konventioneller On-Premise-Software gibt es für solche Dienste zum Beispiel kein Diesseits oder Jenseits einer schützenden Firewall mehr.
In jeder segmentierten Cloud-Umgebung ist es daher notwendig, wirksame Security-Mechanismen bereits in jedem kleinsten Cloud-Bestandteil selbst zu verankern. IT-Sicherheit ist somit keine separate Herausforderung mehr, die sich gleichsam durch eine nachträglich umgelegte Schutzhülle lösen ließe. Stattdessen muss IT-Security im Cloud-Zeitalter als ein elementares Designkriterium verstanden werden, das sich auf alle Layer und Building-Blocks einer Cloud-Anwendungsarchitektur erstreckt.
Cloud-weites Single Sign-On und permanentes Monitoring
Authentisierung und Authentifizierung – also Identitätsnachweise sowie Mechanismen zu deren Prüfung – erfordern in verteilten Cloud-Szenarien einen anwendungs- und plattformübergreifenden Ansatz. Im Zuge der Weiterentwicklung seiner in Teilen noch On-Premise-basierten Plattform für Unternehmenssoftware hin zu einer komplett nativen Business Cloud implementiert Sage beispielsweise ein eigenes Identitätsmanagement – die Sage ID: Rollen und Zugriffsrechte werden dabei aus dem Azure Active Directory importiert. Da die Sage ID auf der multiproviderfähigen Auth0-Technologie basiert, lassen sich im Bedarfsfall mehrere Identitätsprovider einbinden. Theoretisch könnten sich User künftig also auch mit einer Bank-ID in Buchhaltungs- oder Warenwirtschaftsmodule einloggen.
Neben robustem Zugriffsschutz durch ein plattformweites Identity- und Access-Management zählt das Thema Transparenz zu den tragenden Säulen eines jeden ganzheitlichen Cloud-Security-Konzepts. Denn die große Stärke einer Cloud, nämlich die Verarbeitung dynamisch wechselnder Work-Loads, bringt auf der anderen Seite die Notwendigkeit mit sich, diese oftmals weiträumig verteilten Work-Loads permanent zu überwachen. Folglich müssen Monitoring-Funktionen über alle Anwendungen, Services und Architekturebenen hinweg tief in der Cloud-Infrastruktur integriert sein – was sich zum Beispiel mit den erprobten Tools aus dem Azure Security Center realisieren lässt.
Datensicherheit und Schutz vor DDoS-Attacken
Auf der Ebene der Informationssicherheit und des Datenschutzes ist es empfehlenswert, auf eine durchgängige End-to-End-Verschlüsselung zu setzen. Hierbei sind zwei verschiedene Szenarien für den aus- und eingehenden Datenverkehr in Cloud-Rechenzentren zu unterscheiden: Für die Clientkommunikation mit dem Server via Internet, etwa bei der Nutzung von OneDrive for Business, kommen ausschließlich SSL/TLS-Verbindungen mit 2048-Bit-Verschlüsselung zum Einsatz.
Das zweite Szenario betrifft Datenbewegungen zwischen zwei oder mehreren Rechenzentren, um die Datensicherheit durch Georedundanz zu maximieren. Egal, ob klassische SQL-Server-Transaktion oder BLOB-Deltas für Multi-Target-Anwendungen – Datenströme dieser Art sollten gehärtet durch eine zusätzliche Verschlüsselung und ausschließlich über ein privates Netzwerk transportiert werden. Darüber hinaus garantieren SSL-Zertifikate die Echtheit von Quelle und Ziel des verschlüsselten Datentransfers.
Mosaikartig zusammengesetzte Cloud-Anwendungen, deren Servicebausteine auf ganz verschiedenen, geografisch mitunter weiträumig verteilten Servern laufen, sind in besonderer Weise anfällig für DDoS-Angriffe: Wenn es Cyberkriminellen gelänge, nur einen dieser Server zum Beispiel per IP-Stressing in die Knie zu zwingen, können fehlende Dienste eine komplette Cloud-Anwendung lahmlegen.
Genauso wie das Monitoring sollten daher auch unterschiedliche DDoS-Schutzvorkehrungen schon auf der Ebene der Serviceinfrastruktur implementiert sein. Eine Möglichkeit sind beispielsweise selbstlernende DDoS-Protection-Services für die fortlaufende Überwachung und Untersuchung des gesamten Datenverkehrs. Die zugrundeliegenden Algorithmen decken verdächtige Verkehrsmuster und andere Indikatoren auf, die auf einen möglicherweise bevorstehenden DDoS-Angriff hindeuten.
Exkurs: Authentifizierung auf Service- und Prozessebene
Viele Anwendungen der Sage Business Cloud laufen als Docker Container innerhalb der Azure Kubernetes Services-Umgebung (AKS). Diese Plattform bringt zwei bewährte Architekturansätze für den Einsatz von Mikroservices zusammen, nämlich serverlose Dienste als Function-as-a-Service sowie Container mit zugehöriger Orchestrierung.
AKS ermöglicht die effiziente Verwaltung von Anwendungen auf Containerbasis inklusive aller involvierten Speicher- und Netzwerkkomponenten. Und zwar aus der Perspektive der Work-Loads – also weitgehend unabhängig von der zugrundeliegenden Infrastruktur.
AKS-Dienste basieren generell auf unabhängigen Prozessen, die via APIs mit einem sogenannten ETCD-Cluster kommunizieren. Zur API-Authentifizierung können solche Cluster wahlweise LDAP-Server, digitale Zertifikate, statische Token oder das Auth0-Protokoll OpenID-Connect (OICD) verwenden. Darüber hinaus bietet Kubernetes ein integriertes Tool zur rollenbasierten Zugriffskontrolle (RBAC) von API-Servern, womit sich individuelle Schreib- und Leserechte von Pods und darin enthaltenen Containern präzise steuern lassen. An dieser Stelle wird deutlich, inwiefern das Security-by-Design-Prinzip gleichsam als DNA in AKS verankert ist.
Fazit
Die Verlagerung von On-Premise-Work-Loads in die Cloud verlangt ein grundlegend neues Entwicklungsparadigma, das bei der Entwicklung jedes einzelnen Servicebestandteils verteilter Anwendungen IT-Security als Designprinzip zugrunde legt. Außerdem aber muss selbstverständlich auch die physische Plattform gegen Cyberangriffe abgesichert sein. Bei der Beurteilung der Frage, inwieweit dies für eine konkrete Lösung zutrifft, können sich Unternehmen an Zertifikaten wie FISMA, ISO und SOC orientieren.
Oliver Heinrich ist Vice President Product Engineering Central Europe bei Sage.
