Serverlose Architekturen und deren Sicherheit

Originalbeitrag von Trend Micro

Der Wechsel zum Serverless Computing nimmt Fahrt auf. Laut einer Umfrage aus dem Jahr 2019 haben 21% der Unternehmen bereits die serverlose Technologie eingeführt, während 39% dies in Erwägung ziehen. Die serverlose Technologie ist für viele Unternehmen attraktiv, da sie es ihnen ermöglicht, sich auf die Erstellung von besserem Code für ihre Anwendungen zu konzentrieren, anstatt die für die Ausführung der Anwendungen erforderliche Infrastruktur zu verwalten und zu sichern. Das Forschungs-Whitepaper von Trend Micro „Securing Weak Points in Serverless Architectures: Risks and Recommendations“ stellt Sicherheitsüberlegungen für serverlose Umgebungen an und unterstützt Anwender dabei, ihre serverlosen Umgebungen so sicher wie möglich zu gestalten. Der Schwerpunkt liegt auf den von der AWS angebotenen Diensten, die über die breiteste Angebotspalette auf diesem Markt verfügt.

Serverless Computing bezeichnet eine Technologie, die Backend-Dienste unterstützt, sodass Unternehmen bestimmte Verantwortlichkeiten auf Cloud Service Provider (CSPs) wie Amazon Web Services (AWS) übertragen können, unter anderem Kapazitätsmanagement, Patching und Verfügbarkeit. Mit serverlosem Computing lassen sich Backend-Anwendungen erstellen, ohne direkt an Verfügbarkeit und Skalierbarkeit beteiligt zu sein. Der Begriff „serverlos“ bedeutet jedoch nicht, dass dieses Computing-Modell überhaupt keine Server einsetzt, sondern dass Unternehmen nicht mehr direkt an der Wartung und Absicherung von Servern beteiligt sein müssen.

Die Sicherheit der infrastrukturellen Rechenkomponenten dieser Architekturen wird zum größten Teil durch die CSPs (Cloud Service Provider) gewährleistet. Aus diesem Grund gilt die serverlose Technologie als relativ sicherer als andere Cloud-Computing-Modelle. Aber wie jede andere bestehende Technologie ist sie nicht immun gegen Risiken und Bedrohungen.

Vernetzte Services in einer serverlosen Architektur

Um zu verstehen, wie eine serverlose Architektur funktioniert, muss man wissen, welche verschiedenen Services daran beteiligt sind. In diesem Beitrag geht es um eine AWS serverlose Architektur.

Bild 1. Beispiele von miteinander verbundenen Services in einer AWS serverlosen Architektur

Amazon S3

Amazon Simple Storage Service (Amazon S3) ist ein Objektspeicher-Service für skalierbare Datenmengen, die eine Vielzahl von Anwendungsfällen unterstützt, wie z.B. mobile Anwendungen, Big Data Analytics und IoT-Geräte. Amazon S3 ermöglicht es Objekte zu verwalten, die dann über APIs in Buckets gespeichert werden.

AWS Lambda

Einer der am weitesten verbreiteten serverlosen Dienste ist AWS Lambda. Er ermöglicht es Unternehmen, Code ohne die mühsame Bereitstellung und Wartung von Servern auszuführen. Entwickler bezahlen dabei nur für die Anzahl der Instanzen, wenn der Code getriggert wird. Mit AWS Lambda müssen sie nicht Hardware verwalten oder sicherstellen, dass das Betriebssystem und alle installierten Anwendungen auf dem neuesten Stand sind.

Amazon API Gateway

Amazon API Gateway erlaubt die einfache und effiziente Erstellung, Veröffentlichung, Wartung, Überwachung und Sicherung von APIs. Der Dienst fungiert als Portal für Anwendungen, die über RESTful-APIs und WebSocket-APIs auf Backend-Service-Funktionen oder Daten zugreifen können.

AWS IAM

Über AWS Identity and Access Management (AWS IAM) können Entwickler Sicherheitsinfos und Berechtigungen managen, um den Zugang zu serverlosen Services und Ressourcen zu bestätigen.

Fehlkonfigurationen und unsichere Coding-Praktiken

Größere CSPs wie AWS wenden bei der Vergabe von Berechtigungen für bestimmte Aufgaben die Least Privilege Policy an. Sie nutzen auch den Ansatz der standardmässigen Verweigerung, der sicherstellt, dass jeder Dienst nur dann kommunizieren kann oder für einen anderen Dienst zugänglich ist, wenn die erforderlichen Berechtigungen erteilt werden. Die manuelle Zuweisung und Überprüfung von Privilegien sorgt für mehr Sicherheit. Dies kann sich jedoch für  Benutzer als schwierig erweisen, insbesondere angesichts einer komplexen Mischung miteinander verbundener Dienste. Infolgedessen könnten sie bei der Sicherheit serverloser Dienste Fehlkonfigurationen und Risiken wie die folgenden einführen oder übersehen.

