Um fornecedor de tecnologia financeira apresentou um inventário de dados a um grande banco cliente como parte da avaliação anual de fornecedores. O inventário listava sete sistemas com dados financeiros de clientes: o banco de dados principal de transações, a plataforma de relatórios, dois buckets de armazenamento em nuvem, o portal do cliente, o gateway de API e o sistema de backup. A equipe de segurança do banco, ao realizar uma avaliação mais aprofundada, pediu ao fornecedor que executasse uma varredura de descoberta automatizada em seu ambiente de nuvem e apresentasse os resultados junto com o inventário autodeclarado. A varredura encontrou vinte e três sistemas com dados correspondentes às categorias de dados financeiros descritas no inventário. Os dezesseis adicionais incluíam um CRM legado que havia sido substituído dois anos antes, mas nunca desativado; quatro buckets adicionais de armazenamento em nuvem criados por equipes diferentes em momentos diferentes; o data warehouse de análise com uma réplica completa dos dados de produção; um sandbox de desenvolvedores preenchido com dados de produção para testes; o sistema de helpdesk com dados financeiros de clientes em anexos de chamados de suporte; e uma unidade de rede compartilhada usada pela equipe de sucesso do cliente. O fornecedor não havia sido desonesto. Havia inventariado o que conhecia. Não conhecia o resto.
Qual é, de fato, o problema da completude do inventário de dados?
Um inventário de dados é um registro documentado de todos os sistemas, bancos de dados, locais de armazenamento e fluxos de dados que contêm ou tratam dados sensíveis no ambiente de uma organização ou de um fornecedor. É o artefato fundamental da governança de dados: todos os controles subsequentes, da gestão de acessos à criptografia, das políticas de retenção à resposta a incidentes, dependem de o inventário ser abrangente. Um inventário incompleto produz uma governança seletiva: os sistemas do inventário recebem os controles adequados, os sistemas fora do inventário não recebem governança alguma e toda a postura de segurança de dados é sistematicamente superestimada em relação ao cenário real de dados.
O problema da completude do inventário surge da tensão fundamental entre a forma como os inventários são construídos e a forma como os ambientes realmente evoluem. Os inventários costumam ser construídos uma única vez, durante um exercício inicial de mapeamento de dados ou em resposta a um requisito de conformidade, com base em entrevistas, documentação de sistemas e conhecimento institucional. Os ambientes evoluem continuamente com as atividades normais de desenvolvimento, operações e expansão dos negócios: novos sistemas são provisionados, sistemas legados não são desativados, equipes criam buckets de armazenamento para projetos pontuais e dados se acumulam em sistemas que nunca foram concebidos para ser repositórios de dados. Cada uma dessas mudanças amplia o cenário real de dados, enquanto o inventário permanece estático, a menos que seja mantido especificamente.
O problema do inventário autodeclarado é o risco de governança específico nos contextos de TPRM. Quando um fornecedor apresenta um inventário de dados como evidência da maturidade de sua governança de dados, esse inventário reflete o que ele sabe que o seu ambiente contém. Não reflete o que uma varredura sistemática de descoberta encontraria. A diferença entre inventários autodeclarados e inventários verificados por descoberta é sistematicamente significativa: organizações que realizam uma descoberta formal após a autodeclaração costumam encontrar de vinte a quarenta por cento mais sistemas com dados do que a autodeclaração havia identificado. Cada sistema nessa diferença é um sistema que não recebe nada da governança que o inventário declarado deveria apoiar.
As lacunas na completude do inventário de dados se concentram em cinco fontes específicas de imprecisão:
- Sistemas legados nunca desativados: sistemas que foram substituídos, mas nunca removidos do ambiente, e que continuam a conter dados fora de qualquer programa de governança atual
- Armazenamento improvisado provisionado por equipes: buckets de armazenamento em nuvem, unidades compartilhadas e repositórios de dados criados por equipes de desenvolvimento, análise ou operações para projetos específicos e nunca inventariados formalmente
- Cópias de análise e relatórios: snapshots de data warehouse, conexões de ferramentas de BI e réplicas de bancos de dados de relatórios que não foram considerados sistemas com dados quando o inventário foi compilado
- Dados ocultos em sistemas operacionais: plataformas de helpdesk, ferramentas de colaboração e sistemas operacionais que acumulam dados sensíveis nas operações normais sem serem reconhecidos como repositórios de dados
- Sistemas adquiridos ou integrados: sistemas incorporados ao ambiente por meio de aquisições, parcerias ou integrações que nunca foram formalmente inventariados no programa atual de governança de dados
Por que isso importa
A completude do inventário de dados é importante para TPRM porque todos os controles subsequentes de governança de dados (gestão de acessos, criptografia, políticas de retenção, escopo da resposta a incidentes) dependem de o inventário identificar os sistemas aos quais esses controles devem ser aplicados. Um inventário incompleto produz uma governança sistematicamente incompleta: os controles são aplicados de forma abrangente aos sistemas inventariados e não são aplicados de modo algum aos não inventariados. Quando uma investigação de violação mapear os sistemas que continham os dados do cliente, encontrará sistemas que o programa de governança nunca alcançou, porque não estavam no inventário.
A consequência regulatória é uma extensão direta da lacuna de governança. O artigo 30 do GDPR exige que controladores e operadores mantenham registros das atividades de tratamento, um inventário formal dos sistemas, finalidades e categorias de tratamento de dados. Um registro do artigo 30 que omite dezesseis de vinte e três sistemas com dados é um registro incompleto que não atende ao requisito regulatório, por mais minuciosamente que os sete sistemas inventariados estejam documentados. A obrigação regulatória é abrangente. O inventário incompleto é uma falha de conformidade.
Para profissionais de TPRM, a avaliação da completude do inventário exige perguntar não apenas se existe um inventário de dados, mas como ele foi construído e se foi validado por descoberta automatizada. Um inventário autodeclarado que nunca foi validado por ferramentas de descoberta é um inventário dos sistemas conhecidos. Um inventário validado por descoberta é um inventário dos sistemas reais. A diferença entre esses dois inventários é a lacuna de governança.
Onde a maioria das equipes erra
A falha mais recorrente é aceitar inventários de dados autodeclarados sem perguntar como foram construídos ou se foram validados. Um fornecedor que apresenta um inventário de dados documentou o que sabe sobre o seu ambiente. Se esse conhecimento é completo exige verificação independente, seja por meio do seu próprio processo de descoberta automatizada, seja por uma avaliação independente. Tratar a autodeclaração como evidência abrangente de inventário confunde o que o fornecedor sabe com o que o ambiente do fornecedor contém.
A segunda falha é tratar o inventário de dados como um documento estático, e não como um registro mantido continuamente. Os ambientes mudam continuamente. Um inventário que era preciso na criação se torna progressivamente menos preciso à medida que sistemas são adicionados, sistemas legados persistem e o armazenamento improvisado se acumula. Um inventário atualizado pela última vez há dezoito meses pode refletir o ambiente como era há dezoito meses, enquanto o ambiente atual se expandiu significativamente. A periodicidade de atualização do inventário é tão relevante quanto sua completude inicial.
- Aceitar inventários autodeclarados sem validação: o que o fornecedor conhece ou o que a descoberta encontraria
- Nenhuma validação do inventário por descoberta: nunca foi feita a comparação de uma varredura automatizada com a autodeclaração
- Inventário estático sem periodicidade de atualização: inventário preciso na criação e progressivamente menos preciso à medida que o ambiente evolui
- Escopo do inventário limitado aos sistemas de produção principais: armazenamento de análise, legado e improvisado excluído do escopo do inventário
- Nenhuma verificação da desativação de sistemas legados: sistemas que deveriam ter sido desativados, mas não estavam refletidos no inventário
Como é uma boa prática
Programas maduros de inventário de dados combinam a autodocumentação com a validação por descoberta automatizada, usando ferramentas de descoberta para identificar continuamente os sistemas que contêm dados e conciliar as constatações com o inventário documentado, sinalizando discrepâncias para investigação e correção. O inventário é mantido como um documento vivo, atualizado quando novos sistemas são provisionados e validado em relação aos resultados das varreduras de descoberta em uma periodicidade definida.
- Validação por descoberta automatizada: ferramentas de descoberta executadas no ambiente, com as constatações comparadas ao inventário documentado em uma periodicidade definida
- Manutenção contínua do inventário: atualização do inventário acionada quando novos sistemas são provisionados ou sistemas existentes são modificados
- Processo de desativação de sistemas legados: processo formal para remover do ambiente os sistemas desativados e verificar a migração ou a eliminação dos dados
- Inventário de escopo amplo: escopo do inventário que inclui plataformas de análise, sistemas operacionais, sistemas legados e armazenamento improvisado, além dos bancos de dados de produção principais
- Processo de correção de discrepâncias: sistemas encontrados na descoberta, mas ausentes do inventário, avaliados, classificados e colocados sob governança ou documentados como excluídos, com justificativa
Ferramentas
A completude do inventário de dados exige ferramentas de descoberta capazes de identificar sistematicamente os sistemas que contêm dados em ambientes de nuvem e locais.
Descoberta de ativos em nuvem: AWS Config, Azure Resource Graph, GCP Asset Inventory
As plataformas de gestão de nuvem oferecem inventários abrangentes dos recursos implantados, enumerando cada bucket de armazenamento, instância de banco de dados, recurso computacional e serviço no ambiente de nuvem. O AWS Config registra continuamente a configuração dos recursos AWS e pode ser consultado para identificar todos os recursos que contêm dados em todas as regiões e contas. Para profissionais de TPRM, perguntar se os fornecedores usam ferramentas de inventário de ativos em nuvem para validar seu inventário de dados em relação à sua presença real na nuvem é uma pergunta específica sobre o mecanismo de validação.
Descoberta e classificação de dados: BigID, Varonis, Microsoft Purview
As plataformas de descoberta de dados varrem ambientes de armazenamento em busca de dados que correspondam a padrões definidos, identificando sistemas com dados sensíveis que podem não constar do inventário documentado. Para profissionais de TPRM, perguntar se o fornecedor executou uma varredura de descoberta em todo o ambiente e comparou as constatações com o seu inventário documentado é a pergunta mais direta para validar a completude do inventário.
Gerenciamento de postura de segurança em nuvem: Wiz, Orca, Prisma Cloud
As plataformas de CSPM oferecem visibilidade contínua do ambiente de nuvem, identificando todos os recursos de dados, suas configurações e sua postura de segurança. O Wiz oferece especificamente um grafo abrangente de ativos dos ambientes de nuvem que permite validar o inventário por meio da descoberta automatizada de recursos. Para profissionais de TPRM, perguntar se o fornecedor utiliza CSPM com descoberta abrangente de ativos é uma pergunta sobre uma ferramenta de validação de inventário específica para a nuvem.
Desafios de governança
O desafio de governança da completude do inventário de dados é o esforço contínuo necessário para manter a precisão em um ambiente em constante evolução. As varreduras de descoberta identificam a lacuna entre o inventário documentado e o ambiente real em um determinado momento. Elas não impedem que novos sistemas sejam provisionados fora do inventário, que sistemas legados persistam após a desativação ou que armazenamento improvisado se acumule entre os ciclos de varredura. Manter a completude do inventário exige tanto a identificação de lacunas por descoberta quanto controles de processo que impeçam a formação de novas lacunas.
Para programas de TPRM, a questão prática de governança é se o fornecedor consegue demonstrar que seu inventário de dados é validado por descoberta automatizada, e não apenas autodeclarado. Um fornecedor capaz de apresentar resultados recentes de varreduras de descoberta junto com seu inventário, com investigação e correção documentadas das discrepâncias, demonstrou uma governança da completude do inventário que evidências autodeclaradas não conseguem oferecer.
- Exigir evidências de validação por descoberta junto com o inventário autodeclarado: resultados das varreduras comparados com o inventário como evidência de completude
- Perguntar sobre a periodicidade de atualização do inventário: com que frequência o inventário é revisado e atualizado à medida que o ambiente muda
- Perguntar sobre a verificação da desativação de sistemas legados: se os sistemas removidos do inventário foram verificados como efetivamente removidos do ambiente
- Perguntar sobre a frequência das varreduras de descoberta: quando foi executada a última varredura de descoberta em todo o ambiente e o que ela encontrou
- Incluir a completude do inventário na reavaliação anual: não apenas confirmar a existência do inventário, mas validar sua precisão
Se você faz parte de uma equipe pequena
Faça aos seus fornecedores de maior risco uma pergunta que revela de imediato a completude do inventário: quando foi a última vez que vocês executaram uma varredura de descoberta automatizada em todo o seu ambiente para validar o seu inventário de dados, e qual foi a maior discrepância encontrada entre os resultados da varredura e o seu inventário documentado? Essa pergunta exige que o fornecedor descreva um processo de validação por descoberta, em vez de apenas confirmar que existe um inventário, e a resposta sobre a discrepância revela a lacuna entre o que ele conhece e o que o seu ambiente contém.
- Perguntar quando foi executada a última varredura de descoberta automatizada e o que ela encontrou em comparação com o inventário documentado
- Perguntar sobre o processo de investigação e correção de discrepâncias quando a descoberta encontra sistemas não listados
- Perguntar como o inventário é atualizado quando novos sistemas são provisionados ou sistemas existentes são alterados
- Perguntar se ferramentas de descoberta de ativos em nuvem são usadas para validar continuamente o inventário
O que exigir
Pergunte diretamente:
“Quando foi executada a última varredura de descoberta automatizada em todo o seu ambiente para validar o seu inventário de dados? E qual foi a maior discrepância encontrada entre os resultados da varredura e a sua lista documentada de sistemas?”
“Como o seu inventário de dados é mantido à medida que o seu ambiente muda? Especificamente, o que aciona uma atualização do inventário quando um novo sistema é provisionado ou um sistema existente é modificado?”
“O seu inventário de dados inclui plataformas de análise, sistemas de suporte operacional, sistemas legados em processo de desativação e armazenamento em nuvem improvisado, ou se limita principalmente aos bancos de dados de produção principais?”
O que esperar como evidência
- Evidências de varreduras de descoberta comparadas com o inventário documentado, com documentação das discrepâncias
- Documentação do processo de atualização do inventário: gatilhos e periodicidade
- Confirmação do escopo do inventário: todas as categorias de sistemas relevantes incluídas
- Processo de verificação da desativação de sistemas legados
Um fornecedor que responde à pergunta sobre varreduras de descoberta com “nosso inventário de dados é mantido pela nossa equipe de governança de dados” descreveu quem é responsável pelo inventário. Pergunte especificamente quando foi executada a última varredura de descoberta para validar se o inventário reflete o que realmente existe no ambiente. O inventário é preciso quanto ao que foi documentado. A varredura determina se a documentação está completa.
Como comprovar
Os registros das atividades de tratamento do artigo 30 do GDPR, a documentação exigida pelo HIPAA sobre os sistemas de PHI e a delimitação do ambiente de dados do titular do cartão do PCI-DSS exigem inventários abrangentes dos sistemas de dados. Demonstrar a devida diligência exige evidências de que a completude do inventário foi validada por descoberta, e não apenas autodeclarada.
- Evidências de varreduras de descoberta junto com o inventário autodeclarado pelo fornecedor
- Registros de investigação e correção de discrepâncias
- Documentação do escopo do inventário que confirme a cobertura abrangente dos sistemas
- Documentação da periodicidade e dos gatilhos de atualização do inventário
Principal conclusão
O inventário de dados é preciso quanto ao que foi documentado. O que não foi documentado não aparece no inventário, não recebe a governança que o inventário deveria apoiar e não aparece no escopo da violação até que uma varredura de descoberta ou uma investigação forense o encontre. Os dezesseis sistemas fora do inventário autodeclarado do fornecedor não estavam escondidos. Simplesmente não eram conhecidos: sistemas legados esquecidos, armazenamento improvisado criado por equipes que trabalhavam com pressa, réplicas de análise provisionadas sem atualização do inventário. A descoberta encontra o que a memória deixou passar. Um inventário de dados validado por descoberta automatizada é evidência do que o ambiente contém. Um inventário de dados construído com base no conhecimento institucional é evidência do que alguém se lembra. A governança depende da completude. A completude depende da descoberta.