Einführung in AWS Secrets Manager

AWS Secrets Manager ist ein verwalteter Dienst, der Geheimnisse wie Datenbankpasswörter, API-Schlüssel und OAuth-Token während ihres gesamten Lebenszyklus speichert, rotiert und prüft. Dies ist wichtig, da fest codierte Anmeldeinformationen im Anwendungscode eine der häufigsten Ursachen für Datenschutzverletzungen und Compliance-Verstöße sind. Es wird empfohlen, alle Anwendungsgeheimnisse in Secrets Manager zu migrieren, einen kundenseitig verwalteten KMS-Schlüssel für die Verschlüsselung zu konfigurieren, die automatische Rotation zu aktivieren und die CloudTrail-Datenzugriffsprotokollierung für alle Abrufvorgänge von Geheimnissen einzuschalten.

Kurzantwort: Was macht AWS Secrets Manager?

AWS Secrets Manager ist ein zentraler Speicher für geheime Daten, der fest codierte Anmeldeinformationen aus dem Anwendungscode entfernt. Er verschlüsselt alle gespeicherten Geheimnisse mit AWS KMS (AES-256-GCM-Verschlüsselung), überträgt Geheimnisse ausschließlich über TLS, bietet automatische Anmeldeinformationsrotation über AWS Lambda für unterstützte Datenbanken und benutzerdefinierte Ziele, steuert den Zugriff über IAM-ressourcenbasierte Richtlinien und protokolliert jeden Zugriff auf geheime Daten in CloudTrail. Er ist nativ in Amazon RDS, Amazon DocumentDB, Amazon Redshift und über 100 weitere AWS-Services integriert. Secrets Manager unterscheidet sich von AWS KMS: KMS verwaltet Verschlüsselungsschlüssel; Secrets Manager verwaltet die Geheimnisse, die diese Schlüssel schützen. Weitere Informationen zur KMS-Verschlüsselungsebene finden Sie in unserem Leitfaden „ Wie sicher sind die Key Management Services von Amazon (AWS KMS)?“.

Wichtige Erkenntnisse

• Secrets Manager entfernt fest codierte Anmeldeinformationen: Alle Geheimnisse werden in einem zentralen verwalteten Dienst gespeichert und über einen API-Aufruf abgerufen. Dadurch werden Zugangsdaten aus dem Quellcode, den Konfigurationsdateien und den CI/CD-Pipelines entfernt, wo sie routinemäßig in der Versionskontrolle und in Protokollen offengelegt werden.
• Die Verschlüsselung verwendet KMS-Envelope-Verschlüsselung mit AES-256-GCM: Der geheime Wert wird mit einem von AWS KMS generierten Datenschlüssel verschlüsselt. Der Klartext-Datenschlüssel wird nach Gebrauch sofort verworfen. Standardmäßig wird der von AWS verwaltete Schlüssel (aws/secretsmanager) verwendet. Kundenseitig verwaltete Schlüssel bieten eine unabhängige Protokollierung und Widerrufsmöglichkeit für Compliance-Workloads.
• Die automatische Rotation ist das entscheidende Merkmal gegenüber konkurrierenden Diensten: Secrets Manager bietet eine integrierte Lambda-basierte Rotation für Amazon RDS, DocumentDB und Redshift. Benutzerdefinierte Lambda-Funktionen unterstützen die Rotation für alle anderen Geheimnistypen, einschließlich API-Schlüssel von Drittanbietern, lokale Datenbanken und OAuth-Token.
• Ressourcenbasierte IAM-Richtlinien sind der primäre Zugriffskontrollmechanismus: Jedes Geheimnis verfügt über eine Ressourcenrichtlinie, die festlegt, welche Prinzipale es abrufen, rotieren oder löschen dürfen. Dies ermöglicht eine detaillierte Kontrolle auf Geheimnisebene, unabhängig von den IAM-Identitätsrichtlinien auf Kontoebene.
• Die CloudTrail-Integration stellt den Compliance-Audit-Trail bereit: Jeder API-Aufruf des Secrets Managers (GetSecretValue, CreateSecret, RotateSecret, DeleteSecret) wird in CloudTrail mit der anfragenden Identität, dem ARN des Geheimnisses und dem Zeitstempel protokolliert. Durch Aktivieren der KMS-Datenzugriffsprotokollierung wird zusätzlich jedes Entschlüsselungsereignis im Zusammenhang mit dem Abruf von Geheimnissen erfasst.

Was ist AWS Secrets Manager?

AWS Secrets Manager ist ein vollständig verwalteter Dienst zur Verwaltung von Geheimnissen, der die Speicherung, den Abruf, die Rotation und die Prüfung von Anwendungsgeheimnissen während ihres gesamten Lebenszyklus übernimmt. Ein Geheimnis ist in diesem Zusammenhang jede sensible Anmeldeinformation, die eine Anwendung oder ein Dienst zur Authentifizierung gegenüber einer anderen Ressource verwendet: Datenbankbenutzernamen und -passwörter, API-Schlüssel, OAuth-Zugriffstoken, private TLS-Schlüssel, SSH-Anmeldeinformationen und Dienstkontopasswörter.

Ohne einen zentralen Geheimnismanager sind Anmeldeinformationen typischerweise im Anwendungscode, in Konfigurationsdateien, Umgebungsvariablen, CI/CD-Pipeline-Definitionen oder Skripten eingebettet. An all diesen Stellen können Anmeldeinformationen unbeabsichtigt über Versionskontrollsysteme, Protokollaggregation, Build-Artefakte oder Container-Image-Ebenen offengelegt werden. AWS Secrets Manager ersetzt all diese Muster durch einen einzigen API-Aufruf, der den aktuellen Geheimniswert bei Bedarf über einen verschlüsselten Kanal an einen authentifizierten Aufrufer abruft.

AWS Secrets Manager ist ein separater Dienst von AWS Key Management Service (AWS KMS). KMS verwaltet die kryptografischen Schlüssel zum Schutz von Geheimnissen; Secrets Manager verwaltet die Geheimnisse selbst. Die beiden Dienste arbeiten zusammen: Jedes in Secrets Manager gespeicherte Geheimnis wird mit einem AWS-KMS-Datenschlüssel verschlüsselt, bevor es im persistenten Speicher von Secrets Manager abgelegt wird. Dieses Verständnis ist wichtig für die Einhaltung von Compliance-Vorgaben und die Auswahl des passenden KMS-Schlüsseltyps. Ausführliche Informationen zur KMS-Verschlüsselungsschicht finden Sie in unserem Leitfaden „ AWS KMS im Detail“.

