Equipes que administram contas de AWS, Azure ou Google Cloud sem plataforma comercial de postura costumam descobrir a exposição tarde demais: bucket público, chave de acesso esquecida, trilha de auditoria desligada. O Prowler ataca exatamente esse problema. Trata-se de uma ferramenta de código aberto que automatiza verificações de segurança e conformidade em contas de nuvem pela linha de comando e devolve uma lista de achados que pode ser priorizada no mesmo dia. A ação prioritária para quem ainda não tem CSPM pago é rodar a primeira varredura agora e usar o volume de achados para dimensionar o problema antes de discutir compra de plataforma.
O que o Prowler resolve
Postura de nuvem é o conjunto de configurações que decide se uma conta resiste a um adversário curioso: identidade com privilégio mínimo, rede sem saída livre, armazenamento fechado por padrão, criptografia em repouso e logs ativos. Essas decisões ficam espalhadas por consoles, APIs e infraestrutura como código, e revisão manual não escala. O Prowler mapeia esse território: é a plataforma de segurança em nuvem de código aberto mais adotada, com suporte oficial para AWS, Azure e Google Cloud — auditando contas, assinaturas e projetos, respectivamente —, além de Kubernetes, GitHub, Microsoft 365 e outros provedores. O mesmo motor alimenta a CLI, um SDK em Python e um servidor auto-hospedado, e a documentação oficial descreve cada provedor com seu escopo de auditoria.
O diferencial para a defesa é a transparência. São milhares de verificações prontas, com orientação de correção e frameworks de conformidade embutidos, e cada verificação é código aberto que a equipe pode ler, questionar e estender. Nada de caixa-preta: quando um achado parece falso positivo, existe arquivo e regra para inspecionar antes de dispensar o alerta ou corrigir o recurso.
A varredura de postura também serve de ponto de partida para frentes vizinhas. Segredos esquecidos em repositórios aparecem em outra superfície: o guia Gitleaks na prática mostra como varrer o histórico do Git antes que a chave vaze. No Google Cloud, a contenção de exfiltração merece camada própria: o artigo sobre VPC Service Controls explica o perímetro de dados por serviço.
Instalação e primeira varredura
A autenticação usa a credencial padrão da AWS. O comando aws configure registra a chave de acesso ou a sessão; em ambientes com perfis separados, prowler aws -p <perfil> varre a conta associada ao perfil escolhido. Identidades que exigem MFA usam a bandeira --mfa, que pede o ARN do dispositivo e um código TOTP para abrir a sessão. Com a credencial pronta, prowler aws executa a varredura completa da conta com um único comando, sem qualquer agente instalado nos servidores.
| Comando | O que faz |
|---|---|
prowler aws |
Varre a conta inteira contra centenas de verificações e mapeia o resultado aos frameworks de conformidade |
prowler aws -p <perfil> |
Varre a conta associada a um perfil específico de credenciais |
--mfa |
Abre a sessão com ARN do dispositivo MFA e código TOTP |
prowler dashboard |
Explora os resultados da varredura em painel visual |
Dois cuidados operacionais: rode a varredura com uma identidade dedicada de auditoria, para não misturar permissões de leitura com privilégios de operação; e trate o primeiro relatório como linha de base, guardando o resultado para comparar a evolução semana a semana. Em ambientes multiconta, repita a varredura por conta e consolide os relatórios: a conta de segurança, a de produção e a de desenvolvimento quase sempre têm débitos diferentes.
Leitura dos achados sem ruído
Um primeiro relatório costuma assustar. A saída é triagem por tipo, não por volume. A ferramenta exporta os achados em CSV, JSON ou HTML, além do painel visual para exploração: o CSV alimenta a planilha de trabalho da equipe, o JSON alimenta o pipeline interno, e o HTML serve como evidência datada para apresentar à direção.
O atalho de triagem é a conformidade. Os achados já vêm mapeados para frameworks como CIS, NIST e PCI DSS, e o CIS mantém benchmarks de configuração segura dedicados à AWS, incluindo o Amazon Web Services Foundations. Em vez de discutir gosto, a equipe discute desvio de um padrão público: cada falha do benchmark tem recomendação escrita e identificador rastreável. Comece pelos itens de gestão de identidade e de registro de eventos, que concentram o risco de escala — credencial exposta dá acesso, log apagado dá invisibilidade, e os dois combinados dão ao invasor tempo ilimitado.
Priorização P1 e P2
- P1 — tratar em dias: chave de acesso ativa sem rotação e sem uso recente; armazenamento público por engano; usuário root com chave de acesso habilitada; trilha de auditoria desativada; permissão ampla com curinga em recurso de produção.
- P2 — tratar no ciclo normal: criptografia pendente em recursos legados; tags ausentes que atrapalham o inventário; configuração fora do recomendado pelo benchmark sem exposição direta; achados de conformidade sem dono definido.
A regra prática é simples: P1 é o que um adversário usa para entrar ou para apagar rastro; P2 é o que aumenta custo de gestão ou de auditoria. Publicar essa classificação no repositório da equipe transforma o relatório em plano de trabalho, com dono e prazo por item.
Varredura contínua e evidência
Varredura única é fotografia; postura é filme. O SDK em Python usa o mesmo motor da CLI e permite rodar varreduras programáticas em pipelines de CI/CD, consumindo os achados como dados estruturados — útil para bloquear o deploy que reintroduz uma configuração insegura. Para quem não pode mandar achados para fora do ambiente, o servidor local auto-hospedado sobe com Docker Compose, com interface web, API e varreduras agendadas mantendo os dados dentro da própria infraestrutura, o que costuma agradar setores regulados.
Registre cada ciclo: data, escopo, quantidade de achados por severidade e decisão de tratamento. Esse histórico é a evidência que auditoria e fiscalização pedem — e o argumento concreto na próxima conversa sobre orçamento de segurança.