Tem uma frase que aparece com frequência quando o assunto é cloud: "mas está na nuvem, então já é seguro, não é?"

Não é bem assim.

Venho da área de desenvolvimento, tenho pós-graduação em Segurança da Informação, e hoje atuo com análise da cibersegurança. O que me chamou atenção desde que comecei a trabalhar com isso de forma mais focada é como os mesmos erros aparecem repetidamente — em ambientes diferentes, com times diferentes, em empresas de tamanhos variados.

Não são erros causados por falta de capacidade técnica. São erros que acontecem quando segurança fica em segundo plano, quando o prazo aperta, quando "funciona, então está bom" vira o critério de qualidade.

Esses sete pontos são o que eu encontro com mais frequência — nos engajamentos que faço, nos casos públicos documentados, e no que o mercado de segurança reporta ano após ano.

Erro 1: IAM como tarefa secundária

IAM significa Identity and Access Management — o sistema que controla quem pode fazer o quê dentro do ambiente cloud. É, na prática, a fundação de tudo.

O padrão que aparece com mais frequência: uma service account — uma identidade usada por uma aplicação, não por um humano — com permissões de administrador. A aplicação em si é simples, um serviço de processamento de arquivos, por exemplo. Não precisa de nada além de ler de um bucket e escrever em outro.

Quando você questiona, a resposta é quase sempre a mesma: "foi assim que configuraram no início e nunca houve problema."

O princípio do menor privilégio é o conceito central aqui: cada identidade deve ter acesso apenas ao que precisa para funcionar, nada mais. Parece óbvio. Na prática, acaba ficando pra depois — e "depois" nunca chega.

A diferença prática é grande: comprometer uma identidade com acesso excessivo versus uma com permissões mínimas muda completamente o impacto de uma invasão. Com a primeira, dá para mover lateralmente pelo ambiente todo. Com a segunda, o atacante fica preso no escopo daquele serviço.

O que ajuda concretamente: revisar permissões com frequência, preferir tokens temporários a credenciais permanentes, e criar políticas específicas para cada serviço em vez de reutilizar roles genéricas.

Erro 2: Segredos que estão no lugar errado

A quantidade de incidentes causados por credenciais expostas é algo que a gente lê nas estatísticas e pensa "não pode ser tão comum assim." É.

Uma busca simples em repositórios públicos no GitHub — sem ferramenta sofisticada nenhuma — retorna chaves de API e tokens de acesso expostos em projetos reais. Alguns ainda ativos.

Chaves de API, senhas de banco de dados, tokens de serviços externos. São chamados de "segredos" por uma razão. Mas aparecem hardcoded no código, em arquivos .env versionados por engano, em variáveis de ambiente sem controle de acesso.

O que agrava o problema é o histórico do Git. Mesmo que você delete o arquivo com o segredo e faça um novo commit, ele continua lá no histórico. Qualquer pessoa com acesso ao repositório pode encontrar. Ferramentas como o truffleHog fazem exatamente isso — varrem o histórico completo procurando padrões de credenciais. É uma das primeiras coisas que verifico num engajamento quando o escopo inclui análise de código.

A solução existe e é acessível: AWS Secrets Manager, Google Secret Manager, Azure Key Vault. O segredo fica fora do código, é injetado em tempo de execução, e você tem registro de quem acessou e quando. Um scanner de segredos no pipeline de CI/CD — como o truffleHog ou o detect-secrets — bloqueia o commit antes que o dano aconteça.

Erro 3: Buckets abertos sem querer

Esse é provavelmente o tipo de incidente mais noticiado em segurança de cloud. E faz sentido — é fácil de acontecer e o impacto pode ser enorme.

O problema não é descuido. É que tornar algo público é fácil — às vezes um clique — e não tem nenhum atrito que faça você pensar duas vezes. Tornar privado novamente exige que você lembre de fazer isso. E "só por um momento" na internet pode resultar em indexação por scanners automatizados que vasculham a rede 24 horas por dia procurando exatamente esse tipo de configuração exposta.

Num pentest recente, encontrei um bucket com documentos internos acessível publicamente. Não era dado de cliente, mas eram contratos e propostas comerciais. O cliente não sabia. Quando rodei uma ferramenta de enumeração de assets cloud, ele apareceu imediatamente — é o tipo de coisa que qualquer pessoa com conhecimento básico consegue encontrar.

O que resolve: bloquear acesso público por padrão em nível de organização (todas as clouds permitem isso), ativar alertas para quando qualquer recurso de storage for tornado público, e ter uma política clara de que bucket público precisa de justificativa documentada e revisão periódica.

Erro 4: Rede onde tudo fala com tudo

Segmentação de rede é um dos conceitos mais importantes em cloud — e um dos mais ignorados em ambientes que cresceram rápido.

A ideia é direta: se um componente do sistema é comprometido, você quer que o impacto fique contido. Se o servidor web exposto para a internet é invadido, o atacante não deveria conseguir falar diretamente com o banco de dados de produção. Deveria encontrar uma parede.

Em simulações de ataque lateral, a diferença é visível: num ambiente sem segmentação, a partir de um único ponto comprometido, dá para alcançar praticamente tudo em sequência. No ambiente segmentado, cada passo exige contornar uma barreira nova — e cada barreira é um ponto onde o ataque pode ser detectado ou bloqueado.

