Conhecendo o Prowler Open Source

Luiz Machado

Luiz Machado

— 4 min read

1. Visão Geral do Prowler Open Source

  • Multi-nuvem: Embora o Prowler tenha surgido com foco em AWS, a versão atual também suporta Azure, GCP e Oracle Cloud. No contexto de AWS, isso é especialmente útil para organizações que gerenciam ambientes híbridos ou multi-cloud.
  • Checks extensivos: Conta com mais de 300 verificações (checks) que cobrem diferentes áreas de segurança e conformidade (identidade, rede, criptografia, logging, monitoramento etc.).
  • Frameworks integrados: Vem com suporte embutido a benchmarks como CIS (Center for Internet Security), PCI-DSS, HIPAA, ISO 27001, SOC 2, GDPR, entre outros. Você pode escolher rodar auditorias específicas ou mesclar várias.

2. Instalação e Configuração

2.1 Métodos de Instalação

  1. Clone do Repositório (GitHub)
    • Forma mais direta de instalar, obtendo a versão mais recente (ou escolhendo uma versão/tag específica).
    • Ideal para quem deseja customizar o código ou integrar diretamente a pipelines.
  2. Docker / Container
    • O Prowler disponibiliza uma imagem Docker oficial.
    • Permite executar sem precisar instalar dependências na máquina local.
    • Facilita a padronização em ambientes de CI/CD ou clusters como ECS, EKS e Docker Swarm.
  3. Pacotes Distribuídos
    • Alguns usuários empacotam o Prowler em pacotes ou scripts de instalação. Dependendo da distro Linux (Ubuntu, Amazon Linux, etc.), podem existir pacotes ou tutoriais específicos.

2.2 Configurações Básicas

  • Credenciais e Permissões
    • O Prowler precisa de acesso a APIs AWS (via AWS CLI ou variáveis de ambiente).
    • Recomenda-se criar uma IAM Role com permissões de leitura para serviços como IAM, EC2, S3, CloudTrail, e assim por diante, seguindo o princípio de menor privilégio.
  • Variáveis de Ambiente
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_DEFAULT_REGION ou AWS_PROFILE podem ser definidos para apontar para o perfil/credenciais de auditoria.

2.3 Execução Básica

# Exemplo de execução padrão
./prowler -p default

# Exemplo rodando checks CIS
./prowler -p default -g cislevel1
  • -p: indica o perfil AWS (caso você tenha vários no ~/.aws/credentials).
  • -g: indica o grupo de checks (por exemplo, cislevel1, cislevel2, etc.).

3. Utilizações especificas

3.1 Selecionando e Customizando Checks

  • Grupos de Checks
    • O Prowler organiza checks em grupos (ex.: cislevel1, cislevel2, iso27001, hipaa, etc.).
    • Você pode rodar todos os checks simultaneamente ou focar em checks específicos para otimizar tempo e gerar relatórios orientados ao compliance desejado.
  • Arquivos de Configuração e Checks Customizados
    • A documentação mostra como criar módulos custom usando shell scripts ou Python, para adicionar regras internas que não existam nativamente no Prowler.
    • Útil quando a organização segue políticas próprias (por exemplo, checar se algum tag específico está presente).

3.2 Saída e Formatos de Relatório

  • Formatos Suportados:
    • json, csv, json-asff (AWS Security Finding Format), html, pdf, entre outros.
    • json-asff permite integrar facilmente com o AWS Security Hub, gerando findings compatíveis nativamente.
  • Personalização:
    • Você pode adicionar prefixos ou sufixos para identificar o ambiente analisado (ex.: dev, stage, prod).
    • Crie pipelines que enviem esses relatórios para S3, ou indexem em sistemas de log (OpenSearch, Splunk, etc.).

Exemplo:

./prowler -p default -M csv > resultados.csv
./prowler -p default -M json-asff > resultados-asff.json

3.3 Escaneando Múltiplas Contas e Regiões

  • Multi-Account
    • A documentação explica como usar -A para rodar com várias contas se você tiver perfis configurados ou --role para assumir roles em diferentes contas.
    • Em organizações grandes, é comum ter um script que iterere sobre cada conta em AWS Organizations, chamando o Prowler para cada uma.
  • Regiões
    • Por padrão, o Prowler verifica apenas a região definida (AWS_DEFAULT_REGION).
    • Importante quando há recursos sensíveis espalhados por várias regiões.

