Retenção de dados
A retenção de dados define por quanto tempo cada tipo de dado fica guardado na plataforma antes de ser apagado automaticamente. Você configura prazos diferentes para cada tipo de dado (eventos em quarentena, campos novos detectados, histórico, resultados de busca) e a plataforma faz a limpeza sozinha, todos os dias.
Quem opera só pela interface não precisa rodar nenhuma rotina manual: basta definir os prazos e a plataforma cuida do resto.
Quando usar
- Cumprir política de descarte da sua organização (LGPD/GDPR): sua empresa exige que dados operacionais sejam apagados após um prazo definido. Você ajusta os dias de cada tipo de dado para ficar dentro da política.
- Reduzir custo de armazenamento: dados antigos que ninguém mais consulta continuam ocupando espaço. Encurtar o prazo de quarentena ou de resultados de busca libera espaço e reduz custo.
- Limitar a janela de exposição de dados sensíveis: quanto menos tempo um evento sensível fica armazenado, menor o risco em caso de incidente. Você reduz o prazo para diminuir essa janela.
Política padrão
Toda organização nova começa com estes prazos. Eles servem para a maioria dos casos e podem ser ajustados (exceto os logs de auditoria, que têm mínimo obrigatório).
| Tipo de dado | Retenção padrão | Por quê |
|---|---|---|
| Quarentena | 7 dias | Eventos que falharam no processamento; histórico longo raramente é útil. |
| Campos novos detectados (drift) | 90 dias | Descoberta de novos campos; menos urgente, vale manter por mais tempo. |
| Histórico | 30 dias | Registro de atividades da plataforma. |
| Resultados de busca | 7 dias | Cache de buscas; pode ser recalculado a qualquer momento. |
| Logs de auditoria | 365 dias (mínimo fixo) | Exigência de compliance (LGPD/GDPR): pelo menos 1 ano, e não podem ser apagados antes disso. |
Configurar a retenção de uma organização
Cada organização pode ter seus próprios prazos, sobrescrevendo os padrões. Esta configuração é de administrador.
A configuração de retenção por organização existe na plataforma, mas não foi exposta na interface — não há área de retenção em Administração → Organizações. Enquanto ela não chega, o ajuste é feito pela API, por quem tem permissão de administrar organizações.
Passo a passo
Peça ao administrador da plataforma para aplicar os prazos com PATCH /api/organizations/{id}/retention, enviando apenas os campos que mudam:
| Campo | Limites |
|---|---|
quarantine_retention_days | entre 1 e 3650 |
drift_retention_days (campos novos) | entre 1 e 3650 |
history_retention_days | entre 1 e 3650 |
search_result_retention_days | entre 1 e 3650 |
audit_log_retention_days | fixo em pelo menos 365; não pode ser reduzido |
A alteração exige permissão de administrar organizações e fica registrada no log de auditoria. Consultar os prazos vigentes é o GET do mesmo caminho.
Regras de validação
- O mínimo é 1 dia e o máximo é 3650 dias (10 anos).
- Os logs de auditoria nunca podem ficar abaixo de 365 dias, por exigência de compliance.
Os novos prazos passam a valer na próxima limpeza automática (uma vez por dia). Não é preciso fazer mais nada.
Como a limpeza acontece
A plataforma roda uma limpeza automática uma vez por dia, em segundo plano. Em cada execução, ela apaga os dados que já passaram do prazo configurado para cada tipo. Você não precisa iniciar nada manualmente.
A limpeza é rápida e não interrompe o uso da plataforma: você continua buscando, investigando e operando normalmente enquanto ela ocorre.
Retenção nos destinos de entrega
Além das prazos internos, cada destino para onde os dados são entregues pode ter sua própria política de retenção, independente da plataforma. Isso permite manter cópias com prazos diferentes em lugares diferentes.
| Tipo de destino | Quem controla a retenção |
|---|---|
| Armazenamento de longa duração (object-store / S3, usado como cópia "fria" e completa) | A plataforma aplica a limpeza automática com base nos dias configurados para aquele destino. |
| SIEMs e barramentos (Sentinel, Kafka, Splunk, Elastic, syslog, etc.) | O próprio sistema de destino gerencia a retenção do seu lado. A plataforma não apaga dados lá. |
Padrão comum: cópia curta no SIEM, cópia longa no armazenamento
Um arranjo típico usa o Roteamento para enviar o mesmo dado a destinos com prazos diferentes:
- Eventos mais críticos vão para um SIEM com retenção curta (por exemplo, 30 dias), para análise imediata.
- Os demais eventos vão para um armazenamento de longa duração com retenção longa (por exemplo, 2 anos), como arquivo histórico.
Para montar esse arranjo, configure as regras na tela de Rotas e o prazo de cada destino na tela de Destinos. A remoção de dados sensíveis (redação de PII) também é configurada por rota — veja Roteamento.
Para definir o prazo de retenção de um destino de armazenamento, abra Roteia → Destinos, selecione o destino e ajuste o prazo de retenção. Destinos sem essa opção (SIEMs, barramentos) gerenciam a retenção pelo próprio lado.
Conferir que a política está ativa e funcionando
Confirmar os prazos configurados
Consulte GET /api/organizations/{id}/retention. São esses os prazos que a limpeza diária aplica. Uma organização que nunca teve retenção configurada responde com os padrões da tabela acima.
Ver quem alterou a retenção e quando
Toda mudança de prazo fica registrada. Para auditar:
- Abra Visão geral → Histórico.
- Localize os registros de alteração da configuração de retenção. Cada registro mostra quem alterou, qual organização e os novos valores.
Se dados antigos ainda aparecem
Se você esperava que certos dados já tivessem sumido e eles continuam aparecendo:
- Confira o prazo configurado (
GET /api/organizations/{id}/retention). Um prazo maior do que o esperado (por exemplo, 365 em vez de 30 dias) faz os dados ficarem mais tempo. - Lembre-se de que a limpeza roda uma vez por dia. Dados que acabaram de vencer só somem na próxima execução diária.
- Para objetos antigos em um destino de armazenamento, confirme em Roteia → Destinos que aquele destino tem um prazo de retenção definido. Sem prazo definido, a plataforma não apaga nada lá.
- Se mesmo assim os dados persistirem além do prazo, fale com o administrador da plataforma.
Retenção e compliance
LGPD / GDPR
- Direito ao esquecimento: ao atender a um pedido de exclusão, os dados são removidos rapidamente, tanto na plataforma quanto nos destinos de armazenamento que a plataforma controla. Veja LGPD/GDPR.
- Trilha de auditoria: os logs de auditoria não podem ser apagados antes de 1 ano e ficam protegidos contra alteração.
- Várias cópias, vários prazos: cada destino tem sua própria janela de retenção. Nos destinos de armazenamento, o prazo é o que você configurou; nos SIEMs e barramentos, a retenção é responsabilidade do próprio sistema de destino.
- Residência de dados: destinos podem ser marcados com a região onde os dados podem ficar (por exemplo, "UE" ou "EUA"). Eventos não são entregues a destinos com região incompatível. Essa marcação é definida pela equipe de infraestrutura no momento do deploy. Se precisar alterá-la, fale com o administrador da plataforma.
PCI DSS
- Dados de portador de cartão: caso existam (raro neste contexto), a retenção mínima é de 1 ano.
- Retenção de logs: 1 ano, conforme o padrão.
Próximos passos
- Configurar prazos de uma organização? Veja Organizações.
- Atender a um pedido de exclusão (LGPD/GDPR)? Veja LGPD/GDPR.
- Destinos e roteamento? Veja Destinos e Roteamento.
- Auditar alterações? Veja Histórico.