Superfície de ataque na nuvem

A superfície de ataque da nuvem é o conjunto total de pontos pelos quais um invasor poderia tentar entrar em um ambiente de nuvem ou extrair dados dele. Diferentemente das redes locais, a superfície da nuvem é definida principalmente por configuração e identidade, não pelo perímetro físico.

• APIs e consoles de gerenciamento expostos publicamente
• Gerenciamento de identidade e acesso (IAM)
• Contêineres de armazenamento, bancos de dados e funções sem servidor
• Exposição de rede (grupos de segurança, balanceadores de carga)

Uma única configuração incorreta pode expor uma conta inteira.

A maioria dos testes de intrusão em nuvem tem como alvo um dos três principais provedores. Cada um tem seu próprio modelo de identidade e sua própria terminologia, mas os padrões de ataque são semelhantes.

• AWS — usuários e funções do IAM, S3, EC2, Lambda
• Azure — Entra ID (Azure AD), Blob Storage, VMs, Functions
• GCP — contas de serviço do IAM, Cloud Storage, Compute Engine

Aprender profundamente um deles facilita o aprendizado dos outros, pois os conceitos centrais (identidade, computação, armazenamento e rede) correspondem entre todos.

Os provedores de nuvem protegem a infraestrutura; o cliente protege o que coloca dentro dela. Esse é o modelo de responsabilidade compartilhada, e quase toda violação de nuvem ocorre do lado do cliente.

• Provedor: centros de dados físicos, hipervisor e aplicação de correções nos serviços gerenciados
• Cliente: políticas de IAM, dados, aplicação de correções no OS (IaaS) e configuração de rede

Como testador de intrusão, você se concentra nas responsabilidades do cliente, pois é ali que estão os erros exploráveis.

A primeira tarefa em uma avaliação de nuvem é descobrir quem você é e o que pode fazer com as credenciais disponíveis. A CLI da AWS expõe instantaneamente a identidade do solicitante.

Se uma chave tiver permissões excessivas, essa identidade poderá se mover por toda a conta.

Os recursos da nuvem podem ser acessíveis pela internet pública ou apenas de dentro de uma rede virtual. A exposição configurada incorretamente é um dos achados mais comuns.

• Grupos de segurança / NSGs abertos para 0.0.0.0/0
• Contêineres de armazenamento configurados para leitura pública
• Bancos de dados com pontos de extremidade públicos habilitados
• Portas de gerenciamento (22, 3389, 5432) expostas

Mapear quais recursos são públicos é a base do reconhecimento na nuvem.

Mesmo sem credenciais, os invasores enumeram a presença de um alvo na nuvem. Nomes previsíveis e o DNS revelam uma quantidade surpreendente de informações.

As ferramentas fazem força bruta contra nomes de contêineres e armazenamentos com base no nome da empresa e em padrões comuns.

Existem duas camadas de ataque distintas em toda conta de nuvem:

• Plano de gerenciamento/controle — as APIs que criam, modificam e excluem recursos (por exemplo, iam:CreateUser, ec2:RunInstances)
• Plano de dados — acesso aos dados dentro dos recursos (leitura de um objeto S3, consulta a um banco de dados)

Comprometer o plano de gerenciamento geralmente significa o fim do jogo, pois o invasor pode conceder a si mesmo qualquer acesso ao plano de dados que desejar.

As ações na nuvem são registradas centralmente. Como profissional de teste de invasão, deve saber que esses registros existem, pois os defensores os monitoram; encontrar esses registros desativados já é, por si só, uma constatação.

• AWS Trilha de auditoria — registra todas as chamadas de API
• Registro de atividades / Monitor do Azure
• Registros de auditoria da nuvem do GCP

Uma conta com o registro desativado ou não monitorado representa uma constatação de alto risco, mesmo antes de qualquer exploração.

A maioria das invasões de ambientes de nuvem começa a partir de um pequeno conjunto de pontos de apoio:

• Chaves de acesso expostas em repositórios Git, registros de integração contínua ou aplicativos móveis
• Funções do IAM com permissões excessivas vinculadas a servidores comprometidos
• SSRF alcançando o serviço de metadados da instância
• Contêineres de armazenamento públicos expondo segredos ou cópias de segurança

Reconhecer esses padrões permite priorizar onde procurar primeiro.

Uma abordagem estruturada mantém uma avaliação de nuvem completa. As ferramentas automatizadas enumeram toda a conta assim que dispõe das credenciais.

Ferramentas como ScoutSuite e Prowler auditam a configuração dos serviços e sinalizam riscos automaticamente.

Os testes de nuvem devem permanecer dentro da autorização do trabalho. Os provedores também têm regras de engajamento.

• Confirme exatamente quais contas, assinaturas ou projetos estão no escopo
• Evite ações que afetem outros locatários ou a infraestrutura compartilhada
• Nunca execute testes semelhantes a uma negação de serviço sem aprovação explícita por escrito

Testes de nuvem não autorizados podem violar os termos do provedor e a legislação local.

No modelo de responsabilidade compartilhada, qual lado é responsável pelas políticas do IAM e pela configuração dos dados?

Você aprendeu o que define a superfície de ataque da nuvem e como ela difere das redes tradicionais.

• A superfície é moldada por identidade e configuração, não por um perímetro físico
• AWS, Azure e GCP compartilham os mesmos conceitos fundamentais: identidade, computação, armazenamento e rede
• O modelo de responsabilidade compartilhada atribui a configuração e os dados ao cliente
• Diferencie o plano de gerenciamento do plano de dados
• Sempre confirme o escopo e a autorização antes de realizar testes

A seguir, examinaremos detalhadamente as configurações incorretas do IAM, o centro dos ataques à nuvem.