Voltar ao blog Operações e conformidade

Rastros técnicos de SMS A2P: amostragem e retenção com minimização de dados

Um guia operacional para decidir o que registar, como fazer a amostragem com base no risco e como limitar o acesso e a conservação ao investigar incidentes de SMS A2P.

Diagrama de uma operação de SMS A2P que separa rastros técnicos, dados pessoais e conteúdo da mensagem

Um rastro útil também pode acumular informações sensíveis

Os rastros ajudam a reconstruir o que aconteceu numa operação de mensagens: por exemplo, comparar os eventos registados, os respetivos carimbos temporais, os estados comunicados e a rota utilizada. Essa utilidade não justifica guardar todos os dados disponíveis nem conservá-los indefinidamente.

Não existe aqui uma regra universal sobre que campos registar, que percentagem amostrar ou durante quanto tempo conservar os dados. As necessidades técnicas dependem do sistema e do tipo de incidente; as obrigações aplicáveis dependem do contexto e devem ser revistas com os responsáveis pela privacidade e a assessoria jurídica.

  • Trate o registo como uma decisão de conceção: defina uma finalidade antes de recolher dados.
  • Separe os dados necessários para diagnosticar daqueles que apenas oferecem conveniência ou contexto acessório.
  • Documente os limites do registo e as incertezas dos estados de entrega.
Um rastro útil também pode acumular informações sensíveis

Inventariar os campos antes de ativar os registos

Comece por enumerar os campos que cada componente pode produzir e quem os gera. A lista pode incluir identificadores de transação, carimbos temporais, estado comunicado, código ou texto de erro, metadados de rota e dados do destinatário. O conteúdo da mensagem deve ser considerado à parte, não como mais um campo técnico.

Não presuma que todos os campos estão disponíveis, têm o mesmo significado em sistemas diferentes ou são necessários para cada diagnóstico. Verifique o que cada interface regista realmente e como os identificadores se relacionam ao longo da cadeia. Um estado registado não equivale, por si só, a uma confirmação independente de receção no dispositivo.

  • Para cada campo, anote a origem, a finalidade, o formato, a sensibilidade e os sistemas onde fica armazenado.
  • Confirme a semântica dos estados e erros com a documentação técnica aplicável à sua integração.
  • Registe as diferenças horárias e as regras de correlação que possam afetar a reconstrução dos eventos.
Inventariar os campos antes de ativar os registos

Separar diagnóstico, dados pessoais e conteúdo

Classifique cada campo de acordo com a sua função e exposição. Um identificador interno pode facilitar a correlação, mas não deve ser considerado anónimo sem avaliar se pode ser associado a uma pessoa ou a outros registos. Um número de destino pode ser necessário em determinados casos, mas também pode identificar uma pessoa. O conteúdo pode revelar informações adicionais e, em geral, exige uma decisão explícita sobre a necessidade de o registar.

Quando for viável para a finalidade, avalie alternativas que reduzam a exposição: registar metadados em vez do conteúdo, limitar a visibilidade do destino ou utilizar identificadores pseudonimizados. A pseudonimização não torna automaticamente os dados anónimos nem elimina a necessidade de controlar o acesso e a conservação.

  • Pergunte que falha não poderia ser investigada sem cada campo e documente a resposta.
  • Evite copiar conteúdo para registos gerais, painéis ou tickets, salvo se for necessário para o caso.
  • Se uma investigação exigir conteúdo ou dados mais identificáveis, limite a recolha ao caso e às pessoas autorizadas.

Conceber a amostragem de acordo com o risco e a finalidade

Defina regras distintas para a operação normal, erros recorrentes, incidentes de maior impacto e testes controlados. Não existe uma taxa de amostragem adequada a todas as equipas: a decisão deve considerar o volume, a capacidade de investigar com uma amostra e o impacto de omitir eventos relevantes.

Para o tráfego normal, considere um registo limitado a metadados. No caso de erros, pode ser mais útil ativar uma recolha delimitada por condição do que aumentar a retenção de todo o tráfego. Para testes controlados, utilize casos autorizados e dados de teste sempre que possível. Perante incidentes, determine quem pode ampliar temporariamente a recolha, que campos serão acrescentados e quando essa ampliação será revista.

  • Especifique por escrito a população, o critério de seleção, os campos recolhidos e o período de aplicação.
  • Defina a condição que ativa uma amostra ampliada e quem pode aprová-la.
  • Aplique a amostragem e a recolha de conteúdo apenas quando forem necessárias para a finalidade definida e permitidas pelas regras aplicáveis.

Evitar conclusões enviesadas

Uma amostra pode ajudar no diagnóstico, mas não representa necessariamente todo o tráfego. Se forem registados mais eventos com erro do que entregas normais, ou se determinados destinos, horários ou rotas forem excluídos, as observações podem distorcer a interpretação.

