Ir para o conteúdo
  • Revista PROGRAMAR: Já está disponível a edição #60 da revista programar. Faz já o download aqui!

knightcoder

GDPR - Impactos no software

Mensagens Recomendadas

Rui Carlos
Em 3/23/2018 às 12:38, CJCV disse:

o direito a ser "esquecido" nestas aplicações é uma flag , para que surja um alerta de cliente / funcionário inactivo , apagar dados está fora de questão imho , até porque a AT não permite isso.

Diria que depende dos dados que guardas na aplicação.  É normal as aplicações permitirem guardar mais dados do que os legalmente exigidos.  Por exemplo, um contacto de email ou telefónico, uma morada de envio de encomendas (que não a morada de facturação), etc.  E nestes casos tenho dúvidas que possas invocar que a AT (ou a legislação, para ser mais genérico) não eliminar os dados.

Não conheço em detalhe a legislação associada à facturação actualmente, mas esperava que pudesses seguir fazer algo na linha do que o @M6 sugeriu, e conseguisses apagar praticamente todos dos dados do cliente na tabela dos clientes.  É claro que muito provavelmente o cliente terá informação replicada na(s) tabela(s) das facturas, mas aí já podes invocar a base legal para não apagar os dados.  Mesmo aqui, tenho ideia que a legislação só obriga a manter os dados das facturas por um certo número de anos, certo?  Nesse caso também convém que a aplicação esteja preparada para remover os dados antigos.

A solução da flag faz sentido para implementar restrições ao processamento, que também é algo que as pessoas podem solicitar em alguns casos: https://gdpr-info.eu/art-18-gdpr/

20 horas atrás, knightcoder disse:

Tenho algumas dúvidas sobre os logs de acesso a dados.

Que nível de log estão a manter nas vossas aplicações: Quem acedeu, quando acedeu e a que informação acedeu?

Como "logar" por exemplo a consulta de um relatório de "Vendas por cliente"? Devemos guardar os código de todos os clientes listados nesse relatório?

Uma abordagem é registares os parâmetros que foram usados para gerar o relatório (por exemplo, "Vendas por cliente, para datas entre X e Y, da região Z").  Convém que depois consigas inferir quais os valores que aparecem no relatório.

Colocar códigos de clientes nos logs parece-me uma coisa a evitar (pois estes códigos tendem a ser também dados pessoais, que convém não "espalhar").

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
M6
On 3/23/2018 at 4:47 PM, apocsantos said:

Boa tarde,

Ora bem, se eu souber que XPTO fez as seguintes compras cá, nos seguintes, dias, às seguintes horas, dependendo do numero de clientes, consigo identificar de forma razoável, quem é o sujeito, mesmo com "todos os campos a branco"! ;) Por outro lado, com um pouco de cruzamento de dados de diversas fontes, continuo a conseguir identificar ou isolar a quantidade de potenciais "candidatos" a serem o sujeito em causa! Ainda que tudo isto acautelado, pelas compras, consigo fazer uma dedução razoável de um perfil económico, social e psicológico do sujeito que fez as compras, portanto, fica tudo uma beka "pantanoso"! ;) Um bocado como o que acontece com o "cartão continente"! ;)

Cordiais cumprimentos,
Apocsantos

Correto.
E podes usar essa informação uma vez que ela não identifica de forma unívoca uma pessoa. Quando identificas "de forma razoável" não estás a identificar de forma unívoca, e podes usar essa informação num DW por exemplo, onde és apenas um número.

Quando usa o "cartão continente" já meteste a cruzinha do local do consentimento, ou seja, já disseste legalmente que podem usar os teus dados pessoais.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
M6
On 3/23/2018 at 4:50 PM, knightcoder said:

Tenho algumas dúvidas sobre os logs de acesso a dados.

Que nível de log estão a manter nas vossas aplicações: Quem acedeu, quando acedeu e a que informação acedeu?

Como "logar" por exemplo a consulta de um relatório de "Vendas por cliente"? Devemos guardar os código de todos os clientes listados nesse relatório?

É uma excelente questão.

