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

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

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.

...

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 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 procura pesquisa no banco de dados e com isso é como se fosse , 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 em forma de demonstrando Formato, Exemplos e Regras de uso.

...

Bloco de código
languagedelphi
themeEmacs
{SELECT} FROM [<tabela1, tabela2, ..., tabelaN>] WHERE tabela1.codigo = tabela2.codigo AND tabela2.coluna = {<IDENTFICADOR>}


(ideia) Exemplos:

Informações
iconfalse

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:

...

A CONDIÇÃO de anonimização é apenas uma parte de uma instrução SQL que compete compreende a uma condição de filtro da cláusula WHERE a ser agregada juntamente a QUERY 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.

...

titleIMPORTANTE

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?

...

.

...

A

...

cláusula WHERE

...

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

...

da

...

condição

...

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

...

de anonimização

...

Bloco de código
languagepowershell
themeEclipse
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.

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 registrados detalhados abaixo em forma de com Formato, Exemplos e Regras de uso.

...

Bloco de código
languagedelphi
themeEmacs
AND tabela1.dat_conclusao IS NULL OR tabela1.dat_conclusao > {TEMPO}

(ideia) Exemplos:

Informações
iconfalse

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:    ANDwms_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:

...

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


Informações
titleIMPORTANTE

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:  

Bloco de código
languagepowershell
themeEclipse
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, haverá em breve uma forma de validar isso, pois já existe planejamento de implementação de uma melhoria que permitirá validar a query de uma consulta e condição de anonimização, qua talvez seja no formato de um botão de validação das instruções 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 consulta de Mapeamento de Campos por Vínculo do Titular (LOG10003) e Mapeamento de dados Tabelas por Vínculo do Titular (LOG10003LOG10004), ambos com atalhos disponíveis a partir da Central de Campos Protegidos (LOG10005)


Informações
iconfalse

Assim (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 comunicaremos pelos canais de comunicação interna 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)