Blog

AWS Inspector für AWS Lambda

Jacco Kulman

Aktualisiert Oktober 16, 2025
5 Minuten

Frisch von der re:Invent 2022. Ich komme gerade von der Pop-up-Sitzung, die kurz nach der Ankündigung vom AWS Inspector-Team Rick Anthony und Kashish Wadhwa organisiert wurde. Nach der Sitzung konnte ich Rick Anthony ein paar Fragen stellen.

Warum ist das wichtig?

Immer mehr Kunden wechseln zu serverlosen Arbeitslasten auf AWS und entfernen sich von EC2-Instanzen und Containern. Die Nutzung von Lambda nimmt jedes Jahr zu und es gibt kaum native Sicherheitsfunktionen für diesen Service. Deshalb ist es wichtig, diese Schwachstellen zu beseitigen.

Was macht der Inspektor?

Inspector kann bereits EC2-Instanzen und ECR-Images auf Schwachstellen überprüfen. Jetzt wird auch das Scannen von Lambdas unterstützt. Security Hub kann so konfiguriert werden, dass es die Ergebnisse von Inspector akzeptiert, so dass Sie einen Ort haben, an dem alle Sicherheitserkenntnisse zusammengefasst werden.

Inspector entscheidet, was und wann gescannt wird, und nicht Sie, der den Scan plant. Auch brandneue Schwachstellen können ein Grund für AWS Inspector sein, einen erneuten Scan durchzuführen. Im Fall von Lambdas bedeutet dies, dass jedes Mal, wenn die Funktion erstellt oder aktualisiert wird, ein Scan durchgeführt wird. Wenn ein Lambda in den letzten 90 Tagen nicht aufgerufen wurde, wird es nicht mehr gescannt (die monatlichen Kosten entfallen dann ebenfalls). Derzeit wird die Überprüfung für die folgenden Laufzeiten unterstützt: Python, nodejs und Java. Auch das Scannen von Schichten wird unterstützt. Befunde von Schichten werden für alle Funktionen gemeldet, in denen die Schicht verwendet wird, und der Befund gibt an, dass die Ursache der Sicherheitslücke von einer Schicht stammt.

Schwachstellen

Schwachstellen in Lambda stehen nicht im Zusammenhang mit dem Betriebssystem (es sei denn, Sie verwenden benutzerdefinierte Laufzeiten, die von der neuen Funktion nicht unterstützt werden), sondern stammen von den Paketen, die für die gewählte Programmiersprache verwendet werden. Wenn Sie beispielsweise eine Java-Laufzeit verwenden und das Paket log4j einsetzen, könnten Sie eine Sicherheitslücke haben, wenn Sie die ungepatchte Version der Bibliothek verwenden. Inspector scannt die Artefakte, die das Paket-Tooling hinterlässt (package.json für nodejs-Projekte zum Beispiel).

Ausbeutbarkeit

Nicht alle Schwachstellen in Lambda können leicht ausgenutzt werden, da das Betriebssystem Firecracker gut gehärtet ist. Außerdem ist die Angriffsfläche begrenzt, da der Aufruf eines Lambdas eine IAM-Autorisierung erfordert, wenn Sie es auf normalem Wege aufrufen. Wenn Sie jedoch die neue URL-Funktionalität ohne Authentifizierung verwenden, ist die Angriffsfläche etwas größer. Auch wenn der Aufruf über das API Gateway erfolgt und Sie nicht die Anforderungsvalidierung verwenden, könnten Sie für einen Angriff anfällig sein. Inspector berücksichtigt die Netzwerkerreichbarkeit des Lambdas bei der Bewertung des Fundes. Die resultierende Punktzahl gibt einen Hinweis auf die Priorität, mit der dieser Fund behandelt werden sollte. Derzeit wird die AssumeRole-Richtlinie der Lambda-Ausführungsrolle bei der Bewertung nicht berücksichtigt und auch nicht die Tatsache, ob FunctionUrls verwendet werden oder nicht. AWS überwacht 50 Quellen, die Schwachstellen veröffentlichen, und fügt ihnen einige Informationen hinzu. Bei der Bewertung wird auch die Ausnutzbarkeit berücksichtigt. Es wird auch ein Netzwerk-Scan durchgeführt, bei dem die VPC-Ränder auf die Erreichbarkeit des Netzwerks untersucht werden. Dies wird mit den CVE-Daten korreliert. Wenn die CVE nur aus der Ferne ausgenutzt werden kann, die Ressource aber lokal ist, wird die Punktzahl herabgesetzt.

