Good Practises für das Cloud-Management

Von Andreas Heckel, Zürich

Public Clouds sollen Businessprozesse agiler, skalierbarer und schneller machen und dabei helfen, neue Geschäftsmodelle zu erproben sowie Investments in eigene Rechenzentren zu reduzieren. Oft verlagert das Senior-Management heute einen großen Teil der IT-Budgets vom Betrieb in die Digitalisierung von Geschäftsprozessen. Diese Transformation stellt die IT-Abteilung jedoch vor neue Herausforderungen, da sie zum einen den reibungslosen Betrieb während der Transformation sicherstellen muss und „nebenbei“ das Unternehmen digitalisieren soll. Das erfordert zusätzlich noch den Wandel vom „internen Lieferanten“ zum Partner, der mit dem Business auf Augenhöhe diskutiert.

Der Einsatz von Public-Cloud-Services ist aktuell ein zentraler Bestandteil in der Strategie zum digitalen Unternehmen. Viele Diskussionen mit Verantwortlichen erinnern jedoch an die Zeit der Transformation vom Host in Richtung dezentraler Systeme: Auch damals waren Sicherheitsmanager sowie alle im Prozess Beteiligten enorm gefordert bis teilweise überfordert. Es war zwar klar, dass eine Firewall ein wichtiger Baustein ist – Themen wie Hardening, Zugriffskontrolle und Verschlüsselung standen aber oft hinten an, da es an Wissen und Ressourcen fehlte.

Die IT hat zwischenzeitlich ihre Lektionen gelernt und sich dem Thema Sicherheit in interdisziplinären Teams angenommen – idealerweise eingebettet in ein unternehmensweites Governance-, Risk- and Compliance-Management (GRC). Dennoch ist das Thema beim Einsatz von Public Clouds nicht so einfach, da die gemeinsame Verantwortung bei allen Cloud-Anbietern (Shared Responsibility) eine heikle Schnittstelle darstellt: AWS, Azure, GRP, Alibaba und andere stellen Services und Funktionen sowie eine Management-API zur Verfügung – der Kunde muss die Sicherheit implementieren und überwachen sowie bei neuen Bedrohungen und Vorfällen (Incidents) anpassen.

Lagebeurteilung

Sicherheits- und Risikomanager haben die Aufgabe, das Unternehmen vor Cyberangriffen zu schützen, eigene Marken und Ruf zu wahren und so einen Mehrwert für das Unternehmen zu schaffen. Aber woher wissen sie, welche Bedrohungen in der Cloud wirklich bestehen und wie sie Prioritäten setzen und in Echtzeit Abhilfe schaffen können? Die gute Nachricht ist, dass gewonnene Erkenntnisse – vor allem in Form von Standards und Frameworks – weiterhin gültig sind und es viele Leute gibt, die gut ausgebildet sind und bei sinnvoller Automatisierung und Priorisierung ein vergleichbares Sicherheitslevel wie im eigenen Rechenzentrum oder beim Outsourcer erzielen können.

Jedoch muss man fairerweise auch sagen, dass das IT-Management nach der Transformation zu einer oder mehreren Public-Clouds nun nochmals komplexer wird, da die Verantwortlichen auf der Kundenseite aus guten Gründen in unterschiedliche Teams aufgeteilt sind und sich bestehende technische Lösungen nicht eins zu eins einsetzen oder ersetzen lassen.

Wie erwähnt ist bei der Cloud-Migration oder -Erweiterung eine große Zahl an Interessengruppen beteiligt oder verantwortlich – unter anderem Anwendungsteams, DevSecOps, Security-Operations, Identitäts- und Zugriffsmanagement, Compliance-Auditoren, Cloud-Sicherheitsarchitekten, GRC-Teams,
die CISO-Organisation und sogar die Geschäftseinheiten und Geschäftsführung haben viel Interesse daran.

Wenn sich Unternehmen dazu entschließen, ihre bewährte perimetergeschützte Infrastruktursicherheit dem neuen, von allen Cloud-Anbietern gepriesenen Shared-Responsibility-Modell zu überlassen, gibt es unzählige Dinge zu beachten – und verschiedene Teams haben dabei unterschiedliche Vorstellungen, Anforderungen und Checklisten. Angesichts dieser herausfordernden Situation ist es empfehlenswert, sich auf die sechs besonders wichtigen Anforderungen zu konzentrieren, die im Folgenden erörtert werden, und diese einzelnen Verantwortlichen zuzuweisen:

