Wie die Cloud IT-Sicherheit in AppSec verwandelt

Cloud-Computing ist zweifellos ein tiefgreifender Wandel in der Technologiewelt und ermöglicht Effizienzsteigerungen und Innovationen wie nie zuvor. Gleichzeitig hat es eine weitere wichtige Veränderung bewirkt, über die selten gesprochen wird: Die Cloud hat die Infrastruktur zu einem Teil der Anwendung gemacht.

Dieser Wandel hat erhebliche Auswirkungen darauf, wie wir Sicherheit umsetzen. Die heutigen Sicherheitstools und -praktiken sind überwiegend für zentrale IT- und Sicherheitsteams konzipiert und auf deren Kompetenzen und Umgebungen ausgelegt. Bei Cloud-Anwendungen treffen Entwickler Entscheidungen über Netzwerkzugriff, Betriebssystem-Patching, Zugriffsberechtigungen und vieles mehr – nicht die IT. Diese Entscheidungen werden für jede Anwendung einzeln statt zentral getroffen. Und sie fallen fortlaufend im Entwicklungsprozess an, nicht erst an bestimmten Prüfpunkten.

Die Auswirkungen dieser Entscheidungen auf die Sicherheit bleiben jedoch dieselben. Ein offener Port kann eine Cloud-VPC genauso gefährden wie ein Netzwerksegment in einem Rechenzentrum. Ein ungepatchter Container kann ebenso gehackt werden wie eine Bare-Metal-Maschine. Es gelten dieselben Risiken, die durch den Umfang der Anwendung oft noch verstärkt werden.

Deshalb müssen wir unsere Herangehensweise an diese Bedrohungen überdenken – diesmal jedoch im Kontext der Anwendung und mit anderen Teams, Prozessen und Kompetenzen. In diesem Beitrag beschreibe ich, wie sich der Umfang der Anwendung auf die Infrastruktur ausgeweitet hat, und gehe auf die Auswirkungen für die Sicherheit ein. Ich bin überzeugt, dass diese Perspektive Ihnen bei der Gestaltung Ihrer Sicherheitspraktiken, der Auswahl Ihrer Tools und der Organisation Ihrer Teams hilft.

Hinweis zum Sprachgebrauch: Ich verwende den Begriff „Cloud“ nicht nur für Cloud-Computing, sondern auch für Container, Serverless und viele weitere Technologien. Außerdem spreche ich von der Zeit „vor und nach“ der Cloud, obwohl sich in der Praxis nur wenige Unternehmen in einer Übergangsphase befinden. Diese vereinfachte Darstellung ist bewusst gewählt, um das Gesamtbild zu verdeutlichen – mir ist durchaus bewusst, wie komplex dieses Thema ist!

Anwendungen vor dem Cloud-Zeitalter

Vor der Cloud basierten Anwendungen auf einem umfangreichen IT-Stack. Ich beschreibe diese Zeit in der Vergangenheitsform, obwohl die meisten Unternehmen in der Praxis nach wie vor überwiegend so arbeiten.

Unternehmen verfügten über ein Rechenzentrum, in dem die zentrale IT die Kapazitäten sorgfältig verwaltete und Ressourcen zuteilte. Sie mussten die verfügbare Rack-Fläche im Blick behalten, Server kaufen und in Betrieb nehmen, Hardwareausfälle verwalten und nachverfolgen, wer welchen Server nutzte. Brauchte eine Anwendung einen Server, waren dafür Formulare und Genehmigungen nötig: Ein zusätzlicher Server bedeutete entweder höhere Ausgaben oder, dass jemand anderes keinen Server bekam.

Mit der Virtualisierung kam eine weitere IT-Ebene hinzu, in der Regel vSphere. Sie verwaltete virtuelle Maschinen auf der physischen Infrastruktur. Das steigerte die Effizienz, änderte aber nichts am grundlegenden Prozess: Die Kapazitäten waren weiterhin begrenzt und wurden gemeinsam genutzt. Für einen Server musste also ein Ticket eingereicht werden, und eine zentrale IT-Abteilung verwaltete sowohl die Serverkapazität als auch die darüberliegende Virtualisierungsebene.

Neben den Servern verwaltete die IT auch die Netzwerke. Diese wurden über physische Switches und Router konfiguriert. Dabei ging es weniger um Kapazitäten als um Zugriffskontrollen: Welche Nutzer dürfen auf das Netzwerk zugreifen, und welche Netzwerke können miteinander verbunden werden? Netzwerke sind oft komplex – auch deshalb spielte die zentrale IT eine wichtige Rolle. Sie verwaltete komplizierte Kommunikationsberechtigungen im gesamten Rechenzentrum und teilte außerdem die Bandbreite zu.