Wie AWS Secrets Manager Geheimnisse verschlüsselt

Jeder in AWS Secrets Manager gespeicherte geheime Wert wird im Ruhezustand mittels Envelope-Verschlüsselung über AWS KMS verschlüsselt. Der Prozess funktioniert wie folgt:

1. Wenn Sie ein Geheimnis speichern, ruft Secrets Manager den AWS KMS auf. GenerateDataKey Operation, bei der der für dieses Geheimnis konfigurierte KMS-Schlüssel angegeben wird.
2. AWS KMS gibt einen AES-256-Datenschlüssel im Klartext und eine verschlüsselte Kopie desselben Datenschlüssels (umhüllt vom KMS-Schlüssel) zurück.
3. Secrets Manager verwendet den Klartext-Datenschlüssel, um den geheimen Wert mit AES-256-GCM (Authenticated Encryption with Associated Data) zu verschlüsseln.
4. Secrets Manager speichert den verschlüsselten geheimen Wert und den verschlüsselten Datenschlüssel gemeinsam in seinem permanenten Speicher.
5. Der Klartext-Datenschlüssel wird sofort aus dem Speicher gelöscht. Er wird nirgendwo dauerhaft gespeichert.
6. Wird ein Geheimnis abgerufen, sendet Secrets Manager den verschlüsselten Datenschlüssel zur Entschlüsselung an AWS KMS. KMS sendet den Klartext-Datenschlüssel zurück.
7. Secrets Manager verwendet den Klartext-Datenschlüssel, um den geheimen Wert zu entschlüsseln und gibt das Klartext-Geheimnis über eine TLS-verschlüsselte Verbindung an den Aufrufer zurück.
8. Der Klartext-Datenschlüssel wird nach Gebrauch wieder aus dem Speicher gelöscht.

Secrets Manager speichert geheime Werte niemals im Klartext in einem persistenten Speicher. Der zusammen mit dem Geheimnis gespeicherte verschlüsselte Datenschlüssel ist ohne Zugriff auf den zugehörigen KMS-Schlüssel nutzlos. Das bedeutet, dass die Kompromittierung des Speichers von Secrets Manager allein nicht ausreicht, um Geheimnisse im Klartext wiederherzustellen.

Nativer KMS-Schlüssel vs. kundenverwalteter KMS-Schlüssel: Welcher ist der richtige?

Standardmäßig verwendet Secrets Manager einen von AWS verwalteten KMS-Schlüssel mit dem Alias aws/secretsmanagerDieser Schlüssel wird automatisch in Ihrem Konto erstellt, sobald Sie zum ersten Mal ein Geheimnis erstellen, ohne einen KMS-Schlüssel anzugeben. Die Umstellung auf einen kundenverwalteten KMS-Schlüssel (CMK) ist die konforme Konfiguration für regulierte Workloads.

Eigenschaft	AWS-verwalteter Schlüssel (aws/secretsmanager)	Kundenseitig verwalteter KMS-Schlüssel (CMK)
Schlüssel generiert von	AWS automatisch	Sie, in Ihrer AWS KMS-Konsole oder über die API
Schlüsselrichtlinienkontrolle	Keine (AWS übernimmt die vollständige Verwaltung)	Vollständig (Sie legen fest, wer den Schlüssel verwenden und verwalten kann)
CloudTrail-Audit-Protokoll pro Operation	Nein (nur bei begrenzten Veranstaltungen)	Ja (jeder Verschlüsselungs- und Entschlüsselungsvorgang ist mit der Wiederherstellung von Geheimnissen verbunden).
Unabhängige Tastendeaktivierung/-widerruf	Nein	Ja (CMK deaktivieren, um jeglichen Zugriff auf Geheimnisse sofort zu blockieren)
Automatische Schlüsseldrehung	Ja (AWS-gesteuerter Zeitplan)	Ja (konfigurierbar von 90 Tagen bis 7 Jahren)
BYOK-Unterstützung	Nein	Ja (importieren Sie Ihr eigenes Schlüsselmaterial über KMS-Importaufträge)
FIPS 140-2 Level 3 Option	Nein	Ja (mit CloudHSM-eigenem Schlüsselspeicher)
Zusätzliche Kosten	Keine Präsentation	0.06 bis 2.50 US-Dollar/Key-Version/Monat + 0.03 US-Dollar/10 KMS-Operationen
Am besten geeignet,	Entwicklung, nicht regulierte Arbeitsbelastungen	Regulierte Arbeitslasten: PCI DSS, HIPAA, FedRAMP, DSGVO

Für Workloads, bei denen AWS keinen Zugriff auf den geheimen Verschlüsselungsschlüssel haben darf (HYOK/Hold Your Own Key-Anforderungen), empfiehlt sich die clientseitige Verschlüsselung des geheimen Werts vor der Übergabe an den Secrets Manager. Hierfür wird ein Schlüssel verwendet, der vollständig außerhalb von AWS gespeichert ist. Der Secrets Manager speichert anschließend den bereits verschlüsselten Wert. Dies erhöht zwar die operative Komplexität und schließt die native Schlüsselrotation aus, gewährleistet aber den vollständigen Ausschluss von AWS aus der Schlüsselvertrauenskette. Encryption Consulting bietet mit seinem HSM as a Service die externe, FIPS 140-2 Level 3-konforme Schlüsselverwaltungsinfrastruktur für HYOK-Implementierungen.

Wie die automatische Geheimnisrotation funktioniert

Die automatische Rotation ist die Funktion, die AWS Secrets Manager am deutlichsten von einfacheren Parameterspeichern unterscheidet. Wenn die Rotation ausgelöst wird, führt Secrets Manager eine AWS Lambda-Funktion aus, die einem vierstufigen Lebenszyklus folgt:

1. CreateSecret: Die Lambda-Funktion generiert einen neuen Anmeldeinformationswert und erstellt eine neue Version des Geheimnisses im Secrets Manager mit dem Staging-Label. AWSPENDINGDie vorherige Version behält die AWSCURRENT Die Kennzeichnung sollte während dieses Schritts beibehalten werden, damit bestehende Verbindungen weiterhin die aktuellen Anmeldeinformationen verwenden können.
2. SetSecret: Die Lambda-Funktion aktualisiert die Anmeldeinformationen im Zieldienst (Datenbank, API oder anderer Dienst) mit dem neuen Wert. Der Zieldienst akzeptiert nun sowohl die alten Anmeldeinformationen (noch in der Datenbank) als auch die alten Anmeldeinformationen (noch in der Datenbank). AWSCURRENT) und die neue.
3. TestSecret: Die Lambda-Funktion testet die neue Anmeldeinformation gegenüber dem Zieldienst, um deren Funktionsfähigkeit zu bestätigen, bevor die alte deaktiviert wird. Schlägt der Test fehl, wird die Rotation gestoppt und die alte Anmeldeinformation bleibt aktiv.
4. FinishSecret: Die Lambda-Funktion verschiebt die AWSCURRENT auf die neue Version umbenennen und verschieben AWSPREVIOUS Die alten Zugangsdaten sind nun gültig. Die alten Zugangsdaten werden kurzzeitig beibehalten, damit alle damit verbundenen Verbindungen während des Fluges hergestellt werden können.

Für Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), Amazon DocumentDB und Amazon Redshift stellt AWS verwaltete Lambda-Rotationsfunktionen bereit, die alle vier Schritte automatisch ausführen. Diese Funktionen ermöglichen die einfachste Rotation und können über die Secrets Manager-Konsole oder AWS CloudFormation konfiguriert werden. Für alle anderen Secret-Typen stellen Sie eine benutzerdefinierte Lambda-Funktion bereit, die dasselbe vierstufige Muster implementiert. Dies unterstützt die Rotation für lokale Datenbanken, API-Dienste von Drittanbietern, SSH-Schlüssel, OAuth-Token und alle Anmeldeinformationen mit einem programmierbaren Aktualisierungsmechanismus.

Die Rotation kann so konfiguriert werden, dass sie nach einem Zeitplan (mindestens täglich) oder bei Bedarf sofort erfolgt. Für Compliance-Workloads gemäß PCI DSS-Anforderung 8.3.9 (periodische Rotation von Authentifizierungsdaten) erfüllt die automatische Rotation im 90-Tage-Rhythmus oder kürzeren Intervall die Anforderung ohne manuelles Eingreifen.

IAM-Zugriffsmodell: Kontrolle darüber, wer Geheimnisse abrufen kann

Der Zugriff auf Geheimnisse in AWS Secrets Manager wird über zwei Ebenen gesteuert: IAM-Identitätsrichtlinien und ressourcenbasierte Richtlinien für Geheimnisse. Beide müssen einem Prinzipal die Berechtigung erteilen, bevor der Zugriff gewährt wird.

Geheime ressourcenbasierte Politik (primäre Kontrolle): Jedes Geheimnis verfügt über eine Ressourcenrichtlinie, die explizit definiert, welche AWS-Prinzipale (IAM-Rollen, IAM-Benutzer, AWS-Konten oder AWS-Services) welche Operationen für dieses spezifische Geheimnis ausführen dürfen. Die wichtigsten zu steuernden Operationen sind: secretsmanager:GetSecretValue (das Geheimnis entschlüsseln), secretsmanager:RotateSecret (Auslöserrotation), secretsmanager:DeleteSecret (geplante Löschung) und secretsmanager:PutSecretValue (einen neuen geheimen Wert schreiben). Die Ressourcenrichtlinie bietet Granularität auf Geheimnisebene: Einem Dienstkonto einer Anwendung kann die Berechtigung GetSecretValue nur für seine spezifischen Geheimnisse erteilt werden, ohne Zugriff auf andere Geheimnisse im Konto.

IAM-Identitätsrichtlinie (sekundäre Ebene): IAM-Richtlinien, die Rollen, Benutzern oder Gruppen zugeordnet sind, können Secrets Manager Berechtigungen erteilen. Für einen erfolgreichen Zugriff müssen sowohl die Identitätsrichtlinie als auch die Ressourcenrichtlinie die Operation zulassen. Dieses zweischichtige Modell ermöglicht es Ihnen, mithilfe von Identitätsrichtlinien umfassenden Zugriff auf Secrets Manager zu gewähren und diesen anschließend mithilfe von Ressourcenrichtlinien auf Geheimnisebene einzuschränken – oder umgekehrt.

Kontoübergreifender Zugriff: Secrets Manager unterstützt den kontoübergreifenden Zugriff auf Geheimnisse, indem der Principal des externen Kontos zur Ressourcenrichtlinie des Geheimnisses hinzugefügt und die KMS-Schlüsselnutzung für das Geheimnis dem externen Konto gewährt wird. Dieses Muster ist nützlich für gemeinsam genutzte Servicekonten, die Geheimnisse für mehrere Anwendungskonten verwalten, oder für die zentrale Geheimnisverwaltung in einem dedizierten Geheimniskonto.

Tagbasierte Zugriffskontrolle: Secrets Manager unterstützt AWS-Ressourcen-Tags. Sie können IAM-Richtlinienbedingungen basierend auf Secret-Tags verwenden (zum Beispiel aws:ResourceTag/Environment: ProductionUm den Zugriff auf Produktionsgeheimnisse auf bestimmte Rollen zu beschränken, während Entwicklerrollen nur auf als „Entwicklung“ gekennzeichnete Geheimnisse zugreifen können, ist dies in großen Umgebungen nützlich, in denen die Verwaltung einzelner Geheimnis-ARNs in Richtlinien unpraktisch ist.

Service Control Policies (SCPs): Wenn sich Ihre Konten in einer AWS-Organisation befinden, können SCPs organisationsweite Richtlinien durchsetzen: Sie können beispielsweise vorschreiben, dass alle Secrets vom Kunden verwaltete KMS-Schlüssel verwenden, die Löschung von als Produktion gekennzeichneten Secrets verweigern oder vorschreiben, dass der Secrets Manager VPC-Endpunkt für alle Secret-Abrufe innerhalb einer bestimmten Organisationseinheit verwendet wird.

CloudTrail-Auditprotokollierung für Secrets Manager

AWS Secrets Manager ist vollständig in AWS CloudTrail integriert. Jeder API-Aufruf von Secrets Manager generiert ein CloudTrail-Ereignis, das den Vorgangsnamen, den ARN des Geheimnisses, die anfragende IAM-Identität, die Quell-IP-Adresse, die AWS-Region und den Zeitstempel protokolliert. Dieses Audit-Trail dient als primärer Nachweis für Compliance-Prüfungen im Zusammenhang mit dem Zugriff auf Geheimnisse.

Verwaltungsereignisse (CreateSecret, DeleteSecret, RotateSecret, PutResourcePolicy, TagResource) werden automatisch in CloudTrail protokolliert und können nicht deaktiviert werden. Diese Ereignisse erfassen den administrativen Lebenszyklus jedes Geheimnisses.

Datenereignisse (GetSecretValue) müssen in CloudTrail separat aktiviert werden. Durch die Aktivierung von Datenereignissen für Secrets Manager wird für jeden Abruf eines Geheimnisses ein Protokolleintrag erstellt, der genau anzeigt, welche Anwendung oder welcher Benutzer welches Geheimnis wann abgerufen hat. Für die PCI-DSS-Anforderung 10, die HIPAA-Audit-Control-Anforderungen und die FedRAMP-AU-Kontrollen ist die Aktivierung von Datenereignissen erforderlich. Ohne die Protokollierung von Datenereignissen können Sie zwar nachweisen, dass ein Geheimnis erstellt und rotiert wurde, aber nicht, wer es wann abgerufen hat.

KMS-Datenzugriffsprotokolle fügen eine zweite Ebene hinzu: Jeder durch eine Secrets Manager-Anfrage „GetSecretValue“ ausgelöste KMS-Entschlüsselungsaufruf erzeugt ein CloudTrail-Ereignis, das den verwendeten KMS-Schlüssel-ARN, den anfragenden Secrets Manager-Dienst und den Zeitstempel enthält. Dieses Protokoll dient als kryptografischer Nachweis dafür, dass ein bestimmtes Geheimnis zu einem bestimmten Zeitpunkt entschlüsselt wurde.

Wichtige Benachrichtigungen, die über CloudTrail Secrets Manager-Ereignisse konfiguriert werden sollten: Sofortige Benachrichtigung bei DeleteSecret für jedes Produktionsgeheimnis; Benachrichtigung bei GetSecretValue-Aufrufen von IAM-Prinzipalen, die nicht in der Liste der genehmigten Anwendungsrollen enthalten sind; Benachrichtigung bei häufigen GetSecretValue-Aufrufen, die auf automatisiertes Sammeln von Anmeldeinformationen hindeuten könnten; und Benachrichtigung bei PutResourcePolicy-Änderungen an jedem Produktionsgeheimnis, die den Zugriff erweitern könnten.

Kernfunktionen von AWS Secrets Manager

Integration mit AWS KMS: Jedes Geheimnis wird im Ruhezustand mit AWS KMS-Envelope-Verschlüsselung verschlüsselt. Secrets Manager unterstützt sowohl von AWS verwaltete Schlüssel (aws/secretsmanager) als auch vom Kunden verwaltete KMS-Schlüssel. Bei der Konfiguration eines vom Kunden verwalteten CMK generiert jeder Abruf eines Geheimnisses ein CloudTrail KMS-Entschlüsselungsereignis. Dadurch wird ein pro Vorgang protokollierter Prüfpfad bereitgestellt, der mit dem Verschlüsselungsschlüssel des Geheimnisses verknüpft ist. Durch Deaktivieren des CMK wird der weitere Abruf dieses Geheimnisses sofort verhindert, ohne dass das Geheimnis selbst gelöscht wird.

Geheimer Speicher mit mehreren Versionen: Secrets Manager verwaltet mithilfe von Staging-Labels gleichzeitig mehrere Versionen jedes Geheimnisses. Das Label AWSCURRENT kennzeichnet die aktuell verwendete Version. Während der Rotation wird die eingehende Version entsprechend gekennzeichnet. AWSPENDING bis die Rotation abgeschlossen ist, dann wird es AWSCURRENT und die vorherige Version wird AWSPREVIOUSAnwendungen können eine bestimmte Version anhand der Bezeichnung oder der Versions-ID abrufen, was eine Rotation ohne Ausfallzeiten ermöglicht, ohne dass koordinierte Neustarts der Anwendung erforderlich sind.

Native Datenbankintegration: Secrets Manager bietet integrierte Unterstützung für die native Rotation von Anmeldeinformationen für Amazon RDS (alle unterstützten Datenbank-Engines), Amazon DocumentDB, Amazon Redshift und Amazon ElastiCache. Für diese Dienste aktivieren Sie die Rotation in der Secrets Manager-Konsole, wählen einen Rotationsplan aus, und Secrets Manager übernimmt den gesamten Rotationsprozess, ohne dass Sie Lambda-Funktionen manuell schreiben oder bereitstellen müssen.

Regionsübergreifende Geheimnisreplikation: Secrets Manager unterstützt die Replikation von Geheimnissen in mehrere AWS-Regionen. Wird ein Geheimnis in der primären Region aktualisiert oder rotiert, wird die Aktualisierung automatisch an die Replikatregionen weitergegeben. Die regionsübergreifende Replikation ist nützlich für Anwendungen mit mehreren Regionen, bei denen Dienste in jeder Region auf dieselben Anmeldeinformationen zugreifen müssen, ohne regionsübergreifende API-Aufrufe durchführen zu müssen, sowie für Disaster-Recovery-Konfigurationen, bei denen sich die sekundäre Region unabhängig von der primären Region an Datenbanken authentifizieren können muss.

Privater VPC-Endpunkt: Standardmäßig werden API-Aufrufe des Secrets Managers über das öffentliche Internet (über HTTPS) übertragen. Für Workloads, bei denen der gesamte Datenverkehr innerhalb des AWS-Netzwerks bleiben muss (z. B. aufgrund von Compliance-Anforderungen, Netzwerksicherheitsrichtlinien oder Latenzvorgaben), können Sie einen Secrets Manager-VPC-Endpunkt mit AWS PrivateLink konfigurieren. Dieser Endpunkt stellt eine private Verbindung von Ihrer VPC zum Secrets Manager-Dienstendpunkt her und gewährleistet so, dass Anfragen zum Abrufen von Geheimnissen niemals das öffentliche Internet durchlaufen.

Löschschutz und Wiederherstellung: Secrets Manager löscht Geheimnisse nicht sofort. Wenn Sie ein Geheimnis löschen, wird es nach einem Wiederherstellungsfenster von mindestens 7 Tagen (konfigurierbar bis zu 30 Tage) zur endgültigen Löschung eingeplant. Innerhalb dieses Fensters können Sie das Geheimnis und alle seine Versionen wiederherstellen. Nach Ablauf des Fensters werden das Geheimnis und alle seine Versionen endgültig gelöscht. Um ein Geheimnis sofort zu löschen (ohne das Wiederherstellungsfenster zu durchlaufen), verwenden Sie die AWS CLI mit dem entsprechenden Befehl. --force-delete-without-recovery Diese Option zum sofortigen Löschen ist in der Konsole nicht verfügbar.

Hauptanwendungsfälle für AWS Secrets Manager

Vermeidung fest codierter Datenbankzugangsdaten: Der häufigste Anwendungsfall. Der Anwendungscode ruft die Datenbankverbindungsdaten zur Laufzeit über die GetSecretValue-API vom Secrets Manager ab, anstatt sie aus Umgebungsvariablen, Konfigurationsdateien oder dem Quellcode zu lesen. Das Geheimnis wird im Verbindungspool der Anwendung zwischengespeichert und bei einer Rotation aktualisiert. Dadurch wird das Risiko vermieden, dass Zugangsdaten in der Versionsverwaltung, in Build-Protokollen, in Container-Image-Layern oder in Bereitstellungsartefakten offengelegt werden.

Automatisierte Datenbank-Anmeldeinformationsrotation: Für Amazon RDS-Datenbanken kann Secrets Manager das Datenbankbenutzerpasswort planmäßig (z. B. alle 30 oder 90 Tage) ohne Ausfallzeiten rotieren. Die Rotations-Lambda-Funktion erstellt ein neues Passwort in RDS, testet es und aktualisiert anschließend das Geheimnis in Secrets Manager. Anwendungen, die das Secrets Manager SDK mit Caching verwenden, übernehmen das neue Passwort automatisch ohne Neustart.

Lebenszyklusverwaltung von API-Schlüsseln und OAuth-Tokens: API-Schlüssel von Drittanbietern, OAuth-Client-Anmeldeinformationen und Dienstkonto-Tokens können im Secrets Manager gespeichert und mithilfe benutzerdefinierter Lambda-Funktionen rotiert werden. Unterstützt der API-Anbieter die programmatische Rotation von Anmeldeinformationen, ruft die Lambda-Funktion die Rotations-API des Anbieters auf, um einen neuen Schlüssel zu generieren, testet diesen und aktualisiert das Secret im Secrets Manager. Dadurch entfallen manuelle Rotationsprozesse, die fehleranfällig sind und häufig übersehen werden.

Zentralisierte Geheimnisverwaltung für AWS-Umgebungen mit mehreren Konten: In AWS Organizations-Umgebungen mit mehreren Konten (Entwicklung, Staging, Produktion, Shared Services) bietet Secrets Manager mit kontoübergreifenden Ressourcenrichtlinien und regionsübergreifender Replikation ein zentralisiertes Governance-Modell für Geheimnisse. Geheimnisse werden in einem dedizierten Geheimniskonto erstellt und verwaltet, von Anwendungen in anderen Konten über kontoübergreifende IAM-Richtlinien abgerufen und zentral über CloudTrail im Auditkonto geprüft.

Verwaltung von Anmeldeinformationen für lokale und hybride Workloads: Anwendungen, die lokal oder in Nicht-AWS-Umgebungen ausgeführt werden, können Geheimnisse über den öffentlichen API-Endpunkt oder einen mit einer VPC verbundenen privaten Endpunkt vom Secrets Manager abrufen. Dies ermöglicht es hybriden Cloud-Architekturen, die Verwaltung von Geheimnissen in AWS zu zentralisieren, selbst für Workloads, die noch nicht vollständig in die Cloud migriert wurden.

AWS Secrets Manager vs. SSM-Parameterspeicher

AWS Systems Manager Parameter Store (SSM Parameter Store) ist die zweite native AWS-Option zum Speichern von Geheimnissen und Konfigurationen. Beide Dienste können verschlüsselte Werte mithilfe von KMS speichern, dienen aber primär unterschiedlichen Anwendungsfällen.

Abmessungen	AWS Secrets Manager	SSM-Parameterspeicher
Hauptzweck	Geheimnislebenszyklusmanagement (Rotation, Prüfung, Replikation)	Anwendungskonfiguration und Parameterspeicherung
Kosten	0.40 $/Geheimnis/Monat + 0.05 $/10 API-Aufrufe	Kostenlos für Standardparameter; 0.05 $/10 API-Aufrufe für erweiterte verschlüsselte Parameter
Automatische Drehung	Ja (nativ für RDS/DocumentDB/Redshift; benutzerdefinierte Lambda-Funktion für andere)	Nein (muss extern aufgebaut werden)
Geheime Versionierung	Ja (AWSCURRENT, AWSPENDING, AWSPREVIOUS-Labels)	Ja (Versionsnummern)
Kontoübergreifender Zugriff	Ja (über Ressourcenrichtlinie)	Eingeschränkt (komplexere Konfiguration)
Regionsübergreifende Replikation	Ja (eingebaut)	Nein (muss extern aufgebaut werden)
VPC-Endpunkt	Ja (AWS PrivateLink)	Ja (über den SSM VPC-Endpunkt)
KMS-Verschlüsselung	Immer eingeschaltet (AWS-verwaltet oder CMK)	Optional (SecureString-Typ verwendet KMS)
Maximale Geheimgröße	65 KB	4 KB (Standard) / 8 KB (Erweitert)
Am besten geeignet,	Datenbankzugangsdaten, API-Schlüssel, Tokens, die einer Rotation bedürfen	App-Konfiguration, Feature-Flags, nicht rotierte Parameter

Die Entscheidungsregel ist einfach: Benötigt das Geheimnis eine automatische Rotation oder konto- bzw. regionsübergreifenden Zugriff, verwenden Sie den Secrets Manager. Handelt es sich um einen Konfigurationsparameter oder eine Anmeldeinformation, die nicht rotiert wird, ist der SSM Parameter Store ausreichend und deutlich kostengünstiger.

AWS Secrets Manager: Kosten und Optimierung

Die Preisgestaltung von AWS Secrets Manager setzt sich aus zwei Komponenten zusammen: einer Speichergebühr pro Geheimnis und einer Gebühr pro API-Aufruf. Derzeit kostet ein Geheimnis 0.40 US-Dollar pro Monat und 10,000 API-Aufrufe 0.05 US-Dollar. Neue Nutzer von Secrets Manager können Secrets Manager 30 Tage lang kostenlos testen.

Für eine typische Anwendung, die monatlich eine Million Mal ein einzelnes Datenbankgeheimnis abruft (über den zwischengespeicherten Abruf beim Erstellen des Verbindungspools, nicht bei jeder Abfrage), betragen die monatlichen Kosten etwa 0.40 $ für das Geheimnis plus 0.05 $ für die API-Aufrufe, insgesamt also weniger als 1 $ pro Monat. Die Kosten skalieren linear mit der Anzahl der Geheimnisse und dem API-Aufrufvolumen.

Die wichtigste Technik zur Kostenoptimierung für Secrets Manager ist clientseitiges Caching. Das AWS Secrets Manager SDK enthält einen integrierten Caching-Client für Java, Python, .NET, Go und JavaScript. Dieser Client ruft das Geheimnis einmalig ab, speichert es im Arbeitsspeicher und bedient nachfolgende Anfragen für eine konfigurierbare Gültigkeitsdauer (TTL, standardmäßig 1 Stunde) aus dem Cache. Der Cache wird automatisch aktualisiert, sobald ein Rotationsereignis eintritt. Caching reduziert das API-Aufrufvolumen für Anwendungen mit hoher Aufruffrequenz um ein Vielfaches.

Wenn ein vom Kunden verwalteter KMS-Schlüssel für das Geheimnis konfiguriert ist, fallen zusätzliche Kosten für KMS-API-Aufrufe an: 0.03 $ pro 10,000 kryptografische KMS-Operationen. Jeder Aufruf von `GetSecretValue` löst einen KMS-Entschlüsselungsaufruf aus. Bei Anwendungen mit hohem Datenaufkommen ist die Kombination des Secrets Manager Caching SDK mit einem für das Geheimnis konfigurierten CMK-Schlüssel der Standardansatz, um die Kosten für Secrets Manager und KMS gleichzeitig zu kontrollieren.

Multi-Cloud- und Hybrid-Architektur für das Geheimnismanagement

AWS Secrets Manager ist ein AWS-nativer Dienst und verwaltet keine Geheimnisse für Azure- oder GCP-Workloads nativ. Unternehmen, die Multi-Cloud- oder Hybridumgebungen betreiben, benötigen eine explizite Strategie für die Geheimnisverwaltung über verschiedene Cloud-Anbieter hinweg. Drei Ansätze bieten hierfür Lösungen:

• Cloud-nativer Geheimnismanager: Nutzen Sie AWS Secrets Manager für AWS-Workloads, Azure Key Vault für Azure-Workloads und GCP Secret Manager für GCP-Workloads. Die Anwendungen jeder Cloud verwenden ihren jeweiligen nativen Dienst. Eine zentrale Plattform zur Verwaltung von Geheimnissen aggregiert Audit-Logs und Richtliniendurchsetzung über alle drei Anbieter hinweg und ermöglicht so cloudübergreifende Transparenz ohne Verzögerungen beim Abruf von Geheimnissen.
• Zentralisierter Geheimnismanager mit Cloud-basierter Bereitstellung: Ein Drittanbieter- oder selbstgehosteter Geheimnismanager (der außerhalb aller Cloud-Anbieter oder in einer zentralen Cloud betrieben wird) speichert die Masterkopie aller Geheimnisse. Cloudspezifische Agenten oder Synchronisierungsmechanismen übertragen Geheimnisse bei Bedarf an den jeweiligen nativen Dienst der Cloud (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Die Masterkopie dient als maßgebliche Datenquelle für Rotation, Auditierung und Zugriffsrichtlinien.
• Direkter Cloud-übergreifender API-Zugriff: AWS-Workloads greifen ausschließlich auf AWS Secrets Manager zu; Azure- und GCP-Workloads greifen ausschließlich auf ihre jeweiligen nativen Dienste zu. Gemeinsam genutzte Geheimnisse (wie beispielsweise ein API-Schlüssel eines Drittanbieters, der von Diensten in allen drei Clouds verwendet wird) werden unabhängig im jeweiligen nativen Geheimnisdienst jeder Cloud gespeichert. Die Rotation wird in allen drei Clouds synchronisiert, sobald sich die Anmeldeinformationen ändern. (Encryption Consulting) CBOM Secure Hilft dabei, alle Geheimnisse und Schlüssel in Multi-Cloud-Umgebungen zu ermitteln und zu inventarisieren, um Lücken in der Rotationsabdeckung und der Konsistenz der Zugriffsrichtlinien zu identifizieren.

Konformität: PCI DSS, HIPAA, FedRAMP und DSGVO

PCI DSS v4.0.1 (verpflichtend ab 31. März 2025): Secrets Manager erfüllt direkt mehrere PCI-DSS-Anforderungen. Anforderung 8.6.2 verbietet das Festcodieren von Anmeldeinformationen in Skripten, Code oder Konfigurationsdateien; das API-basierte Abrufmodell von Secrets Manager erfüllt diese Anforderung prinzipiell. Anforderung 8.3.9 erfordert die regelmäßige Rotation von Authentifizierungs-Anmeldeinformationen; die automatische Rotation nach Zeitplan erfüllt diese Anforderung für Datenbank-Anmeldeinformationen und Servicekonten. Anforderung 3.5.1 (Schutz gespeicherter Kontodaten durch starke Kryptografie) ist erfüllt, wenn ein vom Kunden verwalteter KMS-Schlüssel mit CloudHSM-Backup verwendet wird. Die CloudTrail-Datenereignisprotokollierung von GetSecretValue-Aufrufen erfüllt Anforderung 10 (Audit-Protokollierung des Zugriffs auf die Karteninhaberdatenumgebung).

HIPAA: AWS Secrets Manager fällt unter die Vereinbarung zur Auftragsverarbeitung (Business Associate Agreement, BAA) von AWS. Für Systeme, die mit elektronischen Gesundheitsdaten (ePHI) in Verbindung stehen (Anwendungen, die sich bei Datenbanken oder Diensten authentifizieren, welche ePHI speichern), verhindert Secrets Manager die Offenlegung von Anmeldeinformationen im Code (Zugriffskontrolle, 45 CFR 164.312(a)(1)). Die CloudTrail-Protokollierung von GetSecretValue-Aufrufen erfüllt die Anforderungen der Audit-Kontrollnorm (45 CFR 164.312(b)) für den Zugriff auf Anmeldeinformationen, die ePHI-Systeme entsperren.

FedRAMP: AWS Secrets Manager ist im AWS FedRAMP High-Autorisierungspaket enthalten. Für FedRAMP High-Workloads, die FIPS 140-2 Level 3-Schlüsselschutz für den zur Verschlüsselung von Geheimnissen verwendeten KMS-Schlüssel erfordern, konfigurieren Sie einen kundenverwalteten KMS-Schlüssel, der durch einen benutzerdefinierten CloudHSM-Schlüsselspeicher unterstützt wird. Dies erfüllt die Anforderungen von SC-12 (Kryptografisches Schlüsselmanagement) und SC-28 (Schutz ruhender Informationen) auf der High-Baseline. Detaillierte Informationen zur CloudHSM-Konfiguration finden Sie in unserem Leitfaden zur AWS KMS-Sicherheit.

DSGVO: Artikel 32 DSGVO fordert geeignete technische Maßnahmen zum Schutz personenbezogener Daten. Die Verwendung von Secrets Manager, um zu verhindern, dass fest codierte Datenbankzugangsdaten im Quellcode, in Protokollen und Build-Artefakten erscheinen, ist eine technische Maßnahme, die die Angriffsfläche für unbefugten Zugriff auf Systeme mit personenbezogenen Daten verringert. Die automatische Rotation reduziert das Zeitfenster der Offenlegung, falls Zugangsdaten kompromittiert werden. CloudTrail-Protokollierung stellt den Prüfpfad bereit, um den Aufsichtsbehörden die Zugriffskontrollen nachzuweisen.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein Beratungsunternehmen für angewandte Kryptografie und Cloud-Sicherheit mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Konzeption, Implementierung und Prüfung von AWS Secrets Manager-Implementierungen – von der ersten Architektur bis hin zur kontinuierlichen Erstellung von Nachweisen zur Einhaltung der Vorschriften.

• Architektur und Migration des Secrets Managers: Wir analysieren Ihre aktuelle Vorgehensweise im Bereich des Anmeldeinformationsmanagements (Identifizierung fest codierter Anmeldeinformationen in Code, Konfigurationen, Umgebungsvariablen und CI/CD-Pipelines), entwerfen die Zielarchitektur des Secrets Managers (Geheimnishierarchie, KMS-Schlüsselkonfiguration, Ressourcenrichtlinienmodell, Rotationsplan pro Geheimnistyp) und setzen den Migrationsplan um. Weitere Informationen finden Sie in unserem Cloud-Beratungsdienste.
• Kundenseitig verwaltete KMS-Schlüsselkonfiguration für Geheimnisse: Wir konfigurieren kundenverwaltete KMS-Schlüssel für Secrets Manager-Geheimnisse, entwerfen die Schlüsselrichtlinie zur Trennung von Schlüsseladministratoren und Schlüsselbenutzern, aktivieren die CloudTrail-Datenzugriffsprotokollierung für Secrets Manager und KMS, um den von PCI DSS und HIPAA geforderten Prüfpfad pro Abruf bereitzustellen, und konfigurieren CloudWatch-Warnungen für anomale Zugriffsmuster. Für die Anforderungen von FIPS 140-2 Level 3 konfigurieren wir CloudHSM-gestützte benutzerdefinierte Schlüsselspeicher. Weitere Informationen finden Sie in unserer Dokumentation. HSM als Service.
• Automatische Rotationsimplementierung: Wir implementieren und testen automatische Rotations-Lambda-Funktionen für unterstützte AWS-Datenbankdienste und benutzerdefinierte Geheimnistypen (lokale Datenbanken, API-Schlüssel von Drittanbietern, OAuth-Token). Wir konfigurieren Rotationspläne, die Ihren Compliance-Anforderungen entsprechen (PCI-DSS-90-Tage-Rotation, HIPAA-konforme Rotation), und testen Rotationsereignisse, um einen unterbrechungsfreien Betrieb in Produktionsumgebungen zu gewährleisten.
• CBOM Secure für die Aufdeckung von Geheimnissen: AWS-Umgebungen, die organisch gewachsen sind, weisen häufig Geheimnisse auf, die über Umgebungsvariablen verstreut, fest im Code codiert, unverschlüsselt im SSM Parameter Store gespeichert oder in mehreren Konten dupliziert sind. Encryption Consulting bietet hierfür Lösungen an. CBOM Secure Erkennt und inventarisiert alle Speicherorte für Geheimnisse in Ihren AWS-Konten, identifiziert unverschlüsselte oder schlecht verwaltete Geheimnisse und generiert eine kryptografische Stückliste (CBOM) im CycloneDX-Format, die die Dokumentation zur Einhaltung der PCI DSS v4.0.1 Anforderung 12.3.3 unterstützt.
• PCI DSS- und HIPAA-Konformitätshinweis: Wir passen Ihre Secrets-Manager-Konfiguration an die spezifischen Anforderungen von PCI DSS v4.0.1, HIPAA, FedRAMP High und DSGVO an. Wir identifizieren Kontrolllücken, erstellen die erforderlichen Nachweise zur Einhaltung der Vorschriften und unterstützen Sie bei Anfragen von QSA und Auditoren zum Thema Geheimnismanagement. Weitere Informationen finden Sie hier. Compliance-Beratungsdienste.

Um Ihre Architektur für das Geheimnismanagement oder Ihre Compliance-Anforderungen zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

AWS Secrets Manager behebt eine der hartnäckigsten und am häufigsten ausgenutzten Schwachstellen in der Cloud-Anwendungssicherheit: Anmeldeinformationen im Code. Durch die Bereitstellung eines zentralen, API-basierten Geheimnisspeichers mit KMS-Verschlüsselung ruhender Daten, automatischer Rotation, IAM-gesteuertem Zugriff und CloudTrail-Auditprotokollierung entfällt für Secrets Manager die Notwendigkeit, Anmeldeinformationen außerhalb eines HSM oder einer authentifizierten API-Antwort im Klartext zu speichern.

Die wichtigsten Konfigurationsentscheidungen sind: die Verwendung eines vom Kunden verwalteten KMS-Schlüssels anstelle des standardmäßigen, von AWS verwalteten Schlüssels (für den Audit-Trail pro Operation und die unabhängige Widerrufsmöglichkeit), die Aktivierung von CloudTrail-Datenereignissen für GetSecretValue (damit Sie nachweisen können, wer wann was abgerufen hat), die Aktivierung der automatischen Rotation nach einem Compliance-konformen Zeitplan und die Verwendung des SDK-Caching-Clients zur Kontrolle der API-Aufrufkosten im großen Maßstab.

Für Organisationen mit bestehenden AWS KMS-Implementierungen lässt sich Secrets Manager nahtlos in die bestehende Schlüsselverwaltungs- und Audit-Infrastruktur integrieren – ohne zusätzliche architektonische Komplexität. Organisationen, die ganz von vorn beginnen, finden in Kombination mit einem kundenseitig verwalteten KMS-Schlüssel und CloudTrail-Datenereignissen den schnellsten Weg zu einer rechtssicheren und auditierbaren Geheimnisverwaltung. Weitere Informationen zur Verschlüsselungsschlüsselverwaltung, die Secrets Manager zugrunde liegt, finden Sie in unserem ausführlichen Artikel zum AWS Key Management Service.

Häufig gestellte Fragen

Was ist AWS Secrets Manager?

AWS Secrets Manager ist ein verwalteter Dienst, der geheime Daten wie Datenbankzugangsdaten, API-Schlüssel, OAuth-Token und SSH-Schlüssel speichert, abruft, rotiert und prüft. Jedes Geheimnis wird im Ruhezustand mit AWS KMS-Envelope-Verschlüsselung (AES-256-GCM) verschlüsselt. Geheimnisse werden niemals im Klartext gespeichert. Anwendungen rufen Geheimnisse per API-Aufruf ab, anstatt sie aus Umgebungsvariablen oder fest codiertem Code zu lesen. Dadurch wird die Offenlegung von Zugangsdaten im Quellcode und in Build-Artefakten verhindert.

Wie verschlüsselt AWS Secrets Manager Geheimnisse?

Secrets Manager verwendet die AWS KMS-Envelope-Verschlüsselung. Beim Speichern eines Geheimnisses ruft Secrets Manager die KMS-Funktion GenerateDataKey auf, um einen AES-256-Datenschlüssel zu erhalten, verschlüsselt den Geheimniswert damit (AES-256-GCM) und speichert das verschlüsselte Geheimnis und den verschlüsselten Datenschlüssel zusammen. Der Klartext-Datenschlüssel wird sofort verworfen. Beim Abruf ruft Secrets Manager die KMS-Funktion Decrypt auf, um den Datenschlüssel wiederherzustellen, entschlüsselt das Geheimnis und gibt den Klartextwert über TLS zurück. Der Standardschlüssel ist der von AWS verwaltete aws/secretsmanager-Schlüssel; kundenseitig verwaltete KMS-Schlüssel bieten eine Nachverfolgbarkeit und die Möglichkeit zum unabhängigen Widerruf für Compliance-Workloads.

Wie rotiert AWS Secrets Manager Geheimnisse automatisch?

Rotation nutzt eine AWS Lambda-Funktion, die vier Schritte ausführt: CreateSecret (Generierung einer neuen Version), SetSecret (Aktualisierung der Anmeldeinformationen im Zieldienst), TestSecret (Überprüfung der neuen Anmeldeinformationen) und FinishSecret (Markierung der neuen Version als AWSCURRENT). Für Amazon RDS, DocumentDB und Redshift stellt AWS verwaltete Rotations-Lambda-Funktionen bereit. Für alle anderen Dienste implementieren Sie eine benutzerdefinierte Lambda-Funktion, die dieselben vier Schritte ausführt. Rotation wird nach einem konfigurierbaren Zeitplan (mindestens einmal täglich) oder bedarfsgesteuert ausgeführt.

Worin besteht der Unterschied zwischen AWS Secrets Manager und AWS Systems Manager Parameter Store?

Secrets Manager kostet 0.40 $ pro Geheimnis und Monat und bietet integrierte automatische Rotation, kontoübergreifenden Zugriff, regionsübergreifende Replikation und eine Geheimnisgröße von bis zu 65 KB. SSM Parameter Store ist für Standardparameter (bis zu 10,000) kostenlos und eignet sich am besten für die Anwendungskonfiguration und nicht rotierte Anmeldeinformationen. Wählen Sie Secrets Manager, wenn Sie automatische Rotation oder konto-/regionsübergreifenden Zugriff benötigen. Wählen Sie SSM Parameter Store für allgemeine Konfigurationsparameter und kostensensible Workloads, die keine Rotation erfordern.

Erfüllt AWS Secrets Manager die PCI DSS- und HIPAA-Anforderungen?

Ja, bei korrekter Konfiguration. Secrets Manager erfüllt die Anforderungen 8.6.2 (keine fest codierten Anmeldeinformationen), 8.3.9 (periodische Rotation) und 10 (Audit-Protokollierung über CloudTrail-Datenereignisse) des PCI DSS v4.0.1. Ein vom Kunden verwalteter KMS-Schlüssel mit CloudHSM-Unterstützung erfüllt die Anforderungen 3.5.1 und 3.7.1. Im Hinblick auf HIPAA ist Secrets Manager durch die AWS-BAA abgedeckt und verhindert die Offenlegung von Anmeldeinformationen im Code (Zugriffskontrollschutz, 45 CFR 164.312(a)(1)). Die CloudTrail-Protokollierung erfüllt den Audit-Control-Standard (164.312(b)).

Wie greife ich von einer Anwendung aus auf AWS Secrets Manager-Geheimnisse zu?

Rufen Sie die GetSecretValue-API mit dem Geheimnisnamen oder ARN auf. Die aufrufende Identität (IAM-Rolle oder Benutzer) benötigt die Berechtigung `secretsmanager:GetSecretValue` für den entsprechenden Geheimnis-ARN, die sowohl in der IAM-Identitätsrichtlinie als auch in der Ressourcenrichtlinie des Geheimnisses festgelegt ist. Verwenden Sie den Caching-Client des AWS Secrets Manager SDK, um das Geheimnis im Arbeitsspeicher zu speichern und die Häufigkeit der API-Aufrufe zu reduzieren. Konfigurieren Sie für Workloads, die keine Internetaufrufe durchführen dürfen, einen Secrets Manager VPC-Endpunkt (AWS PrivateLink), um den Datenverkehr zum Abrufen von Geheimnissen innerhalb Ihrer VPC zu leiten.