• Sicherheit in der „Infrastructure as Code“ (IaC)
• Cloud-Posture und -Compliance
• Identitätsmanagement
• Auditing und Forensik
• Erkennung von Bedrohungen in Echtzeit
• Reporting

Infrastructure als Code (IaC)

Heutzutage wird die Mehrheit der Cloud-Infrastruktur durch IaC-Vorlagen bereitgestellt – Cloud-Formation Vorlagen (AWS), Terraform (alle Clouds), ARM-Vorlagen (Azure) und so weiter. Daher ist es enorm wichtig sicherzustellen, dass Entwickler oder ihre DevOps-Teams während des Entwicklungslebenszyklus frühes Feedback zu ihren IaC-Vorlagen erhalten – mit Empfehlungen als Code. Denn Entwickler sind keine Sicherheitsexperten und ein frühes und effektives Feedback zu ihrem Code verringert die Kluft zwischen Entwicklern und Sicherheitsteams, sobald die Infrastruktur live geht.

Die zeitige Durchführung dieser Prüfungen hilft Unternehmen, Konfigurationsprobleme an der Quelle zu beheben (IaC-Templates) und präventive Kontrollen zu implementieren, anstatt reaktiv zu sein und Probleme erst zu erkennen, sobald die Infrastruktur bereitgestellt wurde.

Da auch hier Vorbeugen besser ist als Heilen, sollte die Sicherheit in den CI/CD-Prozess integriert werden. Hierzu dienen Lösungen, die sich in GitHub/Gitlab-Repositories integrieren lassen, die im Unternehmen bereits bestehen und dabei helfen, Fehlkonfigurationen in den IaC-Vorlagen zu erkennen und Empfehlungen als Code zurückzuliefern. Als betroffene Interessengruppen sind DevSecOps, Anwendungsteams und Architekten mit einzubeziehen.

Cloud-Posture und -Compliance

Die wichtigste Leitplanke in der Cloud-Sicherheitsstruktur eines Unternehmens ist die Fähigkeit, Fehlkonfigurationen schnell zu erkennen, zu priorisieren und zu beheben. Ein häufiges Problem, das man in der gesamten Branche beobachten kann, ist jedoch eine zunehmende Alarmmüdigkeit: Dies gilt vor allem, wenn sich der Cloud-Bestand eines Unternehmens in der Regel jährlich oder zumindest alle zwei Jahre verdoppelt – und damit logischerweise auch die Anzahl der Alarme in der Cloud-Infrastruktur.

Kontext ist superwichtig

Sicherheitsverantwortliche müssen jederzeit sicherstellen, dass sie in der Lage sind, Bedrohungen anhand der drei „goldenen Faktoren“ Gefährdung, Ausnutzbarkeit und geschäftliche Auswirkungen schnell zu priorisieren. Im Idealfall erhalten sie dazu eine spezifische Sicherheitsbewertung für ihre Cloud-Ressourcen, sodass Probleme mit hohem Risiko und hoher Auswirkung einfach und mittels geübter Prozesse und Strukturen angegangen werden können.

Priorisierung anhand eines validen Kontexts ist dabei enorm wichtig. Ist beispielsweise eine Firewall falsch konfiguriert und lässt den Zugriff aus dem öffentlichen Internet zu, so ist das an sich ein kritischer Alarm für alle SOC-Teams. Bevor man das Thema priorisiert bearbeitet, sind jedoch einige Faktoren zu berücksichtigen:

• Gefährdung: Befindet sich überhaupt etwas hinter der Firewall? Gibt es zum Beispiel einen Server, der dort arbeitet?
• Ausnutzbarkeit: Verfügt der Server über mehr Berechtigungen als erforderlich? Gibt es sensible Berechtigungen (z. B. iam:passrole), die in falschen Händen zu Kontoübernahme-Szenarien führen können?

Dies sind häufige Angriffspunkte in der Cloud.

• Auswirkung auf das Geschäft: Handelt es sich um wesentliche produktive Ressourcen oder vielleicht sogar nur um eine Test-Umgebung?

