Proces automatycznie pobiera poświadczenia API dla wielu źródeł bankowych i wywołuje funkcję Lambda powiązaną z zasobem niestandardowym CloudFormation. Deweloper chce przechowywać te poświadczenia API przy minimalnym nakładzie operacyjnym i maksymalnym bezpieczeństwie. Które podejście jest najbardziej bezpieczne i wymaga najmniejszego nakładu operacyjnego?

Poprawna odpowiedź to wywołanie API SSM PutParameter z poziomu funkcji Lambda w celu zapisania poświadczeń jako parametru SecureString. AWS Systems Manager Parameter Store z typem SecureString zapewnia bezpieczne przechowywanie wrażliwych danych, takich jak poświadczenia API, przy użyciu kluczy AWS KMS do szyfrowania. Funkcja Lambda, jako zasób niestandardowy CloudFormation, może dynamicznie zapisywać te poświadczenia, minimalizując nakład operacyjny, ponieważ nie trzeba ręcznie zarządzać sekretami ani ich kodować na stałe. Dodanie zasobu AWS Secrets Manager GenerateSecretString do szablonu CloudFormation nie jest optymalne, ponieważ generuje on losowy ciąg, a nie przechowuje konkretne poświadczenia bankowe. Dodanie zasobu SSM Parameter Store bezpośrednio do szablonu CloudFormation i ustawienie wartości za pomocą NoEcho jest mniej bezpieczne, ponieważ CloudFormation nie jest przeznaczone do przechowywania wrażliwych danych, a NoEcho jedynie ukrywa wartość w dziennikach, nie szyfrując jej. Wywołanie API SSM PutParameter i ustawienie atrybutu NoEcho na true jest niewystarczające, ponieważ NoEcho dotyczy tylko wyświetlania, a nie szyfrowania danych.