Ein Unternehmen testet seinen Incident-Response-Plan für kompromittierte Anmeldeinformationen. Eine Datenbank läuft auf einer Amazon EC2-Instance, und die sensiblen Datenbank-Anmeldeinformationen werden als Secret im AWS Secrets Manager gespeichert, wobei die Rotation über eine AWS Lambda-Funktion basierend auf der generischen Rotationsvorlage aktiviert ist. Die EC2-Instance und die Lambda-Funktion befinden sich im selben privaten Subnetz. Die VPC verfügt über einen Secrets Manager VPC-Endpunkt. Die Rotation schlägt fehl, und CloudWatch Logs zeigt an: „setSecret: Unable to log into database.“ Der VPC-Endpunkt funktioniert wie erwartet. Welche Lösung behebt den Fehler?

Die Fehlermeldung "Unable to log into database" deutet darauf hin, dass die Lambda-Funktion, die für die Rotation zuständig ist, keine Verbindung zur Datenbank auf der EC2-Instance herstellen kann, um die Anmeldeinformationen zu aktualisieren. Da sich beide im selben privaten Subnetz befinden und der VPC-Endpunkt für Secrets Manager funktioniert, liegt das Problem wahrscheinlich an den Netzwerksicherheitsregeln. Die Sicherheitsgruppen müssen so konfiguriert werden, dass die Lambda-Funktion (als Client) ausgehende Verbindungen zur EC2-Instance (als Server) herstellen kann und die EC2-Instance eingehende Verbindungen von der Lambda-Funktion akzeptiert. Die anderen Optionen sind falsch, da sie entweder das Problem nicht beheben (JSON-Struktur bearbeiten, manuelle Rotation erzwingen) oder unnötige öffentliche Konnektivität hinzufügen, die das Problem der internen Kommunikation nicht löst (Internet-Gateway, NAT-Gateway).