API-Schlüssel für sicherheitssensible Workloads verwalten

AWS Secrets Manager hilft Ihnen dabei, Datenbankanmeldedaten, Anwendungsanmeldedaten, OAuth-Token, API-Schlüssel und andere geheime Daten während ihres gesamten Lebenszyklus zu verwalten, abzurufen und zu rotieren. Diese Seite enthält verbindliche Anleitungen für die Verwaltung von API-Schlüsseln und Anmeldeinformationen von Drittanbietern in sicherheitssensiblen Workloads. Kombinieren Sie die automatische Rotation mit vom Kunden verwalteten AWS KMS Schlüsseln und IAM-Richtlinien mit den geringsten Rechten. Konfigurieren Sie außerdem den VPC-Endpunktzugriff, um das Sicherheitsfenster und den Explosionsradius kompromittierter Anmeldeinformationen zu minimieren.

Speichern Sie API-Schlüssel in AWS Secrets Manager

In diesem Abschnitt wird beschrieben, wie Sie Ihre API-Schlüsselgeheimnisse für eine optimale Rotation und einen optimalen Abruf strukturieren. Speichern Sie jeden API-Schlüssel als separates Geheimnis mit einem strukturierten JSON-Wert. Mit dieser Struktur kann Ihre Anwendung einzelne Felder abrufen und Secrets Manager kann die richtigen Werte an eine Rotationsfunktion übergeben.

Das folgende Beispiel zeigt eine allgemeine JSON-Struktur für API-Schlüsselgeheimnisse von Drittanbietern. Die tatsächlichen Felder hängen von den Anforderungen Ihres Anbieters ab. Lesen Sie in der Dokumentation des Anbieters nach, welche spezifischen Anmeldeinformationen und Metadaten Sie speichern müssen.

{
  "apiKey": "your-api-key-value",
  "apiKeyId": "key-identifier",
  "endpoint": "https://api.example.com/v1",
  "provider": "example-service"
}

Beispiel für eine geheime Struktur für API-Schlüssel

Feld	Beispielwert	Zweck
apiKey	sk_live_abc123...	Der Anmeldeinformationswert, den Ihre Anwendung zur Authentifizierung bei der Drittanbieter-API verwendet.
apiKeyId	key_001	Bezeichner für den Schlüssel auf der Anbieterseite. Wird während der Rotation verwendet, um einen neuen Schlüssel zu erstellen und den alten zu löschen.
endpoint	https://api.example.com/v1	URL des API-Endpunkts. Mit dem Schlüssel speichern, sodass beim Abrufen alles zurückgegeben wird, was die Anwendung für die Verbindung benötigt.
provider	stripe	Name des Anbieters. Nützlich für die Funktionslogik zum Taggen, Filtern und Drehen, die mehrere Anbieter verarbeitet.

Taggen Sie jedes Geheimnis mit Metadaten, um die IAM-Richtlinienbedingungen und die organisatorische Filterung zu unterstützen. Beispielsweise können Sie Geheimnisse mithilfe der OR-Konsole mit dem jeweiligen Team, der Umgebung und dem AWS CLI Compliance-Bereich kennzeichnen:

aws secretsmanager tag-resource \
    --secret-id prod/payments/stripe-api-key \
    --tags Key=Team,Value=payments Key=Environment,Value=production \
           Key=Provider,Value=stripe Key=Compliance,Value=pci-dss

Weitere Informationen zum Erstellen von Geheimnissen finden Sie unterErstellen Sie eine AWS Secrets Manager Secret.

Verschlüsselungskonfiguration

Secrets Manager verschlüsselt jeden geheimen Wert im Ruhezustand mithilfe eines AWS KMS Schlüssels. Wählen Sie für sicherheitsrelevante Workloads den Verschlüsselungsschlüssel, der Ihren Compliance- und Zugriffskontrollanforderungen entspricht.

KMS-Schlüsseloptionen für API-Schlüsselgeheimnisse

Schlüsseltyp	Wann sollte dies verwendet werden?	Sicherheitsüberlegungen
AWS verwalteter Schlüssel (aws/secretsmanager)	Standard für die meisten Workloads. Keine zusätzlichen Kosten oder Aufwand für die Schlüsselverwaltung.	Die Schlüsselrichtlinie ist nur auf den Betrieb von Secrets Manager beschränkt und kann nicht geändert werden. Kann nicht für den kontoübergreifenden Zugriff verwendet werden.
Kundenseitig verwalteter Schlüssel	Konformitätsanforderungen (z. B. PCI DSS, HIPAA, SOC 2 oder andere geltende Standards). Cross-account geheimes Teilen. Anforderungen an die Überprüfung der wichtigsten Nutzung.	Sie kontrollieren die wichtigsten Richtlinien. Sie können einschränken, welche Principals entschlüsseln können. Sie können das Löschen von Schlüsseln unabhängig vom Schlüssel deaktivieren oder planen. Stellt einen unabhängigen Prüfpfad zur Verfügung.

