Firma testuje swój plan reagowania na incydenty związane ze skompromitowanymi poświadczeniami. Baza danych działa na instancji Amazon EC2, a poufne poświadczenia bazy danych są przechowywane jako sekret w AWS Secrets Manager z włączoną rotacją za pośrednictwem funkcji AWS Lambda opartej na ogólnym szablonie rotacji. Instancja EC2 i funkcja Lambda znajdują się w tej samej prywatnej podsieci. VPC ma punkt końcowy Secrets Manager VPC. Rotacja kończy się niepowodzeniem, a CloudWatch Logs pokazuje: „setSecret: Unable to log into database.” Punkt końcowy VPC działa zgodnie z oczekiwaniami. Które rozwiązanie usuwa błąd?

Błąd „setSecret: Unable to log into database” wskazuje, że funkcja Lambda nie może nawiązać połączenia z bazą danych na instancji EC2 w celu wykonania rotacji. Ponieważ instancja EC2 i funkcja Lambda znajdują się w tej samej prywatnej podsieci, a punkt końcowy VPC Secrets Manager działa, problemem są najprawdopodobniej reguły sieciowe. Funkcja Lambda potrzebuje uprawnień do wychodzącego połączenia z bazą danych, a instancja EC2 potrzebuje uprawnień do przychodzącego połączenia z funkcją Lambda. Aktualizacja grup zabezpieczeń, aby zezwolić na ten ruch, rozwiąże problem. Edycja struktury JSON sekretu nie rozwiąże problemu z łącznością. Wymuszanie rotacji za pomocą AWS CLI nie rozwiąże problemu z brakiem możliwości zalogowania się. Dodawanie bramy internetowej i bramy NAT jest niepotrzebne, ponieważ obie zasoby znajdują się w prywatnej podsieci i korzystają z punktu końcowego VPC Secrets Manager.