Neste momento mantenho algo relativamente simples: quem criou e quando e quem fez uma alteração e quando (o que nem está propriamente relacionado com o RGPD). Ou seja, não mantenho dados de consulta uma vez que "by design" só acede à informação quem tem de aceder à informação, pelo que é irrelevante manter quem e quando acedeu a quê.
Atenção que isto é válido no caso dos nossos sistemas, em que não nos parece que necessitemos de um log tão forte.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
knightcoder
Em 23/03/2018 às 12:38, CJCV disse:

o direito a ser "esquecido" nestas aplicações é uma flag , para que surja um alerta de cliente / funcionário inactivo , apagar dados está fora de questão imho , até porque a AT 

não permite isso.

Esta situação pode ser um pouco mais complicada: vamos imaginar que eu vou a uma loja fazer compras, pedi fatura com NIF, nome e morada, mas também dei o meu e-mail e telefone para receber campanhas (tudo devidamente autorizado).

Passado algum tempo peço para ser esquecido. A aplicação deve descaracterizar todos os meus dados, mas internamente deve manter os dados estritamente necessários para emitir o SAF-T ou reimprimir a fatura (mas não devem ser mostrados no interface da aplicação)

Na prática as aplicações devem separar o armazenamento/tratamento de dados fiscais dos restantes dados pessoais.

Editado por knightcoder
  • Voto 1

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
CJCV
11 horas atrás, knightcoder disse:

Esta situação pode ser um pouco mais complicada: vamos imaginar que eu vou a uma loja fazer compras, pedi fatura com NIF, nome e morada, mas também dei o meu e-mail e telefone para receber campanhas (tudo devidamente autorizado).

Passado algum tempo peço para ser esquecido. A aplicação deve descaracterizar todos os meus dados, mas internamente deve manter os dados estritamente necessários para emitir o SAF-T ou reimprimir a fatura (mas não devem ser mostrados no interface da aplicação)

Na prática as aplicações devem separar o armazenamento/tratamento de dados fiscais dos restantes dados pessoais.

vamos lá complicar mais : garantias de equipamentos , como é ? 

tem de existir uma ligação do nº serie ao cliente , até  em casos de  necessidade de recolha de equipamentos em que foram detectadas falhas de fabrico .

eliminar dados de clientes não me parece boa ideia , bloquear acesso , excluir de campanhas de marketing tudo bem.

ou está prevista uma fiscalização aos softwares de faturação  para verificarem se cumprem o GPDR ? :P

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
M6

Eh pá, vocês estão a ligar o "complicómetro" e a arranjar cenários para justificar ou encontrar buracos que além de não existirem, não fazem qualquer sentido.

Vamos lá ver.

Como já expliquei acima, a questão da legalidade justifica, só por si, a existência e manutenção dos dados dos clientes num sistema.
A sua descaracterização não é necessária dado que nem sequer é possível ser esquecido como estão a pensar: uma empresa tem de guardar papelada durante 10 anos, por isso esqueçam pedir para o vosso NIF ser esquecido 2 dias depois de uma compra. Se vos pedirem um contacto, vocês só o dão se quiserem, não são obrigados e isso sim, podem pedir para ser eliminado, mas isso não tem qualquer impacto. Portanto essa situação da fiscalização dos softwares de faturação para verificação de cumprimento do RGPD não faz qualquer sentido!

As garantias do equipamento é outra situação que não tem qualquer sentido. Eu chego à marca para arranjar e mostro a fatura de compra que até pode nem ter NIF, pode se ao consumidor final, e até pode nem ser minha, posso ter comprado algo usado no OLX mas ainda estar sob garantia.
Quando se deixa algo a reparar fica-se com uma "ficha de obra", e basta que o cliente assine a dar consentimento para ser usado o teu telefone na situação de reparação ou, se não quiser, telefone todos os dias para saber se já está reparado.

As aplicações não têm de "separar o armazenamento/tratamento de dados fiscais dos restantes dados pessoais". As empresas é que têm de identificar quais os dados pessoais que possuem, como os mesmos são usados e por quem.  É só isso.

  • Voto 1

10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
CJCV

não era para complicar , é só para esclarecer que não se apaga dados de clientes só porque ele pediu para ser "esquecido".

quanto a  fiscalização aos softwares de faturação , era uma piada ;)

mas nunca se sabe :cheesygrin:

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Rui Carlos
1 hora atrás, CJCV disse:

não era para complicar , é só para esclarecer que não se apaga dados de clientes só porque ele pediu para ser "esquecido".

