Hardening de nuvem: as misconfigurations que derrubam empresas em AWS, Azure e GCP

A maioria dos grandes vazamentos da última década não começou com um exploit sofisticado nem com um zero-day. Começou com uma caixa de configuração deixada no lugar errado: um bucket de armazenamento marcado como público, uma permissão de IAM larga demais, um grupo de segurança liberando a porta do banco para a internet inteira. A Gartner cunhou a frase que resume a era da nuvem: até 2026, a esmagadora maioria das falhas de segurança em nuvem será culpa do cliente, não do provedor.

Isso é, ao mesmo tempo, uma má e uma ótima notícia. Má, porque significa que a bala está no seu pé. Ótima, porque significa que a defesa está sob o seu controle: hardening, o endurecimento sistemático da configuração, resolve a maior parte do problema, sem depender de ninguém. Este guia percorre as misconfigurations que mais derrubam empresas em AWS, Azure e GCP, e os controles concretos para fechá-las.

Antes de tudo: o modelo de responsabilidade compartilhada

O erro conceitual que origina quase todos os outros é não entender onde termina a responsabilidade do provedor e começa a sua. AWS, Azure e GCP operam sob o modelo de responsabilidade compartilhada:

• O provedor cuida da segurança da nuvem: datacenter físico, hardware, hipervisor, rede base. Isso é problema deles, e eles fazem bem.
• Você cuida da segurança na nuvem: suas configurações de IAM, seus dados, suas redes virtuais, seu sistema operacional, suas aplicações, seus segredos.

A nuvem é segura por padrão na camada do provedor e configurável de forma insegura na sua camada. O provedor te dá um cofre de altíssima qualidade; se você deixa a porta encostada, o cofre não tem culpa. Hardening é, no fundo, assumir com seriedade a metade que é sua.

As misconfigurations que mais causam estrago

1. Armazenamento exposto publicamente

O clássico dos clássicos. Um S3 bucket (AWS), um Blob Storage container (Azure) ou um Cloud Storage bucket (GCP) configurado com acesso público, muitas vezes "só para testar", e depois esquecido. O resultado é uma base de clientes, backups ou documentos internos indexáveis por qualquer um que descubra a URL.

Como fechar:

• Habilite o bloqueio de acesso público no nível da conta/organização (S3 Block Public Access, e equivalentes). Isso impede exposição acidental mesmo que alguém erre uma política.
• Negue por padrão; conceda acesso via políticas de recurso específicas, nunca via "público".
• Ative criptografia em repouso e logging de acesso aos objetos.

2. IAM permissivo demais

A segunda causa mais comum, e a mais perigosa quando combinada com outra falha. Papéis e usuários com permissões amplas (o temido "Action": "*" sobre "Resource": "*") transformam qualquer credencial comprometida em acesso total. O princípio violado é o do menor privilégio: cada identidade deveria ter só as permissões que realmente usa.

Como fechar:

• Comece restritivo e amplie sob demanda, nunca o contrário.
• Elimine o uso da conta root/owner no dia a dia; proteja-a com MFA e guarde-a.
• Prefira papéis temporários (AWS IAM Roles, GCP Service Accounts com credenciais de curta duração, Azure Managed Identities) a chaves estáticas de longa vida.
• Revise permissões periodicamente e use as ferramentas de análise de acesso do próprio provedor (IAM Access Analyzer, Policy Intelligence) para achar privilégios não usados.

3. Chaves e segredos expostos

Credenciais hardcoded no código, em variáveis de ambiente commitadas ou em repositórios públicos. Bots varrem o GitHub em minutos atrás de chaves de acesso; uma chave vazada vira mineração de cripto na sua conta antes do café esfriar.

Como fechar:

• Use um cofre de segredos (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager), injetando segredos em runtime.
• Prefira identidades gerenciadas a chaves sempre que o serviço permitir: sem chave, não há chave para vazar.
• Rode secret scanning no pipeline (git hooks, CI) para barrar o commit antes que ele aconteça.
• Rotacione credenciais regularmente e revogue na hora quando houver suspeita.

4. Metadados de instância expostos (e SSRF na nuvem)

Cada máquina virtual tem um endpoint de metadados que entrega credenciais temporárias da identidade associada. Se a aplicação nessa VM tem uma falha de SSRF, o atacante força o servidor a buscar esse endpoint e rouba as credenciais da instância, escalando de uma falha web para acesso à conta de nuvem. Foi assim que aconteceram alguns dos maiores vazamentos da história.

Como fechar:

• Na AWS, exija IMDSv2 (que usa token de sessão e mitiga SSRF); desabilite o IMDSv1.
• Restrinja ao máximo as permissões da identidade da instância (volta ao menor privilégio: se a credencial roubada não pode fazer nada, o roubo vale pouco).
• Trate SSRF como risco de primeira ordem em toda aplicação exposta.