Verwenden Sie für sicherheitsrelevante Workloads einen vom Kunden verwalteten Schlüssel, der die folgenden wichtigen Richtlinienbedingungen erfüllt:

• kms:ViaService— Beschränken Sie die Verwendung von Schlüsseln auf Anfragen, die von Secrets Manager () stammen. secretsmanager.<region>.amazonaws.com

• kms:EncryptionContext:SecretARN— Beschränken Sie die Entschlüsselung auf bestimmte geheime ARNs, indem Sie dem Secrets Manager-Verschlüsselungskontext entsprechen.

• Separate Schlüssel pro Compliance-Grenze — Verwenden Sie unterschiedliche AWS KMS Schlüssel für Geheimnisse in unterschiedlichen Compliance-Bereichen (z. B. PCI im Vergleich zu Nicht-PCI).

Eine vollständige Erläuterung des Verschlüsselungs- und Entschlüsselungsvorgangs finden Sie unter. Geheime Verschlüsselung und Entschlüsselung in AWS Secrets Manager

Automatische Rotation für API-Schlüssel

Die automatische Rotation reduziert das Zeitfenster, in dem kompromittierte Zugangsdaten gefährdet sind. Secrets Manager ruft eine Lambda-Funktion nach einem Zeitplan auf. Die Funktion erstellt einen neuen API-Schlüssel beim Anbieter, aktualisiert den geheimen Wert und löscht den alten Schlüssel.

Secrets Manager bietet verwaltete Rotationsfunktionen für einige Drittanbieter über verwaltete externe Geheimnisse. Weitere Informationen zu dieser Funktion und die Liste der unterstützten Anbieter finden Sie unterVerwaltete externe Geheimnisse | Partner. Für Anbieter ohne Unterstützung für verwaltete Rotation implementieren Sie eine benutzerdefinierte Lambda-Rotationsfunktion, die die API des Anbieters aufruft, um Schlüssel zu erstellen und zu löschen.

Lebenszyklus der Rotationsfunktion

Eine Rotations-Lambda-Funktion implementiert vier Schritte. Secrets Manager ruft die Funktion einmal für jeden Schritt auf und übergibt einen Step Parameter. Wenn ein Schritt fehlschlägt, versucht Secrets Manager automatisch die gesamte Rotation erneut.

Schritte zur Rotation von API-Schlüsseln

Schritt	Aktion für API-Schlüssel	Fehlerbehandlung
createSecret	Rufen Sie die Provider-API auf, um einen neuen Schlüssel zu erstellen. Speichern Sie den neuen Schlüsselwert in Secrets Manager mit dem AWSPENDING Staging-Label.	Wenn die Schlüsselerstellung fehlschlägt, geht die Rotation nicht zum nächsten Schritt über. Der vorhandene Schlüssel bleibt aktiv alsAWSCURRENT.
setSecret	Bei API-Schlüsseln, die beim Anbieter erstellt wurden, entfällt dieser Schritt in der Regel. Dieser Schritt wird verwendet, wenn ein zufälliger Schlüssel in Secrets Manager generiert wird und vom Anbieter festgelegt werden muss — was nicht dem typischen API-Schlüsselfluss entspricht.	Schlägt dieser Schritt fehl, wird die Rotation nicht fortgesetzttestSecret.
testSecret	Rufen Sie den AWSPENDING Wert aus Secrets Manager ab und führen Sie einen Test-API-Aufruf an den Anbieter durch, um zu überprüfen, ob der neue Schlüssel funktioniert.	Wenn der Test fehlschlägt, löschen Sie den ausstehenden Schlüssel beim Anbieter und lösen Sie eine Ausnahme aus.
finishSecret	Wechseln AWSCURRENT Sie zum neuen Schlüssel. Der alte Schlüssel wechselt zuAWSPREVIOUS. Löschen Sie optional den alten Schlüssel beim Anbieter.	Schlägt das Label-Update fehl, wird die Rotation nicht abgeschlossen. Der neue Schlüssel ist vorhanden, aber noch nicht beschriftetAWSCURRENT.