Amazon S3

Offen gelassene oder frei zugängliche Amazon S3 Buckets könnten eine Tür für böswillige Akteure sein, um nach sensiblen Daten zu suchen. Kritische Daten oder Codeteile, die nicht öffentlich sichtbar sein sollten, könnten ebenfalls freigelegt werden, wenn Amazon S3-Buckets dazu verwendet werden, Inhalte zu hosten, für die sie nicht vorgesehen sind.

AWS Lambda

AWS-Lambda-Funktionen könnten von böswilligen Akteuren durch Injection-Techniken bei fehlerhaftem oder anfälligem Code ausgenutzt werden. Auch könnten sensible Daten exponiert werden, wenn der Code einer AWS-Lambda-Funktion so gestaltet ist, dass er Variablen zurückgibt und für externe Dienste zugänglich ist. Böswillige Akteure könnten auch die in AWS-Lambda-Funktionen als Variablen gespeicherten Zugangsdaten ausnutzen, um Zugang zum Konto eines Benutzers zu erhalten. Darüber hinaus liesse sich schadhafter Code dazu nutzen,bösartige Tools und Skripts im Ordner /tmp einer AWS Lambda-Ausführungsumgebung zu speichern. Dateien könnten hier persistent genug sein, um Angriffe zu starten oder sensible Daten zu exfiltrieren.

Amazon API Gateway

Sobald ein Amazon API-Gateway-Endpunkt offen und ungeschützt ist, liesse sich darüber einDenial-of-Service (DoS)-Angriff auslösen, um den dahinter liegenden Dienst zu kompromittieren oder abzuschalten. Böswillige Akteure, die einem Unternehmen finanziellen Schaden zufügen wollen, können einen offenen Amazon API Gateway-Endpunkt auch dazu missbrauchen, eine AWS-Lambda-Funktion ununterbrochen abzufragen, um die Rechnung des Unternehmens in die Höhe zu treiben.

AWS IAM

Möglicherweise aus Zeitgründen gestalten Entwickler manchmal die Richtlinien übermässig freizügig, um die Kommunikation zwischen den Systemkomponenten zu gewährleisten. Dies wird durch AWS IAM erleichtert. Aber diese Lockerung der Berechtigungen wirkt sich natürlich auf die Sicherheit der serverlosen Dienste aus, mit denen AWS IAM verwendet wird.

Risiken durch fehlerhaften Code

Um die Risiken der Implementierung von fehlerhaftem Code auf einem serverlosen System noch deutlicher zu machen, haben die Forscher einen Proof-of-Concept erstellt, der eine AWS-Lambda-Funktion mit hohen Berechtigungen beinhaltet. Das folgende Video zeigt, wie schlechte Codierungspraktiken es böswilligen Akteuren ermöglichen, das Timeout der AWS-Lambda-Funktion erfolgreich zu ändern und anschliessend andere Aktivitäten wie die Eskalation von Privilegien und Datenexfiltration durchzuführen.

https://youtube.com/watch?v=vbHdf6WNoO0%3Ffeature%3Doembed

Auswirkungen der Sicherheitsrisiken auf Unternehmen

Serverlose Services beinhalten Stateless-Funktionen, und deshalb bleiben die Daten in diesen Diensten im Cache und werden nicht im Speicher abgelegt. Beim Verschieben von Daten von serverlosen Diensten an externe Standorte müssen Unternehmen darauf achten, wie die Daten verschoben werden, um Datenlecks zu vermeiden. Ein solches Datenleck passierte, als eine Datenbank mit einer halben Million sensibler Rechts- und Finanzdokumente exponiert wurde, weil bei der Änderung der Zugriffsrichtlinien eine Fehlkonfiguration entstand.

Auch ist es wichtig zu wissen, wo Daten gespeichert sind, um Compliance-Problemen aus dem Weg zu gehen, wie denjenigen als z.B. über 36.000 Häftlingsdatensätze aus verschiedenen Justizvollzugsanstalten in den USA bekannt wurden, weil ein mit einer Cloud-basierten Anwendung verbundener Datenspeicher zugänglich war. Die Kompromittierung der Anwendung oder des Dienstes eines Unternehmens könnte auch zu einer Unterbrechung des Geschäftsbetriebs und zu Rufschädigung führen.

Sicherheit für serverlose Services und Installtionen

Das Modell der geteilten Verantwortung, bei dem sowohl der CSP als auch der Anwender Verantwortungsbereiche für die Sicherheit der Cloud-Umgebung übernehmen, gilt auch für das serverlose Computing. Das Forschungsprojekt stellt Möglichkeiten vor, wie serverlose Dienste und Installationen über Best Practices und Sicherheitslösungen vor Risiken und Bedrohungen geschützt werden können.

Weitere Einzelheiten zum Thema liefert das Whitepaper „Securing Weak Points in Serverless Architectures: Risks and Recommendations“.