Einführung: Die einzigartigen Sicherheitsanforderungen von Serverless

Serverless Computing hat die Art und Weise, wie Teams Anwendungen erstellen und bereitstellen, verändert. Durch das Abstrahieren von Servern, Skalieren und Patchen können sich Plattformen wie AWS Lambda, Azure Functions und Google Cloud Functions Entwickler rein auf die Geschäftslogik konzentrieren. Dieser Paradigmenwechsel bringt jedoch auch neue Sicherheitsherausforderungen mit sich, insbesondere im Zusammenhang mit der Verwaltung von Geheimnissen und sensiblen Daten. In einer traditionellen serverbasierten Anwendung befinden sich Geheimnisse oft in einem dedizierten Tresor im Dateisystem oder in einer geschützten Datenbank. In Serverless sind Funktionen ephemer, zustandslos und werden häufig aufgerufen - es gibt kein persistentes Dateisystem oder einen langlebigen Prozess, um Geheimnisse zu schützen.

Dieser Artikel bietet einen umfassenden Leitfaden zum Umgang mit Geheimnissen in serverlosen Umgebungen. Wir werden die wichtigsten Herausforderungen untersuchen, in Best Practices eintauchen, konkrete Implementierungsmuster mit großen Cloud-Anbietern durchgehen und diskutieren, wie der gesamte Lebenszyklus sensibler Daten gesichert werden kann - von der Entwicklung bis zur Produktion.

Die Herausforderungen des geheimen Managements in Serverless verstehen

Serverlose Architekturen sind von Natur aus zustandslos. Wenn eine Funktion aufgerufen wird, läuft sie in einem Container, der nach der Ausführung abgerissen (oder für kurze Zeit wiederverwendet) wird. Dies bedeutet, dass Sie sich nicht auf lang laufende Prozesse oder Dateisysteme verlassen können, um Geheimnisse zu speichern.

  • Exposition in Code und Protokollen: Entwickler können versehentlich Geheimnisse zur Quellenkontrolle festlegen oder sie während des Debuggens protokollieren. Sobald sich ein Geheimnis in einem Protokollstrom befindet, kann es von jedem mit Protokollzugriff abgerufen werden - und Protokolle werden oft auf unbestimmte Zeit gespeichert.
  • Umgebungsvariablenbeschränkungen: Während Umgebungsvariablen bequem sind, werden sie oft während der Bereitstellung festgelegt und in Klartext in der Funktionskonfiguration gespeichert. Wenn ein Angreifer Lesezugriff auf die Funktionskonfiguration erhält (z. B. über eine kompromittierte CI/CD-Pipeline), erhalten sie das Geheimnis. Zusätzlich sind Umgebungsvariablen in der Konsole des Cloud-Anbieters sichtbar, so dass interne Teams unnötig exponiert werden können.
  • Kaltstarts und Caching: Das Abrufen von Geheimnissen bei jedem Aufruf kann Latenz und Kosten verursachen. Entwickler können manchmal Geheimnisse im Speicher zwischenspeichern, aber der ephemere Container kann für mehrere Aufrufe wiederverwendet werden - was zu veralteten oder abgelaufenen Geheimnissen führt, wenn die Rotation häufig ist.
  • Auditability and rotation: Ohne ein zentrales Gewölbe ist es schwierig zu wissen, wer wann auf welches Geheimnis zugegriffen hat, oder Geheimnisse zu drehen, ohne jede Funktion zu aktualisieren.

Diese Herausforderungen werden durch die verteilte, ereignisgesteuerte Natur serverloser Anwendungen noch verschärft. Eine einzelne Funktion muss möglicherweise eine Datenbank, eine externe API und eine Warteschlange aufrufen – jede erfordert separate Anmeldeinformationen.

Best Practices für die Verwaltung von Geheimnissen und sensiblen Daten

Die Grundlage jeder serverlosen Sicherheitsstrategie ist das Prinzip der geringsten Privilegien: Jede Funktion sollte nur auf die Geheimnisse zugreifen können, die sie unbedingt benötigt, und zwar so schnell wie möglich.

1. Dedizierte Secret Management Services nutzen

Jeder große Cloud-Anbieter bietet einen speziell entwickelten Service zum Speichern und Zugriff auf Geheimnisse:

  • AWS Secrets Manager – verwaltet Geheimnisse mit automatischer Rotation und feinkörnigen Zugriffsrichtlinien.
  • Azure Key Vault – speichert Geheimnisse, Schlüssel und Zertifikate und integriert sich über verwaltete Identitäten in Azure Functions.
  • Google Cloud Secret Manager – bietet Versionierung, IAM-Steuerelemente und Integration mit Cloud-Funktionen und Cloud Run.