Você pode usar -r ou --regions para inspecionar múltiplas regiões:

./prowler -p default -r us-east-1,us-west-2,eu-central-1

3.4 Integração com AWS Security Hub

  • AWS Security Finding Format (ASFF)
    • O Prowler gera findings nesse formato se você usar o parâmetro -M json-asff.
    • Depois, é possível importar manualmente ou via script para o Security Hub, correlacionando achados do Prowler com alertas do GuardDuty, Inspector, etc.
  • Automação
    • Um fluxo típico: Prowler roda (pode ser via container no ECS), gera relatório em json-asff, e depois um script de Lambda (ou linha de comando) faz a postagem desses findings no Security Hub.
    • Isso unifica a visualização e facilita priorização de incidentes.

4. Novos Recursos e Destaques da Documentação

4.1 Checks para Outras Nuvens

  • Azure, GCP e OCI
    • Embora nosso foco seja a AWS, a documentação reforça que o Prowler pode agora rodar checks em outras nuvens.
    • Isso permite que equipes de segurança padronizem as auditorias em ambientes híbridos.

4.2 Integração com Ferramentas de CI/CD

  • GitHub Actions
    • Você encontra exemplos de workflows no repositório e na documentação do Prowler, facilitando a execução automática em cada pull request.
    • Use para “shift-left” em segurança: sempre que alguém modificar infraestrutura (Terraform, CloudFormation), você roda o Prowler para garantir que não há violações de conformidade.
  • GitLab CI e CodeBuild
    • Da mesma forma, há templates e guias para integrar a pipelines GitLab ou CodeBuild na AWS.
    • A saída (csv/json) pode ser armazenada como artefato de build ou enviada para repositórios S3.

4.3 Benchmark Mode e Custom Benchmarks

  • Benchmark Mode
    • O Prowler possui um “modo benchmark” que foca exclusivamente em checks de um framework, atribuindo pontuações e gerando relatórios específicos do CIS, PCI, etc.
    • Permite ter uma “nota” de conformidade e saber em que pontos você está falhando ou passando.
  • Custom Benchmarks
    • A documentação explica como criar seus próprios benchmarks juntando checks nativos + checks custom.
    • Bom para empresas que possuem requisitos internos, ou que queiram consolidar vários benchmarks numa única execução.

5. Melhores Práticas de Uso (Conforme a Documentação)

  1. Automatizar Execuções Regulares
    • A documentação enfatiza a importância de rodar o Prowler periodicamente (diário, semanal ou mensal), pois a postura de segurança deve ser acompanhada de forma contínua.
  2. Armazenar Relatórios Historicamente
    • Para auditorias, é útil manter registros de como estava a conformidade ao longo do tempo.
    • Use versionamento em um bucket S3 ou um repositório de logs para comparar evoluções.
  3. Corrigir Achados Criticamente Rápido
    • Alguns checks do Prowler têm maior severidade — por exemplo, “S3 Bucket Permite Acesso Público” ou “Root Account sem MFA”.
    • Recomenda-se criar um processo de remediation imediato para itens de alta prioridade.
  4. Manter Ferramenta Atualizada
    • A equipe do Prowler libera atualizações frequentes, adicionando novos checks, melhorando performance e corrigindo bugs.
    • Acompanhe o changelog e as notas de versão no GitHub ou na própria documentação oficial.
  5. Integrar com Outras Ferramentas
    • A documentação dá exemplos de como enviar achados para Splunk, Elasticsearch/OpenSearch, Slack, Email etc.
    • Isso garante que alertas críticos não fiquem “esquecidos” em um relatório local.

As principais vantagens incluem:

  • Cobertura Abrangente (mais de 300 checks)
  • Suporte a Múltiplos Frameworks de Compliance
  • Execução Multiplataforma (Docker, local, CI/CD, etc.)
  • Integração Fácil com Serviços AWS (Security Hub, EventBridge, S3, etc.)

Recursos Recomendados

Read more