Na prática de cloud: VPCs com sub-redes separadas por função, security groups com regras específicas e mínimas — não "liberar tudo entre serviços internos" — e private endpoints para serviços gerenciados. Banco de dados sem IP público, por padrão.

O modelo Zero Trust resume bem a filosofia: nenhum componente confia automaticamente em outro só porque estão na mesma rede. Toda comunicação é autenticada e autorizada explicitamente. É mais trabalho configurar. É muito menos trabalho do que lidar com o resultado de não configurar.

Erro 5: Logs ativos, mas sem ninguém olhando

Em quase todo caso documentado de incidente de segurança, os logs estavam lá. O ataque estava registrado — às vezes desde o primeiro acesso não autorizado, semanas ou meses antes da descoberta.

Isso é ao mesmo tempo reconfortante e perturbador. Reconfortante porque significa que a telemetria existe. Perturbador porque mostra que ter logs não é suficiente.

Num engajamento de pentest onde o escopo incluía avaliar a capacidade de detecção, executei ações que qualquer sistema de monitoramento decente detectaria — tentativas de acesso fora do horário, enumeração de permissões, chamadas de API em volume anormal. Nenhum alerta foi disparado. Os logs estavam lá, mas sem alertas configurados e sem ninguém revisando.

Logs sem análise são câmeras de segurança sem ninguém assistindo. Eles registram o incidente perfeitamente. Você descobre isso depois que o estrago está feito.

O que precisa existir além dos logs em si: centralização num SIEM, regras de alerta para comportamentos anômalos, e um processo claro de quem responde quando o alerta dispara. Alguns comportamentos que valem atenção: criação de usuários fora do horário comercial, falhas repetidas de autenticação seguidas de sucesso, modificações em políticas de permissão, e acesso a recursos que normalmente ficam quietos. AWS CloudWatch com algumas regras bem configuradas já é infinitamente melhor do que CloudTrail ativo mas ignorado.

Erro 6: Patches como prioridade baixa

Uma parte significativa das explorações bem-sucedidas em ambientes reais usa vulnerabilidades que já têm patch disponível. Às vezes por meses. Às vezes por mais de um ano.

CVE — Common Vulnerabilities and Exposures — é o sistema público que cataloga vulnerabilidades conhecidas. Quando um CVE crítico é publicado, ferramentas automatizadas de scanning começam a varrer a internet procurando sistemas vulneráveis em questão de horas. Se o seu sistema está nessa lista, ele vai ser encontrado.

Num pentest, identifiquei uma versão de serviço com CVE de severidade alta publicado há três meses. Tinha exploit público disponível. O cliente sabia da vulnerabilidade — ela estava no backlog. Só que "não tinha entrado no sprint ainda."

O problema de fundo é de cultura: atualização é tratada como risco — pode quebrar algo — quando na realidade não atualizar é o risco maior. O risco de regressão você consegue testar e controlar. O risco de uma vulnerabilidade conhecida sendo explorada, não.

O que funciona: automatizar atualizações de segurança críticas com testes em staging, usar ferramentas como Dependabot para dependências de código, e ter critério claro de prazo por severidade. Crítico em 48 horas, alto em uma semana — esse tipo de estrutura força a conversa a acontecer de forma objetiva.

Erro 7: Nenhum plano para quando der errado

Esse erro é diferente dos outros. Não é técnico — é organizacional. E é o mais caro quando você precisa dele.

Num pentest, depois da fase de execução, perguntei ao cliente: "se eu tivesse sido um atacante real e tivesse chegado até aqui, o que vocês fariam?" A resposta foi honesta: "a gente ia tentar descobrir o que aconteceu e resolver."

Sem plano documentado. Sem definição de quem aciona quem. Sem critério para decidir se isola o sistema ou mantém operando para investigar. Sem comunicação preparada para clientes ou reguladores.

O que distingue empresas que se recuperam bem de um incidente das que têm danos maiores não é só a qualidade dos controles técnicos. É a qualidade da resposta quando os controles falham — e eventualmente algum controle vai falhar.

Um plano de resposta não precisa ser um documento de 200 páginas. Precisa responder: quem é acionado e em qual ordem? Qual o critério para isolar um sistema comprometido? Como preservar evidências para investigação forense? Como comunicar para quem precisa saber?

E precisa ser praticado. Um tabletop exercise — onde o time percorre um cenário hipotético em mesa, sem pressão real — muda muito a capacidade de resposta. É exatamente o tipo de coisa que parece perda de tempo até o dia que não é mais hipotético.

O que esses erros têm em comum

Nenhum deles exige conhecimento avançado para ser resolvido. Não estamos falando de exploits zero-day ou ataques sofisticados. Estamos falando de configurações e processos básicos que ficam pra depois por uma combinação de pressa, dívida técnica e ausência de processo.

A cloud é uma plataforma com controles poderosos disponíveis. Mas esses controles precisam ser ativamente escolhidos e configurados. O modelo de responsabilidade compartilhada deixa claro: a infraestrutura física é responsabilidade da cloud provider. Tudo que roda em cima é responsabilidade sua.

Segurança em cloud não é um projeto com começo, meio e fim. É uma prática contínua — e ela começa pelos fundamentos.