Também não é suposto manterem-se dados de terceiros só porque nos apetece.  Se o teu software não permitir apagar dados não "essenciais" vai complicar a vida a quem o usa, pois vão ter que ter muito mais cuidado a definir as políticas de privacidade que justifiquem a sua manutenção, e vão estar mais expostos a problemas legais em caso de acesso indevido a dados.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
knightcoder
Em 28/03/2018 às 10:39, M6 disse:

As aplicações não têm de "separar o armazenamento/tratamento de dados fiscais dos restantes dados pessoais". As empresas é que têm de identificar quais os dados pessoais que possuem, como os mesmos são usados e por quem.  É só isso.

As aplicações não têm, mas no meu ponto de vista devem.

Caso contrário fica muito difícil cumprir com o requisito do GDPR de esquecer os dados pessoais e o requisito fiscal de guardar os dados (NIF, Nome e morada) de um documento fiscal durante o período legalmente exigido.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
M6
1 minute ago, knightcoder said:

As aplicações não têm, mas no meu ponto de vista devem.

Caso contrário fica muito difícil cumprir com o requisito do GDPR de esquecer os dados pessoais e o requisito fiscal de guardar os dados (NIF, Nome e morada) de um documento fiscal durante o período legalmente exigido.

Isso é uma questão procedimental/normativa da empresa. O DPO é o responsável por garantir que isso é feito como deve ser.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
knightcoder
Em 29/03/2018 às 11:54, M6 disse:

Isso é uma questão procedimental/normativa da empresa. O DPO é o responsável por garantir que isso é feito como deve ser.

Não estou a ver a relação entre o DPO e a funcionalidade de esquecimento numa aplicação. Nem todas as empresas vão ter um DPO, pois este nem sempre é obrigatório, mas caso exista de certeza que vai valorizar o software que o ajuda a desempenhar o seu papel.

Caso uma aplicação de faturação tenha a funcionalidade de esquecimento de dados pessoais é recomendável que a estrutura de dados separe os dados pessoais dos dados fiscais. 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
M6
Em 30/03/2018 às 08:53, knightcoder disse:

Não estou a ver a relação entre o DPO e a funcionalidade de esquecimento numa aplicação. Nem todas as empresas vão ter um DPO, pois este nem sempre é obrigatório, mas caso exista de certeza que vai valorizar o software que o ajuda a desempenhar o seu papel.

Caso uma aplicação de faturação tenha a funcionalidade de esquecimento de dados pessoais é recomendável que a estrutura de dados separe os dados pessoais dos dados fiscais. 

Todas as empresas têm de ter um DPO (mesmo que não tenham a figura, têm de ter uma pessoa responsável por isso), há regras ligeiramente diferentes para empresas grandes e pequenas, sendo que as pessoas da administração não podem ser DPO por óbvias razões de incompatibilidade.

Posto isto, a relação entre o DPO e a funcionalidade de esquecimento numa aplicação (ou qualquer outra regra do regulamento) é simples de compreender: é o DPO que é responsável por garantir que tal acontece.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Rui Carlos
6 horas atrás, M6 disse:

Posto isto, a relação entre o DPO e a funcionalidade de esquecimento numa aplicação (ou qualquer outra regra do regulamento) é simples de compreender: é o DPO que é responsável por garantir que tal acontece.

Diria que o ponto importante é como é que o DPO garante que as regras são cumpridas.  E aqui concordo com o @knightcoder: ou o software ajuda, ou só resta ao DPO confiar no software.  A separação dos dados também tenderá a ser útil caso o software não implemente de raiz todos os requisitos de privacidade, e a empresa tenha que implementar mecanismos adicionais (com tabelas separadas, pode-se focar em perceber essas tabelas, em vez da BD toda).

Nós estamos habituados a pensar na organização lógica do software, e a abstrair detalhes de implementação.  Mas em assuntos como a privacidade/segurança, os detalhes de implementação fazem toda a diferença.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
antseq

Viva,

Sobre este tema do RGPD, a melhor informação que arranjei está resumida nestas 4 apresentações.
Duas são de empresas (SW) portuguesas a mostrar o que fizeram ou pensam fazer e outras mais genéricas sobre o assunto.

RGPD...
http://www.youtube.com/watch?v=DTeVWY-4VhA&t=23m31s

Entenda o RGPD...
https://www.youtube.com/watch?v=OA1zipbxfIg