Dieses Beispiel zeigt exemplarisch, wie der Kontext die Einschätzung einer Fehlkonfiguration verändern und ihr eine höhere oder geringe Priorität einräumen kann. Erst anhand von Kontextdaten können Sicherheitsverantwortliche und Operations-Teams entscheiden, ob es sich wirklich um ein kritisches Problem handelt – oder um etwas, das auf einen späteren Zeitpunkt verschoben werden kann.

Einhalten von Vorschriften

Die Einhaltung einschlägiger Standards in der Cloud ist de jure eine Voraussetzung für deren Einsatz – dementsprechend wichtig ist die Möglichkeit, die eigene Compliance anhand verschiedener Controls zu überprüfen.

Beispielsweise fordert der Zahlungsvekehrs-Standard PCIDSS v3.2 in Control 1.2: „Erstellen Sie Firewall- und Router-Konfigurationen, die Verbindungen einschränken.“ Diese Anforderung entspricht verschiedenen Controls bei Cloud-Anbietern – bei AWS kann (und muss) man beispielsweise die folgenden Richtlinien hierunter abbilden:

• keine Sicherheitsgruppen erlauben den Zugang von 0.0.0.0/0
• in der Standardsicherheitsgruppe sind keine Regeln vorhanden
• keine Netzwerk-ACLs erlauben den Zugang von 0.0.0.0/0 zu allen Ports
• und so weiter

Beheben von Schwachpunkten

Bevor man Schwachpunkte beheben kann, ist naturgemäß ihre Erkennung von entscheidender Bedeutung. Das gilt umso mehr, wenn die Cloud-Infrastruktur stark wächst oder auf mehrere Anbieter verteilt ist, da die unterschiedlichen Anbieter jeweils eigene Administrationsoberflächen (GUIs) haben, die keinem Standard folgen. Das erhöht die Komplexität und Probleme lassen sich womöglich nicht schnell beheben. Dann wächst die Problemliste und schon bald verlieren die Verantwortlichen die Kontrolle und sehen den Wald vor lauter Bäumen nicht mehr.

Die gute Nachricht lautet, dass die meisten Fehler von Cloud-Security- und Anwendungsteams durch effiziente und eingespielte Prozesse korrigiert werden können. Das ist von entscheidender Bedeutung für die Sicherheitslage sowie Reputation eines Unternehmens und hilft dabei, die Arbeitsbelastung von SOC-Teams auf einem überschaubaren Niveau zu halten.

Einige Beispiele, welche die Sicherheit der Cloud-Services erhöhen und das Risiko von Angriffen reduzieren sind die folgenden Abhilfemaßnahmen, die integrierte Systeme auch automatisch ausführen können:

• Verschlüsseln von Speicherbereichen mit AES 256
• Hinzufügen von Tags zu Cloud-Ressourcen, die noch nicht vorhanden sind (z. B. Org, Kostenstelle usw.)
• Firewall-Regeln entfernen, die den Verkehr von 0.0.0.0/0 zulassen

Es ist wichtig, ein Framework beziehungsweise eine Lösung zu wählen, mit der Unternehmen auch eigene Abhilfemaßnahmen erstellen können. Denn jedes Unternehmen ist anders, die Ziele sind unterschiedlich – darum müssen Organisationen die Möglichkeit haben, individuelle Sicherheitsniveaus zu definieren und festzulegen, wie sie auf einen Cloud-Sicherheitsvorfall reagieren wollen.

Der Werkzeugkasten zählt: Es bedarf eines Tools, das hilft, Risiken schnell zu erkennen, einfach zu priorisieren und schnell zu beheben. Darüber hinaus sollte es möglich sein, das mit Cloud-Ressourcen verbundene Risiko zu quantifizieren und eine leicht verständliche Darstellung zu erhalten, wie hoch die Gefährdung, die Ausnutzbarkeit und die geschäftlichen Auswirkungen einer etwaigen Fehlkonfiguration sind. Mit diesen Informationen lassen sich entsprechende Abhilfemaßnahmen priorisieren und effizient durchsetzen – zu den beteiligten Interessengruppen gehören an dieser Stelle DevSecOps, Cloud-Security-Operations, Compliance Auditoren sowie Anwendungsteams.

Identitätsmanagement

