Linha Logix

Páginas filhas
  • DICAS Cadastro de instruções SQL consulta X anonimização de dados


INTRODUÇÃO


No LOGIX dispomos de informações cadastrais de tabelas e colunas do banco de dados no controle de dados protegidos para atender a Lei Geral de Proteção de Dados. No entanto, para que seja possível a consulta aos dados protegidos registrados, existem duas telas para esse registro que são:

  • Mapeamento de Tabelas por Vínculo de Titular a partir da tela LOG10004.

Neste mapeamento existem queries no padrão SQL que são cadastradas para cada Tabela X Tipo de Informação com objetivo de permitir que o LOGIX possa rastrear as informações de registros de dados gravados na base de dados ligados a uma pessoa física, seja por meio de um número do CPF, endereço de e-mail, número de CNH, RG, ou outros dados que são conhecidos como IDENTIFICADORES. 

  • Mapeamento de Campos por Vínculo de Titular a partir da tela LOG10003.

Neste mapeamento existem as mesmas queries registradas no LOG10004, no entanto este mapeamento de campos também permite registrar as condições também no padrão SQL utilizadas para indicar permissão ou não para anonimizar o conteúdo de campos protegidos registrados na base de dados Logix, onde o sistema acaba utilizando a query de consulta registrada no LOG10004 juntamente com a condição de anonimização informada.


O que são os IDENTIFICADORES no controle de dados protegidos?


Conforme mencionado anteriormente, os IDENTIFICADORES são Tipos de Informações que identificam dados de pessoas físicas que o Logix armazena e utiliza como referência para pesquisar registros cadastrados em tabelas na base de dados.

Estes IDENTIFICADORES podem ser:

  • CPF
  • RG
  • CNH
  • TITULO DE ELEITOR
  • PIS
  • TELEFONE
  • NOME
  • E-MAIL
  • ENDEREÇO PESSOAL
  • entre outros.


Nos programas LOG10003 e LOG10004, disponíveis no produto a partir do pacote LOGIX 12.1.2205, esta informação aparece no campo Tipo de Informação e também é usada nas queries SQL de consulta e condição de anonimização.


Como os IDENTIFICADORES são informados nas queries SQL de consulta e anonimização de dados protegidos?


Toda Instrução SQL registrada no Logix, tanto para consulta de dados quanto para condição de anonimização de um dado protegido, obrigatoriamente deve ter uso obrigatório do IDENTIFICADOR (Tipo de Informação) válido utilizado no seu conteúdo.

O formato obrigatório das QUERIES utilizadas neste controle são iguais tanto para consulta quanto anonimização, mas com algumas pequenas características diferentes citadas a seguir:


QUERY SQL DE CONSULTA DE DADOS

Conceito

A QUERY SQL para consulta de dados é a parte inicial de todo o processo de pesquisa no banco de dados, que funciona como uma instrução SELECT completa, no entanto ela segue alguns critérios e padrões para registro no Mapeamento de Campos por Vínculo do Titular (LOG1003) que estão registrados abaixo demonstrando Formato, Exemplos e Regras de uso.


{SELECT} FROM [<tabela1, tabela2, ..., tabelaN>] WHERE tabela1.codigo = tabela2.codigo AND tabela2.coluna = {<IDENTFICADOR>}


(ideia) Exemplos:

TABELA: usuarios                VÍNCULO DO TITULAR: Usuário do Sistema


Exemplo 1:    {SELECT} FROM usuario WHERE usuarios.e-mail = {E-MAIL}


Exemplo 2:    {SELECT} FROM log_usuarios_compl WHERE cpf_login = {CPF:formatOnlyNumeric}