Neben der Hardware verwaltete die IT auch zentrale Ressourcen. Dazu gehörten beispielsweise Golden Images für virtuelle Maschinen. Auf diesen Golden VMs war genehmigte Software installiert, die auf rechtliche Anforderungen, Sicherheit und allgemeine Qualitätskriterien geprüft worden war. Die zentrale IT überwachte diese VMs ebenfalls und aktualisierte sie, um Schwachstellen zu beheben oder Änderungen an Unternehmensrichtlinien umzusetzen. Anwendungen wurden häufig manuell auf diesen VMs installiert und bei Bedarf neu gestartet, damit solche Updates übernommen werden konnten. 

Verwaltete Services waren ein weiteres Beispiel für zentrale Ressourcen. So konnte die IT etwa eine große, zentrale Oracle-Datenbank verwalten, die Anwendungen für ihren Betrieb benötigten. Eine oder mehrere Datenbankadministratorinnen oder -administratoren (DBAs) verwalteten Indizes und Tabellen und arbeiteten bei Bedarf mit verschiedenen Anwendungsteams zusammen, um diese an deren Anforderungen anzupassen.

Darüber lag die Anwendung selbst. Anwendungen bestanden aus Code und Bibliotheken und mussten in einer ganz bestimmten Umgebung bereitgestellt werden, um zu funktionieren. Jede Änderung an der Hardware, den Basis-VMs, der Datenbanknutzung, dem CDN oder anderen Komponenten erforderte ein Ticket – und Geduld.

Damals war das sinnvoll, denn die Ressourcen waren begrenzt und mussten gemeinsam genutzt werden. Zusätzliche physische Kapazitäten – ob Server, Netzwerk oder Speicher – zu schaffen, kostete viel Zeit und Geld. Eine zentrale Anwendung zu implementieren oder zu erweitern, erforderte erheblichen Aufwand durch die zentrale IT. Auch sie war eine gemeinsam genutzte Ressource, deren Kapazität sich nur langsam und teuer ausbauen ließ. Wenn also eine Anwendung einen größeren Anteil bekam, blieb für eine andere weniger übrig – ein Nullsummenspiel.

Anwendungen im Cloud-Zeitalter

Dann kam die Cloud und beseitigte diese Einschränkungen.

Hardwarekapazität war kein Problem mehr. Entwickler benötigen lediglich Zugriff auf ein Cloud-Konto und können dann so viele Server bereitstellen, wie ihr Budget zulässt. Über Self-Service- und softwaregesteuerte Funktionen lassen sich diese Server flexibel skalieren – ganz ohne Beteiligung der zentralen IT.

Netzwerke sind nicht mehr voneinander abhängig. Anwendungsteams können ihre eigene Virtual Private Cloud (VPC) erstellen, die von der Cloud-Plattform vom Rest getrennt wird. Der Netzwerkzugriff lässt sich detailliert an die Anforderungen der Anwendung anpassen und vollständig per Software konfigurieren – im Self-Service.

Cloud-VMs werden weniger zentral verwaltet als ihre Vorgänger im Rechenzentrum. Container haben diese Verbindung jedoch vollständig gekappt. Anweisungen zum Erstellen von Containern werden üblicherweise in einem Quellcode-Repository definiert und zusammen mit der Anwendung erstellt. Dadurch kann die zentrale IT sie nur schwer einsehen und praktisch nicht patchen. Selbst zentral verwaltete „Golden Images“ verlieren an Bedeutung: Patches für diese Images greifen erst, wenn eine Anwendung neu erstellt wird, und Entwickler nutzen zunehmend externe Basis-Images.

Zentrale Anwendungen wurden durch einfach zu nutzende Services ersetzt, die in die Cloud-Plattform integriert sind, etwa Datenbanken, Authentifizierung, Messaging und vieles mehr. Anders als die meisten zentralen Anwendungen werden diese Services über APIs gesteuert und sind darauf ausgelegt, von Entwicklungsteams im Self-Service bereitgestellt und genutzt zu werden. Vorgefertigte Container ersetzten kleinere Anwendungen. Sie lassen sich einfach aus Docker Hub beziehen und als weitere Microservices in die Anwendungsarchitektur einfügen. In beiden Fällen gehören Tickets und Wartezeiten auf knappe IT-Ressourcen, die Ihre Anwendung bereitstellen, der Vergangenheit an.

Schließlich entstanden DevOps-Teams, manchmal auch SRE- oder Platform-Teams genannt, die die zentrale IT durch eng eingebundene Betriebsteams ersetzten. Diese Teams versuchen nicht, die von Anwendungen genutzte Infrastruktur zu kontrollieren. Stattdessen stellen sie Tools und Services wie Kubernetes bereit, mit denen Entwickler die in ihre Anwendungen integrierten Infrastrukturebenen eigenständig betreiben können.

