Segurança em nuvem AWS e GCP: erros de configuração que derrubam startups

Por que a configuração é o ponto fraco, não a infraestrutura

AWS e GCP operam sob o modelo de responsabilidade compartilhada: o provedor protege a infraestrutura física, o hipervisor e os serviços gerenciados; o cliente é responsável por quem acessa o quê, por como os dados são expostos e por como as credenciais são gerenciadas. Para uma startup, isso significa que a quase totalidade dos vetores de comprometimento está dentro do escopo do próprio time, não do provedor.

O padrão se repete em relatórios de incidentes em nuvem: raramente o problema é uma vulnerabilidade no S3 ou no Compute Engine. O problema é um bucket deixado público, uma chave de acesso commitada no Git, um security group liberando a porta 22 para a internet inteira ou um usuário root sem MFA. São erros de configuração, e configuração é exatamente onde um time pequeno, sem especialista dedicado em segurança, mais escorrega sob pressão de prazo.

A boa notícia é que esses erros são conhecidos, finitos e mensuráveis. O AWS Well-Architected Framework (pilar de Segurança) e o Google Cloud Architecture Framework descrevem as práticas esperadas, e os CIS Benchmarks para AWS e GCP traduzem isso em controles verificáveis. O objetivo deste artigo é mapear os erros que mais aparecem e definir um baseline mínimo que cabe na realidade de uma equipe enxuta.

IAM e least privilege: o erro que amplifica todos os outros

Identidade é o novo perímetro. Uma credencial com permissões amplas transforma um vazamento pequeno em comprometimento total da conta. Os erros mais frequentes são: anexar políticas gerenciadas amplas como AdministratorAccess a usuários ou roles de aplicação; usar uma única chave de acesso de longa duração compartilhada entre serviços; e provisionar usuários humanos com chaves estáticas em vez de identidades federadas com credenciais temporárias.

O princípio de least privilege, descrito no NIST SP 800-53 (AC-6) e nos dois Well-Architected, exige conceder apenas as permissões necessárias para a tarefa, e nada além. Na prática: prefira roles assumidas (AWS IAM Roles, GCP service accounts com Workload Identity) a chaves de longa duração; conceda permissões por recurso e por ação, não por wildcard; e revise periodicamente o que cada principal realmente usou. A AWS expõe o IAM Access Analyzer e o Access Advisor (last accessed) justamente para isso; o GCP oferece o IAM Recommender, que sugere a remoção de papéis não utilizados.

Para workloads, elimine chaves estáticas: em AWS use IAM Roles for Service Accounts (IRSA) no EKS ou instance profiles; em GCP use Workload Identity Federation, que dispensa baixar chaves JSON de service account. Chave de service account em arquivo é uma das credenciais mais vazadas em repositórios públicos, e ela não expira sozinha.

Storage exposto: buckets S3 e Cloud Storage públicos

Vazamentos de dados por bucket aberto continuam entre os incidentes mais comuns e mais embaraçosos. Em AWS, ative o Block Public Access no nível da conta inteira, não apenas por bucket; isso impede que uma ACL ou policy mal configurada exponha dados, mesmo que alguém erre depois. Combine com criptografia em repouso por padrão (SSE-KMS) e com políticas que neguem upload sem TLS.

No GCP, prefira o controle de acesso uniforme em nível de bucket (uniform bucket-level access), que desativa ACLs por objeto e centraliza a permissão via IAM, reduzindo a chance de um objeto isolado ficar público. Use o Domain Restricted Sharing na Organization Policy para impedir que allUsers ou allAuthenticatedUsers sejam concedidos a qualquer recurso, fechando a porta para exposição acidental.

Em ambos os provedores, o erro recorrente é tratar a exposição como decisão por recurso. Trate como decisão de organização: bloqueio público padrão, e exceções explícitas, documentadas e monitoradas. O CIS Benchmark cobre esses itens diretamente (seções de S3 e de Cloud Storage), o que facilita verificar conformidade de forma automatizada.

Secrets, MFA no root e logging: a tríade que define o blast radius

Secrets em código ou em variáveis de ambiente versionadas são uma fonte crônica de comprometimento. Centralize segredos no AWS Secrets Manager ou no GCP Secret Manager, injete-os em runtime, ative rotação automática e use detecção de secrets no pipeline (git hooks, scanning de PR). Nunca commite chaves; quando uma vazar, revogue e rotacione imediatamente, pois bots varrem o GitHub em minutos. O OWASP reforça a separação entre credencial e código como controle básico.

A conta root da AWS e o usuário Organization Admin do GCP têm poder irrestrito. Habilite MFA nessas identidades (idealmente hardware key), não as use para operações do dia a dia, remova chaves de acesso do root e crie usuários administrativos separados via SSO/IAM Identity Center. Esse é o controle de maior retorno por esforço: um root protegido limita drasticamente o estrago de qualquer credencial vazada.