Die vollständige Vorlage für die Rotationsfunktion und Anleitungen zur Implementierung finden Sie unterLambda-Rotationsfunktionen.

Konfiguration des Rotationsplans

Legen Sie das Rotationsintervall auf der Grundlage Ihrer Compliance-Anforderungen und internen Sicherheitsrichtlinien fest. Lesen Sie die für Ihren Workload geltenden Compliance-Standards, um die geeignete Rotationshäufigkeit zu ermitteln.

Verwenden Sie ein Rotationsfenster, um zu steuern, wann eine Rotation stattfindet. Dadurch wird verhindert, dass die Rotation während der Spitzenzeiten oder bei Wartungsarbeiten abläuft:

aws secretsmanager rotate-secret \
    --secret-id prod/payments/stripe-api-key \
    --rotation-rules '{
        "ScheduleExpression": "cron(0 4 ? * SUN *)",
        "Duration": "2h"
    }'

Informationen zur Syntax von Zeitplanausdrücken finden Sie unterRotationspläne.

Effizientes Abrufen von Geheimnissen

Secrets Manager unterstützt 10.000 Transaktionen pro Sekunde bei GetSecretValue Anrufen. Bei den meisten Anwendungen kommt es nicht zu einer Drosselung. Verwenden Sie für Anwendungen mit sehr hohem Anrufvolumen oder latenzempfindlichen Pfaden eine Caching-Lösung, um API-Aufrufe zu reduzieren und die Antwortzeiten zu verbessern.

Secrets Manager bietet Caching-Clients für mehrere Sprachen sowie eine Lambda-Erweiterung, die Geheimnisse lokal in der Ausführungsumgebung zwischenspeichert. Weitere Hinweise zu Caching-Optionen finden Sie unterHolen Sie sich einen geheimen Secrets Manager-Wert mithilfe von Java mit clientseitigem Caching, und. Holen Sie sich einen geheimen Secrets Manager-Wert mithilfe von Python mit clientseitigem Caching Rufen Sie mithilfe von Go mit clientseitigem Caching einen geheimen Wert für Secrets Manager ab

