Best Practices für die Verwaltung von Secrets in serverlosen Anwendungen

Wenn Sie eine serverlose Anwendung entwickeln, müssen Ihre Funktionen wahrscheinlich auf Secrets oder andere sensible Informationen zugreifen, die Sie speichern, etwa API-Schlüssel, Tokens oder Passwörter. Diese Secrets ordnungsgemäß zu verwalten, kann sich jedoch manchmal als schwierig erweisen.

Wenn Nutzer keinen Schlüsselverwaltungsdienst einsetzen, landen diese Secrets leider oft im Quellcode oder in Manifestdateien. Das kann schwerwiegende Folgen haben, etwa wenn Secrets durch die Offenlegung oder Manipulation des Quellcodes kompromittiert werden. Außerdem wird die Verwaltung von Secrets dadurch komplexer, zum Beispiel beim Rotieren und Außerkraftsetzen von Schlüsseln.

Sie können das PDF zum Serverless-Security-Spickzettel herunterladen oder die Online-Version des Blogartikels lesen.

Hier sehen Sie ein Beispiel für einen unsicheren Umgang mit Secrets:

service:
 name: hello-world

provider:
  name: aws

functions:
  helloWorld:
    handler: helloworld.get
    environment:
      GITHUB_API_KEY: ABCDEF

  goodbyeWorld:
    handler: goodbye.get

Sehen wir uns zunächst die positiven Aspekte dieser Struktur an. Die Funktion helloWorld setzt das Prinzip der Funktionsisolierung gut um. Die Umgebungsvariable GITHUB_API_KEY ist nur für die aufgerufene Funktion verfügbar und nicht für andere Funktionen im Code – in diesem Fall also nicht für goodbyeWorld.

Andererseits ist das geheime Token für GITHUB_API_KEY in der Manifestdatei serverless.yml fest codiert. Dadurch werden Konfiguration und Secrets vermischt. Wird diese Manifestdatei öffentlich veröffentlicht oder mit anderen Nutzern geteilt, können Informationen offengelegt werden.

Das folgende Beispiel verwendet den AWS Simple Systems Manager, um Secrets abzurufen, die sicher im AWS Parameter Store verschlüsselt wurden. In unserem Beispiel wird die SSM-Variable verwendet, um auf einen zuvor erstellten Wert zuzugreifen und ihn einer Funktion über eine Umgebungsvariable verfügbar zu machen:

service:
 name: hello-world

provider:
  name: aws

functions:
  helloWorld:
    handler: helloworld.get
    environment:
      GITHUB_API_KEY: ${ssm:/github/api-key}

Beachten Sie, dass ${ssm:/github/api-key} den verschlüsselten Wert dieses Schlüssels zurückgibt. Wenn Sie den tatsächlichen Wert entschlüsseln und zurückgeben möchten, müssen Sie ${ssm:/github/api-key~true} angeben.

Weitere Informationen zum Parameter Store und zum Key Management Service (KMS) finden Sie in der Dokumentation zum Parameter Store von Amazon.

Noch mehr Sicherheit und Flexibilität bei der Verwaltung von Secrets für Ihre Anwendungen erzielen Sie, wenn Sie zur Laufzeit auf Secrets und andere Konfigurationsinformationen zugreifen, statt Umgebungsvariablen zu verwenden, für deren Aktualisierung ein Neustart des Prozesses erforderlich ist.

Rotieren Sie Schlüssel und Zugangsdaten regelmäßig

Die Speicherung Ihrer Secrets verringert zwar das Risiko, dass ein Schlüssel offengelegt wird, beseitigt es aber nicht vollständig. Wenn Sie in Ihrer Funktion einen Secret-Speicher verwenden, ist es zum Glück unerheblich, wie der Schlüssel lautet – Sie können ihn also regelmäßig rotieren! Wird der Schlüssel offengelegt oder gestohlen, kann er so nur kurze Zeit verwendet werden, bevor er abläuft.

Mit einem KMS lassen sich Schlüssel einfach und routinemäßig rotieren. Bei der Integration mit anderen Systemen kann sich das jedoch als etwas schwieriger erweisen. Wenn Sie den Schlüssel für den Zugriff auf ein Drittanbietersystem benötigen, prüfen Sie, ob dessen API eine automatische Schlüsselrotation ermöglicht. Falls ja, richten Sie einen regelmäßigen Job ein, der einen neuen Schlüssel erstellt, das Token im KMS aktualisiert und den alten Schlüssel beim nächsten Durchlauf ablaufen lässt oder auf eine Sperrliste setzt. So sind jederzeit nur zwei Schlüssel aktiv. Da Ihre Funktionen nur sehr kurz laufen, übernehmen sie den neuen Schlüssel schnell. Dadurch können Sie den alten Schlüssel außer Kraft setzen und häufig eine neue Rotation starten – täglich oder sogar stündlich.

Zusammenfassung

Abschließend empfiehlt sich eine sichere Speicherlösung für Ihre Secrets und sensiblen Zugangsdaten, die von führenden Cloud- und FaaS-Anbietern unterstützt wird. Alternativ können Sie eine eigene Lösung wie HashiCorps Vault einsetzen. Die Speicherung von Schlüsseln in einem Secret-Speicher mindert die Risiken, die entstehen, wenn sensible Informationen in statischen Dateien eines Quellcode-Repositorys oder in Umgebungsvariablen abgelegt werden, und verringert das Risiko einer Offenlegung erheblich. Weitere Informationen zu Tools für die Verwaltung von Secrets und Best Practices finden Sie hier.

Erstellen Sie jetzt kostenlos ein Snyk-Konto, um die Sicherheit Ihrer Projekte zu verbessern.