Governança, Retenção e Ciclo de Vida dos Dados

Nota do capítulo 02 (Fontes de Dados e Coleta), que encerra o ciclo tratando do destino legal, ético e econômico dos dados coletados.
Define o ciclo de vida do dado de inteligência, a classificação de sensibilidade com TLP 2.0, a política de retenção por classe, os cuidados com LGPD e o descarte em camadas.
Fecha o capítulo em diálogo com a qualidade (11), a automação (12) e os controles de governança da seção 15.

1. Contexto e Posicionamento na Biblioteca

Times de CTI acumulam dados com a convicção de que reter tudo é prudência, e descobrem tarde que o acúmulo sem política cria três problemas simultâneos: custo de armazenamento que cresce linearmente com o tempo, risco jurídico crescente sobre dados pessoais em telemetria e degradação analítica, porque bases gigantes sem curadoria tornam a busca lenta e a confiança baixa. Governança de dados de inteligência é o conjunto de regras explícitas sobre quem pode ver, por quanto tempo se guarda, quando se descarta e como se comprova cada decisão, e sua ausência não impede o problema: apenas o torna invisível até o incidente.

Esta nota fecha o capítulo 02 conectando as decisões técnicas anteriores às obrigações organizacionais. O ciclo de vida aqui descrito abraça o ciclo de coleta tratado nas notas 08 e 12, a expiração de indicadores definida na nota 09 e as métricas de utilidade da nota 11, transformando-as em política formal com dono, prazo e auditoria. O marco legal central no Brasil é a Lei Geral de Proteção de Dados (Lei nº 13.709/2018, LGPD), que se aplica de forma direta à telemetria de usuários e a muitos dados coletados de fontes externas, tema da seção 5, e o padrão de compartilhamento central é o TLP 2.0, do FIRST, tema da seção 3.

2. Ciclo de Vida do Dado de Inteligência

O dado de inteligência percorre estágios análogos ao ciclo de vida da própria inteligência, e cada transição entre estágios é uma decisão de política, e não apenas um evento técnico. Nas fases iniciais, a coleta traz matéria-prima bruta (feed baixado, evento de telemetria, relatório recebido), o processamento canoniza e enriquece, a análise transforma observáveis em julgamento com contexto. Nas fases finais, a disseminação distribui produtos por audiência, o uso operacional gera feedback de utilidade e, por fim, o arquivo e o descarte encerram o ciclo com retenção documentada ou eliminação segura.

Cada fase precisa de um dono nominal, e a ausência de dono é o modo mais comum de um ciclo de vida morrer no papel. A coleta pertence ao time de inteligência, o processamento à engenharia de dados do SOC, a análise aos analistas sêniores, a disseminação ao coordenador de CTI, o arquivo e o descarte à governança de dados em conjunto com o jurídico. O registro desses papéis não é burocracia: é o que permite responder, em auditoria ou incidente, quem aprovou a regra que manteve determinado dado por dois anos ou quem decidiu eliminar a telemetria de determinado mês.

A regra de desenho mais importante deste ciclo é que o julgamento e o contexto vivem mais que o dado bruto. A telemetria bruta de um comprometimento de 2022 provavelmente já pode ser descartada; a análise daquele comprometimento, com TTPs, infraestrutura e lições, é conhecimento que interessa por anos e alimenta retro-hunting e atribuição futura. Políticas que aplicam um único prazo para tudo (o clássico sete anos para todos os logs) erram nas duas direções: descartam conhecimento valioso e retêm custos que ninguém usa, e o correto é diferenciar por classe, como a seção 4 detalha.

3. Classificação de Sensibilidade e o TLP 2.0

A sensibilidade do dado de inteligência tem duas camadas que nunca devem ser confundidas: a classificação interna da organização (pública, interna, confidencial, restrita) e o protocolo de compartilhamento externo TLP 2.0, mantido pelo FIRST, que define o que o destinatário pode fazer com a informação recebida. A tabela abaixo consolida os cinco rótulos do TLP 2.0 e a política de circulação de cada um, que deve estar refletida tecnicamente nos sistemas: o que é TLP:RED não pode estar em uma watchlist distribuída para o SOC inteiro por engano.

A governança técnica da classificação é o que evita o efeito papel. Cada objeto no TIP carrega o rótulo TLP como atributo obrigatório, e a distribuição automatizada filtra por rótulo em cada destino: watchlist do SIEM recebe até o máximo definido na política de uso interno, export de bloqueio para EDR exige rótulo e confiança compatíveis com ação automatizada, e relatórios externos respeitam o rótulo do material mais sensível incorporado. Filtrar TLP na saída é mais confiável que filtrar na entrada, porque a partir do momento em que o dado entrou, sua propagação é problema de controle de fluxo, e não de disciplina individual.

