Wenn Entwickler von Instanzen sprechen, meinen sie Server, wobei eine Instanz einem Server entspricht. Es ist dasselbe wie eine virtuelle Maschine, die in einem firmeninternen Netzwerk läuft, aber ohne dass das Unternehmen Hardware verwalten muss. Auf AWS werden die Instanzen EC2 (Elastic Cloud Compute) genannt, in Azure werden sie als virtuelle Maschinen und in GCP als Compute Engines bezeichnet. Unabhängig davon, wie sie genannt werden, sind dies die Kernkomponenten der meisten Cloud-Umgebungen.

Instanzen haben verschiedene Typen und Größen. Der Instanztyp gibt an, wofür sie bestimmt ist. AWS verwendet (unter anderem) die folgenden Buchstaben

• M = Allzweck
• R = speicherintensiv
• T = Allzweck
• P = Maschinelles Lernen
• C = Performance-optimiert

Im Wesentlichen geben die Buchstaben an, welche Art von Hardware für den Instanztyp verwendet wird.

Die Instanzgröße bezieht sich auf die Anzahl der CPUs und die Größe des Speichers, über die die Instanz verfügt. So kann man beispielsweise eine AWS M5-Instanz wählen und dabei sowohl CPU-Anzahl als auch Speichergröße nahezu frei wählen (detaillierte Informationen dazu unter https://aws.amazon.com/de/ec2/instance-types/). Jeder Instanztyp und jede Größe hat bei der Abrechnung einen anderen Stundensatz, weshalb es wichtig ist, den richtigen Instanztyp zu wählen, der für das jeweilige Vorhaben am günstigsten ist.

In einer Gruppe von Instanzen mit automatischer Skalierung wird die Anzahl der Instanzen auf der Grundlage des aktuellen Bedarfs automatisch erhöht oder verringert. Wenn man zum Beispiel Instanzen nutzt, um eine Website zu hosten, kann man die Anzahl der Instanzen automatisch erhöhen, wenn es viel Verkehr gibt, und sie verringern, wenn der Traffic nachlässt. Mit der automatischen Skalierung ist man nicht nur in der Lage, eine stark schwankende Nachfrage zu unterstützen, sondern man zahlt auch nur für das, was tatsächlich genutzt wird.

Um Software auf einer EC2-Instanz auszuführen, muss ein Amazon Machine Image (AMI) auf diese Instanz geladen werden. AMI ist nur die Bezeichnung von AWS für eine virtuelle Appliance. Eine virtuelle Appliance ist im Wesentlichen ein Software-Bundle, das das Betriebssystem plus jegliche zusätzliche Software enthält, die auf der EC2-Instanz ausgeführt werden soll. AMIs ermöglichen es einer EC2-Instanz, sofort nach ihrer Erstellung betriebsbereit zu sein. In Azure werden AMIs VM-Images genannt, und in GCP werden sie als Boot-Disks bezeichnet.

Als Sicherheitsexperte ist es wichtig, Einblick in diese Images zu haben, da sie die Bausteine der Instanzen sind. Wenn jemand ein AMI mit einem veralteten Betriebssystem verwendet, das Schwachstellen enthält, dann wird jede EC2-Instanz, die dieses AMI verwendet, dieselben Schwachstellen aufweisen.

Daten reisen mit Lichtgeschwindigkeit über Glasfaserkabel, und je größere Entfernungen sie zurücklegen müssen, desto länger dauert es, bis sie ihr Ziel erreichen. Aus diesem Grund bieten die Cloud-Provider Regionen an. Niemand will einen Server an der Ostküste der USA benutzen, der Daten aus Sydney bezieht, weil es eine Latenz gibt. Sogar Millisekunden summieren sich und führen mit der Zeit zu spürbaren Verzögerungen. Bei Regionen kann man daher eine Instanz auswählen, die in der Nähe des Ortes läuft, von dem Daten abrufen werden sollen. Dies hilft auch bei der Einhaltung von Compliance-Vorschriften wie etwa der DSGVO, nach deren Regeln europäische Kundendaten die EU nicht verlassen dürfen. Internationale Unternehmen, die Kunden aus der EU haben, benötigen daher eine europäische Region, um deren Daten spezifisch zu speichern.

Innerhalb jeder Region gibt es Verfügbarkeitszonen, was im Wesentlichen nur ein anderer Begriff für Rechenzentren ist. Wenn AWS also sagt, dass es drei Verfügbarkeitszonen in einer Region hat, bedeutet dies, dass es drei Rechenzentren in der Region betreibt. Dies ist wichtig für die Zuverlässigkeit und Verfügbarkeit, da Daten und Anwendungen über mehrere Verfügbarkeitszonen repliziert werden können. AWS, Azure und GCP bieten dafür Tools, die automatisch erkennen, wenn in einer Zone ein Problem auftritt, und Traffic und Workloads in eine andere Zone verlagern.

Als Sicherheitsexperte ist es wichtig, Regionen und Zonen zu kennen, da sie von Angreifern ausgenutzt werden können. Viele Cloud-Angriffe zielen nämlich gar nicht auf Daten, sondern auf den Diebstahl von Rechenleistung, etwa um auf fremde Rechnung Kryptowährungen zu schürfen. Angreifer "stehlen" Rechenleistung dabei in der Regel aus der Region, die ihnen am nächsten liegt oder in einer Region, die vom Opfer nicht aktiv genutzt wird. Es ist also wichtig, alle Regionen einschließlich der ungenutzten im Auge zu behalten.

Wer AWS verwendet, wird irgendwann mit dem Begriff "S3 Bucket" konfrontiert. Er steht für Simple Storage Service und ist im Wesentlichen Massenspeicher. Das Äquivalent heißt bei Azure Blob-Storage und bei GCP Cloud Storage. Diese Art der Speicherung wird häufig für die Speicherung von Backups und Lagdaten verwendet. Man kann sich einen S3 Bucket als eine industrielle Version von Dropbox vorstellen - auf ihn kann von überall und zu jeder Zeit zugegriffen werden, und jede Art von Datei kann hier gespeichert werden. Aus Security-Sicht ist es wichtig, sicherzustellen, dass auf S3 Buckets die richtigen Privacy-Einstellungen verwendet werden, da falsche Einstellungen sie öffentlich zugänglich machen können.

Ein weiterer grundlegender Baustein von AWS-Umgebungen ist die Virtual Private Cloud (VPC). Sie ermöglicht dem AWS-Kunden die gleiche Kontrolle über seine Umgebung wie in einem On-Site-Netzwerk. In Azure wird eine VPC als virtuelles Netzwerk bezeichnet, und GCP verwendet den gleichen Begriff wie AWS. Kombiniert man VPCs mit EC2-Sicherheitsgruppen, kommt man vom Sicherheitsstandpunkt aus in den Genuss von Funktionen wie Network Access Control Lists, die ein- und ausgehende Filterung auf Instanz- und Subnetzebene ermöglichen. Damit lässt sich festlegen, welche Endpunkte welche Ressourcen im Netz sehen können, welcher Datenverkehr wo erlaubt ist, und so weiter.

Die größten Vorteile einer Cloud-Infrastruktur liegen in der Schnelligkeit und Einfachheit der Bereitstellung. In einer Cloud-Umgebung können Entwickler und DevOps mit wenigen Klicks eine neue Infrastruktur bereitstellen. Dies beschleunigt die Innovation erheblich, hat aber den Nachteil, dass diese Mitarbeiter mit der Netzwerkkonfiguration und mit Sicherheitsfragen relativ wenig vertraut sind.

Daher ist eines der größten Risiken einer Cloud-Infrastruktur das Auftreten von Fehlkonfigurationen, die ausgenutzt werden können, um unberechtigten Zugang zu erhalten. Viele der Best Practices für Cloud-Sicherheit drehen sich darum, die Wahrscheinlichkeit des Auftretens von Fehlkonfigurationen zu minimieren und diese schnell zu beheben, wenn sie auftreten. Insbesondere agile Methoden wie DevOps stellen dabei eine große Herausforderung für Sicherheitsexperten dar und erfordern eine enge Zusammenarbeit mit den Entwicklerteams.

Eine weitere große Herausforderung ist die Schnelllebigkeit in der Cloud-Infrastruktur. Die einfache und schnelle Bereitstellung in der Cloud bedeutet, dass sich die Dinge viel schneller ändern als in einer On-Site-Umgebung - oft stündlich oder gar minütlich. Darüber hinaus ist eine Schlüsselfunktion der Cloud die automatische Skalierung. Dieser ständige Wechsel macht es für Sicherheitsteams sehr schwierig, die Sicherheit der gesamten Umgebung zu gewährleisten. Die Lösung dieses Problems heißt Automatisierung. Das kann vieles bedeuten, von einer automatischen Verweigerung des Deployments eines falsch konfigurierten Systems bis hin zur sofortigen Isolierung einer Anlage, die scheinbar kompromittiert wurde.

Der erste Schritt bei der Entwicklung einer Sicherheitsstrategie für Cloud-Umgebungen ist die Definition einer Richtlinie. Eine solche Baseline legt genau fest, wie die Cloud-Umgebung aus der Sicherheitsperspektive aussehen soll, und umreißt Dinge wie die Frage, welche Dienste verwendet werden dürfen und welche nicht. Sie legt auch fest, wie diese Dienste konfiguriert werden sollten, wer Zugriff auf welche Teile der Cloud-Infrastruktur erhält, wer Änderungen an dieser Infrastruktur vornehmen kann und so weiter. Die Richtlinie dient als Dokument, auf das sich jeder beziehen kann. Dies ist in der Cloud von entscheidender Bedeutung, da nicht mehr nur die IT- und Sicherheitsteams die Infrastruktur betreiben, sondern auch das DevOps-Team und die Entwickler selbst. Die Baseline stellt sicher, dass alle aufeinander abgestimmt sind. Sie sollte auch Prozesse festlegen, z.B. wie die Organisation auf Vorfälle reagiert. Ein Plan zur Reaktion auf Vorfälle ist hier von entscheidender Bedeutung, da er klar festlegt, wer für was verantwortlich ist, wenn ein Sicherheitsproblem auftritt.

Als Basis für die Erstellung der Richtlinie können Best Practices wie die CIS-Benchmarks dienen, die es für AWS, Azure und die Google Cloud Platform (GCP) gibt. Sie bieten eine breite Palette von Best Practices für die sichere Konfiguration von Cloud-Infrastrukturen. Jeder Cloud-Anbieter hat auch seine eigenen Best Practices, die Kunden nutzen können. Sie alle eignen sich hervorragend als Ausgangspunkt, und von dort aus kann man individuell entscheiden, welche Empfehlungen für das eigene Unternehmen funktionieren und welche nicht.

Eine Richtlinie ist nur ein Stück Papier, wenn sie nicht durchgesetzt wird. Wie also nimmt man die Baseline, die man erstellt, und setzt sie durch, so dass die Menschen sie auch tatsächlich befolgen? Und wie setzt man sie durch, ohne Entwickler zu blockieren, die schnell handeln müssen? Es gibt ein paar Möglichkeiten, dies zu erreichen. Eine davon ist mit Cloud Security Posture Management (CSPM)-Lösungen wie DivvyCloud, die dabei helfen, die Baseline zu erstellen und durchzusetzen. Sie bieten Einblick in Fehlkonfigurationen und die Einhaltung von Richtlinien, so dass bei Abweichungen rechtzeitig Abhilfe geschaffen werden kann. DivvyCloud etwa ist ein Tool, das kontenübergreifend und über mehrere Cloud-Anbieter hinweg eingesetzt werden kann. Es ermöglicht auch automatische Korrekturen bei einem Defekt oder einer Fehlkonfiguration, um zu gewährleisten, dass die Richtlinien der Baseline eingehalten werden.

Auf Enterprise-Ebene ist ein CSPM praktisch ein Muss. Werden mehrere Cloud-Accounts über multiple Cloud-Anbieter hinweg betrieben, kann die Sicherheit sehr schnell komplex werden. In kleineren Umgebungen ist der beste Ansatz die Verwendung einer Infrastructure-as-Code-Lösung, mit der Vorlagen für die Cloud-Infrastruktur erstellt werden können, um eine Baseline-kompatible Konfiguration zu gewährleisten. Solche Templates machen es den Entwickler einfach, alles mit der richtigen Konfiguration bereitzustellen, und reduzieren zudem die Wahrscheinlichkeit menschlicher Fehler erheblich. Die beliebteste Infrastructure-as-Code-Lösung ist Terraform, da sie über mehrere Cloud-Anbieter hinweg funktioniert. Es ist jedoch wichtig zu beachten, dass die Erstellung von Infrastruktur-als-Code-Vorlagen allein nicht ausreicht, sondern dass nach wie vor eine Möglichkeit benötigt wird, alles zu überwachen. Nur weil eine Cloud-Infrastruktur ordnungsgemäß bereitgestellt wird, bedeutet das nicht, dass jemand sie nicht im Laufe der Zeit ändern kann. Hierfür dienen Tools wie die CCA-Funktion (Cloud Configuration Assessment) von Rapid7s InsightVM, das die gesamte Umgebung auf Fehlkonfigurationen hin überwachen kann. AWS, Azure und GCP verfügen ebenfalls über eine eigene plattformspezifische Überwachung - Hauptsache, es wird irgendeine Form der Überwachung verwendet.

Zugriffsrechte sind ein weiteres wichtiges Thema bei der Cloud Security, und wie immer sollte man darauf achten, dass jeder nur die Rechte besitzt, die er wirklich benötigt. Dabei sollte man auf Single-Sign-on (SSO)-Tools zurückgreifen, denn es ist keine gute Idee, Cloud-Logins getrennt von anderen Logins zu speichern und zu verwalten. Wenn eine Person das Unternehmen verlässt, kann man ihr sonst den Zugriff auf die Cloud-Infrastruktur nicht einfach entziehen. Auch sollte die Zuweisung von Berechtigungen bevorzugt auf Gruppen- oder Teamebene erfolgen und nicht auf der individuellen Ebene. Dies gewährleistet Konsistenz und vermeidet Verwirrung durch nicht übereinstimmende Benutzerberechtigungen. Mit AWS IAM (Identity and Access Management) kann man beispielsweise Gruppen für jedes Team in der Organisation erstellen und allen Mitgliedern dieser Gruppe die gleichen Berechtigungen zuweisen. Eine Änderung der Berechtigungen auf Gruppenebene gegenüber der individuellen Ebene verringert auch die Wahrscheinlichkeit, dass sich jemand Zugriffsrechte verschafft, die er nicht haben sollte.

Eine weitere bewährte Praxis ist, niemals den Root-Benutzer zu verwenden. Root ist der Benutzer, der bei der Einrichtung eines Cloud-Accounts angelegt wird. Er hat wie in herkömmlichen Umgebungen Zugriffsberechtigungen, die kein anderer Benutzer hat, einschließlich der Administratoren. Wird dieser Benutzer kompromittiert, könnte ziemlich ernsthafter Schaden angerichtet werden. Der Root-Benutzer sollte daher wirklich nur verwendet werden, wenn es absolut notwendig ist. Für den Rest der Zeit sollten seine Anmeldeinformationen physisch weggeschlossen werden, und vor allem ist eine Multi-Faktor-Authentifizierung (MFA) zwingend - eigentlich sollte man MFA übrigens für alle Benutzer einsetzen. Die meisten Cloud-Plattformen können einen Report erstellen, aus dem hervorgeht, wer auf was Zugriff hat und wofür die Berechtigungen verwendet wurden. Diese Berichte können dabei helfen, festzustellen, ob der Root-Benutzer verwendet wird, und wenn dies der Fall ist, kann man in fast allen Situationen neue Benutzer mit eingeschränkteren Berechtigungen erstellen, um den Root-Benutzer zu ersetzen.

Auch die virtuellen Maschinen in der Cloud können Software-Schwachstellen aufweisen. Wie ein firmeneigenes Netzwerk müssen sie überwacht und gepatcht werden. Instanzen können Minute für Minute hoch- und heruntergefahren werden, so dass man sich nicht allein auf einen wöchentlichen Scan-Bericht verlassen kann, um einen ausreichenden Einblick in die aktuelle Risikoeinstufung zu erhalten. Hier helfen Agenten wie der Insight Agent von Rapid7 in den einzelnen Instanzen, die aktuelle Informationen darüber geben, was passiert und welche Schwachstellen vorhanden sind.

Für den Fall, dass eine Schwachstelle entdeckt wird, verfügen alle Cloud-Anbieter über Patch-Manager, um Patches bereitzustellen. Viele Cloud-Umgebungen sind jedoch unveränderlich, d. h. sie sind so konzipiert, dass Änderungen an der Infrastruktur nach ihrer Bereitstellung nicht mehr möglich sind. In diesen Fällen muss zur Behebung einer Schwachstelle ein neues Image verwendet werden, das eine aktualisierte Betriebssystemversion mit den installierten Patches beinhaltet. Anschließend wird eine neue virtuelle Maschine aufgesetzt, die das neue Image verwendet, und die alte Instanz wird beendet.

Logs sind der beste Freund des Sicherheitsverantwortlichen. Ohne sie tappt man im Dunkeln. Alle Cloud-Anbieter bieten Protokollierungsfunktionen an; bei AWS ist es CloudTrail, bei Azure Monitor und bei GCP heißt sie Cloud Logging. Es ist wichtig, alle Aktivitäten für alle Regionen und Dienste zu protokollieren einschließlich derer, die gerade nicht genutzt werden. Die Logs der Cloud-Provider sollten geschützt und verschlüsselt werden, um Manipulationen auszuschließen. Nur wenige Mitarbeiter sollten Zugang zu ihnen haben. Die meisten Cloud-Anbieter bieten auch Validierungsdateien an, die erkennen können, ob etwas geändert wurde.

Schließlich braucht man dann eine Möglichkeit, auf verdächtige Aktivitäten in den Protokollen mit einer Warnung zu reagieren. Eine Möglichkeit besteht darin, dafür den vom Cloud-Anbieter angebotenen nativen Log-Überwachungsdienst zu nutzen. In AWS heißt dieser Alarmierungsdienst CloudWatch, in Azure heißt er Monitor und in GCP Cloud Monitoring. Das Problem bei diesem Ansatz ist jedoch, dass man jeden einzelnen Alarm selbst definieren und pflegen muss, und es kommt häufig zu Fehlalarmen.

Eine andere Möglichkeit ist die Verwendung eines Erkennungsdienstes des Cloud-Providers. Bei AWS handelt es sich um Guard Duty, bei Azure um Advanced Threat Protection und bei GCP um Event Threat Protection. So ziemlich jede Organisation hat jedoch auch lokale Netzwerke und Remote-Mitarbeiter zu sichern, und solche Dienste können diese Umgebungen nicht überwachen. Aus diesem Grund verwenden viele Unternehmen ein SIEM (Security Information and Event Management) eines Drittanbieters mit Threat-Detection-Funktionen wie InsightIDR von Rapid7. Diese Art von Tool ermöglicht es, die Cloud-Umgebung und alle anderen Umgebungen zentral zu überwachen. Dies ist besonders wichtig bei lateralen Bewegungen eines Angreifers, z. B. zwischen einem kompromittierten Laptop und der Cloud-Umgebung. Hier benötigt man alle Daten an einem Ort, um mit Hilfe von Korrelation eine gründliche Untersuchung durchzuführen, die Auswirkungen abzuschätzen, herauszufinden, wo sich der Angreifer jetzt befindet und worauf man sich bei der Abhilfe konzentrieren muss.

Wer seine Sicherheitsziele im Auge behalten und sicherstellen will, dass Richtlinien und Verfahren richtig zugeordnet und befolgt werden, muss die Dinge straffen. Getrennte Teams für On-Site- und Cloud-Sicherheit zu haben, bedeutet, dass Silos und unklare Rollen entstehen, was bei einem Zwischenfall zu Chaos führen kann. Keep it simple: mit einem einheitlichen Team, das die Sicherheit überwacht, sowie mit einem Tool, das alle Umgebungen kontrolliert. Natürlich kann ein Team einzelne Gruppen für den Umgang mit der Cloud, On-Site usw. haben, aber es muss klare Verantwortlichkeiten und Zuständigkeiten geben. Sonst zeigt schnell einer auf den anderen.

Automatisierung ist heute der Schlüssel zu Skalierbarkeit und Effizienz, insbesondere in der Cloud. Die Dinge in der Cloud bewegen sich schnell, und der Mensch allein kann nicht mithalten, aber die Automatisierung kann es. Ob die Konfiguration der Infrastruktur, die Hinzunahme neuer Mitarbeiter oder die Aktualisierung von EC2-Instanzen - all dies kann automatisiert werden. Eine Möglichkeit, dies zu erreichen, besteht in der Verwendung einer Automatisierungs- und Orchestrierungslösung wie InsightConnect, die alle Tools miteinander verbindet, sich wiederholende Aufgaben, die anfällig für menschliche Fehler sind, rationalisiert und die Kommunikations- und Reaktionseffizienz steigert. Je stärker die Umgebung automatisiert ist, desto geringer die Wahrscheinlichkeit, dass menschliches Versagen zu einem Faktor wird.