Skip to main content

Serverless ist großartig, aber wie steht es um die Sicherheit meiner AWS-Lambda-Funktionen und ihrer Abhängigkeiten?

Artikel von

3. Juli 2019

0 Min. Lesezeit

Function-as-a-Service-Plattformen (FaaS) spielen Betriebssystem-Abhängigkeiten für Sie ein, sichern Ihre Anwendungsabhängigkeiten jedoch nicht ab – etwa Bibliotheken aus npm, PyPI, Maven und ähnlichen Quellen. Diese Bibliotheken sind ebenso verbreitet und anfällig wie Betriebssystem-Abhängigkeiten. Als Eigentümer der Anwendung sind Sie dafür verantwortlich, sie zu aktualisieren oder zu patchen, sobald eine Sicherheitslücke darin bekannt wird.

Da Angreifer wissen, dass Abhängigkeiten auf Betriebssystemebene, für die der Cloud-Anbieter verantwortlich ist, schnell gepatcht werden, richten sie ihre Aufmerksamkeit auf den Anwendungscode und die Anwendungsabhängigkeiten.

Wie komplex es ist, die Abhängigkeiten einer Funktion nachzuverfolgen, zeigt ein aktueller State of Open Source Security Report 2019 von Snyk: 78 % aller Sicherheitslücken entfallen auf indirekte Abhängigkeiten.

Gestapeltes Balkendiagramm mit den Anteilen direkter und indirekter Abhängigkeiten in PyPI, PHP Packagist, Maven Central, RubyGems und npm.

Das bedeutet, dass Sicherheitslücken meist in indirekten Abhängigkeiten gefunden werden, die von Ihren direkten Abhängigkeiten installiert werden. Im npm-Ökosystem sind Abhängigkeiten im Durchschnitt über mehr als vier Ebenen verschachtelt. Dadurch ist es schwierig, Ihre Abhängigkeiten und deren Sicherheit im Blick zu behalten.

Wie bei der Entwicklung von Anwendungen ohne Serverless sollten Sie Ihre Funktionen während des gesamten Entwicklungszyklus schützen. Beginnen Sie in der integrierten Entwicklungsumgebung (IDE) mit einem Plugin, das Sie auf Sicherheitslücken in Abhängigkeiten hinweist, die Sie während der Entwicklung benötigen – etwa in VSCode oder IntelliJ. Prüfen Sie anschließend die Sicherheit in Ihrer CI während des Builds und vor dem Deployment.

Was wäre, wenn es ein Tool gäbe, das Sie bei Sicherheitstests unterstützt, automatisch Pull Requests zur Behebung neu entdeckter Sicherheitslücken erstellt oder CI-Builds fehlschlagen lässt, damit kein Deployment erfolgt, wenn neue Sicherheitslücken eingeführt werden?

In einem früheren Beitrag habe ich weitere Einblicke in die Serverless-Sicherheit gegeben: 10 Best Practices für Serverless-Sicherheit. Vielleicht möchten Sie ihn später lesen. Doch zunächst geht es weiter mit der Geschichte meines eigenen Serverless-Projekts:

Wie teste ich die Sicherheit meiner Serverless-Funktionen auf AWS?

Bei einer Serverless-Plattform kann es schwierig sein, die Abhängigkeiten der bereitgestellten Funktionen auf Sicherheitslücken zu überwachen. Ich zeige Ihnen kurz, wie ich Snyk für mein eigenes Serverless-Nebenprojekt einsetze, das ich mit Node.js entwickelt und auf AWS Lambda bereitgestellt habe.

Um Sicherheitslücken in den Abhängigkeiten Ihrer Funktion zu finden und automatisch zu beheben, verbinden Sie Snyk zunächst mit einem Git-Repository Ihrer Wahl.

Ich habe es mit meinem eigenen Repository ausprobiert. Ich habe meine GitHub-Repositories durchsucht und bazz, mein Serverless-Projekt, ausgewählt. Nachdem mein Projekt gescannt worden war, erfuhr auch ich von Sicherheitslücken in Abhängigkeiten, die meine Lambda-Funktionen verwenden:

Snyk-Benutzeroberfläche mit einer GitHub-Repository-Auswahl und einer schwerwiegenden Sicherheitslücke durch unsichere Zufallswerte in package.json