A camada interna complementa o TLP em três pontos que o protocolo não cobre. Dados pessoais presentes em telemetria precisam de marcador próprio, pois seu tratamento segue LGPD independente do TLP do contexto; segredos de negócio (como a existência de uma investigação em curso sobre fornecedor interno) pedem classificação confidencial mesmo quando o indicador técnico seria TLP:GREEN; e dados de fontes comerciais têm restrições contratuais de uso que nenhuma etiqueta pública substitui, exigindo registro dos termos de cada fonte no catálogo de dados. A regra prática: todo objeto carrega TLP, marcador de dado pessoal e restrição de fonte, e os três campos são independentes e obrigatórios.

4. Política de Retenção por Classe de Dado e Custos em Camadas

A política de retenção deve ser escrita como tabela de classes, com prazo, camada de armazenamento e justificativa, aprovada pelo dono do risco e revisada anualmente. O ponto de partida abaixo reflete a prática de mercado para um time de CTI com SOC ativo, e os prazos exatos devem ser calibrados com obrigações contratuais e regulatórias do setor da organização, sempre documentando o porquê de cada prazo.

Os custos justificam a estrutura em camadas: ingestão quente em SIEM e EDR é a modalidade mais cara por gigabyte do mercado de segurança, e a maior parte do volume não precisa viver ali. A arquitetura de camadas recomendada move dados por idade: quente em índice de busca com réplicas, morna em armazenamento de objeto com formato colunar comprimido (por exemplo, Parquet com zstd) consultável por ferramenta analítica, fria em arquivo de baixo custo com acesso raro e, ao fim do prazo, eliminação. A compressão típica de telemetria bruta em formato colunar é agressiva o suficiente para reduzir o custo de retenção longa a uma fração do custo quente, e o ganho adicional é analítico: dados colunados consultáveis por SQL servem retro-hunt melhor que índice de SIEM caro.

A tabela abaixo resume o perfil de custo e de acesso de cada camada, com as tecnologias típicas de mercado e o papel que cada uma cumpre na política de retenção:

A política ganha força quando vira código executado por jobs de ciclo de vida, com o mesmo raciocínio de infraestrutura como código aplicado ao restante da plataforma. O exemplo abaixo declara, em formato compacto e versionável, as regras que os jobs de movimentação e descarte devem executar, eliminando a divergência silenciosa entre a tabela aprovada e o comportamento real dos sistemas:

politica_retencao:
  versao: "2025.11"
  dono: governanca_dados_seguranca
  revisao: trimestral
  classes:
    - classe: telemetria_bruta
      quente_dias: 60
      fria_meses: 9
      base_legal: "legitimo_interesse_seguranca"
      metodo_descarte: crypto_shred
    - classe: indicadores_tip
      ativo: "TTL por tipo conforme nota 09"
      historico_anos: 5
      metodo_descarte: purge_fisica_com_registro
    - classe: produtos_analiticos
      quente_anos: 3
      fria: permanente_biblioteca_interna
      metodo_descarte: revisao_anual
    - classe: artefatos_forense
      retencao: "encerramento_do_caso_mais_hold_legal"
      metodo_descarte: crypto_shred_com_certificado

A regra de decisão econômica que fecha esta seção é comparar custo de retenção com custo de reaquisição: dados que podem ser rebuscados da fonte (feeds públicos) não precisam de retenção longa própria; dados de telemetria própria são insubstituíveis e justificam retenção mais longa em camada fria; dados de fontes comerciais devem seguir os termos do contrato, que normalmente proíbe retenção além do prazo de uso e redistribuição. Cada exceção a essas regras deve constar na própria tabela de política, com aprovação formal, pois exceção não documentada é política furada sem registro de quem furou.

5. LGPD e Dados Pessoais em Telemetria de CTI

A LGPD se aplica ao trabalho de CTI com mais frequência do que se assume. Endereço IP, nome de usuário, e-mail corporativo, geolocalização aproximada e hash de senha vazada associada a uma conta são dados pessoais, ou potencialmente pessoais, e a telemetria de endpoints, proxies e correio os carrega em volume. A coleta para segurança da informação tem amparo em bases legais próprias (entre elas a execução de contrato, o legítimo interesse e o cumprimento de obrigação legal ou regulatória, conforme o caso concreto), mas a existência de base legal não dispensa os princípios do artigo 6 da lei, em especial necessidade (minimização), qualidade dos dados, segurança e prazo de tratamento, que é exatamente o tema desta nota.

