Una startup gestisce un parco di istanze EC2 Amazon Linux 2 in sottoreti private e gli ingegneri si affidano a SSH per la risoluzione dei problemi. La VPC dispone di sottoreti private e pubbliche, un NAT gateway e una VPN Site-to-Site verso l'on-premises. Gli attuali security group delle istanze EC2 consentono l'SSH diretto dalla rete on-premises. L'azienda desidera controlli SSH più rigorosi e l'audit dei comandi eseguiti dagli ingegneri. Quale approccio dovrebbe raccomandare un architetto di soluzioni?

L'opzione corretta è la migliore perché Systems Manager Session Manager (parte di AWS Systems Manager) consente l'accesso SSH alle istanze EC2 senza aprire la porta 22 nei security group, migliorando la sicurezza. La policy AmazonSSMManagedInstanceCore fornisce le autorizzazioni necessarie alle istanze per comunicare con SSM. Session Manager registra automaticamente le sessioni in CloudWatch Logs o S3, fornendo l'audit dei comandi eseguiti, soddisfacendo i requisiti. Le opzioni errate sono: Installare EC2 Instance Connect richiede ancora l'apertura della porta 22 (anche se solo per gli intervalli IP di EC2 Instance Connect) e non offre funzionalità di audit dei comandi eseguite. Limitare i security group agli IP degli ingegneri mantiene la porta 22 aperta e non fornisce un audit centralizzato dei comandi. L'agente CloudWatch per i log del sistema operativo non registra i comandi SSH in modo strutturato per l'audit. L'uso di AWS Config e Firewall Manager per i security group è una buona pratica di sicurezza, ma non risolve il problema dell'audit dei comandi SSH e richiede comunque l'apertura della porta 22.