GDPR – A practical guide for developers and architects
https://www.youtube.com/watch?v=lGgw_WReFKY

Auditório 8 - Risk, Compliance, Legal & DPOs / Industry & Retail
0:00:00 Risk, Compliance, Legal & DPOs
1:29:00 Industry & Retail
http://entrprise.tv/01/SitePlayer/microsoft?session=31354

Certamente ainda vão ficar muitas dúvidas no ar, mas é um bom começo para perceber o tema.
cps,
A.S.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
knightcoder
Em 03/04/2018 às 14:53, M6 disse:

Todas as empresas têm de ter um DPO (mesmo que não tenham a figura, têm de ter uma pessoa responsável por isso), há regras ligeiramente diferentes para empresas grandes e pequenas, sendo que as pessoas da administração não podem ser DPO por óbvias razões de incompatibilidade.

artigo 37 do GDPR é bastante claro quando é necessário nomear um DPO.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
M6
On 3/28/2018 at 12:07 PM, CJCV said:

não era para complicar , é só para esclarecer que não se apaga dados de clientes só porque ele pediu para ser "esquecido".

quanto a  fiscalização aos softwares de faturação , era uma piada ;)

mas nunca se sabe :cheesygrin:

Deixo aqui uma explicação sobre como ter uma obrigação legal como base legal para o tratamento do RGPD: http://hexonio.com/blog/pt/2018/04/04/base-legal-obrigacoes-legais/


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
knightcoder

Relativamente ao artigo 32, como estão a garantir que o processamento de dados pessoais das vossas aplicações é seguro e evitar que os dados são violados/expostos artigo 34? Uma das opções é encriptar os dados, mas do ponto de vista aplicacional pode ser uma tarefa bastante complexa.

Ou o motor de base de dados suporta encriptação ou será necessário encriptar alguns campos. Esta última opção poderá implicar rever a estrutura de dados, pois dependendo do algoritmo escolhido, o resultado de uma string encriptada pode ocupar mais espaço do que a string em plain text.

Existem outras alternativas para garantir que o processamento é seguro, como inibir o acesso direto ao ficheiro(s) de base de dados, mas em aplicações locais é quase impossível garantir.

Existem alguns artigos interessantes sobre este tema:

https://activereach.net/newsroom/blog/gdpr-data-encryption-really-necessary/

https://www.i-scoop.eu/gdpr-encryption/

https://www.linkedin.com/pulse/gdpr-encryption-mandatory-gary-hibberd/

Editado por knightcoder

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Rui Carlos

Se a ideia for cifrar os dados da BD, diria que o melhor é usar uma BD que suporte essa funcionalidade directamente.  O mais simples até era capaz de ser uma solução que cifre o sistema de ficheiros.  Neste caso protege-se inclusive outros ficheiros que podem inadvertidamente expor dados pessoais (e.g. logs).  Ambos os casos podem ser transparentes para a aplicação.

É claro que depois há o problema da gestão de chaves que é preciso resolver, e se não for bem resolvido, a criptografia vai apenas resultar em ofuscação, sem dar propriamente segurança.  No caso em que é preciso haver um login inicial de um administrador para a aplicação começar a funcionar, essa pode ser a forma de obter a chave.  Em casos em que a aplicação é um serviço que arranca sem interacção do utilizador não conheço nenhuma solução eficaz.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
M6

Em alguns casos estamos a cifrar os dados. Estas operações, de leitura e escrita de dados, estão a ser feitas ao nível do ORM ou ao nível da BD encapsuladas com Store Procedures.
Caso a BD não suporte encriptação nativa, pode-se implementar um algoritmo próprio. Quanto ao espaço adicional consumido por isto, não me parece relevante.
O acesso aos dados é na aplicação é, obviamente, perfilado.

@Rui Carlos, a questão da criptografia ser apenas ofuscação não é diferente da questão dos logins, que, na verdade, ficam apenas ofuscados. É por demais conhecido que os tradicionais md5, sha1, etc. usados nos logins são quebráveis por clash de chaves.
Eu percebo a tua preocupação, todos a partilhamos, mas repara que chega a um ponto em que a questão já nem é propriamente do RGPD mas sim criminal do ponto de vista de hacking.

