getedgehq/security-audit-checklist

Lista de Verificação de Auditoria de Segurança

Execute estas verificações em qualquer sistema antes de enviar para produção ou após mudanças importantes.

Antes de começar

A lista de verificação em si é textual e não requer nada. Os três scanners em scripts/ são Python, portanto, executá-los requer Python 3 em sua máquina (python3 --version). Sem ele, você ainda pode trabalhar a lista manualmente; você apenas não terá a verificação automatizada de segredos, verificação de cabeçalhos e leitura de IaC.

1. Privacidade e Governança de Dados

• Política de privacidade existe se o aplicativo coleta, armazena ou processa qualquer dado do usuário. Vincule-a no rodapé e nos fluxos de cadastro.
• Saiba onde os dados do usuário estão armazenados: documente o banco de dados principal, caches, logs, backups e serviços de terceiros. Verifique os requisitos de residência de dados (LGPD, CCPA).
• Minimização de dados: colete apenas o que precisa. Exclua ou anonimize dados que você não utiliza.

2. Higiene de Segredos e Chaves

• Valores de .env não estão vazando: escaneie o repositório inteiro em busca de segredos codificados.
• Nunca exponha chaves de API no código frontend: sem chaves em bundles JS, sem valores sensíveis em prefixos públicos de env (REACT_APP_, NEXT_PUBLIC_, VITE_).
• Mova as chaves para o lado do servidor ou atrás de um proxy: todas as chamadas de API de terceiros que exigem segredos devem passar por um endpoint backend.
• Remova segredos dos logs: pesquise em logs e relatórios de erro por chaves, tokens e senhas. Masque ou redija antes da saída.
• Rode credenciais vazadas imediatamente se algo for encontrado.

Comandos de varredura rápidos:

# Execute o scanner de segredos incluído
python3 scripts/scan_secrets.py .

# Padrões manuais de ripgrep
grep -rE '(api[_-]?key|secret|token|password)\s*[:=]\s*["\047][a-zA-Z0-9_\-]{16,}' --include='*.{js,ts,py,go,rb,php,java,json,yaml,yml,env,sh,tf,hcl}' .
grep -rE 'AKIA[0-9A-Z]{16}' .  # Chaves AWS
grep -rE 'ghp_[a-zA-Z0-9]{36}' .  # Tokens GitHub
grep -rE 'sk-[a-zA-Z0-9]{48}' .   # Chaves OpenAI

3. Cabeçalhos de Segurança

• Content-Security-Policy restringe fontes de script e bloqueia execução inline sempre que possível.
• X-Frame-Options ou frame-ancestors previne clickjacking.
• Strict-Transport-Security força HTTPS.
• X-Content-Type-Options: nosniff está presente.
• Referrer-Policy limita o vazamento de referenciador.

Verifique cabeçalhos em uma URL ativa:

python3 scripts/check_headers.py https://seu-app.com

4. Fundamentos OWASP Top 10

#	Risco	O que verificar
A01	Falha no Controle de Acesso	Cada endpoint verifica autenticação e autorização. Sem bugs IDOR.
A02	Falhas Criptográficas	Senhas com hash bcrypt/Argon2. TLS 1.2+ aplicado. Sem dados sensíveis em URLs.
A03	Injeção	SQL usa declarações parametrizadas. Sem concatenação bruta de strings em consultas.
A04	Design Inseguro	Limites de taxa em autenticação e ações sensíveis. Lógica de negócios com verificações de abuso.
A05	Configuração Incorreta de Segurança	Credenciais padrão removidas. Modo de depuração desligado em produção. Mensagens de erro não vazam stack traces.
A06	Componentes Vulneráveis	Auditoria de dependências: npm audit, pip-audit, cargo audit, snyk test.
A07	Falhas de Autenticação	Tokens de sessão são aleatórios e rotacionados na mudança de privilégio. MFA para contas sensíveis.
A08	Integridade de Dados	Lockfiles presentes, commits assinados quando possível.
A09	Falhas de Logging	Eventos de segurança registrados sem segredos.
A10	SSRF	Requisições do lado do servidor usam uma lista de permissões. Sem URLs controladas pelo usuário atingindo serviços internos.

5. Validação de Entrada e Injeção

• Injeção SQL: todas as consultas usam parâmetros ORM ou declarações preparadas.
• XSS: a saída do usuário tem escape HTML. dangerouslySetInnerHTML e bypasses similares são auditados.
• Injeção de Comandos: nenhum exec(), system() ou eval() com entrada do usuário.
• Path Traversal: caminhos de arquivo são sanitizados e restritos a um diretório de lista de permissões.
• Injeção NoSQL: consultas MongoDB usam objetos parametrizados.

6. Segurança de API

• Verifique respostas de API por dados sensíveis: sem IDs internos, hashes de senha, tokens ou PII desnecessário.
• Autenticação em todos os endpoints não públicos: sem rotas abertas de admin ou depuração.
• Limites de taxa antes de alguém queimar sua conta de API: limitação de taxa por IP e por usuário em endpoints caros ou de autenticação. Retorne 429 com Retry-After.
• CORS é restrito: Access-Control-Allow-Origin não é *. Pré-voo é necessário para métodos que alteram estado.

