Un'azienda medica esegue un'API REST su istanze EC2 in un gruppo Auto Scaling dietro un Application Load Balancer (ALB). L'ALB si trova in tre sottoreti pubbliche e le istanze EC2 si trovano in tre sottoreti private. Una distribuzione CloudFront utilizza l'ALB come origine. Cosa dovrebbe raccomandare un architetto di soluzioni per rafforzare la sicurezza dell'origine (proteggendo l'ALB dall'accesso diretto) per le richieste provenienti da CloudFront?

L'opzione corretta rafforza la sicurezza dell'origine (ALB) assicurando che solo le richieste provenienti da CloudFront con l'intestazione HTTP personalizzata e il valore segreto corretto possano raggiungere l'ALB. L'uso di AWS Secrets Manager con rotazione automatica garantisce che il segreto sia gestito in modo sicuro e aggiornato regolarmente, migliorando la sicurezza. AWS WAF, associato all'ALB, ispeziona le intestazioni delle richieste e blocca quelle non autorizzate. L'opzione che utilizza la corrispondenza IP per gli intervalli di CloudFront non è ideale perché gli intervalli IP di CloudFront sono ampi e possono cambiare, rendendo difficile la gestione e potenzialmente bloccando richieste legittime o consentendo richieste non autorizzate da IP condivisi. Spostare l'ALB in sottoreti private lo renderebbe inaccessibile da CloudFront. L'opzione che utilizza AWS Systems Manager Parameter Store è meno sicura di Secrets Manager per la gestione di segreti sensibili, e l'ispezione dell'intestazione da parte dell'ALB o del backend potrebbe non essere altrettanto efficiente o sicura quanto l'utilizzo di WAF. L'opzione che abilita AWS Shield Advanced e una policy del gruppo di sicurezza basata su IP non è sufficiente. Shield Advanced è principalmente per la protezione DDoS e una policy del gruppo di sicurezza basata su IP ha le stesse limitazioni degli intervalli IP di CloudFront.