Live-Laufzeiten

Lambda-Container werden nach einer gewissen Zeit recycelt, so dass bei einem erfolgreichen Angriff der Angriff nach einem Recycle erneut ausgeführt werden muss. Wenn die Schwachstelle jedoch eine Code-Injektion beinhaltet, kann ein Angreifer im Grunde jede neu gestartete Lambda-Ausführungsumgebung infizieren. Die laufenden Lambda-Umgebungen selbst werden nicht gescannt. Wie bei ECR handelt es sich um eine agentenlose Lösung. Das bedeutet auch, dass zusätzliche Python-Pakete, die Sie mit einem Unterbefehl in Python installieren, nicht erkannt werden. (Das sollten Sie nicht tun).

Was sollten Sie tun, wenn es Befunde gibt

Wenn Sie eine Sicherheitslücke in einem Lambda haben, sollten Sie die folgenden Schritte unternehmen:

  • überprüfen Sie den Lambda-Code, ob der verwundbare Teil der Bibliothek tatsächlich verwendet wird. Wenn nicht, können Sie den Fund unterdrücken.
  • Wenn Sie feststellen, dass die Sicherheitslücke ausgenutzt werden kann. Das Lambda muss mit gepatchten Bibliotheken und Paketen neu bereitgestellt werden.

Ermöglichung für die Organisation

Die Aktivierung von Lambda Scanning durch Inspector für Ihr gesamtes Unternehmen ist nur ein paar Klicks entfernt: Aktivieren Sie im delegierten Administratorkonto das Kontrollkästchen für Lambda-Scanning (aktivieren Sie auch das Kontrollkästchen für die automatische Aktivierung für neue Konten). Beachten Sie jedoch, dass der Preis $0,30 pro Funktion und Monat beträgt, so dass Sie vielleicht einige Funktionen ausschließen möchten, bevor Sie dies für alle Ihre Konten aktivieren.

Aktuelle Merkmale

  • nodejs, python und java laufzeiten
  • Überprüfung der neuesten Version bei Aktualisierung oder Erstellung
  • erneutes Scannen, wenn es neue Bedrohungen gibt
  • Unterstützung für AWS-Organisationen
  • Erreichbarkeit des Netzwerks in der Bewertung enthalten
  • Bewertung der Schwachstellen (Priorität)

Zukunft

Für die Zukunft sagte Rick vom Inspector-Team, dass sie die Unterstützung der folgenden Funktionen in Betracht ziehen:

  • Hinzufügen einer Option zum Scannen aller Versionen des Lambdas (derzeit wird nur die letzte Version gescannt)
  • Hinzufügen der Lambda-Zugänglichkeit (AssumeRolePolicy der Ausführungsrolle oder FunctionUrls) kann in die Berechnung der Punktzahl einbezogen werden
  • Einstellen des Zeitraums für die Überprüfung der abgelaufenen Funktion

Verfasst von

Jacco Kulman

Jacco is a Cloud Consultant at Binx.io. As an experienced development team lead he coded for the banking- and hospitality- and media-industries. He is a big fan of serverless architectures. In his free time he reads science fiction, contributes to open source projects and enjoys being a life-long-learner.

Contact

Let’s discuss how we can support your journey.