Een applicatie gebruikt een ElastiCache for Redis-cluster voor caching. Het cluster heeft al encryptie at rest ingeschakeld, maar geen encryptie in transit, en clients hebben zonder authenticatie toegang tot de cache. Een solutions architect moet clientauthenticatie vereisen en end-to-end in-transit encryptie inschakelen. Welke oplossing voldoet aan deze vereisten?

De juiste oplossing omvat het genereren van een AUTH-token en dit veilig opslaan in AWS Secrets Manager. Vervolgens configureert u het bestaande ElastiCache-cluster om dit AUTH-token te gebruiken en schakelt u encryptie in transit in. Ten slotte werkt u de applicatie bij om het token uit Secrets Manager op te halen en te gebruiken voor authenticatie. Deze aanpak is correct omdat ElastiCache voor Redis de mogelijkheid biedt om AUTH-tokens en encryptie in transit (TLS) in te schakelen op een bestaand cluster, wat resulteert in minimale downtime en geen noodzaak om een nieuw cluster aan te maken. AWS Secrets Manager is de aanbevolen service voor het veilig opslaan en beheren van geheimen zoals AUTH-tokens. De andere opties zijn minder optimaal: Een nieuw cluster aanmaken (optie 1 en 3) is onnodig en veroorzaakt meer downtime en migratiewerk. SSL-certificaten (optie 3 en 4) worden niet gebruikt voor clientauthenticatie in ElastiCache for Redis; AUTH-tokens zijn hiervoor bedoeld. Encryptie in transit gebruikt wel TLS, maar de authenticatie is via AUTH. Parameter Store (optie 1 en 4) kan geheimen opslaan, maar Secrets Manager biedt geavanceerdere functies voor geheimenbeheer, zoals rotatie.