Auf die eine oder andere Art haben praktisch alle Unternehmen Berührungspunkte mit der Cloud, selbst wenn es vielen nicht unbedingt direkt bewusst sein mag. Je nach Art und Umfang der Cloud-Nutzung entstehen dadurch direkte Folgen für die Cybersicherheit. [...]
Die Migration von Unternehmen in die Cloud ist ein weit gefasster Begriff, der viele verschiedene Trends umfasst. Zum Ersten die Verlagerung bestehender Anwendungen von privaten Rechenzentren zu einem Cloud Service Provider (CSP) wie AWS, Azure oder Google Cloud Platform, oft auch als Lift-and-Shift oder Infrastructure-as-a-Service (IaaS) bezeichnet.
Möglich ist auch die völlige Umstrukturierung der Art und Weise, wie Anwendungen erstellt werden, um die auf diesen Cloud-Service-Plattformen verfügbaren vorkonfigurierten Dienste – oft als Lift-and-Shift, Serverless oder Platform-as-a-Service (PaaS) bezeichnet – stärker zu nutzen. Zum Dritten die Entscheidung, auf die Ausführung von Kopien von Standardanwendungen zu verzichten und sie stattdessen vom Anbieter der Anwendung hosten zu lassen – manchmal auch als Drop-and-Shop oder Software-as-a-Service (SaaS) bezeichnet.
Jede dieser drei Migrationen bringt verschiedene Sicherheitsherausforderungen mit sich:
Infrastructure-as-a-Service
Auf den ersten Blick zieht die IaaS-Migration die geringste Veränderung nach sich. Schließlich ist es nur so, dass in der Cloud eine Anwendung auf dem Computer des Cloud-Betreibers läuft. CSPs stellen diesen Computer zur Verfügung, zusammen mit einer völlig neuen und ungewohnten Verwaltungs- und Steuerungsebene, neuen Identitäts- und Zugriffsparadigmen und neuen Formen der Speicherung.
Die erste Generation von Sicherheitsvorfällen im Zusammenhang mit der Cloud war darauf zurückzuführen, dass Unternehmen dieses neue Paradigma nicht verstanden. Sie legten vertrauliche Informationen in Cloud-Speichern ab, während der Zugang zum Internet offenblieb. Vor Ort, in On-Premises-Umgebungen war dies nicht der Fall, da Netzwerk-Firewalls und Segmentierung diese Art von Fehlkonfiguration verhinderten. Was sich änderte, war die Tatsache, dass es keine echte Möglichkeit gab, alle Ressourcen in der Cloud physisch mit einem Netzwerk zu umgeben und Firewalls an den Rand dieses Netzwerks zu stellen. Leider ist der über das Internet zugängliche Speicherplatz nur ein Symptom dafür, dass sich die IaaS-Cloud stark von der Einrichtung im eigenen Rechenzentrum unterscheidet.
Der Angriff auf AWS im August 2019, der Capital One zu seinem sichtbarsten Ziel zählte, gibt einen Einblick in die Komplexität der Management- und Kontrollebenen von AWS und die Schwierigkeit, alle Sicherheitskontrollen richtig durchzuführen. Das Vorhandensein einer einfachen Schwachstelle in einer Web-Application-Firewall (WAF), die über das Internet ausgenutzt werden konnte, führte zu einem groß angelegten Durchsickern vertraulicher Informationen über mehrere AWS-Kunden hinweg.
Der Kern des Problems ist einfach: CSPs stellen unglaublich komplexe Ökosysteme zur Verfügung, die ständig im Wandel begriffen sind, wenn neue Funktionen hinzugefügt werden. Bei der Einführung von Cloud-Diensten wird die Sicherheit von Natur aus zu einem Modell der geteilten Verantwortung. In diesem Modell obliegt es den CSP-Kunden, ihre Hälfte des Sicherheitsbetriebs, der sich perfekt an die sich ändernde Bedrohungsoberfläche der CSP-Architektur anpassen muss, beizusteuern.
Platform-as-a-Service
Bei PaaS gibt es keine Illusionen, dass alles dasselbe ist. Viele Kunden verstehend jedoch die Auswirkungen der Einführung von PaaS auf die Sicherheit nicht richtig. Die fraglichen Dienste reichen von einfachen (Storage) bis hin zu recht komplexen (Analytik-Stacks). Und jeder dieser Dienste hat seine eigenen Sicherheitseigenheiten.
Im Falle von Amazon DynamoDB muss das Ingenieurteam verstehen, wie sich AWS-Identität und rollenbasierte Zugriffskontrolle (RBAC) mit DynamoDB überschneiden. Es gilt separate Best Practices für die Sicherheit zu befolgen – für präventive Sicherheit und andere für detektivische Sicherheit – und das nur für DynamoDB.
Zusätzlich zum komplizierten Schutz von Diensten wie DynamoDB gibt es bei PaaS-Diensten eine größere Herausforderung: Sicherheitsteams haben keine bereits existierenden Modelle, die zeigen, wie ein in eine Anwendung eingebetteter Dienst gesichert werden kann, ohne ihn mit einem sicheren Netzwerk zu umgeben. Es gibt keine Möglichkeit, dieses Modell auf PaaS-gelieferte Dienste anzuwenden. Bei der Einführung neuer Dienste werden CSPs, die diese Dienste entwickeln, anhand der Akzeptanz des Dienstes beurteilt.
Wenn CSPs Entscheidungen über die Standardsicherheit eines neuen Dienstes treffen, beseitigen sie in der Regel eher Barrieren, um den Kunden die Einführung zu erleichtern, anstatt zusätzliche Sicherheitskontrollen hinzuzufügen. Diese könnten die Akzeptanz des Dienstes seitens der Kunden bremsen.
Software-as-a-Service
SaaS hat sich in großem Stil durchgesetzt. Unternehmen erkennen, dass sie damit buchstäblich über Nacht neue Anwendungen auf den Markt bringen können und sich nie um Software-Upgrades, Backups und andere alltägliche Supportaufgaben kümmern müssen. Die meisten SaaS-Anwendungen bieten jedoch wenig Einblick in Netzwerk- und Sicherheitskontrollen. Kunden haben eine gewisse Autorität darüber, wer auf Anwendungen, Berechtigungen, Datenzugriff und – im Idealfall – eine API zugreifen kann, die Zugriffsprotokolle zur Validierung extrahiert.
Das Sicherheitsmodell von SaaS hängt im Wesentlichen von der Identität und dem Zugriff ab. Die Konfiguration von SaaS-Anwendungen ist jedoch unglaublich komplex geworden. Der Versuch, alle Aspekte von Office 365 oder Salesforce zu verstehen und zu schützen, würde die meisten IT-Fachkräfte vor Herausforderungen stellen. Dies ist zudem nur ein Teil einer viel größeren Aufgabe für IT-Teams ist, die mit der Bereitstellung des Zugriffs und der Überwachung von Sicherheitsfragen für Anwendungen betraut sind. Da immer mehr Unternehmen mehrere SaaS-Anwendungen nutzen, wird das Ein- und Aussteigen von Mitarbeitern beim Zugriff auf SaaS-Anwendungen ziemlich umständlich. In einigen Fällen haben Mitarbeiter auch noch lange nach ihrem Ausscheiden Zugriff auf Anwendungen.
Viele Unternehmen wenden sich an Identitätsprovider und Verbundlösungen zwischen verschiedenen SaaS-Anwendungen, um diese Aufgabe zu automatisieren, wobei häufig ein Cloud-basiertes HR-System als Hauptdatenbank verwendet wird. Leider ist nur eine kompromittierte SaaS-Anwendung oder ein Konto für einen Angreifer erforderlich, um vollen Zugriff auf andere Anwendungen und Server im Verbund zu erhalten. Dies bietet Angreifern einen ausgezeichneten Ausgangspunkt für weitere laterale Bewegungen. Darüber hinaus gibt es kein sicheres Netzwerk, das als Sicherheitsnetz fungiert, wenn ein Endbenutzer erfolgreich Phishing zum Opfer fällt oder ein Fehler bei der Konfiguration eines Teils des Cloud-Modells mit geteilter Verantwortung vorliegt.
*Andreas Müller ist Director DACH bei Vectra AI.
Be the first to comment