Na prática de coleta, três medidas operacionalizam a conformidade. A minimização define o que o pipeline coleta: campo que não serve à detecção, à investigação ou ao requisito de inteligência declarado não entra, e filtros de campo devem ser revisados junto com a matriz de cobertura da nota 11. A pseudonimização separa identidade de evento: hashes determinísticos substituem identificadores diretos onde a análise permite, com a tabela de correspondência guardada com acesso restrito e própria retenção, de modo que a investigação consiga reidentificar por necessidade e com registro, e a exploração rotineira não precise. A segregação de acesso garante que o analista de CTI trabalhando infraestrutura externa não navegue, por padrão, por identidades de funcionários, e que a reidentificação seja operação registrada e justificável.

O inventário de dados pessoais no pipeline é o artefato que sustenta a discussão com o DPO e com o jurídico, e vale a pena mantê-lo explícito. A tabela abaixo traz o formato recomendado, com os campos mais comuns de telemetria e coleta de CTI e a medida de mitigação associada a cada um:

O pipeline de CTI também deve aparecer no registro das operações de tratamento mantido pelo controlador (o chamado ROPA), com finalidade declarada (segurança da informação e prevenção a fraudes), categorias de titulares, prazos de retenção e medidas de segurança. Tratamentos de segurança podem envolver dados sensíveis em situações específicas, e a discussão antecipada com o encarregado evita tanto o superdimensionamento por medo quanto o subdimensionamento por desconhecimento. Quando o desenho do pipeline muda de forma relevante (nova fonte que coleta telemetria de colaboradores, novo destino de compartilhamento), o registro deve ser atualizado na mesma janela da mudança técnica, e não em revisão anual distante dela.

A diferença entre pseudonimização e anonimização tem consequência legal direta e merece precisão terminológica. O dado pseudonimizado continua sendo dado pessoal, porque pode ser reatribuído a um titular com informação adicional mantida separadamente; já o dado anonimizado de forma irreversível sai do escopo da lei, quando a reidentificação é tecnicamente inviável e comprovadamente custosa. Na prática dos pipelines de segurança, a anonimização verdadeira é rara, porque quase sempre existe a tabela de correspondência em algum lugar, e a postura honesta é tratar os dados como pseudonimizados, com os controles daqui, em vez de alegar anonimização sem conseguir demonstrar a irreversibilidade.

Três situações recorrentes merecem atenção específica. Primeira: feeds externos podem carregar dados pessoais de terceiros (e-mails de remetentes em amostras de phishing, dados de registrante), e a retenção desse material deve seguir o mesmo regime do dado próprio, com prazo e finalidade declarados. Segunda: o compartilhamento externo de intel que contenha dado pessoal (por exemplo, lista de contas atacadas em um ISAC) exige avaliação prévia, minimização e, em geral, pseudonimização antes do envio, mesmo com TLP compatível. Terceira: incidentes de segurança com risco relevante a titulares têm dever de comunicação à autoridade (ANPD) e aos titulares conforme a regulamentação vigente, e o time de CTI precisa saber que seus registros fazem parte da evidência desse processo, o que eleva o requisito de rastreabilidade da nota 11 de boa prática para obrigação.

6. Descarte Seguro, Auditoria e Comprovação

Descarte em governança madura é operação comprovável, e não gesto de apagar. A técnica mais econômica para grandes volumes em armazenamento de objeto é o crypto-shredding: todo dado é gravado cifrado com chave própria por período ou por conjunto, e eliminar o dado equivale a destruir a chave correspondente, com registro do ato; o custo é o de gestão de chaves, e o efeito é imediato sobre todas as cópias e réplicas. Para sistemas transacionais, a eliminação lógica com purga programada (tombstone, depois purga física) permite reconciliar auditoria com esquecimento efetivo, e backups recebem regra própria: backup antigo contendo dado a eliminar é tratado por política de expiração natural do backup, documentada, já que restaurar e filtrar é normalmente inviável e desnecessário quando o prazo de backup é inferior ao prazo de retenção legítima.

A comprovação exige três artefatos que precisam existir antes do primeiro descarte real. A política aprovada (a tabela da seção 4, com dono e revisão anual); o registro de execução, que lista o que foi eliminado, quando, por qual regra e com qual método; e o log de acesso ao dado retido, que demonstra quem consultou quê, sustentando tanto a auditoria interna quanto a resposta a exigência regulatória. Auditorias internas amostram esses artefatos anualmente, e o resultado alimenta a revisão da política; descarte sem registro é indistinguível de perda de dado, e a diferença entre os dois, perante um regulador ou um tribunal, é exatamente o papel.