Diese Dienste verschlüsseln Geheimnisse in Ruhe und auf der Durchreise, stellen Überwachungsprotokolle für jeden Zugriff bereit und ermöglichen es Ihnen, Geheimnisse ohne Umstellen von Funktionen zu drehen.

2. Leverage Umweltvariablen - aber mit Sorgfalt

Umgebungsvariablen bleiben eine gängige Methode, um Konfigurationen in serverlose Funktionen einzufügen. Sie sollten jedoch niemals Geheimnisse direkt enthalten. Verwenden Sie stattdessen Umgebungsvariablen, um Verweise auf Geheimnisse zu speichern (z. B. die ARN eines Geheimnisses in AWS Secrets Manager oder den Namen eines Geheimnisses in Azure Key Vault). Die Funktion ruft dann das tatsächliche Geheimnis zur Laufzeit mit dem entsprechenden SDK ab. Auf diese Weise erhalten Angreifer, selbst wenn sie die Umgebungsvariablen lesen, nur einen Zeiger, nicht das Geheimnis selbst.

3. Alles in Ruhe und Transit verschlüsseln

Geheimnisse müssen verschlüsselt werden, wo immer sie sich befinden: innerhalb des Secret Management Service, im Speicher zwischengespeichert (unter Verwendung von Techniken wie Memory-Hard-Verschlüsselung) und über das Netzwerk übertragen. Alle großen Secret Management Services erzwingen Verschlüsselung im Ruhezustand mit Hilfe von Umschlag-Verschlüsselung mit Customer-Managed Keys (CMKs), wo immer möglich. Verwenden Sie für den Transit immer TLS 1.2 oder höher zwischen Ihrer Funktion und dem Secret Store.

4. Strenge Zugangskontrollen und das Prinzip der geringsten Privilegien

Verwenden Sie rollenbasierte Zugriffskontrolle (RBAC) oder attributbasierte Zugriffskontrolle (ABAC), um zu begrenzen, welche Funktionen welche Geheimnisse lesen können. In AWS fügen Sie IAM-Richtlinien an die Ausführungsrolle der Funktion an, die nur für bestimmte geheime ARNs gewähren. In ähnlicher Weise verwenden Sie in Azure verwaltete Identitäten und weisen granulare Key Vault-Zugriffsrichtlinien zu. Vermeiden Sie Platzhalterberechtigungen, die es einer Funktion ermöglichen, jedes Geheimnis im Konto zu lesen.

Außerdem sollte der Zugang zum Geheimdienst selbst eingeschränkt werden; nur Administratoren sollten Geheimnisse erstellen, ändern oder löschen können; Betreiber und Entwickler sollten sich darauf beschränken, die für ihre Arbeit erforderlichen Geheimnisse zu lesen, und die Auditprotokolle sollten regelmäßig überprüft werden.

5. Rotate Secrets Regelmäßig

Automatische geheime Rotation ist entscheidend für die Begrenzung des Explosionsradius eines Kompromisses. AWS Secrets Manager kann Geheimnisse nach einem Zeitplan (z. B. alle 30 Tage) drehen, indem eine Lambda-Funktion aufgerufen wird, die das Geheimnis im Zieldienst aktualisiert (z. B. eine Datenbank). Azure Key Vault integriert sich mit anderen Azure-Diensten für die Rotation, obwohl es eine benutzerdefinierte Automatisierung für nicht-Azure-Ziele erfordert. Google Cloud Secret Manager unterstützt die Versionierung, wodurch die manuelle Rotation unkompliziert wird, aber die automatische Rotation erfordert einen Cloud-Funktions- oder Cloud-Scheduler-Job.

Selbst bei automatischer Rotation müssen Sie sicherstellen, dass alte geheime Versionen nicht auf unbestimmte Zeit aufbewahrt werden.Implementieren Sie eine Aufbewahrungsrichtlinie, die ältere Versionen nach einem sicheren Fenster (z. B. 30 Tage nach der Rotation) bereinigt, um einen Angreifer daran zu hindern, ein altes, kompromittiertes Geheimnis zu verwenden.

6. Verwenden Sie dynamische und temporäre Anmeldeinformationen, wo möglich