In einer typischen Cloud-Umgebung gibt es jede Menge menschliche und nicht-menschliche Identitäten mit zehntausenden von zugehörigen Berechtigungen – all das manuell zu verwalten, wird schnell unmöglich. Zu den größten Herausforderungen im Zusammenhang mit Cloud-Identity-Governance gehören:

• die Möglichkeit, ein einheitliches Inventar aller Identitäten, Benutzer und Rollen zu erhalten,
• ein gemeinsamer Weg zur Anwendung von IAMGovernance über mehrere Cloud-Plattformen hinweg,
• das Zuweisen, Überwachen und Verwalten von Identitätsberechtigungen,
• Audit, Überwachung und Verwaltung von (über-) privilegierten Benutzern,
• die Quantifizierung von IAM-Risiken sowie
• Echtzeit-Einblicke in sensible IAM-Ereignisse.

Die Mehrzahl der Cloud-Sicherheitsverletzungen der letzten Jahre lässt sich darauf zurückführen, dass eine Identität kompromittiert wurde und Angreifer die damit verbundenen Privilegien nutzten, um sich lateral in der Cloud-Infrastruktur zu bewegen. Das Ziel dahinter ist, die wertvollsten Daten zu finden und zu extrahieren.

Eine Lösung zum Cloud-Management sollte daher helfen, die folgenden Fragen zu beantworten – außer für die Cloud-Security-Operations auch für IAM-Architekten und -Administratoren sowie DevSecOps als weitere beteiligte Interessengruppen:

• Welche Identitäten existieren in der Cloud-Infrastruktur des Unternehmens? Wie hoch ist ihr Sicherheitsniveau?
• Wie ist der „Explosionsradius“ einer Identität? Gibt es Identitäten, für die zu viele Ressourcen zur Verfügung stehen?
• Wer sind die privilegierten Benutzer und welche Rechte haben sie? Wann haben sie diese Privilegien zuletzt genutzt?
• Gibt es Identitäten, die gegen bewährte IAMGrundsätze verstoßen?
• Welche sensiblen IAM-Änderungen wurden in der gemanagten Cloud-Infrastruktur kürzlich vorgenommen?

Audit und Forensik

Einer der größten Vorteile des Cloud-Computings ist das Hinzufügen oder Verringern von Ressourcen nach Bedarf. Diese Schnellebigkeit bringt jedoch auch viele Sicherheitsprobleme mit sich: Eine kurzlebige Recheninstanz kann innerhalb weniger Minuten erzeugt, für böswillige Aktivitäten genutzt und dann wieder zerstört werden. Daher ist die Fähigkeit, Cloud-Infrastrukturen zu auditieren, äußerst wichtig.

Eine gute Cloud-Auditing-Lösung muss Administratoren bei folgenden Aufgaben unterstützen:

• Analyse von Identitäten und Nutzern
• Ermittlung durchgeführter Aktionen inklusive der Ressourcen, auf die zugegriffen wurde
• Ursachenanalyse fehlgeschlagener Cloud-Ereignisse
• das „Wer, Was, Wann und Wie“ von Cloud-Ereignissen ergründen

Einblicke in das „Wer“, „Was“ und „Wann“ für alle ressourcenübergreifenden Änderungen zu erhalten und diese auszuwerten, ist Voraussetzung für die Sicherheit in der Cloud. Eine einheitliche Ansicht für die Prüfung und Forensik über mehrere Cloud-Services und -Anbieter hinweg ist sehr wichtig, da die Prüfer dann nicht mehr die
Feinheiten jedes einzelnen Dienstes oder Anbieters verstehen müssen. Zu den Interessengruppen zählen hier Anwendungsteams, DevSecOps sowie Security-Operations.

Bedrohungserkennung

Eine allgemeine Angriffsmethodik umfasst drei Phasen: Erkundung, Identifizierung von Schwachstellen und Erstellen von Exploits. Ein Unternehmen sollte sicherstellen, dass es über Echtzeit-Überwachungsfunktionen zur Erkennung von Aufklärungsaktivitäen und Versuchen zur Erweiterung von Privilegien verfügt, die sich an Frameworks wie Mitre ATT&CK orientieren. Dadurch lässt sich sicherstellen, dass Angriffswege frühzeitig erkannt und womöglich mit automatisierten Abhilfemaßnahmen verknüpft werden können, um das Zeitfenster für die Gefährdung zu verkleinern.

