Drift & Anomaly Detection

A partir da v4.5, o CipherVault detecta anomalias e drift em secrets, AppConnections e padrões de acesso. Funcionalidade equivalente ao HashiCorp Vault Radar.

Categorias detectadas

Tipo	O que detecta
Stale rotation	Secrets com last_rotated_at antigo demais conforme política do tenant
Unusual access pattern	Picos de leitura fora do baseline (24h moving window)
IP region anomaly	AppConnection acessada de região geográfica não vista nos últimos 30 dias
Drift no backend	dynamic_backends reconcile detecta usuários cv_* órfãos no DB
Privilege creep	Vault membership crescendo sem revisão (> N membros sem revisão > 90 dias)
Zombie AppConnection	AppConnection sem uso há > 60 dias mas ainda ativa
Risk score spike	Variação > 30 pontos no Risk Score em 24h

Endpoint principal

GET  /anomalies                        Lista anomalies ativas
GET  /anomalies/:id                    Detalhe + recomendação
POST /anomalies/:id/acknowledge        Marcar como triada
POST /anomalies/:id/dismiss            Falso positivo (com motivo)

Filtros: type, severity (low|medium|high|critical), tenant, since, status.

Exemplo

curl "https://cv.acme.com.br/anomalies?severity=high&status=open" \
  -H "Authorization: Bearer $CV_TOKEN"

{
  "anomalies": [
    {
      "id": "anom_01HXY...",
      "type": "unusual_access_pattern",
      "severity": "high",
      "resource": "vault/producao/api/stripe/secret_key",
      "detected_at": "2026-05-12T14:23:11Z",
      "baseline": { "reads_per_hour_p95": 12 },
      "observed": { "reads_per_hour_last": 87 },
      "recommendation": "Investigar acessos via /audit?resource=...&from=...",
      "status": "open"
    }
  ],
  "total": 1
}

Scheduler

Background job roda a cada 24h (padrão; configurável via ANOMALY_SCHEDULER_INTERVAL_HOURS):

1. Para cada tenant ativo:
   • Compute baselines (média + p95 dos últimos 30 dias)
   • Compare observação atual contra baseline
   • Gera anomaly se desvio > threshold
2. Insere em tabela anomalies com status=open
3. Dispara webhook anomaly.detected se configurado

Webhooks

Configure em Settings → Webhooks ou via API:

curl -X POST https://cv.acme.com.br/webhooks \
  -d '{
    "url": "https://hooks.acme.com.br/security",
    "events": ["anomaly.detected"],
    "min_severity": "high"
  }'

Payload:

{
  "event": "anomaly.detected",
  "anomaly": { ... },
  "tenant": "...",
  "timestamp": "..."
}

Integration com Risk Scoring

Anomalies em secrets aumentam temporariamente o Risk Score do secret afetado (+10 pts por anomaly high, +20 pts por critical). Score volta ao baseline 7 dias após anomaly dismissed ou resolved.

Acknowledge vs Dismiss

Ação	Quando usar	Efeito
acknowledge	"Eu vi, estou investigando"	Tira da inbox padrão; baseline NÃO é recalculado
dismiss	"Falso positivo / esperado"	Adiciona ao training-set negativo; baseline incorpora

Anomalies não-acionadas em > 30 dias são auto-resolved (assumindo que o padrão se normalizou).

Tabelas

• anomalies — eventos detectados, status lifecycle
• anomaly_baselines — moving averages por tenant + resource + métrica
• anomaly_training_set — dismissed false-positives para fine-tuning

Métricas Prometheus

cv_anomalies_detected_total{type, severity}
cv_anomalies_open                                  gauge
cv_anomaly_scheduler_duration_seconds              histogram
cv_anomaly_false_positive_rate                     gauge

Boas práticas

• Configure webhooks pra severity >= high apenas — medium/low viram noise
• Revise dismisseds trimestralmente — dismiss excessivo treina o sistema a ignorar comportamento real malicioso
• Combine com Attack Paths — anomaly em secret crítico → revisar grafo
• Threshold por tenant — tenants enterprise podem ter thresholds mais sensíveis (ANOMALY_THRESHOLD_OVERRIDE em tenant config)
• Não substitui SIEM — anomaly detection do CV é específico do produto. Continue exportando audit logs pra SIEM/UEBA externo