Für Dienste, die es unterstützen, sollten temporäre Anmeldeinformationen längerfristigen Geheimnissen vorgezogen werden. Beispielsweise können AWS Lambda-Funktionen IAM-Rollen übernehmen, die temporäre Anmeldeinformationen (über STS) für den Zugriff auf S3, DynamoDB oder andere AWS-Dienste ausgeben. Dadurch entfällt die Notwendigkeit für fest codierte Anmeldeinformationen. Ebenso können Azure Functions verwaltete Identitäten verwenden, um sich bei Azure-Diensten zu authentifizieren, ohne irgendwelche Geheimnisse zu speichern. Google Cloud Functions kann Dienstkonten mit kurzlebigen Token verwenden.

7. Audit und Überwachung des geheimen Zugangs

Aktivieren Sie die Anmeldung in Ihrem Secret Management Service und versenden Sie diese Protokolle an eine zentrale SIEM-Plattform (Sicherheitsinformations- und Ereignismanagement). Überwachen Sie ungewöhnliche Zugriffsmuster, wie z. B. häufiger als erwartet, oder Zugriff von unbekannten IP-Adressen. Richten Sie Warnmeldungen für Fehler wie "Zugriff verweigert" zum Secret Store ein, die auf eine falsch konfigurierte Funktion oder einen Brute-Force-Versuch hinweisen könnten.

Implementierung von Secrets Management: Real-World Patterns

Die Praktiken zu kennen ist eine Sache, die richtige Anwendung eine andere. Im Folgenden finden Sie Implementierungsmuster für die drei großen Cloud-Anbieter sowie plattformübergreifende Überlegungen.

AWS Lambda mit AWS Secrets Manager

Um AWS Secrets Manager mit einer Lambda-Funktion zu integrieren, führen Sie die folgenden Schritte aus:

  1. Erstellen Sie das Geheimnis – Speichern Sie Ihr Datenbankpasswort, Ihren API-Schlüssel oder eine andere sensible Zeichenfolge als Geheimnis im Secrets Manager. Aktivieren Sie die automatische Rotation, wenn der Zieldienst es unterstützt.
  2. Gestatte der Lambda-Ausführungsrolle Zugriff – Fügen Sie eine Richtlinie hinzu, die auf dem spezifischen Geheimnis ARN erlaubt.
  3. Retrieve the secret at runtime – Importieren Sie in Ihrem Funktionscode (Node.js, Python, etc.) das AWS SDK und rufen Sie auf.
const AWS = require('aws-sdk');
const secretsManager = new AWS.SecretsManager();
let cachedSecret;

exports.handler = async () => {
 if (!cachedSecret) {
 const data = await secretsManager.getSecretValue({ SecretId: 'arn:aws:secretsmanager:us-east-1:123456789012:secret:MyDbPassword-abc123' }).promise();
 cachedSecret = data.SecretString;
 }
 // use cachedSecret securely, never log it
};

Beachten Sie, dass das Geheimnis nur einmal pro Kaltstart abgerufen wird. Bei nachfolgenden Warminvokationen wird der zwischengespeicherte Wert wiederverwendet. Wenn Sie Geheimnisse häufig drehen, sollten Sie eine kurze Time-to-Live (TTL) im Cache einstellen oder die Version des Geheimnisses vor der Wiederverwendung überprüfen.

Azure-Funktionen mit Azure Key Vault

Azure bietet eine nahtlosere Integration durch Key Vault Referenzen in der App-Konfiguration oder als Teil der Funktionseinstellungen. Anstatt das SDK manuell aufzurufen, können Sie eine Umgebungsvariable für diese spezielle Syntax festlegen:

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/DbPassword/)

Wenn die Funktion ausgeführt wird, löst Azure automatisch die Referenz auf und fügt den geheimen Wert als Umgebungsvariable ein. Dieser Ansatz vereinfacht den Code erheblich und hält Geheimnisse aus jeder Konfigurationsdatei heraus. Sie müssen der systemzugeordneten verwalteten Identität der Funktion jedoch dennoch die Rolle zuweisen.

Verwenden Sie für Funktionen, die mehrere Geheimnisse dynamisch abrufen müssen, die SDKs und , um Geheimnisse mit Namen abzurufen.

Google Cloud funktioniert mit Secret Manager

Google Cloud Functions kann über Umgebungsvariablen auf Geheimnisse zugreifen, die auf eine geheime Version verweisen. Im Bereitstellungsbefehl können Sie eine Umgebungsvariable wie angeben, deren Wert auf gesetzt ist. Die Funktion löst den geheimen Wert automatisch zur Laufzeit auf. Alternativ können Sie die Secret Manager-Clientbibliothek verwenden, um Geheimnisse auf Anfrage abzurufen.

