Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Strategien zur Rotation von Lambda-Funktionen
Denn für Rotation durch Lambda-Funktion Datenbankgeheimnisse bietet Secrets Manager zwei Rotationsstrategien.
Rotationsstrategie: Einzelbenutzer
Diese Strategie aktualisiert die Anmeldeinformationen für einen Benutzer in einem Secret. Da Benutzer bei Amazon RDS Db2-Instances ihre eigenen Passwörter nicht ändern können, müssen Sie Administratoranmeldedaten in einem separaten Geheimnis angeben. Dies ist die einfachste Rotationsstrategie und eignet sich für die meisten Anwendungsfälle. Insbesondere empfehlen wir Ihnen, diese Strategie für Anmeldeinformationen für einmalige (Ad-hoc) oder interaktive Benutzer zu verwenden.
Wenn das Secret rotiert, werden offene Datenbankverbindungen nicht gelöscht. Während dieser Rotation gibt es einen kurzen Zeitraum zwischen dem Ändern des Passworts in der Datenbank und dem Zeitpunkt, an dem das Secret aktualisiert wird. Während dieser Zeit besteht ein geringes Risiko, dass die Datenbank Anrufe ablehnt, die die rotierten Anmeldeinformationen verwenden. Sie können dieses Risiko abschwächen indem Sie eine angemessene Wiederholungsstrategie
Rotationsstrategie: wechselnde Benutzer
Diese Strategie aktualisiert die Anmeldeinformationen für zwei Benutzer in einem Secret. Sie erstellen den ersten Benutzer, und während der ersten Rotation klont die Rotationsfunktion ihn, um den zweiten Benutzer zu erstellen. Jedes Mal, wenn das Secret rotiert, wechselt die Rotationsfunktion ab, welches Benutzerkennwort sie aktualisiert. Da die meisten Benutzer keine Berechtigung haben, sich selbst zu klonen, müssen Sie die Anmeldeinformationen für einen superuser in einem anderen Secret angeben. Wir empfehlen die Verwendung der Einzelbenutzer-Drehungsstrategie, wenn geklonte Benutzer in Ihrer Datenbank nicht über dieselben Berechtigungen verfügen wie der ursprüngliche Benutzer, sowie für Anmeldeinformationen für einmalige (Ad-hoc-) oder interaktive Benutzer.
Diese Strategie ist für Datenbanken mit Berechtigungsmodellen geeignet, bei denen eine Rolle Eigentümer der Datenbanktabellen ist und eine zweite Rolle die Berechtigung zum Zugriff auf die Datenbanktabellen hat. Sie ist auch für Anwendungen geeignet, die eine hohe Verfügbarkeit erfordern. Wenn eine Anwendung das Secret während der Rotation abruft, erhält die Anwendung dennoch einen gültigen Satz von Anmeldeinformationen. Nach der Rotation sind sowohl user- als auch user_clone-Anmeldeinformationen gültig. Die Wahrscheinlichkeit, dass Anwendungen bei dieser Art der Rotation abgelehnt werden, ist noch geringer als bei der Rotation durch einen Einzelbenutzer. Wenn die Datenbank in einer Serverfarm gehostet wird, bei der die Passwortänderung einige Zeit für die Weitergabe an alle Server benötigt, besteht die Gefahr, dass die Datenbank Aufrufe ablehnt, die die neuen Anmeldeinformationen verwenden. Sie können dieses Risiko abschwächen indem Sie eine angemessene Wiederholungsstrategie
Secrets Manager erstellt den geklonten Benutzer mit denselben Berechtigungen wie die des ursprünglichen Benutzers. Wenn Sie nach der Erstellung des Klons die Berechtigungen des ursprünglichen Benutzers ändern, müssen Sie auch die Berechtigungen des geklonten Benutzers ändern.
Wenn Sie beispielsweise ein Secret mit den Anmeldeinformationen eines Datenbankbenutzers erstellen, enthält das Secret eine Version mit diesen Anmeldeinformationen.
Erste Rotation – Die Rotationsfunktion erstellt einen Klon Ihres Benutzers mit einem generierten Passwort, und diese Anmeldedaten gelten als die aktuelle geheime Version.
Zweite Rotation – Die Rotationsfunktion aktualisiert das Passwort für den ursprünglichen Benutzer.
Zweite Rotation – Die Rotationsfunktion aktualisiert das Passwort für den geklonten Benutzer.
