Der Begriff „Cloud“ erweckt den Eindruck, es handele sich dabei um ein abstraktes Gebilde mit ganz eigenen Regeln. Tatsächlich handelt es sich aber auch bei einer „Cloud“ letztendlich nur Computer/ Server anderer Personen. Dementsprechend unterscheiden sich auch die möglichen Angriffsvektoren nicht frappierend von On-Prem-Umgebungen. Die Verteilung der Verantwortlichkeiten von Anbieter und Nutzer in Bezug auf IT Sicherheit sind ein Aspekt, der beim Cloud Pentesting besondere Beachtung finden muss. In diesem Artikel erläutern wir daher, wie sich die Gegebenheiten von Cloud-Settings auf Verantwortlichkeiten und Rahmenbedingungen eines Cloud Security Assessments auswirken.
Seit der Einführung erster cloudbasierter Systeme 2006 wächst das Angebot dedizierter Anbieter dieser Services stetig weiter. Diese reichen von der gesamtheitlichen Übertragung der eigenen Infrastruktur in die Cloud (bei der die Verantwortlichkeiten weiterhin im eigenen Unternehmen liegen) bis zur vollständigen, nativen Integration von Services (bei der man sich „um gar nichts mehr“ kümmern muss, was die darunter liegende Systempflege betrifft).
Die Cloud hat vieles für den täglichen Betrieb vereinfacht, gleichzeitig die Komplexität jedoch erhöht. Dies trifft auch auf den Bereich des Pentesting zu, denn die Cloud gibt es nicht „von der Stange“. Die Einsatzbereiche sind stets genauso individuell wie das Unternehmen selbst und stellen enorme Anforderungen und enge Rahmenbedingungen an ein Cloud Security Assessment.
Für ein Cloud Security Assessment macht es einen Unterschied, ob die betreffende Cloud-Infrastruktur auf eigenen Servern gehosted ist oder ob es sich um Public Cloud Umgebungen handelt.
Denn bei Public Cloud Umgebungen wie Microsoft Azure, Amazon Web Services oder die Google Cloud sind die Testmöglichkeiten innerhalb eines Penetrationstests eingeschränkt. Hier darf nur getestet werden, was im Scope der Cloud Anbieter liegt. Ein weiterer Faktor, der die Vorgehensweise eines Cloud Pentests beeinflusst, ist der Einsatzbereich der Cloud. Darauf gehen wir im folgenden Abschnitt ein.
Beim Scoping gilt es im Bereich Cloud Security Assessment einiges zu beachten: Während bei Infrastructure as a Service (IaaS) bis auf physischen Server und Netzwerkinfrastruktur alles in den Pentest einbezogen werden kann, beschränkt sich der Prüf-Scope bei Software as a Service (SaaS) auf den Umgang der Nutzer mit der Software. Warum ein Security Assessment in der Regel bei allen drei Varianten sinnvoll ist, erklären wir im Folgenden.
Unter Infrastructure as a Service oder kurz „IaaS“ versteht man gemeinhin die Übertragung und Migration der eigenen IT-Infrastruktur in die Cloud. Dies kann entweder vollumfänglich oder „hybrid“ geschehen. Hierfür ist die Anbindung der eigenen Active Directory Domäne an eine cloudbasierte Komponente wie Azure AD-Connect ein typisches Beispiel.
Hierbei liegt die Hauptverantwortung für den Betrieb, das Patchmanagement der virtualisierten Infrastruktur (mit Ausnahme der Hypervisor) sowie gehostete Inhalte weiterhin im eigenen Unternehmen. Lediglich die Verantwortung der Verfügbarkeit der Dienste sowie die unterliegende Hardware wird an den Clouddienstleister übertragen.
Was bedeutet das für das Scoping eines Pentests? Im Fall einer IaaS ergeben sich hier die kleinsten Unterschiede zum „klassischen“ Pentest. Typischerweise vom Scope ausgenommen sind hierbei Tests der physischen Server und Netzwerkinfrastruktur. Ansonsten könnte nicht sichergestellt werden, dass andere Teilnehmer auf derselben Plattform oder im selben Cluster nicht vom Test mit betroffen sind.
Bei Platform as a Service (PaaS) wird nur ein Teil der Infrastruktur in die Cloud verschoben. In der Regel handelt es sich hierbei um Dienste, die man externen Nutzern zur Verfügung stellen will, für die dedizierte Ressourcen jedoch überdimensioniert wären oder potenzielle Sicherheitsrisiken bergen können. Hierunter fallen beispielsweise Webpräsenzen wie Blogs, Unternehmensseiten oder Online-Shops.
Im Bereich des Cloud Security Assessment nähert man sich hier bereits einem schwierigen Terrain, da der Umfang des Pentests auf die Applikation selbst beschränkt ist. Sämtliche darunterliegende Infrastruktur (einschließlich des Containers, auf dem die Applikation läuft) liegen bereits im Verantwortungsbereich des Cloud-Anbieters.
In den Bereich Software as a Service (SaaS) fallen sämtliche Dienste, die bereits als fertige Applikation seitens des Herstellers zur Verfügung gestellt werden. Hierzu zählen Microsoft Teams, Slack, Google-Cloud Storage.
Entscheidend für einen Pentest ist hier, dass selbst die Applikation an sich nicht mehr im Verantwortungsbereich des Unternehmens liegt. Somit befindet sie sich nicht im Scope eines Security Assessments. Dennoch gibt es auch in diesem Fall Aspekte, die sinnvollerweise in einen Penetrationstest integriert werden können. Hierzu zählen die Beschaffung von Zugängen oder die Erweiterung von Privilegien innerhalb der Applikation sowie das Erbeuten sensitiver Informationen.
Gerade in Cloud Umgebungen und Ressourcen kann der Überblick über Rechte der Nutzer schnell abhandenkommen. Ein Cloud Security Assessment zeigt auf, welche Berechtigungen im schlimmsten Fall ausgenutzt werden können, um als normaler Benutzer seine Privilegien zu erweitern (Privilege Escalation). So könnten Angreifer auf Ressourcen zuzugreifen, auf die ein normaler Benutzer nicht zugreifen soll.
Egal, in welchem Umfang Cloud-Services genutzt werden: Die Nutzer und ihre Geräte befinden sich vor Ort und werden sinnvollerweise durch Social Engineering und Physical Access Szenarien in ein Cloud Security Assessment einbezogen.
Denn wenn ein Phishing Angriff erfolgreich verläuft, befindet sich der Angreifer ggf. schon in der Cloud Umgebung. Dort kann er sensitive Informationen erlangen oder Fehlkonfigurationen ausnutzen, um weiteren Schaden anzurichten.
Hinzu kommt, dass externe Assets häufig nur durch die Public IP-Adressen des Unternehmens erreichbar sind. Das macht die Unternehmensgebäude durchaus zu einem lohnenswerten Ziel, auch wenn Ihre Server nicht mehr On Premise betrieben werden.