A forma mais recente que usámos para ultrapassar este tipo de situações foi recorrer a um certificado.
Usamos a chave privada (que fica sempre connosco) e fazemos o deploy do software com o certificado público.
No entanto sabemos que também não é inviolável, a começar pelas notícias dos últimos tempos de falhas de segurança nesta área.


10 REM Generation 48K!
20 INPUT "URL:", A$
30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50
40 PRINT "404 Not Found"
50 PRINT "./M6 @ Portugal a Programar."

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Rui Carlos
15 minutos atrás, M6 disse:

@Rui Carlos, a questão da criptografia ser apenas ofuscação não é diferente da questão dos logins, que, na verdade, ficam apenas ofuscados. É por demais conhecido que os tradicionais md5, sha1, etc. usados nos logins são quebráveis por clash de chaves.
Eu percebo a tua preocupação, todos a partilhamos, mas repara que chega a um ponto em que a questão já nem é propriamente do RGPD mas sim criminal do ponto de vista de hacking.

Para clarificar o meu ponto da ofuscação...  Cifrar a BD e meter as chaves num qualquer ficheiro de configuração da aplicação, como é norma em aplicações web por exemplo, não serve de muito, sobretudo se a BD e a aplicação estiverem na mesma máquina.  Neste caso a protecção que isto traz aos dados persistidos é mesmo próxima de 0: se alguém consegue acesso ao sistema de ficheiros, vai ter os dados cifrados, mas só precisa de procurar a chave para os decifrar.

O meu ponto é essencialmente este: usar criptografia é muito bonito, mas há muitos detalhes de implementação que facilmente tornam a criptografia inútil.  E por vezes fico com a ideia que se usam mecanismos de segurança só para dizer que sim.


Atenção que não são os ataques de brute force que considero que tornam uma implementação pouco mais do que ofuscação.  Os hashes para armazenar passwords são outro exemplo onde convém ter cuidado com a implementação para que sejam minimamente seguros, mas aqui na maior parte das vezes o problema é garantir que o ataque por brute force (e similares) não é eficaz na prática (e há formas de efectivamente tornar os hashes bastante resistentes a brute force -- salts, múltiplas iterações, algoritmos lentos, etc.).

  • Voto 1

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
desconfiado

Isto vai ser uma grande "tourada".

Ainda agora vi numa apresentação referida acima, uma software house a "anonimizar" os dados de uma ficha de um cliente, nomeadamente o nome e o Nif desse cliente.

Ora a AT no despacho 8632_2014 "Obriga" a 

3.3 A aplicação não pode permitir:

3.3.3 — A alteração do NIF, numa ficha de cliente já existente e com documentos emitidos. Apenas poderá ser averbado o NIF em falta, no caso de o campo não estar preenchido, ou estar preenchido com o NIF do cliente genérico “999999990”.
3.3.4 — A alteração do nome numa ficha de cliente já existente e com documentos emitidos, mas cujo NIF não foi fornecido. Esta limitação cessa, quando na ficha do cliente for averbado o respetivo NIF.

 

Nessa mesma apresentação, a funcionalidade de "exportação de informação" (para mim esta questão é ainda mais ridícula) resume-se, neste software, á exportação do nome e morada do cliente. Mas o RGPD aplica essa exportação a "toda a informação" existente, ou seja, o histórico de todas as compras (no caso de facturação) que o cliente efetuou na empresa incluindo todos os produtos adquiridos.

Nós falamos da legislação portuguesa, que quem a faz não tem noção nenhuma da realidade, mas a europeia não fica atrás. Isto é um grande bico de obra.

Podiam ter ficado pelo direito ao "esquecimento" e mecanismos de protecção de acesso à informação mas foram mais além e, na minha opinião, "borraram a pintura". Não estou a ver isto a ser aplicado de forma realista.

 

Editado por desconfiado

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
CJCV
25 minutos atrás, desconfiado disse:

Isto vai ser uma grande "tourada".

 

também julgava que a exportação se referia a dados pessoais e não ao histórico de facturação ( por exemplo ).

se é um cliente genérico , sem ficha de cliente , sem nif , é complicado e falível pesquisar  informação da facturação apenas por nome.

corre-se o risco de existirem clientes com nomes iguais .

quanto a encriptação de dados na BD , não havia uma portaria / comunicação da AT a proibir isso ?

é "tourada" :confused:

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.