Logging não é opcional. Em AWS, mantenha o CloudTrail ligado em todas as regiões, com trail organizacional, validação de integridade de log e entrega para um bucket dedicado com acesso restrito; ative também o GuardDuty para detecção. Em GCP, garanta os Cloud Audit Logs (Admin Activity é padrão; ative Data Access onde fizer sentido) e considere o Security Command Center. Sem trilha de auditoria habilitada antes do incidente, a investigação fica cega: você não saberá o que foi acessado nem por quem.

Security groups e rede: pare de abrir 0.0.0.0/0

Security groups (AWS) e firewall rules (GCP) abertos para a internet inteira são um clássico. Os casos mais perigosos: SSH (22), RDP (3389) e portas de banco de dados (5432, 3306, 27017) acessíveis de 0.0.0.0/0. A regra é simples: nenhuma porta administrativa ou de dados deve estar exposta à internet. Use acesso via bastion, AWS Systems Manager Session Manager ou IAP (Identity-Aware Proxy) do GCP, que dispensam abrir SSH por completo.

Estruture a rede com segmentação: sub-redes privadas para bancos e workloads internos, públicas só para o que precisa receber tráfego externo, e tudo atrás de um load balancer ou WAF quando aplicável. Restrinja regras por origem (CIDR específico, security group de origem) em vez de liberar faixas amplas. O CIS Benchmark verifica explicitamente a ausência de regras 0.0.0.0/0 para portas sensíveis, então esse é um item fácil de medir e manter limpo.

Baseline mínimo com time enxuto: CSPM e CIS sem time de segurança dedicado

Startup não precisa de um SOC para começar; precisa de um baseline aplicado de forma consistente e de uma forma automática de detectar quando o ambiente sai dele. É aí que entra o CSPM (Cloud Security Posture Management): a ferramenta avalia continuamente a sua conta AWS/GCP contra um conjunto de regras, normalmente alinhado aos CIS Benchmarks, e aponta os desvios com prioridade e remediação sugerida. Isso substitui a auditoria manual, que um time pequeno não consegue manter.

Há recursos nativos que já entregam parte disso: AWS Security Hub (que agrega o CIS AWS Foundations Benchmark, GuardDuty e Inspector) e GCP Security Command Center. Ative pelo menos o tier padrão, conecte os achados a um canal que o time leia (Slack, e-mail, ticket) e trate os findings críticos como bugs de produção: com dono, prazo e fechamento. Infraestrutura como código (Terraform) com revisão e scanning estático (tfsec, Checkov) impede que desvios entrem em primeiro lugar.

O ponto central é tornar a postura mensurável e contínua, não um projeto pontual de hardening que envelhece em semanas. Com IAM em least privilege, storage bloqueado, secrets centralizados, root com MFA, logging ligado e rede fechada, você cobre a maioria dos vetores reais com investimento proporcional ao tamanho do time.

Checklist prático

1. 1

   1. Proteja o root e habilite MFA

   Ative MFA na conta root da AWS e no Organization Admin do GCP, remova chaves de acesso do root e crie acesso administrativo via SSO/IAM Identity Center com perfis separados.

2. 2

   2. Aplique least privilege no IAM

   Substitua políticas amplas (AdministratorAccess) por permissões específicas, migre workloads para roles temporárias (IRSA, Workload Identity) e use Access Analyzer e IAM Recommender para remover privilégios não usados.

3. 3

   3. Bloqueie acesso público ao storage

   Ligue o Block Public Access da conta inteira na AWS e o uniform bucket-level access mais Domain Restricted Sharing no GCP. Ative criptografia em repouso por padrão.

4. 4

   4. Centralize e rotacione secrets

   Mova credenciais para Secrets Manager (AWS) ou Secret Manager (GCP), injete em runtime, habilite rotação e adicione secret scanning ao pipeline. Revogue qualquer chave já vazada.

5. 5

   5. Ligue o logging em todas as regiões

   Habilite CloudTrail organizacional com validação de integridade e GuardDuty na AWS; garanta Cloud Audit Logs e avalie o Security Command Center no GCP. Entregue logs a um destino restrito.

6. 6

   6. Feche a rede

   Remova regras 0.0.0.0/0 para SSH, RDP e bancos. Use Session Manager ou IAP para acesso administrativo e segmente bancos em sub-redes privadas.

7. 7

   7. Meça contra o CIS com um CSPM

   Ative Security Hub (CIS AWS Foundations) ou Security Command Center, ou um CSPM dedicado, e trate os findings críticos como bugs com dono e prazo. Use IaC com tfsec/Checkov para prevenir desvios.

Perguntas frequentes