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 Proteção de Dados. No entanto, para que seja possível a consulta aos dados protegidos registrados existe um cadastro de mapeamento de dados , 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 algumas informações dados de pessoas físicas que o Logix utilizará armazena e utiliza como referência para pesquisar dados 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.

No programa LOG10003 disponível 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  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 QUERY 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 de no mínimo um IDENTIFICADOR 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 citados 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>}

...

Exemplos:

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 { } , sem espaços 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 algum conteúdo do 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.
• 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).

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.

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:

• • formatCPFasCNPJ
  • formatNoMaskCPFasCNPJ
  • formatNoBlankSpace
  • formatOnlyNumeric
  • formatOnlyAlphaNumeric

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}

Exemplos:

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.
• 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).

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.

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:

• • formatDateAsDbDate
  • formatDateAsDbDttimeY2S
  • formatDateAsDbDttimeY2M
  • formatDateAsDbDttimeY2Y 

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}) ) )

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)

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)

• Respeitar a descricao principal do IDENTIFICADOR exatamente da forma como é apresentado na lista padrão de todos identificadores disponíveis.
• Deve estar entre chaves { }, sem espaços em branco no início e final. Exemplos:  {CPF} {RG} {CNH}

Sintaxe

formatOnlyNumeric( [ <l_value> ] ) => CHAR

Parâmetros

l_value

Retorno

...

Tipo

...

Descrição

...

CHAR

...

Conteúdo numérico recuperado do valor original enviado como parâmetro.

Exemplo

#------------------------------------------------#
FUNCTION formatOnlyNumeric_test()
#------------------------------------------------#

   #Extrair a máscara de edição de um CEP
   CALL conout("O valor do CEP 89.222-543 sem máscara de edição é: "||formatOnlyNumeric("89.222-543"))

END FUNCTION

Observações

Disponível a partir do Logix 12.1.2205