Menu de navegação

[MottaParticipante]

Prezados ,

Como tratar dados sensíveis para a LGPD ?

Digo de forma simples , apenas na camada de exibição , isto é resultado da query ?

Procurei alguma documentação de funções Oracle que possam ofuscar dados mas achei apenas funções do tipo “hash” , mas estas geram strings muita grandes para serem trabalhadas.

Existe alguma documentação que fale disto ?

[José Laurindo ChiappaModerador]

Blz ? Então, na situação normal DEPOIS que o banco de dados (seja Oracle ou seja outro!!) entregou os dados solicitados pro cliente, ACABOU a responsabilidade do banco de dados – se/como a aplicação cliente vai ou não exibir os dados, é 100% POR CONTA DELA….
Assim sendo, o que vc PODE ter no banco de dados Oracle é uma CAMADA DE SOFTWARE a mais que, imediatamente antes de entregar os dados, os embaralhe de alguma maneira – o software “Automático” que a Oracle oferece pra isso é o Oracle Data masking, vide em https://www.oracle.com/security/database-security/data-masking/ … Caso vc não tenha verba pra ele E realmente queira trabalhar isso a nível de banco de dados, a melhor Possibilidade é vc alterar a fonte de dados, tipo : vc tem uma VIEW com o mesmo nome da tabela mas o SQL da view extrai os dados ‘embaralhados’, OU então vc tem uma Função (ou Procedure , via OUT variables) que devolve os dados embaralhados e vc remove privilégios de acesso à tabela e só dá privilégios de execução na procedure/function, FORÇANDO os usuários a acessar os dados pela rotina que os embaralha….

Porém, fica o Aviso : há MUITAS tools de programação que, depois de trazer os dados pra tela do usuário via uma query qualquer, permitem que o usuário ALTERE na tela esses dados e depois, ao clicar num botão de GRAVAR, a linguagem/tool de programação Automaticamente envia esses dados alterados na tela pro banco via UPDATE – nem preciso dizer, provavelmente isso TEM que revisto, POIS vc não quer gravar 123xxxxxx como número do cartão de crédito, mas sim o número real….
Assim, provavelmente TODAS as telas da aplicação que te dão direito de alterar dados sensíveis Vão ter que ser revistas, ter a segurança reforçada só permitindo a uma pessoa de alto nível dentro da Empresa as revisar, OU MESMO (como algumas pessoas defendem) como esses dados Não Pertencem á Empresa mas sim aos Clientes dela, que simplesmente a aplicação NUNCA os altere : se houve um erro no input, que eles sejam deletados e re-inseridos pelo dono…. E sempre há Casos onde na verdade o Ideal é vc não gravar no banco os dados sensíveis – por exemplo, cartões de crédito, o Ideal (se minimamente possível) é que vc o o envie Direto pra Financeira após o input e depois simplesmente não o salve, assim EVITANDO possibilidades de vazamentos…

E, é Óbvio, a LGPD trata de Muito Mais do que simples acesso aos dados : por exemplo, vc TEM que ter AUDITORIA provando que apenas os poucos usuários realmente autorizados acessaram os dados, MESMO que eles estejam mascarados….

[]s

Chiappa

[MottaParticipante]

Grato pelo resposta mais uma vez.

Inicialmente precisava de uma ofuscação apenas para a saída dos dados mas com um problema ,

dados que seriam usados em BI é o BI indexa valores iguais assim um nome , número cliente etc só poderia ter

um valor não poderia haver colisões.

Vou pesquisar os links passados.

[José Laurindo ChiappaModerador]

Blz ? Bom, “BI” é uma expressão Absolutamente Genérica, existem Trocentas ferramentas de BI que trabalham de inúmeras maneiras diferentes, mas isso ABSOLUTAMENTE NÃO MUDA o que eu disse, que os dados Vão Ser Extraídos do database via comandos SQL, e que OU vc tem uma tool extra especializada, como o Oracle Data masking, que já faz a ‘troca’ dos dados OU vc muda a consulta dos dados, para que os dados não sejam acessados a partir das tabelas reais mas SIM a partir de um código SEU, onde VC faz a obfuscação que quiser, seja uma view, view materializada, procedure ou function, o que for….

