Cinco más configurações cloud que encontramos quase sempre

As plataformas cloud não são inseguras por omissão, mas são permissivas por omissão, e é nessa distância que vive a maioria das nossas constatações em cloud. As cinco seguintes aparecem na maioria dos ambientes que revemos, tanto em AWS como em Azure ou Google Cloud.

1. Armazenamento mais público do que alguém pretendia

O armazenamento de objetos continua a ser o sítio mais fiável para encontrar dados expostos. Raramente é um contentor deliberadamente marcado como público — os fornecedores tornaram isso difícil e ruidoso. São as variantes subtis: uma política que concede leitura a qualquer entidade autenticada (ou seja, qualquer conta da plataforma, não apenas as suas), um URL pré-assinado gerado com validade de dez anos e colado num bilhete de suporte, ou uma distribuição CDN à frente de um contentor privado que serve discretamente caminhos que ninguém quis publicar.

O que fazer: enumere todos os contentores e verifique o acesso efetivo, não o interruptor visível. Ative o bloqueio de acesso público ao nível da conta e trate as exceções como alterações que precisam de aprovação. Limite a validade dos URLs pré-assinados no código, não por convenção.

2. Perfis que cresceram e nunca encolheram

A identidade é onde a segurança cloud acontece de facto, e os conjuntos de permissões acumulam-se. Um perfil recebe uma permissão genérica durante um incidente às duas da manhã e fica com ela três anos. Um pipeline de CI/CD recebe administração porque ninguém conseguiu apurar de que doze permissões precisava. Uma conta de serviço criada para uma função é reutilizada para outras quatro.

A consequência é que uma única credencial comprometida rende muito mais do que devia. Numa revisão, o perfil de um servidor aplicacional não só lia a base de dados de que precisava como podia alterar as políticas de identidade que o limitavam — o que transforma um ponto de entrada em controlo total da conta.

O que fazer: use o analisador de acessos da própria plataforma para comparar permissões concedidas com permissões efetivamente usadas nos últimos noventa dias, e corte a diferença. Proíba genéricos nos campos de ação e de recurso para tudo o que não seja humano. Separe os perfis que fazem implantação dos perfis que executam.

3. Chaves de acesso de longa duração

As chaves estáticas são a credencial com maior probabilidade de acabar onde não devia: um repositório, uma variável de CI copiada para uma mensagem, uma imagem de portátil, uma camada de contentor. Encontramos rotineiramente chaves criadas há anos, pertencentes a alguém que já saiu, e que continuam a funcionar.

O que fazer: substitua chaves estáticas por credenciais de curta duração sempre que a plataforma o permita — perfis de instância, federação de identidade de carga de trabalho, OIDC a partir do seu fornecedor de CI. Para as chaves que não consegue mesmo remover, force a rotação por calendário e alerte sobre qualquer chave sem utilização há trinta dias, porque chaves não usadas são só risco.

4. Redes planas atrás do perímetro

A fronteira externa costuma ser razoável — um balanceador, dois ou três portos abertos. Atrás dela, tudo alcança tudo. Os grupos de segurança referenciam gamas de IP largas, serviços internos escutam em todas as interfaces e as bases de dados aceitam ligações de toda a rede virtual em vez das duas sub-redes que precisam.

Isto não cria a violação, mas determina a sua gravidade. O movimento lateral de uma instância web comprometida para uma base de dados ou um serviço interno de administração é o passo que transforma um incidente numa divulgação obrigatória.

O que fazer: negue por omissão entre camadas e abra apenas os caminhos necessários. Coloque as bases de dados geridas em sub-redes privadas sem rota para a internet. Verifique também as regras de saída — saída para todo o lado é como os dados saem e como chegam as cargas de segunda fase.

5. Registos que existem mas não servem

Quase toda a gente tem registo de auditoria ativo. Bastantes menos o têm numa forma que responda a uma pergunta durante um incidente. Lacunas comuns: registos escritos para um contentor na mesma conta que um atacante já controlaria, retenção de trinta dias, eventos de plano de dados (quem leu que objeto) nunca ativados por causa do custo, e ausência de alertas nos poucos eventos que realmente importam.

O que fazer: envie os registos para uma conta ou projeto separado, com acesso apenas de escrita a partir da origem. Defina a retenção pelas suas necessidades reais de investigação, não pelo valor por omissão. Ative o registo de plano de dados pelo menos no armazenamento com dados pessoais ou financeiros. Depois defina um número reduzido de alertas de alto sinal — uso da conta raiz, alterações de políticas de identidade, desativação do próprio registo — e confirme que chegam a uma pessoa.

O padrão por baixo

Nenhum destes casos é exótico. São o que acontece quando a infraestrutura é construída depressa sob pressão de entrega e nunca mais revista, o que descreve quase todas as empresas em crescimento. A contramedida mais eficaz que vemos é pouco glamorosa: uma revisão trimestral com lista de verificação escrita, e infraestrutura definida como código para que a revisão tenha algo para ler além de uma consola web.

Se este trimestre fizer apenas um destes pontos, faça a revisão de identidade. Perfis demasiado amplos são a constatação que mais fiavelmente transforma um incidente pequeno num incidente grande.