Konfigurieren Sie für alle Zugriffsmuster IAM-Richtlinien, die sich auf die spezifischen Geheimnisse secretsmanager:GetSecretValue beschränken, die jede Anwendung benötigt:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/payments/*",
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/Environment": "production"
      }
    }
  }]
}

Erhöhung der Sicherheit für sensible Workloads

Die folgenden Verfahren bieten umfassenden Schutz für API-Schlüssel in Umgebungen mit strengen Sicherheitsanforderungen (z. B. PCI DSS, SOC 2, HIPAA oder andere geltende Compliance-Frameworks):

Beschränken Sie den Netzwerkzugriff mit VPC-Endpunkten

Erstellen Sie einen VPC-Schnittstellen-Endpunkt für Secrets Manager, damit das Abrufen geheimer Daten niemals über das öffentliche Internet erfolgt. Wenden Sie eine Endpunktrichtlinie an, die einschränkt, auf welche Geheimnisse über den Endpunkt zugegriffen werden kann. Weitere Informationen finden Sie unter Verwenden eines AWS Secrets Manager VPC-Endpunkts.

Wenden Sie Ressourcenrichtlinien auf Geheimnisse an

Hängen Sie jedem Secret eine Ressourcenrichtlinie an, die den Zugriff von Principals außerhalb Ihres Kontos oder außerhalb bestimmter VPC-Endpoints explizit verweigert. Dies bietet eine zweite Autorisierungsgrenze, die unabhängig von den IAM-Identitätsrichtlinien ist.

Überwachen Sie den geheimen Zugriff mit

protokolliert automatisch alle Secrets Manager-API-AufrufeGetSecretValue, einschließlichPutSecretValue, undRotateSecret. Erstellen Sie für sicherheitsrelevante Geheimnisse einen CloudWatch Amazon-Alarm, der bei unerwarteten GetSecretValue Aufrufen ausgelöst wird — beispielsweise bei Aufrufen von unbekannten Quell-IP-Adressen oder IAM-Prinzipalen.

AWSPREVIOUSFür eine anmutige Rotation verwenden

Während der Rotation behält Secrets Manager den vorherigen Schlüsselwert mit dem AWSPREVIOUS Staging-Label bei. Wenn Ihr Anbieter den vorherigen Schlüssel ungültig macht, wenn ein neuer Schlüssel erstellt wird, konfigurieren Sie Ihre Anwendung so, dass sie darauf zurückgreift, AWSPREVIOUS wenn ein AWSCURRENT Authentifizierungsfehler zurückgegeben wird. Dadurch werden Ausfallzeiten während des kurzen Zeitfensters zwischen der Schlüsselerstellung und der Aktualisierung des Labels vermieden.

Überprüfen Sie die Ressourcenrichtlinien vor dem Anhängen

Geheimnisse ohne Ressourcenrichtlinie blockieren bereits den öffentlichen Zugriff. Wenn Sie Ihrem Secret eine Ressourcenrichtlinie hinzufügen, stellen Sie mithilfe der ValidateResourcePolicy API sicher, dass Ihre Richtlinie keinen breiten öffentlichen Zugriff gewährt. Sie können den BlockPublicPolicy Parameter with auch verwendenPutResourcePolicy, um das Anhängen von Richtlinien zu verhindern, die öffentlichen Zugriff gewähren. Verwenden Sie den aws:PrincipalOrgID Bedingungsschlüssel in den Ressourcenrichtlinien, um den Zugriff durch Prinzipale außerhalb Ihrer Organisation zu verhindern.

Häufig gestellte Fragen

In diesem Abschnitt werden häufig gestellte Fragen zur API-Schlüsselrotation und zur Verwaltung geheimer Schlüssel in AWS Secrets Manager beantwortet.

Wie gehe ich mit der Überschneidungszeit während der Rotation um?

Dies ist nur erforderlich, wenn der Anbieter den vorhandenen Schlüssel ungültig macht, wenn ein neuer Schlüssel erstellt wird. Wenn der Anbieter mehrere aktive Schlüssel gleichzeitig unterstützt, funktionieren beide Schlüssel während der Rotationsperiode ohne anwendungsseitige Fallback-Logik. Für Anbieter, die den alten Schlüssel ungültig machen, konfigurieren Sie Ihre Anwendung so, dass sie es erneut versucht, AWSPREVIOUS wenn der aktuelle Schlüssel einen 401- oder 403-Fehler zurückgibt. Löschen Sie den alten Schlüssel beim Anbieter in diesem finishSecret Schritt erst, nachdem Sie bestätigt haben, dass der neue Schlüssel funktioniert.

Was ist, wenn mein Anbieter die programmatische Schlüsselerstellung nicht unterstützt?

Wenn der Anbieter eine manuelle Schlüsselerstellung erfordert (z. B. über eine Webkonsole), können Sie die Rotation nicht vollständig automatisieren. Verwenden Sie stattdessen eine Rotationsfunktion, die eine Benachrichtigung (über Amazon Simple Notification Service) sendet, wenn die Rotation fällig ist, und den Bediener auffordert, den Schlüssel manuell zu erstellen und den geheimen Wert zu aktualisieren. Stellen Sie den Rotationsplan so ein, dass er Ihren Anforderungen an die Einhaltung der Vorschriften entspricht, und verwenden Sie die CloudWatch Amazon-Alarmedays_since_last_rotation, um verpasste Rotationen zu erkennen.

Wie vermeide ich eine API-Drosselung beim Abrufen von Geheimnissen?

Secrets Manager unterstützt ab 10.000 Transaktionen pro Sekunde. GetSecretValue Bei den meisten Anwendungen kommt es nicht zu einer Drosselung. Wenn Ihre Anwendung ein außergewöhnlich hohes Aufrufvolumen tätigt, verwenden Sie einen Caching-Client oder die Lambda Parameters and Secrets-Erweiterung. Diese speichern den geheimen Wert im Speicher und werden regelmäßig aktualisiert, wodurch die Anzahl der API-Aufrufe reduziert wird. Stellen Sie die Cache-TTL auf einen Wert ein, der kürzer als Ihr Rotationsintervall ist, damit die Anwendung nach der Rotation neue Schlüssel aufnimmt.

Sollte ich ein Geheimnis pro Umgebung oder ein Geheimnis für Versionen verwenden?

Verwenden Sie separate Geheimnisse für jede Umgebung (z. B. prod/payments/stripe unddev/payments/stripe). Dies ermöglicht unterschiedliche IAM-Richtlinien, Rotationspläne und Verschlüsselungsschlüssel pro Umgebung. Geheime Versionen (Staging-Labels) dienen der Verwaltung von Rotationszuständen, nicht der Trennung von Umgebungen.