Eine Besonderheit des Google Cloud Secret Managers ist, dass Sie mit IAM-Bindungen Zugriff auf geheimer Ebene gewähren können, und Sie können auch Customer-Managed Encryption Keys (CMEK) für zusätzlichen Schutz verwenden.

Beyond the Cloud: Geheimnisse in CI/CD und Entwicklung

Geheimnisse müssen nicht nur in der Produktion, sondern auch während der Entwicklung und der Continuous Integration/Continuous Deployment (CI/CD)-Pipelines verwaltet werden. Entwickler müssen häufig serverlose Funktionen lokal mit echten Service-Endpunkten testen. Die sicherste Vorgehensweise ist die Verwendung persönlicher Geheimnisse oder temporärer Anmeldeinformationen, die auf ihre Identität ausgerichtet sind und über begrenzte Berechtigungen verfügen.

  • Lokale Entwicklung: Verwenden Sie Tools wie (für AWS), mit oder , um Anmeldeinformationen über Umgebungsvariablen einzufügen.
  • CI/CD-Pipelines: Speichern Sie Geheimnisse als Pipeline-Geheimnisse (z. B. GitHub Actions Secrets, GitLab CI/CD-Variablen) und fügen Sie sie zum Build- oder Bereitstellungszeitpunkt ein. Vermeiden Sie es, Geheimnisse in Protokollen zu drucken; verwenden Sie, wenn möglich, maskierte Variablen. Für mehrstufige Bereitstellungen sollten Sie einen dedizierten Secret-Management-Service in Betracht ziehen, den die Pipeline über ihre eigene Identität aufruft, anstatt Geheimnisse durch Umgebungsvariablen zu übertragen.
  • Infrastructure as Code (IaC): Wenn Sie Terraform, AWS CloudFormation oder Azure Bicep verwenden, um serverlose Funktionen bereitzustellen, verwenden Sie niemals Hardcode-Geheimnisse in den IaC-Vorlagen. Verwenden Sie stattdessen ein sicheres Remote-State-Backend und verweisen Sie auf Geheimnisse aus dem Secret Store des Cloud-Anbieters. Viele IaC-Tools verfügen über spezielle Ressourcen, um Geheimnisse sicher zu lesen (z. B. Datenquelle in Terraform).

Compliance und Standardisierung

Viele regulatorische Rahmenbedingungen (DSGVO, SOC 2, PCI-DSS) erfordern strenge Kontrollen des Zugangs zu sensiblen Daten.

  • Audit-Trails: Secret Management Services protokollieren jedes Lesen, Schreiben und Löschen, sodass Sie eine vollständige Zugriffshistorie erhalten.
  • Least privilege enforcement: IAM-Richtlinien stellen sicher, dass nur autorisierte Funktionen und Benutzer auf Geheimnisse zugreifen können.
  • Verschlüsselung: Geheimnisse werden in Ruhe und auf der Durchreise verschlüsselt und erfüllen die Datenschutzanforderungen.

Verwenden Sie Tools wie OWASP’s Secret Management Cheat SheetOWASP Secrets Management Cheat Sheet und NIST SP 800‐57 (NIST SP 800‐57) als maßgebliche Referenzen für das Schlüsselmanagement.

Fazit: Aufbau einer geheimen sicheren Serverlosen Architektur

Die Verwaltung von Geheimnissen in serverlosen Anwendungen ist keine einmalige Aufgabe, sondern eine ständige Disziplin. Die ephemere und verteilte Natur von Serverlosen erfordert, dass Sie niemals Code oder Konfiguration vertrauen, um Geheimnisse zu bewahren. Verlassen Sie sich stattdessen auf dedizierte geheime Managementdienste, erzwingen Sie den Zugriff auf die geringsten Privilegien, drehen Sie Anmeldeinformationen automatisch und überwachen Sie jeden Zugriff.

Wenn Sie die in diesem Artikel beschriebenen Best Practices befolgen – AWS Secrets Manager, Azure Key Vault oder Google Cloud Secret Manager nutzen, Umgebungsvariablen nur als Zeiger verwenden, mit Bedacht zwischenspeichern und sicheres Geheimhandling in CI/CD integrieren – können Sie serverlose Anwendungen erstellen, die sowohl leistungsstark als auch sicher sind. Denken Sie daran, dass Geheimnisse der Schlüssel zu Ihrem digitalen Königreich sind. Behandeln Sie sie mit dem Respekt, den sie verdienen.

Für tiefere Tauchgänge, siehe die offizielle Dokumentation: