Um guia prático de Quando as plataformas analíticas violam seus dados

Este guia explica Quando as plataformas analíticas violam seus dados na prática, com foco em decisões de analytics que respeitam a privacidade.

As violações de dados analíticos raramente são tratadas com a urgência de vazamentos de cartões de pagamento ou roubo de credenciais. Isso é um erro. As plataformas analíticas podem conter URLs, termos de pesquisa, referenciadores, campanha IDs, localização derivada de IP, eventos de conta, uso de produto e, às vezes, identificadores de nível de usuário. No contexto errado, esses dados podem revelar clientes, estratégia, interesses de saúde, funis de aquisição ou comportamento confidencial de produtos.

A questão jurídica também é clara: ao abrigo da GDPR, uma violação de dados pessoais inclui destruição, perda, alteração acidental ou ilegal, divulgação não autorizada ou acesso a dados pessoais. O responsável pelo tratamento deve avaliar o risco e poderá ter de notificar a autoridade de controlo no prazo de 72 horas nos termos do artigo 33 e as pessoas afetadas nos termos do artigo 34. O fato de um fornecedor ter causado o incidente não elimina a responsabilidade do controlador.

Como são as violações de análise

Nem todo incidente é um hacker filtrando um banco de dados. Os incidentes de análise geralmente resultam de falhas operacionais comuns:

• Um painel multilocatário exibe os dados de um cliente para outro cliente.
• O registro de depuração armazena URLs completo contendo e-mails, tokens de redefinição ou parâmetros de consulta de integridade.
• Uma exportação mal configurada do BigQuery, S3 ou data warehouse torna-se pública.
• A equipe de suporte pode acessar fluxos de eventos brutos sem motivo comercial.
• Um gerenciador de tags carrega um script não aprovado que copia os dados do evento para terceiros.
• Um fornecedor subprocessa dados em um país que não foi coberto pelo contrato ou pela avaliação de transferência.

Esses incidentes são dolorosos porque os dados analíticos geralmente são amplos. Um script de rastreamento pode afetar cada página e cada jornada do usuário.

A soberania dos dados é mais do que a localização do servidor

A soberania dos dados significa que você entende quais leis, empresas, pessoas e infraestrutura podem afetar seus dados. Hospedar-se em Frankfurt ou Dublin é útil, mas não responde a todas as perguntas. Você ainda precisa saber a jurisdição corporativa do provedor, subprocessadores, acesso de suporte remoto, modelo de criptografia, processo de resposta a incidentes e se os dados podem ser transferidos fora do EEA.

Para os dados pessoais da EU, as transferências internacionais são regidas pelo GDPR Capítulo V. As transferências podem depender de uma decisão de adequação, de cláusulas contratuais padrão, de regras corporativas vinculativas ou de outro mecanismo aprovado. Depois de o Tribunal de Justiça ter invalidado o Privacy Shield no Schrems II, as organizações também tiveram de considerar se eram necessárias medidas suplementares para transferências para países com riscos de vigilância. A Estrutura de Privacidade de Dados EU-US já existe, mas se aplica apenas a organizações US certificadas e continua sendo uma área de risco que deve ser monitorada.

Por que a infraestrutura compartilhada muda o modelo de risco

A maioria das plataformas analíticas SaaS são multilocatários. Isso é normal, mas torna o isolamento dos inquilinos um controle crítico. Você deseja evidências de que os dados do cliente estão separados nas camadas de aplicativo, banco de dados, controle de acesso, registro, backup e suporte.

Peça aos fornecedores respostas precisas:

• Os locatários estão separados por banco de dados, esquema, permissões em nível de linha ou lógica de aplicativo?
• A equipe pode consultar diretamente os eventos brutos do cliente?
• As sessões de acesso à produção são registradas e revisadas?
• As exportações são criptografadas em repouso e em trânsito?
• Como os backups são isolados e excluídos?
• O que acontece se a configuração de um locatário for aplicada acidentalmente a outro?

Se um fornecedor não consegue explicar claramente a separação dos inquilinos, isso é um risco de aquisição, e não uma peculiaridade de documentação.

Preparação para incidentes para dados analíticos

Um plano prático de incidentes analíticos deve definir o que é considerado reportável, quem faz a chamada e com que rapidez as evidências podem ser coletadas. Inclua análises em seus exercícios de violação. A investigação deve responder:

1. Quais conjuntos de dados foram expostos ou alterados?
2. Os dados incluíam dados pessoais, identificadores pseudônimos ou URLs confidenciais?
3. Quantas pessoas e contas foram afetadas?
4. Os dados poderiam ser vinculados a indivíduos?
5. Os dados foram acessados ​​por outro cliente, funcionário de um fornecedor, público ou invasor?
6. São necessárias notificações ao regulador ou ao cliente?
7. Quais registros comprovam a contenção?

As diretrizes de notificação de violação do EDPB são úteis porque se concentram no risco e não nos rótulos.

Como reduzir a exposição antes de um incidente

O controle mais forte é a minimização. Não envie dados pessoais para análises, a menos que você realmente precise deles. Evite coletar URLs completo se URLs puder conter entradas do usuário. Remova os parâmetros de consulta por padrão e permita apenas parâmetros de campanha aprovados. Nunca coloque e-mails, números de telefone, nomes, tokens ou valores de formulário de texto livre nas propriedades do evento.

Em seguida, reduza a retenção. Mantenha os dados brutos do evento apenas enquanto forem operacionalmente úteis e depois agregue. Uma janela de eventos brutos de 30 ou 90 dias pode ser suficiente para depuração e análise de funil, enquanto os relatórios agregados mensais podem ser retidos por mais tempo.

Por fim, prefira arquiteturas que limitem o acesso de terceiros. Para algumas equipes, isso significa um SaaS com privacidade em primeiro lugar, hospedado pelo EU, com contratos fortes e sem identificadores entre sites. Para equipes regulamentadas ou do setor público, isso pode significar infraestrutura auto-hospedada ou dedicada, chaves de criptografia gerenciadas pelo cliente e aprovações rigorosas de acesso ao suporte.

Perguntas de due diligence do fornecedor

Antes de escolher uma plataforma analítica, peça:

• Um contrato de processamento de dados e uma lista de subprocessadores.
• Documentação de residência e transferência de dados.
• Certificações de segurança ou auditorias independentes, quando disponíveis.
• Um compromisso de notificação de violação com prazos.
• Uma política de retenção e exclusão.
• Uma lista de campos e identificadores coletados.
• Suporte para desabilitar cookies, armazenamento IP, impressão digital e rastreamento no nível do usuário.
• Fluxos de trabalho de exportação e exclusão se você sair.

A análise deve reduzir a incerteza. Se a própria plataforma criar incerteza jurídica, de segurança e de soberania, a ferramenta estará trabalhando contra o negócio.

Lista de verificação de análise pronta para incidentes

Prepare-se para incidentes analíticos antes que eles aconteçam. Mantenha um mapa de dados atualizado, lista de fornecedores, lista de subprocessadores, cronograma de retenção, log de acesso, caminho de exportação e rota de contato para avisos de segurança. Incluir ferramentas analíticas em exercícios de mesa de violação.

Reduza o raio de explosão coletando menos identificadores, excluindo URLs e eventos confidenciais, reduzindo a retenção de dados brutos, limitando o acesso ao painel e preferindo fornecedores que possam explicar a separação de locatários, o acesso de suporte e a localização de dados em termos concretos.