Só um ponto adicional : como eu disse na minha resposta, IDEALMENTE teus usuários comuns e/ou tuas rotinas de data mining e BI NÃO ACESSARIAM os dados sensíveis/pessoais dos clientes (até porque via de regra quem tá minerando dados quer saber QUANTIDADE de clientes que compraram determinados produtos, LOCAIS GEOGRÁFICOS que venderam mais ou menos, etc, não faz sentido se preocupar com o Documento, o e-mail ou seja qual for o dado pessoal de CADA cliente, eu quero Agrupação por grandes indicadores, agrupar por NOME DA PESSOA não faz muito sentido)…..
Porém, se EFETIVAMENTE vc precisar MESMO incluir nos dados finais que o usuário da sua aplicação vai consumir quaisquer dados confidenciaisa dos teus clientes (NÃO É COMUM, como eu disse, mas enfim), já que o usuário da tua app não está acessando os dados reais diertmente mas sim através de uma tool de BI, eu SUPONHO que vc vai ter um código que leia os dados reais, os agrupe cfrme desejado e só depois os salve num destino permanente (uma view materializada ? uma tabela física mesmo ?) com a obfuscação necessária…Já sobre QUAIS procedimentos vc vai codificar/qual metodologia vc vai usar pra codificar a obfuscação, depende : já vi casos de strings com nomes onde o algoritmo era mostrar só o primeiro nome e o resto era mostrar só a inicial , , aí o usuário da app só via os cliente como Sr. JOAO P. S. SILVA, Sra ANA O., coisas assim… Já para dados confidenciais numéricos, ou costumo ver ser exibido só os números de início ou de fim, trocando o resto por s (tipo, CARTÂO DE CREDITO 1234.., ou TELEFONE (11) ****-123), ou cosutumo ver Anonimização dos dados, ie, se troca o dado por um número equivalente….

[]s

Chiappa

[José Laurindo ChiappaModerador]

Tipo assim : SUPONHA que por qquer motivo Absurdo seja desejado fazer um data minig que vai mostrar os TOP-3 clientes que mais compras fizeram , E que o nome desses clientes não seja um nome fantasia criado pelo sistema mas sim o nome REAL, que portanto pode ser considerado um dado sensível…. A idéia seria deixar a ferramenta mandar pro banco a query que vai fazer as agrupações cfrme necessário, aí foi encontrado que os TOP-3 clientes são :

JOAO DA SILVA
ANA OLIVEIRA
JOSE OLIMPIO XAVIER

Seria retornado pro usuário os dados obfuscados, tipo :

JOAO S.
ANA O.
JOSE O. X.

Como eu disse, há muitas maneiras de se operacionalizar isso, UMA delas poderia ser mandar a tool de BI executar uma PROCEDURE DE BANCO que dispara a query real, recebe o resultset, faz a Obfuscação e depois popula uma tabela com esses dados obfuscados, aí é ESSA tabela que a tool de BI usa pra mostrar o dashboard / dados pro usuário da sua app… Outra poderia ser uma view materializada, talvez….

[]s

Chiappa

[MottaParticipante]

Neste caso especifico precisa ao mesmo tempo do detalhe e do ofuscamento , coisa do negócio , não estranhe.

Tenho de estudar melhor o assunto mas as dicas já foram boas.

Mas concordo com você que a função do banco e guardar e entregar o dado.

A lei brasileira se junta a outras legilações o que tofnaco problema comum gerando soluções.

Abraço.
<p style=”text-align: right;”></p>

[José Laurindo ChiappaModerador]

OK… Bom, como no seu caso as suas necessidades parecem ser MUITO particulares, acredito que as suas soluções vão ter que ser múltiplas, específicas para cada dado : para alguns dados vc pode contornar a necessidade de acesso ao dado real (digamos, ao invés de usar o nome real do cliente usa um NOME FANTASIA, criado pelo sistema, que seria, talvez, o nome abreviado Concatenado com o ID numérico de cliente, pra dar unicidade, sei lá) E para outros casos a solução seria ter um código (protegido, seguro, onde os usuários finais só tenham priv de execute) que ACESSA o dado real e faz as manipulações / agrupamentos / etc necessárias MAS grava na tabela de trabalho que os usuários finais vão acessar pela app dados obfuscados (novamente concatenando com algum tipo de ID numérico pra garantir unicidade, se for o caso), E (para alguns POUCOS casos, como cartão de crédito, senha de usuário, digamos) vc simplesmente não guarda o dado permanentemente no banco – uma vez enviado o cartão de crédito pra financeira, a informação não presiste, por exemplo…..
O importante na LGPD é que ter PROVAS (via dump de dados, regras de modelagem, etc) de quais dados que podem ser considerados sensíveis vc armazena (não, não adianta vc ‘esconder’ que a coluna guarda CPF das pessoas renomeando a coluna para LIXO_AUXILIAR, vc TEM que extrair um apanhado dos dados PROVANDO que o conteúdo não é sensível) E COMPROVAR, via Auditoria, que ninguém tem acesso aos dados sensíveis dos usuários que porventura vc TENHA que armazenar….

[]s

Chiappa

[MottaParticipante]

Tenho que começar mapeando os dados.

Não adianta mesmo começar pelo “fim”.

Valeu + uma vez.

[Autor]

Posts