Regras de uso para toda QUERY SQL de consulta de dados:

  • Deve sempre iniciar com a TAG {SELECT} pois durante a execução das buscas de dados, o sistema irá automaticamente identificar a lista de colunas que será selecionada de acordo com o Vínculo de Titular que estiver sendo feita a busca de dados. Portanto, nunca preencha nomes de colunas antes ou depois da TAG {SELECT}.
  • Respeitar o nome do IDENTIFICADOR exatamente da forma como está descrito na lista padrão de todos identificadores disponíveis.
  • Todo IDENTIFICADOR deve obrigatoriamente estar escrito SEMPRE em caixa ALTA, entre chaves { } e SEM ESPAÇOS em branco no início e final. Exemplos:  {CPF} {RG} {CNH}
  • NUNCA usar ASPAS DUPLAS. Neste caso SEMPRE utilize ASPAS SIMPLES para delimitar conteúdos de tipo alfanumérico.
  • Tente seguir as regras de caixa ALTA e baixa, para manter uma visualização mais hamônica das instruções. Isso trará um efeito visual muito mais bonito quando for realizar a consulta em tela destas instruções. (sorriso)
  • Observe que de ambos IDENTIFICADORES representados em AZUL nos exemplos acima, um deles está escrito diferente que é {CPF:formatOnlyNumeric}. O motivo deste conteúdo diferenciado após o IDENTIFICADOR CPF é que os identificadores sempre chegam nas queries em um formato padrão, ou seja, no caso do CPF, por exemplo, o valor sempre chegará com o conteúdo de um número de CPF contendo os caracteres de máscara onde existem pontos e hífen. No entanto, caso a informação deste IDENTIFICADOR precise ser formatado para garantir a correta pesquisa do dado com o qual foi comparado na QUERY, basta informar o nome de uma função 4GL disponível no RPO do produto Logix que irá realizar a formatação ou até transformar este valor em outro valor que seja necessário para a consulta e que não seja possível buscá-la utilizando instrução SQL. Com isso o formato de um IDENTIFICADOR na query passa a ter 2 formatos possíveis sendo:

{IDENTIFICADOR}     ou    {IDENTIFICADOR:função4GL}

Onde:

      • O identificador continua escrito em caixa ALTA e delimitado por { } (chaves)
      • Após o nome do IDENTIFICADOR é possível informar o nome de uma função 4GL disponível no RPO do produto Logix que obrigatoriamente deve receber um parâmetro único que será o valor do IDENTIFICADOR que é recebido no ato do processamento da consulta no sistema e deverá também ter um único retorno obrigatório que fará com que o valor do IDENTIFICADOR seja substituído pelo valor retornado pela função durante o processamento da consulta.
      • O retorno NUNCA deverá voltar com o conteúdo contendo aspas, pois o sistema já coloca as aspas de delimitação de dados e para campos numéricos a princípio não ocorrerá erros pois não existirão espaços em branco e os bancos de dados geralmente resolvem este tipo automaticamente, ignorando as aspas.
      • A função4GL, quando utilizada junto ao nome do IDENTIFICADOR, deverá ser uma função especificamente mapeada e desenvolvida para atender as queries de CONSULTA e ANONIMIZAÇÃO dos dados protegidos, para evitar que qualquer alteração futura impacte diretamente nas informações processadas pelo TPD (TOTVS Privacidade de Dados).

(aviso) Caso a função seja inválida, ocorrerá falha na execução da consulta desta respectiva QUERY e o sistema irá registrar em LOG de processamento todas situações de falhas ocorridas. (aviso)


Funções 4GL para uso QUERY de consulta de dados:

Foram disponibilizadas algumas funções padrões no produto Logix que permite ajustar o valor do conteúdo dos IDENTIFICADORES:


CONDIÇÃO DE ANONIMIZAÇÃO DE DADOS

Conceito

A CONDIÇÃO de anonimização é apenas uma parte de uma instrução SQL que compreende a uma condição de filtro da cláusula WHERE a ser agregada junto à QUERY de Consulta de Dados registrada para a ligação Tabela X Vínculo do Titular.

Esta condição WHERE pode ser vista como um COMPLEMENTO da QUERY Consulta de Dados que será utilizada para identificar quando determinada coluna de uma determinada Tabela X Vínculo do Titular, pode ter seu conteúdo anonimizado de acordo com a sua Classificação.

A cláusula WHERE da condição de anonimização segue alguns critérios e padrões para registro no Mapeamento de Campos por Vínculo do Titular que estão detalhados abaixo com Formato, Exemplos e Regras de uso.


AND tabela1.dat_conclusao IS NULL OR tabela1.dat_conclusao > {TEMPO}

(ideia) Exemplos:

TABELA: wms_docum_saida                VÍNCULO DO TITULAR: Destinatário


Exemplo 1:    AND wms_docum_saida.dat_hor_emissao > {TEMPO} AND EXISTS (SELECT 1 FROM tabela2 WHERE tabela2.codigo = tabela1.codigo AND table2.situacao IN ('A','P','S') )


Exemplo 2:    AND wms_docum_saida.dat_hor_emissao > {TEMPO:formatDateAsDBDttimeY2S} AND EXISTS (SELECT 1 FROM tabela2 WHERE tabela2.codigo = tabela1.codigo AND table2.situacao IN ('A','P','S') )


OBS: A query de exemplo não reflete necessariamente uma condição real registrada no sistema, apenas foi usada para exemplificar o padrão das regras de uso.


Regras de uso para toda QUERY de condição de anonimização de dados:

  • Pode usar o mesmo padrão da query de consulta onde pode iniciar com a TAG {SELECT} pois durante a execução das buscas de dados, o sistema irá automaticamente ignorar a query de consulta e refazer a pesquisa usando apenas a QUERY registrada na condição de anonimização.
  • Pode iniciar com uma condição AND ou OR, que neste caso o sistema irá utilizar como um complemento da QUERY de consulta de dados registrada para o mesmo Vínculo de Titular.
  • O uso de IDENTIFICADORES, quando utilizados, segue o mesmo padrão da query de consulta de dados.
  • NUNCA usar ASPAS DUPLAS. Neste caso SEMPRE utilize ASPAS SIMPLES para delimitar conteúdos de tipo alfanumérico.
  • Tente seguir as regras de caixa ALTA e baixa, para manter uma visualização mais hamônica das instruções. Isso trará um efeito visual muito mais bonito quando for realizar a consulta em tela destas instruções. (sorriso)
  • No exemplo acima temos o uso de um TAG chamado {TEMPO}. Neste caso ele NÃO É UM IDENTIFICADOR mas sim um TAG que assumirá o valor de uma data que é calculada automaticamente pelo sistema com base na data corrente onde está sendo realizado o processamento, onde no ato de uma validação de anonimização de dados considerando o TEMPO DE GUARDA registrado no cadastro da condição SQL de anonimização do dado de acordo com a Classificação do Dado registrada para a Tabela / Campo e Vínculo do Titular.
  • Observe que de ambos TAGS representados em VERMELHO ESCURO nos exemplos acima, um deles está escrito diferente que é {TEMPO:formatDateAsDBDttimeY2S}. O motivo deste conteúdo diferenciado após o TAG TEMPO é que a data calculada automaticamente com base no TEMPO DE GUARDA chegará na querie de condição de anonimização em um formato padrão de DATA, respeitando o formato de data do banco de dados que estiver em uso. No entanto, caso a informação deste TAG de  precise ser formatado em outro formato, como por exemplo DATETIME YEAR TO SECOND para garantir que não ocorrerá falha na comparação com a coluna de tabela do banco de dados por conflito de formato da coluna, basta informar o nome de uma função 4GL disponível no RPO do produto Logix que irá realizar a formatação ou até transformar este valor em outro valor que seja necessário para a consulta e que não seja possível buscá-la utilizando instrução SQL, lembrando apenas de retornar o valor no formato aceito para o banco de dados em uso. Com isso o formato do TAG TEMPO na query passa a ter 2 formatos possíveis sendo:

{TEMPO}     ou    {TEMPO:função4GL}

Onde:

      • O TAG continua escrito em caixa ALTA e delimitado por { } (chaves)
      • Após o nome do TAG TEMPO é possível informar o nome de uma função 4GL disponível no RPO do produto Logix que obrigatoriamente deve receber um parâmetro único que será o valor da DATA que o sistema irá calcular com base no TEMPO DE GUARDA registrado para o dado e Classificação em questão, que é recebido no ato do processamento da consulta no sistema e deverá também ter um único retorno obrigatório que fará com que o valor do TAG seja substituído pelo valor retornado pela função durante o processamento da consulta. Lembre-se que neste caso precisa ser o valor de um DATE ou DATETIME no formato aceito pela respectiva coluna.
      • O retorno NUNCA deverá voltar com o conteúdo contendo aspas, pois o sistema já coloca as aspas de delimitação de DATE e DATETIME automaticamente.
      • A função4GL, quando utilizada junto ao  TAG TEMPO, deverá ser uma função especificamente mapeada e desenvolvida para atender as queries de CONSULTA e ANONIMIZAÇÃO dos dados protegidos, para evitar que qualquer alteração futura impacte diretamente nas informações processadas pelo TPD (TOTVS Privacidade de Dados).