5. Rede aberta: grupos de segurança e portas administrativas

Um Security Group (AWS), NSG (Azure) ou regra de firewall (GCP) liberando 0.0.0.0/0 na porta 22 (SSH), 3389 (RDP) ou direto na porta do banco de dados. É um convite para força bruta e acesso direto a serviços que jamais deveriam encarar a internet.

Como fechar:

• Nunca exponha portas administrativas à internet. Use bastion host, VPN ou serviços de acesso gerenciado (SSM Session Manager, Azure Bastion, IAP).
• Bancos de dados e serviços internos vivem em sub-redes privadas, sem IP público.
• Segmente a rede: aplicação, dados e administração em zonas separadas, com regras mínimas entre elas.

6. Logging e monitoramento desligados

Não é uma porta aberta, mas determina se você verá o ataque. Sem CloudTrail (AWS), Azure Monitor / Activity Log ou Cloud Audit Logs (GCP), um intruso opera às cegas do seu lado. A ausência de trilha também inviabiliza investigação forense e prova de diligência para a LGPD.

Como fechar:

• Ative o log de auditoria da API de gestão em todas as regiões e contas, com armazenamento imutável.
• Centralize logs e configure alertas para eventos críticos: criação de usuário privilegiado, mudança de política de bucket, desativação de logging.
• Considere os serviços nativos de detecção (GuardDuty, Microsoft Defender for Cloud, Security Command Center).

Um comparativo rápido dos controles equivalentes

Área	AWS	Azure	GCP
Identidade	IAM Roles, IAM Access Analyzer	Entra ID, Managed Identities	IAM, Service Accounts
Segredos	Secrets Manager	Key Vault	Secret Manager
Bloqueio de storage público	S3 Block Public Access	Storage firewall / private endpoints	Public access prevention
Auditoria	CloudTrail	Activity Log / Azure Monitor	Cloud Audit Logs
Detecção gerenciada	GuardDuty	Microsoft Defender for Cloud	Security Command Center
Postura (CSPM)	Security Hub	Defender for Cloud	Security Command Center

Os nomes mudam; os princípios não: menor privilégio, negar por padrão, segredos em cofre, rede segmentada, tudo auditado.

Automatize a postura: CSPM e Infraestrutura como Código

Hardening manual não escala. Numa conta com centenas de recursos criados por vários times, alguém vai errar uma configuração; a questão é apenas quando. Duas práticas transformam hardening de esforço pontual em propriedade contínua:

• CSPM (Cloud Security Posture Management): ferramentas (nativas ou terceiras) que varrem continuamente o ambiente contra benchmarks como o CIS, apontando desvios (bucket que virou público, IAM que ficou largo) e, muitas vezes, corrigindo automaticamente.
• Infraestrutura como Código (IaC): definir recursos em Terraform, CloudFormation ou Bicep torna a configuração versionada, revisável e auditável. Somado a scanners de IaC (Checkov, tfsec) no pipeline, você barra a misconfiguration antes do deploy: o shift-left aplicado à nuvem.

A combinação fecha o ciclo: IaC previne o erro na entrada; CSPM detecta o desvio que passar.

Um checklist mínimo de hardening

1. Responsabilidade compartilhada entendida pelo time: a parte "na nuvem" é sua.
2. Storage: bloqueio de acesso público no nível da organização; criptografia e logging ativos.
3. IAM: menor privilégio, sem uso de root, MFA obrigatório, credenciais temporárias.
4. Segredos em cofre; secret scanning no pipeline; rotação em dia.
5. Metadados: IMDSv2 obrigatório; SSRF tratado como risco crítico.
6. Rede: portas administrativas fechadas à internet; dados em sub-redes privadas; segmentação.
7. Auditoria ativa em todas as regiões, centralizada, com alertas para eventos críticos.
8. Automação: IaC versionada + CSPM contínuo contra benchmark CIS.

Nuvem segura é configuração disciplinada, não sorte

A nuvem não é insegura: ela é poderosa e não perdoa desatenção. O mesmo IAM que permite arquiteturas elegantes permite conceder acesso total com uma linha errada; o mesmo bucket que serve um site estático vaza uma base de clientes com um clique. Segurança em nuvem é, essencialmente, a disciplina de configurar com intenção, verificar continuamente e nunca confiar no padrão sem conferir. As empresas que sofrem vazamentos raramente foram alvo de gênios do crime; foram alvo da própria caixa de configuração esquecida.

Na ConstructorTI, fazemos cloud security assessment e hardening em AWS, Azure e GCP: revisão de IAM e superfície de rede, caça a misconfigurations contra os benchmarks CIS, avaliação de exposição de storage e segredos, e desenho de guardrails com IaC e CSPM para que o ambiente permaneça seguro à medida que cresce. Se você opera em nuvem e quer saber quais portas estão encostadas antes que alguém as empurre, converse com o nosso time de CyberSecurity.