Zunächst einmal können Organisationen auch statische Regeln implementieren, die bei sensiblen Änderungen in der Cloud-Infrastruktur alarmieren – hierzu gibt es viele Open-Source-Lösungen sowie Lösungen der Cloud-Anbieter selbst. Ein Problem bei diesem Ansatz ist jedoch, dass SOC-Teams schnell mit Fehlalarmen überschwemmt werden. Eine Cloud-Sicherheitslösung mit Funktionen zu „User and Entity Behaviour Analytics“ (UEBA) und Anomalieerkennung kann hier für Abhilfe sorgen. Sicherlich wird es auch dabei Fehlalarme geben,
aber im Vergleich zu statischen Regeln ist dies überschaubarer und der gesamte Prozess verbessert sich, da die eingesetzten Machine-Learning-(ML)-Modelle aus Cloud-Daten des Unternehmens lernen.

Wichtig: Funktionen zur Erkennung von Bedrohungen in Echtzeit sind zwingend notwendig! Die meisten Cloud-Sicherheitslösungen arbeiten jedoch auf der Grundlage eines stündlichen Scans, was zu Lücken in der Überwachung führen kann. Angesichts der Kurzlebigkeit von Cloud-Prozessen ist es wesentlich, anormale Ereignisse zeitnah zu erkennen. Im Idealfall können in Echtzeit erkannte Sicherheitsbedrohungen auch mit automatischen Abhilfemaßnahmen, Ticketing-oder Benachrichtigungssystemen verknüpft werden, die auf der Incident-Response-Strategie des jeweiligen Unternehmens basieren. Neben den Cloud-Security-Operations sollte man an dieser Stelle auch die DevSecOps-Abteilung einbinden.

Reporting

Die Effektivität eines Cloud-Sicherheitsprogramms ist nur so gut wie seine Fähigkeit, die Sicherheitslage der Cloud-Infrastruktur eines Unternehmens kontinuierlich zu bewerten und zu melden, Abweichungen von etablierten Baselines und Best Practices zu identifizieren und Einblicke in die Faktoren zu geben, die zu diesen Abweichungen beitragen.

Eine umfassende Berichtsfunktion hilft Sicherheitsverantwortlichen, die Effektivität ihrer Vorkehrungen für die Cloud zu verstehen, hilft Anwendungsteams, den Zustand ihrer Cloud-Anwendungen zu überblicken, und Betriebsteams, Abhilfemaßnahmen für die meisten erkannten Fehlkonfigurationen zu planen.

Genutzte Lösungen sollten unbedingt in der Lage sein, anpassbare einmalige oder vorgeplante, aber auch vordefinierte Berichte oder Zusammenfassungen zu erstellen, die der Geschäftsleitung vorgelegt werden können, um ihr einen Überblick über die allgemeine Sicherheitslage in der Cloud zu geben. Einzubeziehende Interessengruppen sind hierbei Sicherheitsverantwortliche/ CISO, Cloud-Sicherheitsarchitekten, Anwendungsteams sowie auch DevSecOps.

Fazit

Zusammenfassend lässt sich sagen, dass die Vorteile durch den Einsatz von Public-Cloud-Services Unternehmen ein gutes Stück agiler und schneller machen und die Bereitstellung und das Testen neuer Geschäftsmodelle und Services ermöglichen, welche über die Zeit auf- und ausgebaut werden können. Die Themen Sicherheit und Compliance bleiben dabei durchaus beherrschbar.

Hierzu müssen Unternehmen jedoch die beschriebenen sechs Schlüsselanforderungen erfüllen, um jederzeit die Kontrolle über ihre Cloud-Sicherheitslage zu behalten. Für die meisten dieser Anforderungen gibt es heute Lösungen von verschiedenen Herstellern. Der effektivste Weg integriert alle diese Anforderungen in eine einzige Konsole, welche bestehende Sicherheits- und Risikomanagementstrukturen ebenfalls einbinden kann. Denn je weniger Medienbrüche es gibt, desto weniger „Rauschen“ und False Positives sind zu erwarten.

Andreas Heckel ist Managing Partner bei der cybovate AG, Zürich