Protegendo um Ambiente de Cloud que Você Não Construiu

Você acaba de receber as chaves de uma conta cloud que vem crescendo sem supervisão há três anos. Ninguém deixou documentação. IAM tem 40 roles com permissões wildcard, existem buckets S3 que ninguém lembra de ter criado, e a última pessoa que entendia a topologia de rede saiu da empresa em 2022. Isso é mais comum do que a maioria das ofertas de emprego admite, e o primeiro mês define o tom para tudo depois.

Faça um inventário antes de tocar em nada

Resista ao impulso de começar a trancar as coisas imediatamente. Você precisa de um mapa primeiro. Execute aws resourcegroupstaggingapi get-resources em todas as regiões, não apenas us-east-1 — equipes adoram girar recursos de teste em ap-southeast-2 e esquecer deles. Combine isso com AWS Config se já estiver habilitado, ou ative agora se não estiver. No Azure, az resource list --output table redirecionado para uma planilha funciona bem para um primeiro passe. No GCP, o gcloud asset search-all-resources do Cloud Asset Inventory oferece a mesma visão.

Faça referência cruzada com o faturamento. Qualquer coisa que custe dinheiro deve aparecer em seu inventário de recursos; qualquer coisa no inventário com zero atividade recente é candidata para arquivamento. Discrepâncias aqui são geralmente onde as coisas assustadoras se escondem — instâncias EC2 órfãs com IPs públicos, snapshots RDS esquecidos sem criptografia, load balancers apontando para nada.

Audite IAM como se fosse uma cena de crime

Extraia cada política IAM e procure por "Action": "*" combinado com "Resource": "*". Essa combinação não deve existir fora de um punhado de roles de admin break-glass, e mesmo essas devem ter aplicação de MFA e alertas CloudTrail. Use IAM Access Analyzer para encontrar roles que concedem acesso a contas externas — isso detecta tanto relacionamentos de confiança entre contas intencionais quanto erros de alguém testando um módulo Terraform contra o ID de conta errado.

Verifique chaves de acesso com mais de 90 dias com aws iam generate-credential-report. Ambientes herdados quase sempre têm chaves de longa duração anexadas a contas de serviço, às vezes hardcoded em uma variável de ambiente Lambda ou um job Jenkins. Rotacione-as, mas organize em fases — matar uma chave da qual um job de lote noturno depende às 2 da manhã é como você é chamado durante sua primeira semana.

Encontre a exposição pública antes de um atacante encontrar

Execute uma verificação de acessibilidade de rede em suas VPCs. Security groups com 0.0.0.0/0 em qualquer coisa diferente de 80/443 precisa de justificativa, não suposição. Ferramentas como ScoutSuite ou Prowler vão processar uma conta em minutos e cuspir um relatório classificado por severidade — comece por lá em vez de construir sua própria checklist do zero.

Buckets S3 merecem atenção especial porque são a mina clássica de ambiente herdado. Verifique políticas de bucket e configurações de Block Public Access no nível de conta; alguém pode ter desabilitado o padrão de conta anos atrás para um site estático único e nunca ativou novamente. aws s3api list-buckets combinado com um loop verificando get-bucket-acl e get-bucket-policy-status em cada um oferece uma visão clara em menos de dez minutos para a maioria das contas.

Estabeleça logging antes de estabelecer confiança

Se CloudTrail, VPC Flow Logs ou GuardDuty já não estão em execução em todos os lugares, ative agora, antes de fazer outras mudanças. Você quer um registro do que acontece daqui em diante, e quer antes de começar a deletar coisas, porque deleção é exatamente quando erros acontecem e são culpa da pessoa nova. Envie logs para uma conta ou subscription separada se possível, para que uma workload comprometida não possa também apagar suas próprias evidências.

Configure GuardDuty ou Azure Defender for Cloud com alertas roteados para algum lugar onde um humano realmente verifica — não um canal Slack com 400 mensagens não lidas. O valor de ferramentas de detecção é próximo a zero se os alertas caem no vazio.

Resolva os problemas mais evidentes primeiro, documente tudo

Você não vai resolver um ambiente herdado em um sprint. Faça triagem por raio de explosão: exposição de dados públicos primeiro, depois identidades com privilégios excessivos, depois segmentação de rede, depois tudo mais. Anote o que você encontrar e o que mudou, mesmo em um Google Doc simples, porque a próxima pessoa que herdar isso de você merece melhor do que o que você recebeu.

Espere resistência quando você aperta um security group e o teste de integração de um dev começa a falhar. Isso é normal — significa que a auditoria está funcionando. Fale com a equipe que detém a workload antes de mudar qualquer coisa em produção, e mantenha um plano de rollback pronto para as primeiras duas semanas.

Para mais sobre as ferramentas e o raciocínio por trás de auditorias de cloud, confira os segmentos do Korra Studio sobre hardening de IAM e engenharia de detecção em cloud — ambos combinam bem com o workflow acima.