(aviso) Caso a função seja inválida, ocorrerá falha na execução da consulta desta respectiva QUERY e o sistema irá registrar em LOG de processamento todas situações de falhas ocorridas. (aviso)


Funções 4GL para uso na CONDIÇÃO de anonimização de dados


Foram disponibilizadas algumas funções padrões no produto Logix que permite ajustar o valor do conteúdo do TAG TEMPO:


IMPORTANTE

A condição de anonimização é obrigatória para todo campo protegido cadastrado?

NÃO. Ela apenas é informada para campos (colunas de tabelas) marcados como Anonimizáveis no cadastro LOG10000 (Cadastro de Dados Protegidos)


Quando a condição de anomimização deve ser informações?

Quando existir alguma situação em que a anonimização do conteúdo da coluna da tabela, marcada como anonimizável, não puder ser anonimizado, por alguma restrição LEGAL.

Exemplo: A legislação Brasileira prevê que um determinado dado deve ser mantido por um período mínimo de 5 anos para efeitos de fiscalização pela Receita Federal. Neste caso a cláusula WHERE deverá pesquisar por dados ligados ao registro da tabela onde esta informação de coluna está prestes a ser anonimizado, para avaliar que não existam informações ligadas ao dado e que estejam registradas com um período menor do que 5 anos. 


Qual deve ser o resultado da cláusula WHERE para permitir a anonimização?

Para permitir a anonimização do dado, o resultado da cláusula WHERE deve ser verdadeiro, ou seja, deve ser uma condição válida para que o processo de anonimização prossiga.

Exemplo: Anomização de informações de um funcionário desde que:

        • não seja mais funcionário;
        • não possua pendencias de contas a receber da empresa;
        • todos pagamentos realizados tenha sido realizados a mais de 2 anos.

Condição de anonimização:  

AND funcionario.situacao = "DEMITIDO" 
AND NOT EXISTS (SELECT 1 FROM pgtos_funcionario.matricula = funcionario.matricula 
                   AND (pgtos_funcionario.situacao = "PENDENTE" 
                    OR (pgtos_funcionario.situacao = "PAGO" AND pgtos_funcionario.dat_pgto >= {TEMPO}) ) )

Veja que na condição acima foram satisfeitas as 3 condições descritas no exemplo e se esta condição for SATISFEITA, indicará que o funcionário está demitido e nao possui pendencias de pagamentos a receber e nem possui valores recebidos nos ultimos 2 anos e com isso o conteúdo da coluna da tabela poderá ser anonimizado de acordo com a Classificação do Dado e o Vínculo do Titular para qual foi solicitada a anonimização.



Como consigo identificar se a QUERY de consulta e anonimização serão executadas com sucesso no banco de dados?


Durante a fase de testes de uma consulta e anonimização para saber se a query não possui falhas e como saber como o dados serão dispostos, no ato em que a query é modificada, ao tentar confirmar a gravação da inclusão ou alteração é feita a validação tanto da query de consulta, quanto da condição de anonimização a partir do programa de Mapeamento de Campos por Vínculo do Titular (LOG10003) e Mapeamento de Tabelas por Vínculo do Titular (LOG10004), ambos com atalhos disponíveis a partir da Central de Campos Protegidos (LOG10005)


(seleção) Atualmente não estão disponíveis os botões para manutenção de dados a partir das telas LOG10003 e LOG10004, mas assim que esta opção estiver disponível em pacote oficial Logix informaremos pelas documentações de Notas de Release e também ajustaremos esta documentação.


Informações Complementares


TOTVS Privacidade de Dados

Mapeamento de tabelas por vínculo do titular (LOG10004)

Mapeamento de campos por vínculo do titular (LOG10003)

Configurador de dados pessoais e sensíveis (LOG10000)