← Voltar para central legal
Documento de Compliance

Segurança da Informação

Vigência atual. Atualizações são publicadas com 30 dias de antecedência via e-mail e no painel administrativo.

📌 Versão 1.0 📅 Vigente desde abril/2026 📧 dpo@cataloga.ai

Plano de Segurança da Informação — Cataloga-ai

Versão: 1.0

Data: 2026-04-25

Responsável: Cyber Head

Stack: Supabase self-hosted, Vercel, Redis, Asaas, GPTMaker, WhatsApp Cloud API

1. Política de Senhas

Requisitos Obrigatórios

Comprimento e Complexidade:

Rotação:

Armazenamento:

Como Implementar

No Supabase Auth:


-- Configurar política de senha forte no Supabase Auth
-- Em /supabase/config.toml:
[auth]
  minimum_password_length = 14
  password_required_characters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*"

Validação no Frontend (Vercel Edge Functions):


import zxcvbn from 'zxcvbn';

export function validatePassword(password: string): { valid: boolean; errors: string[] } {
  const errors: string[] = [];
  
  if (password.length < 14) {
    errors.push('Senha deve ter no mínimo 14 caracteres');
  }
  
  if (!/[a-z]/.test(password)) errors.push('Falta letra minúscula');
  if (!/[A-Z]/.test(password)) errors.push('Falta letra maiúscula');
  if (!/[0-9]/.test(password)) errors.push('Falta número');
  if (!/[!@#$%^&*()_+\-=\[\]{};':"\\|,.<>\/?]/.test(password)) {
    errors.push('Falta caractere especial');
  }
  
  const strength = zxcvbn(password);
  if (strength.score < 3) {
    errors.push(`Senha muito fraca (score ${strength.score}/4)`);
  }
  
  return { valid: errors.length === 0, errors };
}

Lista de senhas proibidas:

Ferramentas Recomendadas:

2. Política de Acesso (Least-Privilege)

Princípios

  1. Acesso mínimo necessário: usuário só acessa o que precisa para sua função
  2. Zero trust: sempre autenticar, sempre autorizar
  3. MFA obrigatório para contas administrativas
  4. Segregação de ambientes: dev/staging/prod com credenciais distintas

Roles e Permissões

Supabase (PostgreSQL RLS)

Roles principais:

Row Level Security (RLS):


-- Exemplo: lojista só acessa seus próprios produtos
CREATE POLICY "Lojistas veem apenas seus produtos"
  ON produtos
  FOR SELECT
  TO authenticated
  USING (auth.uid() = lojista_id);

-- Exemplo: consumidor final não acessa diretamente tabela de pedidos
CREATE POLICY "Consumidores não acessam pedidos diretamente"
  ON pedidos
  FOR ALL
  TO anon
  USING (false);

MFA Obrigatório:


// Vercel Edge Function — middleware de MFA enforcement
export async function middleware(req: Request) {
  const user = await supabase.auth.getUser();
  const isAdmin = user.app_metadata.role === 'admin';
  const hasMFA = user.app_metadata.mfa_enabled;
  
  if (isAdmin && !hasMFA) {
    return new Response('MFA obrigatório para admins', { status: 403 });
  }
}

Vercel (Projetos e Ambientes)

Ambientes:

Variáveis de ambiente sensíveis:

Ferramentas:

Redis

Autenticação:

Exemplo ACL Redis 6+:


# User para Vercel Edge Functions (só cache de sessão)
ACL SETUSER vercel_edge on >SenhaForte123! ~session:* +get +set +del

# User para worker de jobs (só filas)
ACL SETUSER worker_jobs on >OutraSenha456! ~queue:* +rpush +blpop +llen

# Admin (full access)
ACL SETUSER admin on >AdminSecure789! ~* &* +@all

Ferramentas:

Como Implementar MFA

Supabase Auth:


// Ativar MFA para um usuário
const { data, error } = await supabase.auth.mfa.enroll({
  factorType: 'totp',
});

// Verificar MFA no login
const { data, error } = await supabase.auth.mfa.challenge({
  factorId: data.id,
});

const { data: verifyData, error: verifyError } = await supabase.auth.mfa.verify({
  factorId: data.id,
  challengeId: challengeData.id,
  code: '123456', // código do app TOTP
});

Apps TOTP recomendados:

Fallback (recovery codes):

3. Backup + Disaster Recovery

Requisitos

RTO (Recovery Time Objective): 4 horas

RPO (Recovery Point Objective): 1 hora (máximo perda de dados tolerável)

Estratégia de Backup

PostgreSQL (Supabase Self-Hosted)

Frequência:

Retenção:

Onde armazenar:

Ferramentas:


#!/bin/bash
# /opt/scripts/postgres-backup.sh

set -euo pipefail

BACKUP_DIR="/backups/postgres"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
S3_BUCKET="s3://cataloga-ai-backups-prod"

# Full backup
pg_basebackup -h localhost -U postgres -D "$BACKUP_DIR/$TIMESTAMP" -Ft -z -P

# Upload para S3
aws s3 sync "$BACKUP_DIR/$TIMESTAMP" "$S3_BUCKET/postgres/$TIMESTAMP/" \
  --sse AES256 \
  --storage-class STANDARD_IA

# Limpar backups locais > 7 dias
find "$BACKUP_DIR" -type d -mtime +7 -exec rm -rf {} +

# Log
echo "Backup concluído: $TIMESTAMP" >> /var/log/postgres-backup.log

Cron:


0 2 * * * /opt/scripts/postgres-backup.sh

Redis

Frequência:

Configuração redis.conf:


# RDB
save 3600 1
save 300 100
save 60 10000

# AOF
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Backup de RDB/AOF:


#!/bin/bash
# /opt/scripts/redis-backup.sh

REDIS_DATA="/var/lib/redis"
BACKUP_DIR="/backups/redis"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Trigger BGSAVE
redis-cli BGSAVE

# Aguardar conclusão
while [ $(redis-cli LASTSAVE) -eq $LAST_SAVE ]; do
  sleep 1
done

# Copiar RDB
cp "$REDIS_DATA/dump.rdb" "$BACKUP_DIR/dump-$TIMESTAMP.rdb"

# Upload S3
aws s3 cp "$BACKUP_DIR/dump-$TIMESTAMP.rdb" \
  "s3://cataloga-ai-backups-prod/redis/dump-$TIMESTAMP.rdb" \
  --sse AES256

Vercel (Edge Functions + Configuração)

Código:

Configuração (Variáveis de Ambiente):


vercel env pull .env.production.backup
gpg --encrypt --recipient admin@cataloga-ai.com.br .env.production.backup
aws s3 cp .env.production.backup.gpg s3://cataloga-ai-backups-prod/vercel/

Restore Testing

Frequência: mensal (primeira segunda-feira de cada mês)

Procedimento:

  1. Provisionar ambiente de staging isolado
  2. Restaurar último full backup do PostgreSQL
  3. Aplicar WAL incrementais até ponto específico no tempo (PITR)
  4. Validar integridade:
  1. Testar restore do Redis (carregar RDB, validar keys críticas)
  2. Documentar tempo de restore e issues encontrados
  3. Destruir ambiente de teste

SLA de Restore:

Ferramentas:

4. Criptografia

Nota: Esta seção foi desenvolvida em colaboração com o Cryptography Counsel para garantir conformidade com melhores práticas criptográficas.

Em Trânsito (TLS)

Requisitos:

Configuração Nginx (Supabase Self-Hosted):


server {
  listen 443 ssl http2;
  server_name api.cataloga-ai.com.br;

  ssl_protocols TLSv1.3 TLSv1.2;
  ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
  ssl_prefer_server_ciphers on;
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:50m;
  ssl_session_tickets off;

  # HSTS (15768000 = 6 meses)
  add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" always;

  ssl_certificate /etc/letsencrypt/live/api.cataloga-ai.com.br/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/api.cataloga-ai.com.br/privkey.pem;
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/api.cataloga-ai.com.br/chain.pem;

  location / {
    proxy_pass http://localhost:3000;
  }
}

Verificação:


# Testar ciphers
nmap --script ssl-enum-ciphers -p 443 api.cataloga-ai.com.br

# SSL Labs (online)
# https://www.ssllabs.com/ssltest/analyze.html?d=api.cataloga-ai.com.br

Alvo: A+ no SSL Labs

Redis TLS:


# redis.conf
tls-port 6380
port 0
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-protocols "TLSv1.2 TLSv1.3"

Em Repouso (AES-256)

PostgreSQL (Supabase)

Opções:

  1. Disk encryption (LUKS):

# Criptografar volume de dados
cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb postgres_data
mkfs.ext4 /dev/mapper/postgres_data
mount /dev/mapper/postgres_data /var/lib/postgresql
  1. PostgreSQL pgcrypto (column-level):

-- Para campos ultra-sensíveis (CPF, cartão de crédito)
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Inserir dados criptografados
INSERT INTO usuarios (nome, cpf_encrypted)
VALUES ('João', pgp_sym_encrypt('12345678901', 'chave-secreta-do-vault'));

-- Ler dados
SELECT nome, pgp_sym_decrypt(cpf_encrypted::bytea, 'chave-secreta-do-vault') AS cpf
FROM usuarios;

Recomendação: LUKS para proteção de volume + pgcrypto para campos PII críticos.

Backups


# Exemplo GPG
tar czf - /backups/postgres/$TIMESTAMP | \
  gpg --encrypt --recipient backup@cataloga-ai.com.br | \
  aws s3 cp - s3://cataloga-ai-backups-prod/postgres/$TIMESTAMP.tar.gz.gpg

Secrets Management

Proibido:

Permitido:

  1. HashiCorp Vault (recomendado para prod):

# Armazenar secret
vault kv put secret/cataloga-ai/prod/database password="SuperSecurePass123!"

# Ler secret (em runtime)
export DB_PASSWORD=$(vault kv get -field=password secret/cataloga-ai/prod/database)
  1. Vercel Environment Variables (com criptografia nativa):
  1. Doppler (alternativa SaaS):

Key Rotation (ver próxima seção para detalhes):

Ferramentas Recomendadas

5. Gestão de Chaves

Princípios

  1. Nunca em código: chaves nunca commitadas no Git
  2. Segregação: chaves de dev ≠ staging ≠ prod
  3. Rotação regular: minimizar janela de exploração se vazar
  4. Acesso auditado: log de quem acessou qual chave, quando

Onde Armazenar Chaves

Tipo de Chave Onde Armazenar Rotação
Database password Vault (prod) / Vercel Env Vars (edge functions) 180 dias
Redis password Vault 180 dias
API keys (Asaas, GPTMaker) Vault / Vercel Env Vars 180 dias
JWT signing key (Supabase) Vault 365 dias
Encryption keys (pgcrypto) Vault (nunca em DB) 365 dias
TLS private keys Servidor (permission 600, root-only) Renovação cert (90 dias Let's Encrypt)
GPG keys (backup encryption) Password manager (1Password Team) 2 anos

Rotação de Chaves

Senha do PostgreSQL

Procedimento:

  1. Gerar nova senha forte (32 chars)

NEW_PASSWORD=$(openssl rand -base64 32)
  1. Atualizar senha no PostgreSQL

ALTER USER cataloga_ai_prod WITH PASSWORD 'nova-senha-aqui';
  1. Atualizar Vault

vault kv put secret/cataloga-ai/prod/database password="$NEW_PASSWORD"
  1. Atualizar Vercel Env Vars (se Vercel acessa DB diretamente)

vercel env add DATABASE_PASSWORD production
# Colar nova senha quando solicitado
  1. Restart gradual de serviços (zero-downtime)
  1. Validar conectividade

psql "postgresql://cataloga_ai_prod:$NEW_PASSWORD@localhost:5432/cataloga_ai"
  1. Revogar senha antiga (já feito no passo 2, mas confirmar)

API Keys de Terceiros (Asaas, GPTMaker, WhatsApp)

Asaas:

  1. Gerar nova API key no dashboard Asaas
  2. Testar em staging
  3. Atualizar Vault/Vercel
  4. Deploy
  5. Revogar chave antiga no dashboard Asaas após 24h (janela de grace)

WhatsApp Cloud API:

JWT Signing Key (Supabase Auth)

Atenção: rotacionar esta chave invalida todas sessões ativas.

Procedimento (maintenance window):

  1. Anunciar manutenção (15min downtime ou force logout)
  2. Gerar nova chave

NEW_JWT_SECRET=$(openssl rand -base64 64)
  1. Atualizar config.toml do Supabase:

[auth]
  jwt_secret = "nova-chave-aqui"
  1. Restart Supabase Auth
  2. Todos usuários precisam fazer login novamente
  3. Comunicar via email/in-app notification

Frequência: anual ou em caso de vazamento

Revogação de Chaves

Gatilhos:

Checklist de Revogação:

  1. Identificar todas chaves acessíveis pela pessoa/sistema comprometido
  2. Gerar novas chaves para substituição
  3. Atualizar secrets em Vault/Vercel
  4. Deploy atômico (ou maintenance window se breaking)
  5. Revogar chaves antigas em sistemas terceiros (dashboards de API)
  6. Validar que serviços continuam funcionando
  7. Documentar incidente em log de auditoria

Auditoria de Acesso a Chaves

Vault Audit Log:


# Habilitar audit log no Vault
vault audit enable file file_path=/var/log/vault-audit.log

# Consultar quem acessou um secret
grep "secret/cataloga-ai/prod/database" /var/log/vault-audit.log

Vercel:

Alertas:

Ferramentas

6. Logs de Auditoria

O Que Logar

Eventos de Autenticação

Eventos de Acesso a Dados

Eventos de Mutação Crítica

Eventos Administrativos

Formato de Log (JSON estruturado)

Exemplo:


{
  "timestamp": "2026-04-25T21:45:32.123Z",
  "event_type": "auth.login.success",
  "user_id": "550e8400-e29b-41d4-a716-446655440000",
  "email": "lojista@example.com",
  "ip_address": "203.0.113.42",
  "user_agent": "Mozilla/5.0 ...",
  "session_id": "abc123",
  "mfa_used": true,
  "country_code": "BR",
  "severity": "info"
}


{
  "timestamp": "2026-04-25T21:50:15.456Z",
  "event_type": "data.access.pii",
  "user_id": "admin-user-id",
  "action": "SELECT",
  "table": "usuarios",
  "query_hash": "sha256-of-query",
  "rows_affected": 1,
  "ip_address": "10.0.1.5",
  "severity": "warning",
  "reason": "Suporte N3 acessou dados de usuário para investigação de bug"
}

Onde Armazenar Logs

Stack de Logging:

  1. Aplicação → stdout/stderr (Vercel Edge Functions, Supabase)
  2. Collector: Vector.dev ou Fluent Bit (agregação + parsing)
  3. Storage:

Configuração Vector.dev:


# /etc/vector/vector.toml

[sources.vercel_logs]
  type = "http"
  address = "0.0.0.0:8080"
  encoding = "json"

[sources.supabase_logs]
  type = "file"
  include = ["/var/log/supabase/*.log"]
  encoding = "json"

[transforms.parse_audit]
  type = "remap"
  inputs = ["vercel_logs", "supabase_logs"]
  source = '''
    .timestamp = parse_timestamp!(.timestamp, "%Y-%m-%dT%H:%M:%S%.fZ")
    .severity = downcase!(.severity)
    if .event_type == "auth.login.failed" {
      .alert = true
    }
  '''

[sinks.elasticsearch]
  type = "elasticsearch"
  inputs = ["parse_audit"]
  endpoints = ["http://localhost:9200"]
  index = "cataloga-ai-audit-%Y.%m"
  compression = "gzip"

[sinks.s3_archive]
  type = "aws_s3"
  inputs = ["parse_audit"]
  bucket = "cataloga-ai-audit-logs"
  key_prefix = "year=%Y/month=%m/day=%d/"
  compression = "gzip"
  encoding.codec = "json"

Retenção

Tipo de Log Retenção Hot Retenção Total Justificativa
Auth events 30 dias 2 anos LGPD Art. 37: evidência de consentimento e acesso
Data access (PII) 30 dias 7 anos Auditoria de compliance + investigações futuras
Mutations críticas 90 dias 7 anos Rastreabilidade de transações financeiras
Application logs (debug) 7 dias 30 dias Troubleshooting; sem PII
Admin actions 90 dias 5 anos Auditoria interna + investigações

Monitoramento de Anomalias

Alertas Automáticos (SIEM):

  1. Múltiplos logins falhados (brute-force):
  1. Login de localização anômala:
  1. Acesso em massa a PII:
  1. Mudança de role para admin:
  1. Download de dump de banco:

Ferramentas SIEM:

Exemplo ElastAlert Rule:


# /etc/elastalert/rules/brute_force_login.yaml

name: Brute Force Login Attempt
type: frequency
index: cataloga-ai-audit-*
num_events: 5
timeframe:
  minutes: 5
filter:
- term:
    event_type: "auth.login.failed"
query_key: "ip_address"
alert:
- slack
slack_webhook_url: "https://hooks.slack.com/services/YOUR/WEBHOOK"
slack_title: "🚨 Brute Force Detected"
slack_text: |
  IP: {0}
  Failed logins: {1} in 5 minutes

Integridade de Logs (Proteção Contra Adulteração)

Problema: atacante com acesso root pode modificar logs para ocultar rastros.

Solução:

  1. Forward-only logging: logs enviados para collector remoto em tempo real (atacante não tem acesso)
  2. Assinatura de logs: cada linha de log recebe hash SHA-256 encadeado
  3. Append-only storage: S3 com versionamento + Glacier Vault Lock (imutável)

Exemplo de Hash Encadeado:


{
  "timestamp": "2026-04-25T22:00:00.000Z",
  "event_type": "auth.login.success",
  "user_id": "user-123",
  "log_hash": "sha256-of-this-log-entry",
  "previous_log_hash": "sha256-of-previous-entry"
}

Se atacante alterar uma linha, previous_log_hash da próxima linha não baterá → adulteração detectada.

Ferramentas Recomendadas

7. Hardening de Servidor (Supabase Self-Hosted)

Princípios

  1. Minimizar superfície de ataque: desabilitar serviços desnecessários
  2. Firewall restritivo: só portas essenciais abertas
  3. Atualizações regulares: patches de segurança aplicados em < 48h (critical) / < 7 dias (high)
  4. Monitoramento ativo: detectar intrusões em tempo real

Configuração de Portas e Firewall

Portas Necessárias:

Serviço Porta Origem Permitida Protocolo
PostgreSQL 5432 VPC interna apenas (10.0.0.0/8) TCP
Redis 6379/6380 (TLS) VPC interna TCP
Supabase API (Kong) 443 Internet (público) HTTPS
Supabase Studio (admin) 3000 VPN ou IPs de escritório HTTPS
SSH 22 IPs de SRE apenas (whitelist) TCP
Prometheus exporter 9100 Monitoring server TCP

Firewall (iptables):


#!/bin/bash
# /etc/iptables/rules.v4

# Flush existente
iptables -F

# Políticas padrão
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Permitir loopback
iptables -A INPUT -i lo -j ACCEPT

# Permitir conexões estabelecidas
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH (só de IPs autorizados)
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACCEPT  # IP do SRE 1
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.11 -j ACCEPT  # IP do SRE 2

# HTTPS (público)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# PostgreSQL (só VPC)
iptables -A INPUT -p tcp --dport 5432 -s 10.0.0.0/8 -j ACCEPT

# Redis TLS (só VPC)
iptables -A INPUT -p tcp --dport 6380 -s 10.0.0.0/8 -j ACCEPT

# Rate limiting (anti-DDoS básico)
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 1 --hitcount 20 -j DROP

# Log de DROP (debug)
iptables -A INPUT -j LOG --log-prefix "iptables-dropped: " --log-level 4

# Salvar
iptables-save > /etc/iptables/rules.v4

Firewall alternativo (UFW - mais simples):


# Resetar
ufw --force reset

# Padrão deny
ufw default deny incoming
ufw default allow outgoing

# SSH (whitelist)
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow from 203.0.113.11 to any port 22 proto tcp

# HTTPS
ufw allow 443/tcp

# PostgreSQL (VPC)
ufw allow from 10.0.0.0/8 to any port 5432 proto tcp

# Habilitar
ufw enable

Atualizações de OS

Sistema: Ubuntu Server 22.04 LTS (ou 24.04 LTS)

Política:

Automação (unattended-upgrades):


# Instalar
apt install unattended-upgrades

# Configurar /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
  "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::MinimalSteps "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";  # 3am UTC

Monitoramento de patches pendentes:


# Verificar updates disponíveis
apt list --upgradable

# Verificar apenas security
apt-cache policy | grep -i security

Alerta automático:


# Cron diário
0 8 * * * /usr/lib/update-notifier/apt-check --human-readable | mail -s "Updates disponíveis" sre@cataloga-ai.com.br

Hardening Adicional

Desabilitar Serviços Desnecessários


# Listar serviços rodando
systemctl list-units --type=service --state=running

# Desabilitar exemplos comuns desnecessários
systemctl disable bluetooth.service
systemctl disable cups.service  # impressão
systemctl disable avahi-daemon.service  # Zeroconf

Kernel Hardening (sysctl)


# /etc/sysctl.d/99-hardening.conf

# Proteção contra IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignorar ICMP redirects (anti-MITM)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Desabilitar source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Proteção SYN flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048

# Log de pacotes suspeitos
net.ipv4.conf.all.log_martians = 1

# Aplicar
sysctl -p /etc/sysctl.d/99-hardening.conf

SSH Hardening


# /etc/ssh/sshd_config

# Desabilitar root login direto
PermitRootLogin no

# Só key-based auth (sem senha)
PasswordAuthentication no
ChallengeResponseAuthentication no

# Protocolo 2 apenas (1 é inseguro)
Protocol 2

# Limitar usuários
AllowUsers sre-user1 sre-user2

# Port alternativo (obscurity, não segurança real, mas ajuda contra bots)
Port 2222

# Idle timeout
ClientAliveInterval 300
ClientAliveCountMax 2

# Reiniciar SSH
systemctl restart sshd

Fail2Ban (Anti Brute-Force)


# Instalar
apt install fail2ban

# Configurar /etc/fail2ban/jail.local
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port = 2222
logpath = /var/log/auth.log

[nginx-limit-req]
enabled = true
filter = nginx-limit-req
logpath = /var/log/nginx/error.log
maxretry = 3

# Iniciar
systemctl enable fail2ban
systemctl start fail2ban

Monitoramento de Intrusões (IDS)

AIDE (Advanced Intrusion Detection Environment):


# Instalar
apt install aide

# Inicializar baseline
aideinit

# Verificar mudanças (diário via cron)
aide --check | mail -s "AIDE Report" sre@cataloga-ai.com.br

OSSEC (Host-based IDS):

Ferramentas Recomendadas

8. Vulnerability Management

Processo de Scan Periódico

Frequência:

Ferramentas de Scan

Scan de Infraestrutura

OpenVAS (Open Vulnerability Assessment System):


# Instalar via Docker
docker run -d -p 443:443 --name openvas mikesplain/openvas

# Acessar https://localhost:443
# Criar target: api.cataloga-ai.com.br
# Rodar scan completo semanal

Nmap (network scan):


# Scan de portas abertas
nmap -sS -sV -O api.cataloga-ai.com.br

# Scan de vulnerabilidades (scripts NSE)
nmap --script vuln api.cataloga-ai.com.br

Scan de Aplicação

OWASP ZAP (Dynamic Application Security Testing - DAST):


# Rodar via Docker
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.cataloga-ai.com.br \
  -r zap-report.html

# Revisar relatório
# Gatilho: falhar CI/CD se severity >= High

Trivy (Container scan):


# Scan de imagem Docker do Supabase
trivy image supabase/postgres:15

# Scan de filesystem
trivy fs /var/lib/postgresql

Scan de Dependências

npm audit (Node.js):


# No projeto Vercel Edge Functions
npm audit --production

# Fix automático (cuidado com breaking changes)
npm audit fix

# CI/CD: falhar build se critical/high
npm audit --audit-level=high

Dependabot (GitHub):

Snyk (SaaS - alternativa):


# Instalar CLI
npm install -g snyk

# Autenticar
snyk auth

# Scan
snyk test

# Monitor contínuo
snyk monitor

Scan de Secrets (Leaked Credentials)

Gitleaks (secrets no Git):


# Scan de repositório
gitleaks detect --source . --verbose

# Pre-commit hook (prevenir commits com secrets)
# .git/hooks/pre-commit:
#!/bin/bash
gitleaks protect --staged --verbose --redact

TruffleHog (scan de histórico completo):


trufflehog git https://github.com/cataloga-ai/backend --only-verified

Classificação de Severidade

Severity CVSS Score Patching SLA Ação
Critical 9.0 - 10.0 24 horas Patch imediato, hotfix se necessário, comunicar stakeholders
High 7.0 - 8.9 7 dias Patch na próxima janela de manutenção, revisar mitigações temporárias
Medium 4.0 - 6.9 30 dias Incluir em roadmap de patches mensais
Low 0.1 - 3.9 90 dias Revisar em ciclo trimestral

Exceções: se vulnerabilidade não é explorável no nosso contexto (ex: Windows vulnerability em servidor Linux), pode ser marcada como wontfix com justificativa.

Workflow de Patching

  1. Detecção: Scan automático identifica CVE-2024-XXXXX em pacote libssl1.1
  2. Triagem: Security team avalia severidade (CVSS score) e exploitabilidade
  3. Priorização: Se critical, escala para SRE imediatamente; se high/medium, agenda
  4. Teste: Aplicar patch em ambiente de staging, validar que não quebra aplicação
  5. Deploy: Aplicar em produção (com rollback plan se der ruim)
  6. Verificação: Re-scan para confirmar que vulnerabilidade foi remediada
  7. Documentação: Registrar em ticket de patching (Jira/Linear) com CVE ID, ação tomada, timestamp

Mitigações Temporárias (Quando Patch Não Está Disponível)

Exemplos:

Responsible Disclosure (Recebimento de Vulnerabilidades Externas)

Canal: security@cataloga-ai.com.br

Página pública: https://cataloga-ai.com.br/security.txt (RFC 9116)


Contact: mailto:security@cataloga-ai.com.br
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: pt-BR, en
Canonical: https://cataloga-ai.com.br/.well-known/security.txt

Processo:

  1. Researcher reporta vulnerabilidade por email
  2. Security team confirma recebimento em < 24h
  3. Triagem: reproduzir + avaliar impacto
  4. Fix: desenvolver patch (SLA conforme severidade)
  5. Validação: testar com researcher se possível
  6. Deploy: aplicar em produção
  7. Disclosure: após fix, publicar advisory (opcional: Hall of Fame para researcher)
  8. Recompensa: se programa de bug bounty, pagar conforme tabela

Bug Bounty (Futuro):

Compliance e Auditoria

Relatórios mensais:

Dashboard (Grafana):


# Métrica Prometheus: vulnerabilities_detected_total{severity="critical"}
sum(vulnerabilities_detected_total{severity="critical"}) by (service)

KPIs:

Ferramentas Recomendadas

Camada Ferramenta Tipo Custo
Infraestrutura OpenVAS Open-source Grátis
Infraestrutura Nessus Comercial $$
Aplicação (DAST) OWASP ZAP Open-source Grátis
Aplicação (SAST) SonarQube Open-source/Comercial Grátis/$$$
Container Trivy Open-source Grátis
Dependências Dependabot Grátis (GitHub) Grátis
Dependências Snyk SaaS $ (free tier)
Secrets Gitleaks Open-source Grátis
Pen Test Externos Serviço $$$ (anual)

9. Anexos

Checklist de Implementação

Responsáveis

Seção Implementador Revisor Deadline Sugerido
1-2 (Auth + Access) Backend Lead Cyber Head Sprint 1 (2 semanas)
3 (Backup) SRE Lead Cyber Head Sprint 1
4-5 (Crypto + Keys) Cryptography Counsel Cyber Head Sprint 2 (2 semanas)
6 (Logs) Backend Lead + SRE Cyber Head Sprint 2
7 (Hardening) SRE Lead Cyber Head Sprint 3 (1 semana)
8 (Vuln Mgmt) DevSecOps Cyber Head Sprint 3

Custos Estimados (Mensal)

Item Ferramenta Custo Mensal
Secrets Management HashiCorp Vault Cloud (Starter) $40
Logging Elasticsearch (3 nodes, 50GB) $120
S3 Archive (500GB) AWS S3 Glacier $2
SIEM Wazuh (self-hosted) $0
Vulnerability Scan OpenVAS + Trivy (self-hosted) $0
Dependabot GitHub (incluído) $0
Backup Storage Backblaze B2 (1TB) $5
Total ~$167/mês

Custo anual de Pen Test externo: $3.000 - $5.000 (1x/ano)

Revisão e Atualização

Documento aprovado por:

[ ] Cyber Head

[ ] Cryptography Counsel (seção 4)

[ ] CTO

[ ] DPO (validação de compliance LGPD)

Próxima revisão agendada: 2026-07-25