luizmachado.dev

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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