Documente o denominador e o método de seleção: quantos eventos podiam fazer parte da população, que eventos foram incluídos e o que ficou de fora. Assim, será possível distinguir um sinal observado nos registos de uma conclusão sobre o tráfego como um todo. Não apresente uma amostra operacional como uma medição completa da qualidade ou da entrega.

  • Mantenha critérios de seleção reproduzíveis e registe as respetivas alterações.
  • Verifique se a amostra abrange as categorias relevantes para o incidente, sem presumir que uma amostra pequena as representa.
  • Separe os resultados dos testes internos de quaisquer afirmações sobre o desempenho comercial ou a receção final.

Reduzir a exposição através de controlos de acesso e separação

Os controlos devem corresponder às funções que precisam de consultar os registos. Uma equipa que diagnostica erros de transporte pode não precisar de aceder ao conteúdo da mensagem; uma revisão de privacidade pode exigir informações diferentes das necessárias para uma tarefa operacional de rotina.

Considere separar os registos técnicos dos dados mais identificáveis e limitar a correlação entre sistemas aos utilizadores autorizados. Reveja também as cópias, exportações e tickets: os controlos do sistema principal não protegem automaticamente as cópias criadas durante uma investigação.

  • Defina as funções autorizadas, os motivos de acesso e um processo para conceder e retirar permissões.
  • Limite as exportações e evite duplicar rastros completos em ferramentas de suporte.
  • Reveja a forma como os acessos são registados e quem pode aprovar consultas excecionais.

Retenção definida pela finalidade e pelo evento, não pelo hábito

Estabeleça prazos por categoria de dados e finalidade e defina qual o evento que inicia a contagem: por exemplo, a criação de um rastro ou o encerramento de uma investigação. Não adote um prazo genérico sem verificar as necessidades operacionais e as obrigações aplicáveis à sua organização e jurisdição.

Inclua um processo de eliminação que abranja os sistemas principais e as cópias sob o controlo da organização. Se houver uma exceção para uma investigação, registe quem a autorizou, por que motivo é necessária, que dados abrange e quando deve ser revista. Uma exceção temporária deve ter um desfecho definido, em vez de se transformar, por inércia, numa conservação indefinida.

  • Atribua uma finalidade, categoria, prazo aprovado, responsável e mecanismo de eliminação a cada conjunto de registos.
  • Agende a revisão das exceções em aberto e documente a decisão de encerrar, renovar ou eliminar.
  • Coordene a política com as equipas de privacidade, segurança e operações, bem como com a assessoria jurídica, antes de a aplicar.

Preservar provas durante um incidente sem as perpetuar

Quando um incidente exigir a conservação de provas adicionais, transforme a medida numa ação delimitada: identifique o caso, selecione os registos pertinentes, restrinja o acesso e designe uma pessoa responsável. Preserve o que for necessário para a investigação e evite alargar a recolha a tráfego não relacionado sem um motivo documentado.

Quando a investigação terminar, reveja a exceção e execute a decisão aprovada: elimine os dados que já não sejam necessários ou justifique formalmente qualquer conservação adicional. O registo dessa decisão ajuda a demonstrar que a conservação excecional foi revista e não simplesmente esquecida.

  • Registe o motivo, o âmbito, quem aprovou, a pessoa responsável e a data da revisão.
  • Verifique se ainda existem cópias do caso em ferramentas auxiliares.
  • Encerre a exceção com uma decisão explícita de eliminação ou com uma nova revisão devidamente justificada.
FAQ

Perguntas frequentes

Que campos deve incluir todo o rastro de SMS A2P?

Não existe aqui um esquema universal. Defina os campos de acordo com a finalidade e os componentes do seu sistema; verifique que dados cada interface produz e evite conservar campos que não ajudem a resolver um problema definido.

Deve guardar-se o conteúdo de cada SMS?

Com as informações disponíveis, não é possível estabelecer uma regra universal. Avalie se o conteúdo é necessário para uma finalidade concreta, considere alternativas menos intrusivas e reveja as obrigações aplicáveis antes de o registar.

Durante quanto tempo devem ser conservados os rastros?

Não existe um prazo único adequado a todas as organizações. Defina prazos por finalidade e categoria, estabeleça quando começa a contagem e valide a decisão com as equipas responsáveis e a assessoria jurídica.

A pseudonimização elimina o risco para a privacidade?

Não necessariamente. Um identificador pseudonimizado ainda pode ser associado a uma pessoa através de informações adicionais. Mantenha controlos de acesso, limites de utilização e uma regra de conservação.

Um estado de entrega confirma que o destinatário recebeu o SMS?

Não, por si só. Distinga o estado comunicado pelo sistema de mensagens de uma confirmação independente de receção no dispositivo e documente as limitações de cada fonte.

Fontes consultadas

  1. Protección de datos en la UE: principios y derechosComisión Europea
  2. Recomendaciones UIT-T de la serie E.164Unión Internacional de Telecomunicaciones
  3. Especificaciones técnicas 3GPP3GPP
  4. Recursos técnicos de redes móvilesGSMA