Re: Key encryption and relational integrity - Mailing list pgsql-general

Il 28/03/2019 23:29, Peter J. Holzer ha scritto:
> On 2019-03-28 18:36:40 +0100, Moreno Andreo wrote:
>> Il 26/03/2019 18:08, Adrian Klaver ha scritto:
>>> To me it would seem something like:
>>>
>>> Table medications
>>> id    user_id        med
>>> 1    sgkighs98    Medication
>>> 2    sghighs98    Ear check
>>>
>>>
>>>
>>> Table users
>>> id            surname    last name
>>> sgkighs98     John            Doe
>>> jkopkl1       Jane            Doe
>>> uepoti21      Foo             Bar
>>>
>>> Where there is no direct link between the two.
>> Are you sure there isn't?... the key "sgkighs98" is present on both
>> tables and I can join tables on that field, so the pseudonimysation
>> does not apply,
> Yes. It doesn't matter whether the key is 'sgkighs98' or 1438 or
> 692da0c1-cf2d-476d-8910-7f82c050f8fe.
>
>> it's just "separation" (that was OK with the last privacy act, but not
>> with GDPR
> I doubt that this is correct. The GDPR doesn't prescribe specific
> technical means (there may be laws or standards in your country which
> prescribe such means for medical data, but that's not the GDPR).

That was told me by a privacy consultant, there was an Italian law 
(196/2003) that introduced "minimal security measures", that has been 
revoked with the GDPR appliance.


>> The problem is not on the application side... there you can do almost
>> anything you want to do. The prolem is that if someone breaks in the
>> server (data breach) it is easy to join patients and their
>> medications.
> I sure hope that the doctors are able to join patients and their
> medications. So at some level that has to be possible.
It would be possible at application level, that resides on another 
server (so it would be compliant the separation between the 
pseudonimysation and the reverse method)
> If you assume a
> break-in into the server, there will always be a level of penetration at
> which the attacker will be able to access any data an authorized user
> can access.

That's not what I got reading the GDPR article... but I may have 
misunderstood (juridic text is non my cup of tea). My understanding was 
that even in a data breach event there should be a mechanism that 
prevents (or "mitigate the risk that") the attacker to gain access to 
the data in the "joined" form, so he cannot acquire that patient John 
Doe has got Alzheimer, for instance, but only that in that database 
there is a patient which name is John Doe and someone that has got 
Alzheimer.

And I tried to find a solution, and since I did not like that much what 
I found (and it seems that neither you do :-) ), I came here hoping that 
someone would share his experience to shed some light on the topic.


>          hp
>