7. Autenticação e Sessão

• Política de senha: mínimo de 8 caracteres, sem comprimento máximo que impeça frases-senha.
• Proteção contra força bruta: backoff exponencial ou CAPTCHA após logins com falha.
• Gerenciamento de sessão: cookies secure, httpOnly, SameSite. JWTs com expiração curta e rotação de refresh.
• Redefinição de senha: tokens são de uso único, aleatórios e expiram rapidamente.

---

8. Segurança do Provedor de Nuvem

Aplica-se a AWS, GCP, Azure e qualquer outra plataforma de nuvem.

8.1 Gerenciamento de Identidade e Acesso (IAM)

• Nenhuma chave de acesso da conta raiz existe. MFA da raiz está habilitado.
• Princípio do menor privilégio: cada função, usuário e conta de serviço tem as permissões mínimas necessárias. Nenhuma ação ou recurso curinga (*) a menos que absolutamente necessário.
• Nenhuma chave de acesso de longa duração para usuários. Prefira funções IAM com credenciais temporárias (STS, perfis de instância, identidade de workload).
• MFA aplicado para todos os usuários humanos, especialmente administradores e acesso de cobrança.
• Identidades inativas removidas: exclua ou desabilite usuários, funções e contas de serviço não utilizados por 90+ dias.
• Acesso entre contas usa suposições de função explícitas com ID externo quando aplicável. Sem políticas de confiança com Principal: *.

8.2 Armazenamento (S3 / GCS / Azure Blob)

• Nenhum bucket/container público a menos que esteja propositalmente hospedando ativos estáticos públicos. Bloqueie acesso público no nível da conta.
• Criptografia em repouso habilitada (AES-256 ou KMS). Sem volumes de armazenamento ou snapshots não criptografados.
• Criptografia em trânsito aplicada (apenas HTTPS/TLS). Nenhum http permitido.
• Políticas de ciclo de vida excluem ou transitam dados antigos. Versionamento habilitado para buckets críticos.
• Políticas de bucket não concedem Principal: * ou AllUsers. O acesso é via funções IAM, não chaves codificadas.
• Logging habilitado para logs de acesso e eventos em nível de objeto (S3 Server Access Logs, eventos de dados CloudTrail).

8.3 Computação (EC2 / GCE / Azure VM / Lambda / Cloud Run)

• Nenhum grupo de segurança padrão permitindo 0.0.0.0/0 em portas sensíveis (22, 3389, 3306, 5432, 6379, 27017).
• SSM / Session Manager usado em vez de SSH direto quando possível. Nenhuma porta 22 aberta para a internet.
• IMDSv2 obrigatório no AWS EC2 (desabilite IMDSv1).
• Metadados de instância não são expostos a containers ou código não confiável.
• Runtime de função usa privilégios mínimos. Lambda/GCP Cloud Functions não executam com funções de admin.
• Variáveis de ambiente de função não contêm segredos em texto simples. Use gerenciador de segredos (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).

8.4 Banco de Dados e Cache

• Nenhum acesso público: bancos de dados estão em subnets privadas ou VPCs. Nenhum 0.0.0.0/0 em grupos de segurança.
• Criptografia em repouso e em trânsito habilitada.
• Backups automatizados com recuperação pontual.
• Autenticação forte: sem senhas padrão. Use autenticação de banco de dados IAM ou certificados de cliente TLS quando suportado.
• Logging de auditoria habilitado para conexões e alterações de esquema.

8.5 Rede

• VPC / segmentação de rede: produção, staging e desenvolvimento estão em redes separadas ou pelo menos subnets separadas.
• Grupos de segurança / firewalls são negar por padrão. Apenas portas necessárias estão abertas.
• Nenhum CIDR excessivamente permissivo: 0.0.0.0/0 é evitado, exceto para HTTPS (443) em balanceadores de carga públicos.
• Subnets privadas para bancos de dados, caches e serviços internos. NAT Gateway ou endpoints VPC para internet de saída.
• Proteção DDoS habilitada quando aplicável (AWS Shield, Cloud Armor, Azure DDoS Protection).
• DNS / Domínio: DNSSEC habilitado se o registrador suportar. Nenhum registro DNS pendente apontando para IPs expirados ou recursos excluídos (risco de takeover de subdomínio).

8.6 Logging, Monitoramento e Alertas

• CloudTrail / Audit Logs / Activity Logs habilitados em todas as regiões e serviços.
• Integridade dos logs: logs são imutáveis ou armazenados em uma conta separada com permissões de escrita única.
• Dados sensíveis não registrados: logs da nuvem não incluem senhas, tokens ou PII.
• Alertas configurados para login de raiz, alterações de política IAM, criação de bucket público, alterações em grupo de segurança e picos de autenticação com falha.
• Retenção de logs atende aos requisitos de conformidade (normalmente 1 ano).