O registro de descarte não precisa ser sofisticado, precisa ser consistente. O exemplo abaixo mostra o formato mínimo de um certificado de eliminação gerado pelo job de ciclo de vida, com os campos que uma auditoria vai pedir:

registro de descarte no 2025-1147
regra aplicada: telemetria_bruta (fria_meses = 9)
janela eliminada: 2024-11-01 a 2024-11-30
volume: 1,8 TB comprimidos, 214 milhoes de eventos
metodo: crypto-shred (chave k-2024-11 revogada em 2025-08-30T02:00Z)
execucao: job lifecycle-tiers v1.4
verificacao: sonda de leitura apos revogacao retornou 0 objetos acessiveis
aprovacao: responsavel de governanca de dados (registro em ata)

Dois detalhes desse formato evitam discussões futuras. A verificação por sonda de leitura depois da revogação da chave é o que transforma a alegação de eliminação em evidência, e deve ser registrada no próprio certificado. E a referência à regra da política, e não a uma decisão ad hoc, é o que mantém o vínculo entre o ato e a aprovação formal, permitindo que a auditoria rastreie o descarte até a tabela aprovada da seção 4 em um único passo.

7. Erros Comuns e Pontos de Atenção

O erro mais comum é a retenção por omissão: guardar tudo porque decidir é trabalhoso, acumulando custo quente caro e risco jurídico sobre dados pessoais que ninguém usa. O inverso também aparece e é igualmente caro: purgar agressivamente telemetria para cortar custo, descobrindo em um incidente que a janela histórica necessária ao retro-hunt já não existe, com o agravamento de que essa decisão costuma ser tomada por quem não mede a utilidade da base. A tabela de retenção existente e revisada é o antídoto para os dois extremos, e o número que a alimenta é a métrica de acionamento do capítulo 11.

Outros erros recorrentes incluem: aplicar TLP como etiqueta decorativa sem filtro técnico na distribuição, permitindo que material TLP:RED vire anexo de e-mail em número errado; confundir backup com retenção, tratando o backup como arquivo consultável de longo prazo; ignorar restrições contratuais de fontes comerciais ao exportar dados enriquecidos para parceiros; e tratar LGPD como problema só de DPO, descobrindo em avaliação formal que o pipeline coleta campos pessoais sem necessidade declarada. Cada um desses erros tem correção barata na fase de desenho e correção cara na fase de incidente, o que define a prioridade prática desta nota.

Um ponto final de atenção é a interação entre retenção longa e precisão do dado retido. Histórico de indicadores retido por anos vale muito para retro-hunt apenas se carregar a confiança e o contexto da época, pois um IP marcado como malicioso em 2021 não conta a história de que foi reavaliado como limpo em 2023 se o registro não preservar as duas versões. A regra de ouro do arquivo é preservar estados, não só valores, e essa exigência volta como requisito técnico na integração abaixo, porque depende do desenho do TIP e do schema adotado lá atrás, no pipeline.

8. Integração com o Restante da Biblioteca

Esta nota fecha o capítulo 02 amarrando as decisões anteriores ao regime de responsabilidade: o pipeline (08) e a automação (12) produzem os dados que a política daqui classifica e retém; a normalização (09) define as chaves cujo histórico precisa sobreviver ao arquivo; a qualidade (11) mede a utilidade que justifica cada prazo de retenção; e a correlação (10) depende de que os vínculos históricos permaneçam consultáveis com filtro de época, requisito que a política de retenção deve declarar explicitamente. O TLP 2.0 aqui operacionalizado conecta o capítulo ao ecossistema de compartilhamento tratado na seção 22 da biblioteca e no controle PLT.5 da seção 15.

Em relação aos capítulos seguintes, a matriz de classificação interna desta nota prepara o terreno para a proteção da própria inteligência (capítulo de contra-inteligência, 13), que assume que o atacante também tenta descobrir o que a organização sabe, e a política de descarte apoia a disciplina de evidência do ciclo de resposta a incidentes da seção 15. A evolução de maturidade recomendada é transformar a tabela de retenção em código de política executado por jobs de ciclo de vida no TIP e no armazenamento, com revisão trimestral apoiada nas métricas de acionamento e utilidade, porque política que roda em tabela parada e política que roda em job divergem silenciosamente, e a divergência entre o que a política diz e o que o sistema faz é, na auditoria, sempre interpretada contra o time.