Oh je! Sowohl in meinem Frontend-Projekt als auch im API-Service für die Serverless-Funktionen gibt es einige Sicherheitslücken. Zeit, sie zu beseitigen. Ich kann sie manuell beheben, indem ich auf der jeweiligen Projektseite in der Snyk-Benutzeroberfläche einen PR zur Fehlerbehebung erstelle. Oder der Snyk-Bot findet die Probleme und erstellt in meinem Namen automatisch einen PR in meinem Repository. Ich muss nur abwarten, bis die Tests erfolgreich sind, und den PR mergen. Sehen Sie selbst:

GitHub-Pull-Request, in dem Snyk Bot eine anfällige npm-Abhängigkeit im Repository lirantal/bazz-frontend behebt

Sichere Deployments von Serverless-Funktionen durchsetzen

Neben der Überwachung der CI und des Quellcode-Repositorys sowie dem proaktiven Patchen von Sicherheitslücken sollte auch der Deployment-Workflow einer Funktion auf Sicherheit geprüft werden. Werden beim Deployment Sicherheitslücken in Funktionen gefunden, sollte das Deployment gestoppt werden.

Die Durchsetzung der Open-Source-Sicherheitsüberwachung bei Serverless-Deployments schafft eine zusätzliche Schutzebene. So wird verhindert, dass Funktionen mit bekannten Sicherheitslücken in gebündelten Open-Source-Abhängigkeiten in ihren Zielumgebungen bereitgestellt werden.

Das Serverless-Framework ist ein gängiges Toolkit für die Entwicklung und Bereitstellung von Serverless-Funktionen. Seine Plugin-Architektur ermöglicht die Integration benutzerdefinierter Workflows in den Lebenszyklus einer Funktion. Snyk bietet ein Open-Source-Serverless-Plugin, das sich nahtlos in das Framework integrieren lässt.

Das folgende Bild zeigt, wie das Plugin aktiv verhindert, dass eine Funktion bereitgestellt wird, wenn Sicherheitslücken in Open-Source-Abhängigkeiten erkannt werden:

Terminal, in dem eine Bereitstellung mit dem Serverless Framework durch Snyk-Warnungen zu anfälligen Abhängigkeiten wie minimatch und request blockiert wird.

Außerdem empfiehlt es sich, das Plugin für das Serverless-Framework einzurichten, damit bei jedem Deployment Snapshots der Projektabhängigkeiten erstellt und auf neu entdeckte Sicherheitslücken überwacht werden können. Eine Lösung wie Snyk kann Sie warnen und das Problem automatisch beheben, indem sie Pull Requests mit Korrekturen für unsichere Abhängigkeiten erstellt.

Für Serverless-CI/CD-Workflows sind manchmal mehr Anpassungsmöglichkeiten und Kontrolle erforderlich. Hier kommt das Open-Source-Kommandozeilenprogramm von Snyk ins Spiel: Es bietet Entwicklern und DevOps-Engineers ein flexibles Sicherheitstool, das sich in ihre Workflows integrieren lässt.

Sie können Snyk lokal oder in einem CI-Job installieren, in dem das Serverless-Projekt erstellt wird. Führen Sie dann snyk test aus, um Sicherheitslücken zu finden – so:


$ npm install -g snyk
$ snyk test

Sicherheitslücken so schnell wie möglich zu beheben, ist eine gute Praxis. Dennoch können die Versionen der Abhängigkeiten im Quellcode-Repository von denen in der tatsächlich bereitgestellten Funktion abweichen. Das passiert vor allem, wenn es bei der Übertragung des Codes in eine Staging- oder Produktionsumgebung zu Verzögerungen kommt. Dadurch besteht das Risiko, dass die bereitgestellte Funktion mit veralteten und möglicherweise bekanntermaßen anfälligen Abhängigkeiten gebündelt wird.

Vergessen Sie zum Schluss nicht die von mir zusammengestellte Liste mit ausführlichen 10 Best Practices für Serverless-Sicherheit! Melden Sie sich für ein kostenloses Snyk-Konto an und beginnen Sie, Sicherheitslücken zu beheben.

Starten Sie mit Capture the Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.