---

9. Segurança de Container e Orquestração

9.1 Docker / Imagens de Container

• Nenhum segredo em imagens: escaneie Dockerfiles e camadas por .env, config.json ou credenciais codificadas.
• Imagens base mínimas: use distroless, Alpine ou scratch em vez de Ubuntu/Debian completo quando possível.
• Nenhuma execução como root: Dockerfile define USER para um UID/GID não root.
• Varredura de imagem: habilite varredura de vulnerabilidades no registro (ECR, GCR, ACR, Docker Hub) e bloqueie CVEs críticas no CI.
• Tags imutáveis: não use latest em produção. Fixe no digest ou semver específico.
• Builds multi-estágio: artefatos de build e dependências de desenvolvimento não vão para a imagem final.

9.2 Kubernetes

• RBAC: funções e bindings de menor privilégio. Nenhum cluster-admin para contas de serviço.
• Nenhum token de conta de serviço padrão montado em pods que não precisam deles (automountServiceAccountToken: false).
• Políticas de rede: deny padrão para ingress/egress, depois permita explicitamente o tráfego necessário.
• Padrões de segurança de pod: aplique perfil restricted ou baseline. Nenhum container privilegiado, nenhum hostPath, nenhum hostNetwork.
• Criptografia de segredos: criptografia etcd em repouso habilitada. Nenhum segredo em texto simples no Git.
• Segurança de runtime de container: perfis seccomp, AppArmor ou SELinux aplicados.
• Controladores de admissão: use OPA/Gatekeeper ou Kyverno para aplicar políticas (sem tag latest, labels obrigatórios, limites de recursos).
• Limites de recursos: todo pod tem limites de CPU e memória para prevenir DoS por exaustão de recursos.

---

10. Infraestrutura como Código (IaC)

• Nenhum segredo em Terraform / CloudFormation / Pulumi / CDK: arquivos de estado não contêm senhas ou chaves em texto simples. O estado remoto é criptografado e com controle de acesso.
• Backend de estado do Terraform é seguro: S3 com SSE-KMS, bloqueio DynamoDB e sem acesso de leitura público.
• Varredura de IaC: execute checkov, tfsec ou terrascan em Terraform/CloudFormation antes do merge.
• Detecção de drift: varreduras programadas detectam alterações manuais no console que divergem do IaC.
• Módulos têm versão fixa: não puxe módulos de branches ou fontes sem versão.

Varredura rápida de IaC:

python3 scripts/scan_iac.py .

# Ou use ferramentas dedicadas se instaladas:
checkov -d . --framework terraform,cloudformation,dockerfile
# tfsec .

---

11. Segurança do Pipeline CI/CD

• Nenhum segredo em configurações de pipeline: sem tokens codificados em .github/workflows, .gitlab-ci.yml, Azure Pipelines ou Jenkinsfiles.
• Segredos são injetados do gerenciador de segredos nativo da plataforma CI (GitHub Secrets, GitLab CI Variables, Azure DevOps Library).
• Permissões do pipeline são mínimas: contas de serviço de CI têm apenas as permissões necessárias para implantar.
• Proteção de branch: pushes diretos para main/master são bloqueados. Todas as alterações exigem PR/MR + revisão.
• Commits assinados ou requisitos de merge: exija commits assinados ou pelo menos commits de merge verificados para repositórios sensíveis.
• Varredura de dependências: ferramentas SCA (Snyk, Dependabot, Renovate) executam em cada PR.
• SAST: análise estática (Semgrep, CodeQL, SonarQube) executa em cada PR.
• Varredura de container: imagens são escaneadas por CVEs antes da implantação.
• Nenhum runner auto-hospedado exposto à internet pública sem VPN ou lista de permissão de IP.
• Pipeline não executa código não confiável de forks sem aprovação manual (previna pwn requests).

---

12. Segurança de Domínio e DNS

• DNSSEC habilitado no registrador se suportado.
• Nenhum registro CNAME / A / NS pendente apontando para serviços expirados (risco de takeover de subdomínio).
• Certificados curinga ou certificados por assunto de uma CA confiável. Nenhum certificado autoassinado em produção.
• Monitoramento de expiração de certificado: alertas 30 e 7 dias antes da expiração.
• CDN / WAF configurado com regras sensatas (bloqueios SQLi, XSS, LFI). Limitação de taxa habilitada na borda.

---

Saída da Auditoria

Após executar a lista de verificação, produza um relatório conciso em markdown com:

1. Resumo — Passou / Falhou / Precisa de Revisão por categoria.
2. Descobertas críticas — Qualquer coisa que precise ser corrigida antes da produção.
3. Correções recomendadas — Alterações específicas de código, atualizações de configuração ou upgrades de bibliotecas.
4. Matriz de risco — Probabilidade × Impacto para cada descoberta.
5. Cronograma de remediação — Sugira ordem de prioridade e prazos.