Ihnen sollte nun klar sein, was für Daten Sie haben, wo sie gespeichert sind und wie Sie die gespeicherten Daten schützen wollen. Jetzt ist es an der Zeit, sich die anderen Cloud Assets anzuschauen und zu überlegen, wie Sie diese inventarisieren und schützen.
Wie schon in Kapitel 2 erwähnt, verwalten die Cloud-Provider eine Liste mit den Assets, die Sie provisioniert haben, denn sie wollen Ihnen ja eine Rechnung stellen können. Es gibt auch APIs, um sich diese Liste ausgeben zu lassen, und manchmal haben die Provider spezialisierte Anwendungen, die Ihnen beim Inventory und Asset Management helfen.
Ihr Cloud-Provider kennt im Allgemeinen nur Assets, die Sie über sein Portal oder seine APIs provisionieren. Provisionieren Sie beispielsweise eine virtuelle Maschine und erzeugen dort manuell Container, kann der Cloud-Provider davon nichts wissen.
Cloud-Infrastruktur und -Services sind oft günstig und einfach zu provisionieren, was schnell dazu führen kann, dass Sie einen großen Berg Assets haben, die über die ganze Welt verstreut sind und vergessen werden. Jedes dieser vergessenen Assets ist wie eine tickende Zeitbombe, die nur darauf wartet, als Sicherheitsvorfall zu explodieren.
Ein wichtiger Unterschied beim Schutz und beim Management von Cloud Assets ist, dass Sie sich im Allgemeinen keine Sorgen um physische Assets oder überhaupt um den physischen Schutz Ihrer Cloud-Umgebung machen müssen. Sie können physische Asset-Tags, Vereinzelungsanlagen, die Positionierung von Fenstern, Kameras und anderen physischen Sicherheitsmaßnahmen und Tracking-Möglichkeiten für Assets fröhlich outsourcen.
Ein weiterer wichtiger Unterschied findet sich in der Beteiligung der IT-Abteilung am Provisionieren von Cloud Assets. In einer klassischen IT-Umgebung ist das Erstellen eines Assets wie zum Beispiel eines Servers oft schwierig und zeitaufwendig. Sie müssen sich im Allgemeinen an eine zentrale IT-Gruppe wenden, die dann einen detaillierten Provisionierungsprozess abarbeitet und eine Liste von Assets in einer Datenbank oder in einem Spreadsheet vorhält. Es gibt ein natürliches Hindernis, eine Schatten-IT zu schaffen (also IT-Ressourcen, die verborgen oder nicht offiziell genehmigt sind), weil für die IT typischerweise Kapitalressourcen erforderlich sind. Und in den meisten Organisationen werden große Kapitalausgaben sorgfältig kontrolliert.
Ein wichtiger Vorteil des Cloud Computing besteht darin, diese hohen Investitionskosten durch monatliche Ausgaben zu ersetzen und die Kapazitätsplanung an einen IaaS-Anbieter auszulagern. Das ist super, es bedeutet aber auch, dass es für die IT und die Finanzabteilung schwieriger ist, IT-Ressourcen effektiv im Griff zu behalten. Jeder kann in jedem Businessbereich leicht eine große Zahl von IT-Ressourcen provisionieren, und er braucht dafür nur eine Kreditkarte (manchmal nicht einmal das). Das kann schnell zu Problemen beim Asset Management führen.
Bevor es die Cloud gab, hatten die meisten Organisationen einen gewissen Anteil an Schatten-IT. Mit der Cloud ist das oft viel schlimmer – und die Assets sind nicht einfach nur Server.
Bevor wir Cloud Assets effektiv managen können, müssen wir verstehen, was sie sind und wie ihre sicherheitsrelevanten Eigenschaften aussehen. Mir selbst hilft das Schaffen von klar definierten Asset-Kategorien dabei, meine Gedanken zu ordnen. Aus diesem Grund habe ich Cloud Assets als Compute-, Storage- und Netzwerk-Assets kategorisiert – Sie können sich natürlich andere Kategorien überlegen.
Jeden Tag entstehen neue Arten von Cloud Assets, und es ist wahrscheinlich, dass Sie nicht alle diese Typen selbst nutzen. Sie müssen auch nicht alle Arten von Assets an einem Ort protokollieren. Wichtig ist, dass Sie über alle Assets Bescheid wissen, die für Ihre Sicherheit wichtig sind.
Kommen Sie in eine Umgebung mit einer großen Zahl von bestehenden Cloud Assets, sollten Sie daran denken, dass Sie nicht sofort eine vollständige und umfassende Lösung für das Asset Management haben werden. Konzentrieren Sie sich auf die Assets, die für die Sicherheit am relevantesten sind, um direkte Vorteile aus dem Management ziehen zu können, und ergänzen Sie dann Schritt für Schritt zusätzliche Arten. Bei vielen Organisationen werden die für die Sicherheit wichtigsten Assets nur ein paar Arten von Data Storage und Compute Assets sein.
Schauen Sie sich die Arten von Cloud Assets an, kann es helfen, sich zu notieren, von welchen Typen Sie schon wissen, dass Sie sie haben, und diejenigen mit Sternchen zu versehen, die für die Sicherheit am relevantesten sind. Auch wenn es in diesem Kapitel vor allem um Asset Management geht, können einige der Sicherheitseigenschaften dieser Assets das aktuelle oder zukünftige Design Ihrer Cloud-Umgebung beeinflussen. Im zweiten Teil dieses Kapitels werde ich ein paar Ideen vorstellen, wie Sie die Arten von Cloud Assets inventarisieren können, die Sie so ermittelt haben.
Viele Cloud Assets sind kurzlebig – sie werden ziemlich häufig erstellt und auch wieder gelöscht. Das kann das Asset Management erschweren und auch einige der verbreiteten Methoden zum Asset Tracking – wie zum Beispiel das Tracken über IP-Adressen – ineffektiv machen.
Compute Assets nehmen im Allgemeinen Daten, verarbeiten sie und tun dann etwas mit den Ergebnissen. So kann beispielsweise eine sehr einfache Compute-Ressource Daten auf Anforderung von einer Datenbank holen und an einen Webbrowser oder einen Geschäftspartner schicken oder sie mit Daten aus einer anderen Datenbank kombinieren.
Diese Kategorien an Cloud Assets sind nicht vollständig disjunkt. Compute-Ressourcen können auch Daten – insbesondere temporäre – speichern. Bei manchen Arten von regulierten Daten kann es notwendig sein, sicherzustellen, dass Sie jeden Ort protokollieren, an dem sich Daten befinden könnten, daher sollten Sie solchen temporären Data Storage nicht vergessen.
Virtuelle Maschinen (VMs) sind die bekannteste Art von Cloud Assets. Auf ihnen laufen Betriebssysteme und Prozesse, die Businessfunktionen ausführen. VMs verhalten sich in Cloud-Umgebungen in vielen Fällen sehr ähnlich wie ihre On-Premises-Verwandten.
Angriffe auf virtuelle Maschinen
VMs in der Cloud unterscheiden sich in einem Punkt grundlegend von On-Premises-VMs: In einer Cloud-Umgebung teilen Sie sich eventuell dasselbe physische System mit anderen Cloud-Kunden. Diese anderen Kunden können einfach unaufmerksam sein und sich wie »laute Nachbarn« benehmen, indem sie die ganze Rechenzeit, Netzwerk- oder Storage-Bandbreite verbrauchen, sodass Ihre VM ihre Arbeit nicht effizient erledigen kann. Aber sie können auch bewusst böswillig sein und versuchen, die Tatsache auszunutzen, dass Sie sich auf derselben physischen Hardware bewegen, um die Vertraulichkeit, Integrität oder Verfügbarkeit Ihres Systems anzugreifen. Das sind also zusätzliche Risiken im Vergleich zu den üblichen »Front-Channel«-Risiken für Server, wie zum Beispiel dem Einsatz gestohlener Zugangsdaten oder dem Ausnutzen von Softwaresicherheitslücken auf dem Server.
Im Allgemeinen gibt es zwei primäre Wege, wie Sie von anderen Kunden (oder sogar angreifenden Personen, die Zugriff auf Ihre eigenen VMs erlangt haben) angegriffen werden können. Der erste geschieht über ein »Hypervisor Breakout« oder »VM Escape«, bei dem ein Angreifer auf einer VM dazu in der Lage ist, den Hypervisor zu überwinden und das physische System vollständig zu kontrollieren. Glücklicherweise ist das nicht einfach, weil Hypervisoren so designt sind, dass sie nur sehr wenige Eingaben von den virtuellen Maschinen akzeptieren. Im Allgemeinen muss eine VM, die den Hypervisor übernehmen will, eine Sicherheitslücke entweder in paravirtualisierten Storage- oder den Netzwerkschnittstellen finden, was keine sehr große Angriffsoberfläche bietet. Wenn physische Systeme vergleichbar sind mit getrennten Gebäuden, dann sind virtuelle Maschinen getrennte Wohnungen, die den Verwalter nur über zwei Briefkästen namens »Netzwerk« und »Storage« erreichen können. Ich nenne dies Back-Channel-Angriffe, weil die Infrastruktur hinter der VM angegriffen wird.
Der andere Weg, auf dem bei einem Angriff Informationen erlangt werden können, sind Side-Channel-Angriffe, die auf ungewollten Nebeneffekten beim Ausführen von Code auf einem physischen System beruhen. Lässt man Code auf derselben Hardware laufen, könnten Personen bei einem Angriff vielleicht dazu in der Lage sein, wichtige Informationen über Ihre VM herauszufinden, wie zum Beispiel Passwörter oder Schlüssel, indem das Timing von Prozessoranweisungen oder Zugriffe auf den Cache präzise ausgewertet werden. So funktionieren im Prinzip die berüchtigten Spectre- und Meltdown-Sicherheitslücken.
Das heißt nicht, dass Sie VMs nicht nutzen sollten – die Risiken dieser Art von Side-Channel- und Back-Channel-Angriffen sind für die meisten Organisationen akzeptabel, und Sie sollten sich vermutlich zunächst über andere Dinge Sorgen machen. Aber es ist wichtig, sich bewusst zu sein, dass die gemeinsame Nutzung physischer Hardware potenzielle Sicherheitslücken schaffen kann. Wie physische Sicherheit liegt aber das Abmildern solcher Arten von Angriffen so gut wie immer in der Verantwortung Ihres Cloud-Providers (auch wenn Sie in manchen Fällen trotzdem Fixes für das Betriebssystem auf Ihren VMs installieren müssen).
VMs haben immer ein Betriebssystem, zu dem ein Kernel und andere »Userspace«-Programme gehören, die alle vom Hersteller des Betriebssystems ausgeliefert werden. Manche Server können all ihre Funktionen allein mit der Software ausführen, die als Teil des Betriebssystems geliefert wurden. Auf den meisten VMs ist aber zusätzliche Software installiert, wie zum Beispiel Plattform- oder Middleware-Software und Kundenanwendungen, die von Ihrer Organisation geschrieben wurden.
Weil so viele Komponenten zusammengemischt werden können, um eine VM zu nutzen, müssen wir beim Managen der Schwachstellen, des Zugriffs und der Konfiguration für jede der vielen Softwareschichten sorgfältig vorgehen. Bei erfolgreichen Angriffen wird eventuell Zugriff auf irgendwelche Daten erlangt, auf die auch die VM Zugriff hat. Die kompromittierte VM könnte dann ebenfalls genutzt werden, um den Rest Ihrer Infrastruktur anzugreifen – oder andere Organisationen (was für Ihre Reputation nicht unbedingt hilfreich sein wird).
Hier ein paar Beispiele für Inventarelemente, die Sie für VMs im Auge behalten sollten:
Das meiste davon gilt auch für On-Premises-VMs. Aber Cloud-VMs brauchen im Allgemeinen nicht mehr als eine oder zwei Minuten, bis sie erstellt wurden (auch wenn das Initialisieren durchaus länger dauern kann), sodass sie nach Bedarf erzeugt und wieder gelöscht werden können. Das ist zum schnellen Hoch- und Runterskalieren sehr nützlich, um Lastspitzen abzudecken, kann aber das Asset Management komplizierter gestalten. Daher werden Sie vermutlich Agenten nutzen müssen, die auf Ihren VMs installiert sind, oder auf ein Inventory-System des Cloud-Providers setzen, um alle relevanten Informationen automatisch einsammeln zu können.
Neben dem Tracken der VMs selbst (häufig als »Instanzen« bezeichnet) müssen Sie auch die »Images« oder Templates erfassen, die zum Erstellen neuer VMs kopiert werden. Sie wollen keine neuen Server online gehen lassen, die kritische Sicherheitslücken haben, auch wenn diese nach dem Starten schnell gepatcht werden.
Manche Cloud-Provider bieten neben VMs auch »Bare-Metal«-Systeme an.1 Diese haben die gleichen Sicherheitsanforderungen wie VMs, können allerdings auch noch Firmware besitzen, die gelegentlich aktualisiert werden muss.
Viele Cloud-Provider bieten darüber hinaus »dedizierte« VMs an. Diese werden wie normale VMs erstellt, aber der Provider verspricht dabei, keine VMs von anderen Kunden auf physischen Systemen zu schedulen, auf denen Ihre VMs laufen. Das kann »laute Nachbarn« und Side-Channel-Angriffe verhindern.
Bare-Metal-Maschinen und dedizierte VMs haben keine Probleme mit den in »Angriffe auf virtuelle Maschinen« auf Seite 51 beschriebenen Risiken, kosten aber meist mehr. Wie bei allen Entscheidungen rund um Sicherheit müssen Sie die Kosten und Vorteile gegeneinander abwägen. Im Allgemeinen halte ich Bare-Metal-Maschinen oder dedizierte VMs für zusätzliche Sicherheit nicht für nötig, sofern Sie die verbreiteteren Probleme, wie zum Beispiel das Vulnerability und Access Management, im Griff haben.
Beachten Sie, dass viele der folgenden Asset-Typen als Dekonstruktion einer VM in kleinere Komponenten betrachtet werden können, die dann »as a Service« bereitgestellt werden.
Container führen wie VMs Prozesse aus, die Businessfunktionen realisieren, wie zum Beispiel Webserver oder eigene Anwendungen. Aber anders als VMs enthalten sie kein vollständiges Betriebssystem. Container nutzen den Kernel der VM, auf der sie gehostet sind, und enthalten möglicherweise auch nichts von der zusätzlichen Software, die beim Betriebssystem mitgeliefert wird.
Container können in weniger als einer Sekunde starten, weshalb sie in vielen Umgebungen nahezu durchgehend erstellt und gelöscht werden.
Angriffe auf Container
Während die Hypervisoren, die VMs betreiben, eine sehr kleine Angriffsoberfläche haben, besitzt der gemeinsam von allen Containern genutzte Kernel eine viel größere Oberfläche. So enthält der Linux-Kernel beispielsweise über 300 Systemaufrufe, von denen viele durch Container genutzt werden können. Eine Sicherheitslücke bei einem dieser Systemaufrufe könnte es Code ermöglichen, aus einem Container heraus Zugriff auf das gesamte System zu erlangen.
Das bedeutet nicht, dass Container inhärent unsicher sind, aber Sie sollten darauf achten, Container nicht als einzige Trust Boundary zwischen Komponenten einzusetzen, die sehr unterschiedliche Sicherheitsanforderungen haben. So schreit es beispielsweise förmlich nach Problemen, wenn Sie Container, die Internetusern erlauben, ihren eigenen Code auszuführen, auf dem gleichen Server laufen lassen wie Container, die Ihre kritischsten Daten verarbeiten.
Die Containerisolierung wird sich mit der Zeit noch weiterentwickeln. Container werden eventuell mit Technologien wie seccomp auf weniger Systemaufrufe beschränkt werden, was die Wahrscheinlichkeit verringert, dass eine Sicherheitslücke in einem dieser Systemaufrufe ausgenutzt werden kann. Der Kernel wird zudem vielleicht zusätzliche Prüfungen als weitere Schutzschicht gegen das »Escapen« aus Containern durchführen. Hybride Lösungen, die die stärkere Isolation von VMs mit dem einfachen Deployment bei Containern kombinieren, wie zum Beispiel Firecracker (https://oreil.ly/4ixDY), sind ebenfalls eine Option.
Sofern Ihre Container eine vollständige Kopie des Betriebssystems enthalten und Administratoren eine Anmeldung erlauben, sind sie im Prinzip Mini-VMs. Auch wenn Container in diesem »Mini-VM-Modell« genutzt werden können, ist das nicht die beste Vorgehensweise. Ihre Asset-Management-Strategie für Container wird zum Teil davon abhängen, wie Sie sie verwenden. Wir werden uns zwei Modelle anschauen – das Native-Container-Modell und das Mini-VM-Modell. Hinzu kommt noch eine Möglichkeit, Container zu managen.
Native-Container-ModellDas gilt in einem reinen Native-Container-Modell:
Auf nativen und immutablen Containern sollten sich keine Administratorinnen oder Administratoren anmelden, um routinemäßige Wartungsarbeiten durchzuführen, auch wenn Sie vermutlich Vorkehrungen treffen sollten, im Notfall auf sie zugreifen zu können. Wenn Container-Log-ins ganz allgemein nicht erlaubt sind, sorgt das Zugriffsmanagement für weniger Risiko als bei Servern. Sicherheitslücken und das Konfigurationsmanagement sind immer noch zentrale Risiken, aber der Umfang eines gegebenen Containers ist viel geringer als bei einem Server, der viele verschiedene Funktionen ausführen kann.
Native Container werden im Allgemeinen viel häufiger erstellt und wieder zerstört als VMs. Das bedeutet, es ist sinnvoll, die Container-Images zu inventarisieren und nicht die Container selbst, zu dokumentieren, aus welchem Image ein Container erstellt wurde, und sicherzustellen, dass Sie keine veralteten Container nutzen. Ein Container-Image muss vor allem deshalb inventarisiert werden, um Software und Konfiguration im Image im Blick zu behalten, sodass es durch Sicherheitsfixes und eine neue Konfiguration aktualisiert werden kann, wenn Sicherheitslücken entdeckt werden.
Mini-VM-Container-ModellIn einem Modell, in dem Sie Container wie Mini-VMs behandeln, gilt:
Nutzen Sie Container wie Mini-VMs, sollten Sie sie auch wie VMs inventarisieren und schützen. Das bedeutet im Allgemeinen, Inventory Agents zu installieren, auch wenn solche Agenten normalerweise in einem Native-Container-Modell als zu »schwergewichtig« betrachtet werden. Es heißt ebenfalls, dass Sie User, Software und all die anderen Elemente dokumentieren, die im vorherigen Abschnitt zu VMs aufgeführt sind.
In beiden Modellen sollten Sie die Images inventarisieren und aktualisieren, weil Sie keine neuen Container erstellen wollen, die Sicherheitslücken besitzen.
Orchestrierungssysteme für ContainerContainer sind toll, aber noch besser ist es, etwas zu haben, das sich darum kümmert, Container zusammenzubringen, um ausgefeiltere Funktionen umsetzen zu können, mehrere Kopien dieser Kombinationen zu starten, Load Balancing damit zu realisieren und andere Features anzubieten, wie zum Beispiel einfache Möglichkeiten, die Komponenten miteinander reden zu lassen. Diese Art von System wird als Container-Orchestrierungssystem bezeichnet. Solche Funktionalität ist ausgesprochen nützlich, deshalb ist sie für Angreifer auch ein lohnendes Ziel.
Die aktuell beliebtesten Umsetzungen der Containerorchestrierung sind Kubernetes und seine Varianten wie OpenShift und K3s. Bei einem Kubernetes-Deployment sind die primären Assets Cluster, die Pods enthalten, die wiederum Container enthalten, die aus Images erstellt werden. In einer Kubernetes-Umgebung sollten Sie folgende Komponenten beim Inventarisieren berücksichtigen:
Application-Platform-as-a-Service-(aPaaS-)Angebote, wie zum Beispiel AWS Elastic Beanstalk, Azure Pipelines, Google App Engine oder IBM Cloud Code Engine, ermöglichen Ihnen, Ihren Code zu deployen, ohne selbst VMs provisionieren zu müssen. Diese Angebote bieten zudem viele Ressourcen als Teil der Plattform an, zum Beispiel Datenbanken. So kann beispielsweise ein Deployment aus dem von Ihnen geschriebenen Code sowie einer von aPaaS bereitgestellten Datenbank bestehen. Das Deployment beginnt zu laufen, wenn Sie es erstellen, und stoppt, wenn Sie es abräumen, aber Sie müssen nie selbst eine VM oder einen Container erzeugen, in der oder dem es läuft – das erledigt Ihr Cloud-Provider für Sie.
Die Sicherheit eines aPaaS hängt stark vom aPaaS und der Implementierung des Providers ab. Es ist wichtig, das Isolationsmodell zu verstehen, das Ihre Compute, Network und Storage Assets von denen anderer Cloud-Kunden getrennt hält. In vielen Fällen werden Ihre Deployments auf den gleichen VMs wie die anderer Kunden laufen, was zu einer eingeschränkten Compute-Isolierung führt. Oft werden Sie keine anderen Container im Netz ansprechen können, daher haben Sie eine gute Netzwerkisolierung. Storage-Isolierung hängt davon ab, welche Levels an Verschlüsselung (wenn überhaupt) von den Persistent-Storage-Services Ihres Providers angeboten werden, und sie kann sich zwischen verschiedenen Storage-Services unterscheiden.
Erstellen Sie ein aPaaS-Deployment, müssen Sie das Deployment selbst und seine Abhängigkeiten (wie zum Beispiel Build Packs oder andere Unterkomponenten) zum Zweck des Vulnerability Management und des Konfigurationsmanagements dokumentieren. Die zugrunde liegenden Compute- oder Storage-Ressourcen müssen Sie aber nicht inventarisieren, weil diese nicht Ihrer Kontrolle unterliegen.
Serverless Functions sind eine Möglichkeit, Ihren Code nur bei Bedarf ausführen zu lassen. Beispiele dafür sind AWS Lambda, Azure Functions, Google Cloud Functions und IBM Cloud Functions.
Serverless-Angebote unterscheiden sich von aPaaS-Angeboten darin, dass erst dann etwas läuft, wenn der Service angefordert wird – es gibt nichts, was herumsitzt und auf eintreffende Requests wartet. Das bedeutet, Sie müssen kein Image und keine Instanzen dokumentieren, die aus diesem Image erstellt werden, weil es keine lang laufenden Instanzen gibt. Nur aus Ihrer Sicht als Kunde ist das Ganze serverless, weil der Provider die Server hinter einer Abstraktionsschicht verbirgt.
Bei Serverless Assets müssen Sie weder ein Betriebssystem noch Plattformkomponenten inventarisieren. Sie müssen nur Ihre Serverless-Deployments erfassen, sodass Sie Schwachstellen in Ihrem Code managen und den Zugriff auf die Funktion steuern können.
Storage Assets persistieren meist Daten und tendieren damit dazu, dauerhafter als die anderen hier vorgestellten Arten von Assets zu sein. Manchmal werden Daten als »sticky« beschrieben oder dass sie »Gravitation« zeigen, weil das Bewegen großer Datenmengen schwierig und zeitaufwendig sein kann. Sie haben Ihre wichtigsten Data und Storage Assets in Kapitel 2 identifiziert, aber es kann auch noch andere Storage Assets geben, die nicht berücksichtigt Kapitel 2 wurden. Wir werden uns hier einige der möglichen Kandidaten anschauen.
Da ich den meisten Organisationen für das Risk Assessment einen Asset-orientierten Ansatz empfehle, legt dieses Buch seinen Schwerpunkt vor allem auf Storage Assets. Die Zugriffsverwaltung ist für alle in diesem Abschnitt aufgeführten Cloud Storage Assets der wichtigste zu beachtende Punkt bei der Sicherheitsanalyse.
Block Storage ist einfach die Cloud-Version einer Festplatte – die Daten stehen einem Server wie bei einem Festplatten-Controller in kleinen Blöcken (beispielsweise 16 KB) zur Verfügung. Beispiele sind AWS Elastic Block Storage, Azure Disk Storage, Google Persistent Disk sowie IBM Cloud Block Storage.
Der primäre Sicherheitsaspekt liegt bei Block Storage in der Zugriffsverwaltung, weil man mit einem direkten Angriff auf den Block Storage alle Schutzfunktionen des Betriebssystems umgeht, die auf Ihrem Server für diesen Storage eventuell eingerichtet sind.
File Storage ist die Cloud-Version eines Dateisystems, in dem Daten in Verzeichnissen und Dateien organisiert sind. Beispiele dafür sind AWS Elastic File System, Azure Files, Google Cloud Storage FUSE und IBM Cloud File Storage. Wie beim Block Storage ist der zentrale Sicherheitsaspekt die Zugriffskontrolle. Auch wenn das Dateisystem selbst oft Access Control Lists für die Dateien anbieten, werden diese vom Betriebssystem erzwungen – nicht vom File Storage. Bei einem direkten Angriff auf den File Storage können alle dort abgelegten Dateien gelesen werden.
In Storage-Begriffen ist ein Objekt einer einfachen Datei sehr ähnlich – es handelt sich um einen Bytestream mit Metadaten zum Objekt. Die Hauptunterschiede sind:
Bei den meisten Object Storages gibt es unterschiedliche Ebenen von Zugriffskontrolle, wie zum Beispiel High-Level-Policies für ein Bucket und individuelle ACLs für spezifische Objekte. Es gab schon viele erwähnenswerte virtuelle Einbrüche, weil die Policies für das Object Storage Bucket für einen freien Zugriff eingerichtet waren. Es ist daher sehr wichtig, Ihre Object Storage Assets und die Zugriffskontroll-Policies für jedes davon zu dokumentieren.
Beispiele für Object-Storage-Services sind Amazon S3, Azure Blob Storage, Google Cloud Storage und IBM Cloud Object Storage.
Images sind Codeblöcke – einschließlich aller zugrunde liegenden Systemkomponenten, wie zum Beispiel des Betriebssystems –, die Sie nutzen, um VMs, Container oder aPaaS-Deployments in einer Cloud-Umgebung zu starten. Sie erstellen eine Kopie eines Image und führen diese aus. Die neue Kopie – oder Instanz – kann sich dann vom Image entfernen. Bei VMs, Bare-Metal-Systemen, Containern und aPaaS-Umgebungen werden überall Images kopiert, um laufende Systeme zu erzeugen. In vielen Organisationen gibt es eine Hierarchie der Images, bei der Sie mit einem »Golden Image« beginnen, das bestimmte Patches und Sicherheitsvorkehrungen besitzt, und dann daraus zusätzliche Images erstellen.
Während Images auf verschiedenen Arten von Cloud Storage gespeichert werden können, wie zum Beispiel Block Storage oder Object Storage, wird der Zugriff auf die Images oft getrennt vom zugrunde liegenden Storage gesteuert.
Unterschiedliche Typen von Cloud Assets und Providern handhaben Images auch auf unterschiedliche Art und Weise, aber oft gibt es viele Personen in der Organisation, die auf die Inhalte der Images zugreifen und Instanzen davon erstellen können. Daher sollten Images nicht alle Informationen enthalten, die zum Ausführen erforderlich sind. Beispielsweise sollten keine kritischen Informationen wie Passwörter oder API-Schlüssel darin zu finden sein, weil nicht jeder mit Zugriff zum Erstellen oder Anzeigen des Image diese Secrets kennen sollte. Ein Image sollte so konfiguriert sein, dass beim Starten einer Kopie (Instanz) davon die Secrets von einem sicheren Ort geholt werden, auf den nur sehr wenige Personen Zugriff haben. Das wird genauer in Abschnitt »Secrets Management« auf Seite 90 behandelt. Abhängig davon, wie Sie Images bauen, können Sie eventuell ein paar Kontrollen einbauen, um sicherzustellen, dass keine Secrets im Image enthalten sind.
Müssen Ihre Images kritische Informationen enthalten, ist es wichtig, den Zugriff auf sie zu kontrollieren, sodass bei einem Angriff ein Einblick in ein Image nicht möglich ist und keine Credentials herausgezogen und eingesetzt werden können. Zudem müssen alle Images protokolliert werden, sodass man sie mit Sicherheitspatches für das Betriebssystem, die Middleware/Plattform oder eigene Anwendungssoftware aktuell halten kann. Ansonsten werden Sie Cloud Assets erzeugen, die in dem Moment angreifbar sind, in dem sie erstellt werden. Das wird genauer in Kapitel 5 behandelt.
Es wurden schon umfangreiche Abhandlungen über die verschiedenen Arten von Datenbanken geschrieben, wie zum Beispiel relationale DBs, Datenbanken für Dokumente, Zeitserien, Graphen, Schlüssel/Wert-Paare und Spaltendatenbanken. Die Wahl des richtigen Datenbanktyps ist für Ihre Anwendung wichtig – sowohl für die Funktionalität als auch aus Performancegründen.
Die Wahl der Datenbank hat auch einen signifikanten Einfluss auf die Sicherheit der gesamten Anwendung. So bieten beispielsweise manche In-Memory-Datenbanken, die für einen schnellen Zugriff genutzt werden, standardmäßig keine Verschlüsselung über das Netzwerk oder auf der Festplatte. Das kann abhängig von den zu speichernden Daten ein Sicherheits- und/oder Compliance-Risiko sein.
Alle Cloud-Datenbanken können eine Zugriffskontrolle für die gesamte Datenbank bieten, und einige Datenbankarten unterstützen auch eine feingranularere Zugriffskontrolle über die Daten in der Datenbank. Sie müssen mindestens Ihre Datenbanken und die Art der darin gespeicherten Daten inventarisieren. Außerdem müssen Sie den Zugriff auf jede Datenbank als Ganzes und potenziell auf verschiedene Bereiche der Datenbank (zum Beispiel Schemata) managen.
Message Queues ermöglichen Komponenten, kleine Datenmengen (meist weniger als 256 KB) aneinander zu schicken – in der Regel über ein Publisher/Subscriber-Modell. Auch wenn das sehr bequem sein kann, können selbst diese kleinen Datenblöcke kritische Daten enthalten, wie zum Beispiel personenbezogene Informationen. Daher ist es wichtig, den Zugriff auf Ihre Message Queues zu schützen. Und wenn einige Ihrer Komponenten Anweisungen aus Messages entgegennehmen, könnte ein Angreifer mit Schreibzugriff auf die Message Queue unerwünschte Aktionen auslösen.
Secrets, wie zum Beispiel Schlüssel oder Passwörter, sollten im Allgemeinen nicht über eine Message Queue geschickt werden. Stattdessen sollte man einen Storage-Service nutzen, der spezifisch für diese Art von Daten entworfen ist (siehe den folgenden Unterabschnitt und Kapitel 4).
In vielen Fällen bringt ein Cloud-Deployment Code und Konfiguration zusammen. Meist nutzen verschiedene Instanzen der Anwendungen denselben Code, aber sie werden in unterschiedliche Gebiete oder Regionen mit unterschiedlicher Konfiguration deployt. Ein Configuration Storage erlaubt Ihnen, diese Konfigurationsinformationen getrennt vom Code zu halten. Beispiele dafür sind etcd, HashiCorp Consul und AWS Systems Manager Parameter Store.
Ein Secrets Configuration Storage ist Configuration Storage, der spezifisch dafür entworfen ist, Secret-Daten zu verwalten, mit denen eventuell auf andere Systeme zugegriffen wird. So wie es ein gutes Vorgehen ist, Ihren Code und Ihre Konfigurationen getrennt zu halten, ist es auch eine gute Idee, den Zugriff auf Ihre Secrets von anderen Konfigurationsdaten zu trennen. Eventuell müssen viele Menschen Ihren Code und Ihre Konfigurationen einsehen können, aber nur sehr wenige sollten die Secrets zu Gesicht bekommen! Daher ist es wichtig, alle Assets zu ermitteln, die Secrets speichern, sicherzustellen, dass sie dazu gebaut sind, diese Secrets zu schützen, und den Zugriff sorgfältig zu kontrollieren.
Das Ganze wird im Detail in Kapitel 4 besprochen. Beispiele für Secret-Storage-Lösungen sind HashiCorp Vault, Keywhiz, Kubernetes Secrets, AWS Secrets Manager, Azure Key Vault, Google Secret Manager und IBM Cloud Secrets Manager. Weil sich das Risiko sehr stark konzentriert, wenn all Ihre Secrets an einem Ort sind, müssen Sie beim Einsatz eines Secrets Manager sehr sorgfältig vorgehen. Ich empfehle Ihnen in den meisten Fällen, einen zu verwenden, der von einem Cloud-Provider »as a Service« angeboten wird.
Encryption Keys oder kryptografische Schlüssel sind eine spezifische Art von Secrets, die zum Verschlüsseln und Entschlüsseln von Daten dienen. Wie bei der Secrets Configuration hat der Einsatz eines speziell für diese Art von Daten gedachten Service viele Vorteile, wie zum Beispiel Wrap- und Unwrap-Operationen, ohne das Exponieren des Master Key durchführen zu können. Sie müssen alle Assets ermitteln, die Schlüssel speichern, und den Zugriff auf sie sorgfältig kontrollieren, wie Sie auch den Zugriff auf die verschlüsselten Daten steuern müssen.
Diese Art von Systemen wurde genauer in Kapitel 2 besprochen. Die wichtigsten Arten von Encryption Key Storages sind dedizierte Hardware Security Modules und Multitenant Key Management Systems.
Eine weitere Spezialisierung eines Secrets Storage ist ein Certificate Storage. Solche Systeme können die privaten Schlüssel Ihrer X.509-Zertifikate speichern, die genutzt werden, um kryptografisch zu beweisen, dass Sie die Zertifikate besitzen. Zudem können diese Systeme Sie benachrichtigen, wenn eines Ihrer Zertifikate auszulaufen droht, sofern Sie keine Automatismen verwenden (wie zum Beispiel Tools, die das ACME-Protokoll implementieren), um sie zu erneuern.
Viele Organisationen achten sorgfältig darauf, all ihre anderen Arten von Assets zu protokollieren, lassen es aber zu, dass ihr Quellcode überall verstreut ist und mithilfe vieler verschiedener Pipelines gebaut wird.
In vielen Fällen muss Quellcode nicht als Secret behandelt werden, wenn man sich an die guten Praktiken wie das Trennen von Konfiguration und Secrets hält. Aber es ist sehr wichtig, sicherzustellen, dass bei einem Angriff nicht Ihr Quellcode oder Artefakte während des Deployments verändert werden können.4 Daher müssen diese Assets dokumentiert werden, um ihre Integrität schützen zu können.
Zudem brauchen Sie einen guten Überblick über Ihre Quellcode-Repositories, um sie effektiv auf Schwachstellen überprüfen zu können. Es gibt Tools, um auf Bugs im von Ihnen geschriebenen Code zu prüfen, aber auch um auf Fehler in Code hingewiesen zu werden, den Sie von anderen Quellen einbinden. Diese Tools können nicht mit Code arbeiten, von dem sie nichts wissen! Das wird ausführlicher in Kapitel 5 behandelt.
Network Assets sind das Cloud-Äquivalent von Switches, Routern, Virtual Local Area Networks (VLANs), Subnets, Load-Balancer-Komponenten und ähnlichen Assets in der On-Premises-Welt. Sie ermöglichen die Kommunikation zwischen anderen Assets und der Außenwelt, und sie setzen oft auch bestimmte Sicherheitsfunktionen um.
Virtual Private Clouds (VPCs) und Subnets sind Möglichkeiten, auf einem hohen Level Grenzen um das zu ziehen, was miteinander reden darf. Es ist wichtig, darüber einen guten Überblick zu haben – wie schon erwähnt, hängt bei vielen anderen Schutzmaßnahmen, wie zum Beispiel Netzwerkscannern, die Effektivität davon ab, dass sie gute Eingangsparameter erhalten. Subnets und VPCs werden genauer in Kapitel 6 besprochen.
Content Delivery Networks (CDNs) können Inhalte global mit geringer Latenz zur Verfügung stellen. In den meisten Fällen sind die Inhalte in einem CDN zwar nicht kritisch, aber Angreifer mit Zugriff auf das CDN könnten sie durch Malware, Bitcoin Miner oder Code für einen Distributed Denial-of-Service (DDoS) »vergiften«.
Sie müssen Ihre DNS-Domains und die von Ihnen genutzten Registrare dokumentieren. Auch wenn TLS-Verbindungen einen Schutz vor Spoofing bieten, nutzen manche Browser nicht standardmäßig TLS, und User ignorieren gerne die Warnungen. Das Spoofen von DNS Records kann jemanden dazu bringen, eine böswillige Seite statt der Ihren aufzurufen, und dann können Credentials entwendet, alle Ihre Site durchlaufenden Daten mitgelesen und sogar Daten auf dem Transportweg verändert werden.
Neben Sicherheitsaspekten können Ihre Services auch nicht mehr verfügbar sein, wenn Sie eine Ihrer DNS-Domains nicht dokumentieren und vergessen, sie zu erneuern.
TLS-Zertifikate – oft immer noch als SSL-Zertifikate bezeichnet, wobei X.509-Zertifikate der korrektere Begriff wäre – bauen auf kryptografischen Prinzipien auf. Sie sind die beste Verteidigungslinie gegen Angriffe, bei denen Ihre Website gespooft wird. Sie müssen Ihre TLS-Zertifikate aus folgenden Gründen protokollieren:
Haben Sie viele Zertifikate, sollten Sie darüber nachdenken, einen Certificate-Storage-Service zu nutzen (siehe oben), um sie managen zu können.
DNS Records zeigen normalerweise auf Load Balancer, Reverse Proxies oder Webanwendungs-Firewalls, um Traffic zu verarbeiten und zu verteilen. Es ist wichtig, einen guten Überblick über diese Assets zu besitzen, um eine saubere Zugriffskontrolle zu ermöglichen. Denn diese Assets können im Allgemeinen den gesamten Netzwerk-Traffic für Ihre Anwendungen sehen und manipulieren. Im Detail sprechen wir darüber in Kapitel 6.
So, jetzt wissen Sie, nach welchen Arten von Assets Sie Ausschau halten müssen. Aber wie können Sie sie protokollieren? In den meisten Organisationen gibt es ganz natürliche Kontrollpunkte beim Provisionieren von Services und Infrastruktur. Diese sind je nach Organisation unterschiedlich, aber Sie müssen diese Punkte finden und dafür sorgen, dass sie immer durchlaufen werden, damit Sie alles über Ihre Cloud Assets wissen und sich entsprechend um die Risiken kümmern können.
Ich möchte das anhand einer Klempner-Analogie erläutern. Stellen Sie sich vor, Sie hätten eine Pipeline mit Ihren diversen Cloud Assets, die von Ihren Cloud-Providern zu Ihren verschiedenen Sicherheitssystemen fließen. Sie müssen versuchen, zu verhindern, dass es »Lecks« beim Asset Management gibt, wodurch Assets ohne wichtige Sicherheitsvorkehrungen in Betrieb genommen werden. Das ist bedeutsam, wenn Sie die gesamte IT Ihrer Firma betreiben, aber auch, wenn Sie nur für eine einzelne Anwendung verantwortlich sind. Konzeptionell sieht das wie in Abbildung 3-1 aus. Wir werden uns die verschiedenen Arten von Lecks anschauen, die dabei auftreten können.
Abbildung 3-1: Beispiel für eine Asset Management Pipeline
An der Quelle haben Sie mehrere Möglichkeiten, Assets erstellen zu lassen. Es kann diverse Cloud-Provider mit unterschiedlichen Delivery-Modellen geben (IaaS, PaaS, SaaS), die verschiedenste Arten von Assets provisionieren. In den meisten Fällen werden Ihnen diese Assets in Rechnung gestellt. Das bedeutet häufig, dass ein guter erster Schritt ein Blick auf den Beschaffungsprozess ist.
Manche Cloud-Provider besitzen eingebaute Asset-Management-Systeme, die schon mit den anderen angebotenen Services integriert sind und eventuell sogar die Möglichkeit besitzen, Assets aus Ihren On-Premises-Umgebungen oder von anderen Cloud-Providern zu übernehmen. Da entwickelt sich gerade so einiges, daher sollten Sie sich anschauen, was Ihre Provider zu bieten haben, bevor Sie eine eigene Lösung bauen.
Das Ganze ist nicht narrensicher – manche Cloud-Ressourcen können provisioniert werden, ohne dass Geld ausgegeben werden muss, und in größeren Organisationen sind Menschen eventuell dazu in der Lage, ihre Ausgaben für die Cloud auf unterschiedliche Art und Weise zu kategorisieren. Aber es ist ein guter Ausgangspunkt.
Schauen Sie sich Ihre IT-Kosten an. Sie müssen sich für jede Cloud-Ausgabe an die Person wenden, die dafür verantwortlich ist, und (zumindest beschränkte) Auditing-Credentials bekommen.5 So können Sie automatisch Inventarinformationen ermitteln. Ein »Leck« bedeutet hier im Allgemeinen, dass Sie einen ganzen Cloud-Provider übersehen haben – entweder weil Sie von dort keine Rechnungen zu Gesicht bekommen haben oder weil es sich um einen kostenlosen Service handelt.6
Der zweite Schritt besteht darin, diese Audit-Credentials zu nutzen, um herauszufinden, was die Cloud-Provider genau für Sie tun. Sie müssen also deren Portale, APIs oder Inventursysteme nutzen, um sich eine Liste mit Assets erstellen zu lassen. Beachten Sie, dass es auch Assets innerhalb von anderen Assets geben kann. So haben Sie vielleicht einen Webserver innerhalb einer VM.
Jeder Cloud-Provider besitzt ein Portal, eine API oder einen Satz an Befehlszeilentools, die Ihnen dabei helfen können, Informationen über Assets zu ermitteln. So gut wie immer lohnt es sich, per API oder Befehlszeile zu automatisieren, weil manuell erzeugte Listen nur schwer aktuell zu halten sind. Aber ein manuelles Verzeichnis ist besser als gar keines, und für ein paar Arten von Assets, die sich nur sehr selten ändern, kann es sogar ausreichend sein.
Neben Portalen und APIs bieten manche Cloud-Provider und Fremdanbieter Inventory oder Security Tracking Systems an. Manche Systeme erlauben Ihnen sogar, sich anzuschauen, was auf den unterschiedlichen virtuellen Maschinen installiert ist, dies direkt mit anderen verfügbaren Sicherheitsservices zu kombinieren (wie zum Beispiel Scannern) und Assets von anderen Providern oder On-Premises-Infrastruktur zu importieren. Tabelle 3-1 führt einige der aktuell verfügbaren Services auf.
Tabelle 3-1: Optionen für das Auditieren von Cloud-Aktivitäten
Infrastruktur |
Möglichkeiten zum Auditieren |
Amazon Web Services |
API, Portal, Befehlszeile, AWS Systems Manager Inventory |
Microsoft Azure |
API, Portal, Befehlszeile, Azure Automation Inventory |
Google Cloud Platform |
API, Portal, Befehlszeile, Cloud Security Command Center Asset Inventory |
IBM Cloud |
API, Portal, Befehlszeile, IBM Cloud Security Advisor |
Stellen Sie sicher, dass Sie sich jeden Asset-Typ genauer anschauen, um zusätzliche Assets zu finden, die aus einem Sicherheitsblickwinkel wichtig sein könnten. Ein »Leck« bedeutet hier, dass Sie den Cloud-Provider nach Assets gefragt, aber manche der Cloud-Assets dieses Providers nicht abgerufen haben. So haben Sie vielleicht beispielsweise alle virtuellen Maschinen inventarisiert, aber die Object Storage Buckets vergessen, die Ihr Team provisioniert hat. Dokumentieren Sie diese Object Storage Buckets nicht, werden die folgenden Tools und Prozesse die Buckets nicht prüfen können, um sicherzustellen, dass der Zugriff auf sie ordentlich kontrolliert wird oder ihnen die richtigen Tags zugewiesen sind.
Mit dem dritten Schritt stellen Sie sicher, dass jedes Tool, das dabei hilft, die Sicherheit Ihrer Assets zu überprüfen, mit diesem Asset-Inventar verbunden ist und die Informationen auslesen kann, die es zum Erledigen seiner Aufgabe benötigt. Hier ein paar Beispiele:
Ein »Leck« bedeutet hier, dass Sie bestimmte Assets kennen, Ihre Tools oder Prozesse diese aber nicht auf Sicherheitsprobleme überprüfen. Weitere Informationen zu diesen Tools und Schutzmaßnahmen werden in Kapitel 5 vorgestellt, aber Tools können nun einmal keine Schwachstellen in Assets finden, von denen sie nichts wissen.
Im letzten Schritt stellen Sie sicher, dass Sie alle Erkenntnisse aus Ihren Tooling-Systemen auch tatsächlich berücksichtigen. Das mag offensichtlich sein, aber in der Praxis werden diese Ergebnisse oft ignoriert, insbesondere bei »lauten« Scanning-Systemen, die viele falsch-positive Ergebnisse produzieren.
Es ist vollkommen in Ordnung, sich dazu zu entscheiden, eine Erkenntnis oder ein Risiko zu akzeptieren und es nicht zu beheben, aber wenn Sie die Ergebnisse einfach ignorieren, ohne sie zumindest durchzugehen, ist das ein »Leck«.
Es ist sinnvoll, Ihre Assets beim Erstellen zu kategorisieren und zu organisieren, sodass Sie wissen, was sie enthalten und wofür sie gedacht sind. Tags können eine Automatisierung und eine Zugriffskontrolle viel einfacher machen. So wie Sie Ihre Data Assets mit den Arten von Daten in Kapitel 2 getaggt haben, so müssen Sie auch andere Arten von Assets taggen, um sowohl den Typ der damit verarbeiteten Daten zu kennzeichnen als auch zu erklären, wofür sie benötigt werden.
Es ist wichtig, die gleichen Daten-Tags aus Kapitel 2 zu nutzen, um die mit einem Compute Asset verarbeiteten Arten von Daten zu kennzeichnen, damit Sie einen konsistenten Überblick darüber haben, wo Ihre Daten gespeichert und verarbeitet werden. Während es aber recht einfach ist, einen Satz von Klassifikationsstufen oder eine Liste von Compliance-Anforderungen zusammenzustellen, gibt es fast unendlich viele Möglichkeiten für andere operative Tags.
Hier ein paar Beispiele für eventuell sinnvolle Arten von Tags:
Bei vielen Cloud-Providern ist die Groß- und Kleinschreibung bei Tags entscheidend, daher werden ApplicationA und applicationA nicht übereinstimmen.
Schauen wir uns unsere Beispielanwendung aus Kapitel 1 an, stellen wir fest, dass wir die Server mit Tags versehen können (siehe Abbildung 3-2).
Ein sauberes Taggen kann automatisierte Sicherheitsprüfungen ermöglichen. So haben Sie beispielsweise eventuell eine sehr sinnvolle Policy, dass kritische Daten nicht auf Entwicklungs- oder Testsystemen gespeichert werden dürfen. Um dabei sicherzustellen, dass diese Policy auch greift, könnten Sie Folgendes tun:
Abbildung 3-2: Diagramm der Beispielanwendung mit Tags
Damit Tags effektiv sein können, müssen Sie einen konsistenten Satz mit Tag-Namen und zulässigen Werten pflegen – Sie brauchen also einen Tagging-Standard und müssen sich auch daran halten. In den meisten kleineren Organisationen sollte der Tagging-Standard auch organisationsweit gelten. Eine größere Organisation wird sich auf organisationsweite Tags einigen, aber auch Tags erlauben müssen, die von bestimmten Business Units genutzt werden können. In beiden Fällen sollte klar sein, wer dafür zuständig ist, den Tagging-Stand bei Bedarf um zusätzliche Tags zu erweitern.
Sie sollten auch einen Automatismus entwickeln, der sämtliche aktuell genutzten Tags einsammelt und alle aufführt, die nicht im Tagging-Standard für Ihre Organisation oder Business Unit enthalten sind.
Es gibt heutzutage so viele Cloud-Angebote as a Service, dass es schwierig sein kann, sie alle zu verstehen und zu protokollieren.
Sie müssen bei Ihren Inventuraktivitäten möglichst viel rausholen. Priorisieren Sie daher das Dokumentieren von Providern und Assets, bei denen eine fehlende Erfassung am wahrscheinlichsten eine große Auswirkung hat, wie zum Beispiel Assets, die kritische Daten speichern oder verarbeiten, oder solche mit administrativer Kontrolle über andere Assets. Sie könnten beispielsweise entscheiden, sich keine Gedanken über das Dokumentieren all Ihrer VM-Images zu machen, solange sie noch nicht all Ihre Datenbanken mit Kundendaten, Ihre bestehenden virtuellen Maschinen mit Zugriff auf diese Datenbanken und Ihren Quellcode (und abhängige Bibliotheken) zum Verarbeiten der Kundendaten erfasst haben.
Verfolgen Sie einen Pipeline-Ansatz, der Cloud-Provider, die von diesen Providern erzeugten Assets, die Ergebnisse der Auswertungen Ihrer Tools für diese Assets und die Aktionen aus diesen Ergebnissen dokumentiert. Haben Sie Probleme, in der Organisation Unterstützung für eine Asset-Management-Lösung rein aufgrund der Sicherheitsanforderungen zu finden, können Sie sie auch noch als Maßnahme zum Einsparen von Kosten bewerben.
Nachdem Sie nun verstanden haben, was für Cloud Assets es gibt und wie Sie sie am besten inventarisieren, wollen wir uns anschauen, wie diese Assets und die Daten darin vor den am häufigsten anzutreffenden Sicherheitsproblemen geschützt werden können – den Problemen mit dem Identity and Access Management.
