Superfície de ataque da nuvem

Na nuvem, o provedor protege a infraestrutura, enquanto o cliente protege a configuração, a identidade e os dados. A maioria das violações ocorre do lado do cliente nessa divisão.

• O provedor corrige hipervisores e cuida da segurança física.
• O cliente é responsável pelas políticas de IAM, pelas permissões de armazenamento e pelas regras de rede.
• Configurações incorretas, e não o comprometimento do provedor, são o risco predominante.

A nuvem não tem uma borda de rede tradicional. O acesso é controlado pelo IAM: usuários, funções, políticas e chaves. Uma chave de acesso exposta pode ser tão prejudicial quanto uma senha roubada de administrador do domínio.

• As políticas de IAM concedem ações sobre recursos.
• As funções permitem que serviços e usuários assumam credenciais temporárias.
• Identidades com permissões excessivas são o principal vetor de elevação.

As credenciais da nuvem vazam constantemente. As fontes mais comuns incluem:

• Chaves de acesso enviadas para repositórios Git públicos.
• Chaves codificadas diretamente em aplicativos móveis, registros de integração contínua ou imagens de contêineres.
• Falsificação de solicitações do lado do servidor (SSRF) alcançando o serviço de metadados.
• Compartilhamento excessivamente amplo de chaves de longa duração em vez de funções de curta duração.

Cada instância de nuvem expõe um ponto de extremidade de metadados que pode fornecer credenciais temporárias de função. Um SSRF ou RCE em uma VM que consiga acessá-lo geralmente permite obter a função da instância.

• O AWS IMDS está disponível em 169.254.169.254.
• O IMDSv1 aceita apenas requisições e é facilmente explorado por meio de SSRF.
• O IMDSv2 exige um identificador de sessão (PUT e depois GET), reduzindo a eficácia de muitos ataques SSRF.

O armazenamento de objetos (S3, GCS, Blob do Azure) é uma fonte recorrente de exposição de dados.

• Contêineres de leitura pública expõem arquivos confidenciais.
• Contêineres de escrita pública permitem adulteração ou hospedagem de malware.
• Políticas de contêineres ou listas de controle de acesso excessivamente amplas concedem acesso a usuários autenticados.
• URLs pré-assinadas com expiração longa expõem acesso persistente.

Os controles de rede da nuvem (grupos de segurança, grupos de segurança de rede e regras de firewall) podem facilmente ser configurados de forma excessivamente aberta.

• Bancos de dados ou portas administrativas expostos a 0.0.0.0/0.
• Planos de gerenciamento (API do Kubernetes, RDP, SSH) acessíveis pela internet.
• Serviços internos que confiam implicitamente na VPC, sem autenticação.

A arquitetura sem servidor transfere o risco, mas não o elimina. Funções, filas e bancos de dados gerenciados têm, cada um, uma identidade de execução.

• A função de execução de uma Lambda pode ter permissões excessivas.
• Variáveis de ambiente frequentemente armazenam segredos que podem ser lidos após uma comprometimento.
• Uma configuração incorreta da fonte de eventos pode permitir que uma entrada não confiável acione funções privilegiadas.

Diferencie as duas superfícies de ataque:

• Plano de controle: a API da nuvem (criar recursos, modificar o IAM e ler configurações). O comprometimento dessa camada afeta toda a conta.
• Plano de dados: as próprias cargas de trabalho (aplicativos, VMs e contêineres).

Obter um ponto de apoio no plano de dados que forneça credenciais do plano de controle é a forma clássica de escalação na nuvem.

Grandes organizações dividem as cargas de trabalho entre muitas contas, assinaturas e projetos.

• Funções entre contas com políticas de confiança fracas permitem a movimentação lateral.
• Uma entidade confusa em uma função de integração de terceiros pode ser explorada.
• Funções no nível da organização (por exemplo, OrganizationAccountAccessRole) têm alto valor.

As equipes de defesa dependem de registros nativos da nuvem. Os invasores tentam cegá-las.

• CloudTrail / registro de atividades / registros de auditoria registram chamadas do plano de controle.
• Os invasores podem desativar trilhas ou interromper a entrega de registros.
• GuardDuty / Centro de Comandos de Segurança / Defender sinalizam anomalias.

Desativar o registro de eventos é, por si só, um evento de alto sinal que merece um alerta.

Os testes de invasão na nuvem exigem conhecimento do provedor e autorização. Algumas ações (negação de serviço e determinados tipos de varredura) violam os termos do provedor. Sempre confirme a propriedade da conta, defina o raio de impacto em conjunto e prefira começar pela enumeração somente leitura.

Use uma conta de testes dedicada ou recursos claramente identificados com etiquetas, e nunca acesse recursos fora do escopo documentado.

Confirme seu entendimento da superfície de ataque na nuvem.

Você mapeou a superfície de ataque na nuvem.

• As configurações incorretas no lado do cliente predominam entre os riscos da nuvem.
• A identidade é o perímetro; chaves e funções vazadas são vetores principais.
• O serviço de metadados conecta falhas no plano de dados a credenciais da nuvem.
• Configurações incorretas de armazenamento, rede e registro de eventos completam a superfície.

Próximo: enumerar recursos da nuvem para encontrar esses problemas.