Den Rahmen des Tests abstecken
Aufgrund des Konzepts der geteilten Verantwortung gibt es einige Überlegungen, die IT-Verantwortliche vor einem Cloud-Penetration-Test anstellen sollten. Dabei muss von drei Entitäten ausgegangen werden, die beteiligt sind: Der Cloud-Service-Provider, dessen Kunde (also das Unternehmen) und der Penetration-Tester. Wenn ein Unternehmen nach einem solchen Test verlangt, wird darunter gewöhnlich eine Überprüfung aller Services und IT-Infrastrukturen verstanden. Das gibt dem Experten sehr viel Freiheit, um gezielte, spezialisierte und hinterlistige Angriffe durchzuführen.

Aus diesem Grund aber sind vorab einige Maßnahmen zu treffen, um sicherzustellen, dass die Aktionen des Penetration-Tests innerhalb des gewollten Rahmens bleiben und sie nicht plötzlich auf unbeteiligte Bereiche und sogar dritte Parteien übergreifen. Hier kommt der Dreiklang wieder ins Spiel, denn im ersten Schritt muss der erwähnte Rahmen festgelegt und hierfür bestimmt werden, ob der Auftraggeber ein Cloud-Service-Provider oder ein Kunde ist. Danach geht es um die Art der Cloudumgebung (Cloud Deployment Model) und die Weise ihrer Anbindung an das Netzwerk des Unternehmens (Cloud Service Model).

• Private
• Public
• Community
• Hybrid

Wird ein Sicherheitsexperte gebeten, eine Private-Cloud-Umgebung zu prüfen, kann er ohne große Umschweife die gesamte Struktur attackieren. Innerhalb einer Public Cloud aber muss er zuvor die Verbindungen und Verantwortungsbereiche zwischen Cloud-Service-Provider und Kunde (also dem Unternehmen) herausheben und abgrenzen.

• Infrastructure-as-a-Service (IaaS)
• Platform-as-a-Service (PaaS)
• Software-as-a-Service (SaaS)

Sicherheitslösungen und Kontrollmechanismen, die unter die Aufsicht des Cloud-Service-Providers fallen, gehören natürlich nicht zum Arbeitsbereich des Penetration-Testers, wenn er von einem Unternehmen beauftragt wurde. Beispielhaft sei hier SaaS genannt: Der Penetration-Tester soll unter anderem die Zugriffsrechte der einzelnen Nutzer überprüfen und exzessive Berechtigungen ausnutzen. Er soll aber nicht die Implementierung der Zugriffskontrolle (Session Validation) testen oder das Input-Filtering der SaaS-Anwendung, wie SQL Injection.

Das rührt daher, dass ein solcher Test die gesamte zugrundeliegende Cloudinfrastruktur einbezöge, was in diesem Fall nicht im Rahmen des in Auftrag gegebenen Tests läge. Die Prüfung der Cloudinfrastruktur ist also niemals Teil eines Penetration Testings, bis der Cloud-Service-Provider seine ausdrückliche Zustimmung erteilt hat. Daher ist es wichtig, diese Überlegungen vorab anzustellen. Die folgende Grafik verdeutlicht das Modell der geteilten Verantwortung.

Bild 1: Das Prinzip der geteilten Verantwortung (blau=Cloudprovider, grau=Unternehmen) bringt mit sich,
dass der Penetration-Tester gerade in Cloudumgebungen nicht alle Bereiche prüft.

Das Bild zeigt deutlich, dass der Rahmen eines Penetration Testings stark variiert, und zwar je nach Service-Modell. SaaS schränkt ihn am engsten ein und erlaubt nur die Prüfung der Zugangsberechtigungen und der Dateien. Bei PaaS kommt die Anwendung selbst in den erlaubten Spielraum hinzu und bei IaaS das Betriebssystem. Überall ausgeschlossen aber bleiben Virtualisierung, Netzwerk, Infrastruktur und Hardware. Diese dürfen nicht Teil eines Penetrationstests sein, den das Unternehmen in Auftrag gibt. Das müssen sowohl das Unternehmen als auch der angeheuerte Sicherheitsexperte selbst immer bedenken. Lautet der Auftrag etwa, das Betriebssystem einer Prüfung zu unterziehen, und der Kunde ist Nutzer einer Public Cloud, dann ist dies nur in einem IaaS-Modell erlaubt . In den anderen beiden Fällen (PaaS und SaaS) kontrolliert der Cloud-Service-Provider das Betriebssystem und es bedarf daher seiner Zustimmung.



ln/Hassan Moradi, Head of Cyber Security Technical Assessment bei TÜV SÜD