Um fornecedor global da área de saúde mantinha um programa de classificação de dados com quatro níveis. Os prontuários clínicos dos pacientes eram de Nível 1, o mais sensível. Sua plataforma de governança de dados aplicava a classificação de Nível 1 aos prontuários clínicos no sistema de origem de EHR, com os controles de acesso, a criptografia e o registro de auditoria correspondentes. Quando esses prontuários eram replicados para o data warehouse de análise para estudos de saúde populacional, o pipeline de replicação não levava os rótulos de classificação: o warehouse recebia os dados sem metadados de classificação. A equipe de análise, precisando classificar os dados do warehouse, aplicou seu próprio esquema de classificação, que usava nomes de níveis diferentes e era calibrado de forma diferente do esquema da plataforma de governança. No warehouse, os prontuários clínicos foram classificados pelo esquema de análise como 'dados de pesquisa', uma categoria com acesso muito mais amplo do que o Nível 1 no esquema da plataforma de governança. Os mesmos prontuários clínicos tinham duas classificações diferentes em dois sistemas diferentes, e a classificação que regia o acesso no ambiente de análise era a mais fraca. Todo usuário da plataforma de análise que podia acessar 'dados de pesquisa' podia acessar prontuários clínicos que a classificação de Nível 1 do sistema de origem restringia a um pequeno grupo de clínicos autorizados.
O que é, de fato, o problema das inconsistências na marcação de dados?
A marcação de dados é a aplicação de rótulos de classificação (níveis de sensibilidade, categorias de dados, requisitos de manuseio) aos elementos de dados em todos os sistemas em que existem. Uma marcação consistente garante que um elemento de dado tenha a mesma classificação e os controles correspondentes, independentemente do sistema em que esteja. Uma marcação inconsistente produz uma postura de governança em que o mesmo elemento de dado tem rótulos de classificação, controles de acesso e requisitos de manuseio diferentes em sistemas diferentes, e a classificação mais permissiva determina o que é possível fazer com os dados na prática.
O problema da propagação de rótulos é a raiz estrutural da inconsistência na marcação. Quando os dados passam de um sistema para outro, por replicação, processos de ETL, feeds de API, pipelines de análise ou fluxos de exportação, os metadados de classificação que regem os dados no sistema de origem podem não acompanhar os dados. O sistema de destino pode não ter capacidade técnica para receber metadados de classificação, pode usar outro esquema de classificação ou simplesmente pode não receber os metadados como parte da transferência de dados. O resultado são dados que existem no novo sistema sem seu contexto de classificação, o que exige que a classificação seja aplicada de forma independente no novo sistema ou que os dados sejam tratados sem nenhuma classificação.
O problema dos vários esquemas agrava a questão da propagação. Organizações com ambientes de dados complexos frequentemente têm vários esquemas de classificação funcionando em paralelo: o esquema da plataforma de governança corporativa, o esquema interno da equipe de análise, a classificação padrão da plataforma de armazenamento em nuvem e as categorias de dados da própria aplicação SaaS. Cada esquema foi concebido para seu contexto específico e faz sentido dentro dele. Entre contextos, eles produzem classificações inconsistentes dos mesmos dados, sem uma classificação canônica que rija os dados em todos os sistemas. O esquema mais permissivo que qualquer sistema aplica a um elemento de dado é a classificação efetiva desse elemento do ponto de vista do controle de acesso.
- Classificação não propagada nos processos de ETL e de replicação: dados movidos entre sistemas perdendo os metadados de classificação
- Inconsistência entre vários esquemas: esquemas de classificação diferentes em sistemas diferentes produzindo classificações diferentes dos mesmos dados
- Nenhuma autoridade de classificação canônica: ausência de uma classificação oficial única que valha para todos os sistemas
- Reclassificação em nível mais fraco: sistemas de destino que aplicam uma classificação independente menos restritiva do que a classificação de origem
- Lacunas de cobertura da classificação nos sistemas secundários: plataformas de análise, data warehouses e ferramentas de colaboração operando sem classificação
Por que isso importa
A inconsistência na marcação de dados importa para TPRM porque significa que os controles de proteção de dados aplicados no sistema principal dos dados não se aplicam necessariamente aos mesmos dados nos sistemas secundários, e os sistemas secundários podem ter populações de acesso muito mais amplas. Um fornecedor da área de saúde cujos prontuários clínicos de Nível 1 são acessíveis a todos os usuários da plataforma de análise, porque essa plataforma aplica uma classificação menos restritiva, deu acesso a prontuários clínicos a uma população muito mais ampla do que os controles de Nível 1 preveem, não por meio de uma violação, mas por uma inconsistência de classificação embutida no pipeline de replicação.
A implicação regulatória é direta. Os princípios de proteção de dados do GDPR se aplicam aos dados pessoais independentemente do sistema em que estejam e do rótulo de classificação que um sistema específico tenha aplicado a eles. Um regulador que pergunte por que prontuários clínicos estavam acessíveis a usuários da plataforma de análise com acesso a 'dados de pesquisa' não aceitará 'a plataforma de análise os classificou de outra forma' como defesa de conformidade. Os dados são o que são. A classificação que os rege deve refletir isso, independentemente do sistema que os mantém.
Onde a maioria das equipes erra
A falha mais recorrente é avaliar a classificação nos sistemas principais e presumir que ela é consistente nos sistemas secundários. Um fornecedor cuja plataforma principal de gestão de dados tem uma classificação excelente pode ter plataformas de análise, data warehouses e ferramentas de colaboração com esquemas de classificação totalmente diferentes ou sem nenhuma classificação. A avaliação do sistema principal confirma a capacidade de classificação. A lacuna nos sistemas secundários continua sem ser examinada.
- Avaliar a classificação nos sistemas principais sem cobrir os sistemas secundários
- Nenhuma avaliação da propagação de rótulos: se os metadados de classificação acompanham os dados pelos pipelines
- Inconsistência entre vários esquemas não avaliada: esquemas diferentes em sistemas diferentes
- Efeito da classificação mais permissiva não avaliado: o esquema mais fraco determinando o acesso real
- Nenhuma autoridade de classificação canônica: ausência de governança da classificação entre sistemas
Como é uma boa prática
Programas maduros de classificação mantêm um esquema canônico de classificação que vale para todos os sistemas, implementam mecanismos técnicos para propagar os rótulos de classificação pelos pipelines de dados e validam a consistência da classificação entre sistemas por meio de varreduras periódicas.
- Esquema canônico de classificação entre sistemas: uma única estrutura oficial de níveis que vale para todos os sistemas
- Propagação de rótulos pelos pipelines: processos de ETL e de replicação que levam os metadados de classificação
- Validação da consistência da classificação: varreduras periódicas que confirmam que a classificação dos dados coincide entre os sistemas de origem e os secundários
- Cobertura da classificação nos sistemas secundários: plataformas de análise e data warehouses incluídos no programa de classificação
- Alinhamento dos controles de acesso à classificação canônica: controles de cada sistema calibrados ao nível canônico, independentemente da nomenclatura específica do sistema
Ferramentas
Catálogo de dados com classificação: Collibra, Alation, Microsoft Purview
Plataformas de catálogo de dados oferecem gestão canônica da classificação em vários sistemas, mantendo uma única definição de classificação que se aplica aos dados independentemente do sistema que os mantém. O Microsoft Purview, especificamente, oferece a propagação da classificação pelos pipelines de dados, levando os rótulos de sensibilidade dos sistemas de origem para os repositórios de dados conectados. Para profissionais de TPRM, perguntar se o fornecedor usa um catálogo de dados com propagação da classificação entre sistemas revela se existe governança da classificação canônica.
Qualidade e linhagem de dados: Monte Carlo, dbt, Great Expectations
Plataformas de linhagem de dados rastreiam como os dados fluem entre sistemas, permitindo identificar inconsistências de classificação ao comparar a classificação nos sistemas de origem com a classificação nos sistemas a jusante. Para profissionais de TPRM, perguntar se a consistência da classificação é validada com ferramentas de linhagem de dados é uma pergunta específica de governança entre sistemas.
Desafios de governança
O desafio de governança da consistência da classificação é o problema da responsabilidade organizacional. A equipe principal de governança de dados é dona do esquema de classificação. A equipe de análise é dona do data warehouse. A equipe de infraestrutura é dona dos pipelines de replicação. Nenhuma equipe é dona da questão de saber se a classificação é consistente entre os três. Fechar a lacuna exige uma responsabilidade multifuncional pela governança da classificação canônica que abranja todos os domínios de dados.
- Pergunte sobre a consistência da classificação entre sistemas: se o mesmo elemento de dado tem classificação consistente nos sistemas principais e secundários
- Pergunte sobre a propagação de rótulos: se os metadados de classificação acompanham os dados nos processos de replicação e de ETL
- Pergunte sobre a classificação nos sistemas secundários, especificamente warehouses e plataformas de análise
- Exija documentação da classificação canônica: um único esquema oficial que vale para todos os sistemas
Se você faz parte de uma equipe pequena
Faça aos seus fornecedores com uso intensivo de dados uma pergunta que revela a inconsistência de classificação: o nível de classificação que vocês aplicam aos dados sensíveis no sistema principal se propaga automaticamente para as plataformas de análise e os data warehouses quando esses dados são replicados, ou cada sistema classifica de forma independente? A resposta revela imediatamente se existe governança da classificação canônica ou se cada sistema opera com seu próprio esquema de classificação.
- Pergunte se os rótulos de classificação se propagam pelos pipelines de replicação e de ETL
- Pergunte se as plataformas de análise usam o mesmo esquema de classificação dos sistemas principais
- Pergunte se a consistência da classificação entre sistemas é validada por meio de varreduras
O que exigir
Pergunte diretamente:
"O nível de classificação aplicado aos dados sensíveis nos seus sistemas principais se propaga automaticamente quando esses dados são replicados para plataformas de análise ou data warehouses, ou cada sistema classifica de forma independente?"
"Qual é o esquema canônico de classificação que rege os dados em todos os seus sistemas, e a mesma estrutura de níveis é aplicada de forma consistente no seu banco de dados principal, no seu warehouse de análise e nas suas plataformas de colaboração?"
O que esperar como evidência
- Descrição do mecanismo de propagação de rótulos ou reconhecimento da lacuna
- Documentação do esquema canônico de classificação que abrange todos os sistemas
- Evidências de validação da consistência da classificação entre sistemas
Um fornecedor que responde com 'temos um esquema de classificação abrangente' deve ser questionado especificamente se esse esquema se aplica de forma consistente no data warehouse de análise e se os registros clínicos ou sensíveis classificados no nível mais alto no sistema principal têm a mesma classificação no warehouse. O esquema é a especificação. A consistência é a governança.
Como comprovar
- Registros de avaliação da consistência da classificação nos sistemas principais e secundários
- Documentação da propagação de rótulos
- Evidências de validação entre sistemas
- Documentação do esquema canônico de classificação
Principal conclusão
A classificação que rege os dados deve acompanhá-los em todos os sistemas em que estiverem. Quando isso não acontece (quando o rótulo muda à medida que os dados se movem, quando cada sistema aplica seu próprio esquema de forma independente, quando o warehouse de análise reclassifica registros de Nível 1 como dados de pesquisa porque ninguém configurou o pipeline para levar o rótulo), o programa de classificação criado para proteger os dados só os protege nos sistemas que aplicam o rótulo pretendido. A classificação mais permissiva em qualquer sistema é a classificação efetiva para todos os fins de acesso. Um rótulo que muda quando os dados se movem não é um rótulo. É uma sugestão.