luizmachado.dev

PT EN

Conhecendo o Prowler Open Source

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 específicas

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