Infrastruktur als Teil der Anwendung absichern

Mit der Zeit macht die Cloud den Großteil der zentral verwalteten Infrastruktur überflüssig. Stattdessen wird diese Infrastruktur selbst zu einem Teil der Anwendung. Dieser Trend wird sich unweigerlich fortsetzen: CDNs, API-Gateways, Middleware und vieles mehr werden Teil der Anwendung und erhöhen so die Unabhängigkeit und Geschwindigkeit der Entwicklungsteams. Dieser Wandel begann in der Public Cloud, hat sich in der Praxis aber auch auf die Private Cloud ausgeweitet, die dieselben Vorgehensweisen übernimmt.

Die Sicherheitsrisiken sind jedoch nicht verschwunden.

Ein ungepatchter Container lässt sich ebenso leicht hacken wie eine vernachlässigte VM oder Bare-Metal-Maschine. Ein unnötig offener Port kann Angreifern Zugriff auf vertrauliche Daten verschaffen – unabhängig davon, wo diese gehostet werden. Und unverschlüsselte Daten in einer Datenbank können sehr schnell kompromittiert werden, insbesondere wenn sie in einem gemeinsam genutzten Service gespeichert sind. Es gelten dieselben Angriffsvektoren. Wir sollten diese Sicherheitsrisiken im Blick behalten und Maßnahmen zum Schutz unserer Anwendungen ergreifen.

Ändern muss sich die Art und Weise, wie wir uns gegen diese Infrastrukturbedrohungen schützen.Die heutigen Lösungen und Praktiken sind für zentrale IT-Teams konzipiert, nicht für eigenständig arbeitende Anwendungsteams. Manchmal werden sie nachträglich so angepasst, dass getrennte Teams sie nutzen können. Wirklich für diesen Anwendungsfall geeignet sind sie jedoch nur selten.

Wir müssen eine neue Perspektive einnehmen, die auf dieser neuen Realität der „Infrastruktur als Teil der Anwendung“ beruht. Ein solches Umdenken ist eine große Aufgabe, die sich nicht in ein paar kurzen Stichpunkten zusammenfassen lässt. Hier sind dennoch einige Beispiele für Änderungen, die Sie in Betracht ziehen sollten:

• Überdenken Sie die Struktur Ihrer Sicherheitsorganisation, damit sie Cloud-Produkte absichern kann. Die Sicherheit von IT-Stacks wurde so gestaltet, dass sie gut mit der IT-Organisationsstruktur zusammenarbeitet. Die Sicherheit von Anwendungs-Stacks sollte hingegen auf die Entwicklungsorganisation ausgerichtet sein. Zu diesem Thema hätte ich noch viel mehr zu sagen, aber das wird wahrscheinlich ein eigener Beitrag …

• Verstehen Sie die Anforderungen von Anwendungsentwicklern. Nehmen Sie sich Zeit, ihre Realität zu verstehen – nicht nur ihre Technologie – und passen Sie Ihre Praktiken, Tools und Erwartungen an ihre Bedürfnisse an. Die branchenüblichen Best Practices orientieren sich oft an den Anforderungen der IT, nicht der Entwicklung. Verlassen Sie sich also nicht einfach auf sie.

• Gehen Sie nicht davon aus, dass Ihre bestehenden Lösungen aus der Zeit vor der Cloud auch für Cloud-Anwendungen geeignet sind. Dieselben Tools für alte und neue Stacks zu verwenden, ist zwar praktisch, aber wahrscheinlich werden sie beiden Umgebungen nicht gleichermaßen gerecht. Prüfen Sie, welche anderen Tools Ihr Anbieter im Portfolio hat und welche Alternativen es gibt, und wählen Sie das passende Tool für die Cloud-Umgebung.

• Investieren Sie in flexible, API-gesteuerte Sicherheits-Tools mit Self-Service-Funktionen. IT-Teams übernehmen eine zentrale Funktion, sodass Sie mehr Zeit in individuelle Integrationen investieren können. Entwicklungsteams und ihre Stacks unterscheiden sich deutlich stärker. Investieren Sie in Tools, die sich an unterschiedliche Umgebungen anpassen lassen und dabei vergleichbare Sicherheitskontrollen und Governance ermöglichen.

Dieser Wandel vollzieht sich nicht über Nacht. In zehn Jahren werden Anwendungen aus der Zeit vor der Cloud als Legacy gelten – ebenso wie heute Mainframe-Umgebungen und ihre veralteten Sicherheitskontrollen. Jetzt ist der richtige Zeitpunkt, die nächste Generation Ihrer Sicherheitslösungen aufzubauen.