A equipe de DevOps da BrightKite recebe uma descoberta do GuardDuty: UnauthorizedAccess:EC2/SSHBruteForce direcionada a uma instância EC2 em uma sub-rede pública. A instância atualmente permite TCP/22 e TCP/8080 de 0.0.0.0/0, mas os administradores precisam manter o acesso SSH dos escritórios corporativos. Qual é a remediação imediata mais eficaz?

A remediação mais eficaz é restringir o grupo de segurança. Ao permitir SSH (TCP/22) apenas do bloco CIDR corporativo, você limita drasticamente a superfície de ataque, impedindo que IPs não autorizados tentem a força bruta. Remover 0.0.0.0/0 de outras portas abertas (como TCP/8080) também é crucial para seguir o princípio do privilégio mínimo, garantindo que apenas o tráfego necessário seja permitido. As outras opções são menos eficazes: Anexar uma ACL da web do AWS WAF à instância EC2 não é o ideal, pois o WAF é projetado para proteger aplicações web e não diretamente o acesso SSH. Além disso, a instância EC2 não está necessariamente rodando uma aplicação web que se beneficiaria do WAF. Adicionar uma regra de negação de ACL de rede para o IP de origem único listado na descoberta do GuardDuty é uma medida reativa e temporária. O atacante pode simplesmente mudar de IP, e a ACL de rede opera no nível da sub-rede, não da instância, sendo menos granular que um grupo de segurança. Desativar o Internet Gateway para a VPC interromperia todo o tráfego de entrada e saída da internet, o que causaria uma interrupção inaceitável para a instância e quaisquer serviços que ela forneça.