PII lauku kriptēšana datubāzē

[duncanf293]

Klients pieprasa, lai datubāzē tādi PII (personally identifiable information) lauki kā email, first_name, last_name un address glabātos nevis plaintext formā, bet būtu kriptēti. Tas tiek pamatots ar GDPR prasībām. Pēc manas saprašanas GDRP kontekstā šāda kriptēšana ir rekomendācijas līmenī un nav dotas specifiskas vadlīnijas ne kriptēšanas algoritmiem, ne arī encryption key drošai uzglabāšanai. Vieta interpretācijai. Vai esat saskārušies ar šādu prasību, kā to risinājāt?

Konkrēti lietoju Laravel FW, tāpēc ir doma paņemt kādu package, piemēram, šo: https://github.com/betterapp/laravel-db-encrypter
Iekšēji package izmanto Laravela Crypt fasādi, kas paņem encryption key no .env faila. Modeļos var norādīt, kurus laukus vajag kriptēt, pārējie paliks plaintext.
Teorētiski ar šo būtu jāpietiek?

[briedis]

Visdrīzāk ar to ir domāts, ka datubāze ir kritpēta, nevis saturs. Tas būtu diezgan liels absurds, lai ielogotos lietotāja kontā, būtu jādekriptē visi ieraksti, lai atrastu kurš lietotājs tas ir :)

Piemēram, ja lieto AWS RDS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html

[duncanf293]

17 minutes ago, briedis said:

Visdrīzāk ar to ir domāts, ka datubāze ir kritpēta, nevis saturs. Tas būtu diezgan liels absurds, lai ielogotos lietotāja kontā, būtu jādekriptē visi ieraksti, lai atrastu kurš lietotājs tas ir :)

Piemēram, ja lieto AWS RDS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html

Tas, ko tu ielinkoji, manuprāt ir disk-level encryption, kas pasargā pret scenāriju, kur kāds datucentra darbinieks nospertu SSD disku.

Mans klients savukārt runā par scenāriju, kur kāda trešā puse iegūtu mūsu datubāzes dumpu. Tādi precedenti citām kompānijām, protams, ir bijuši. Ja PII lauki datubāzes saturā būtu kriptēti, tad tas būtu... mazliet labāk. Var argumentēt, ka gadījumā, ja hakeris ir atradis piekļuvi datubāzes dumpam, tad vienlaicīgi ir atrasta piekļuve arī servera failu sistēmai un līdz ar to encryption key iekš .env faila. Tādā gadījumā kriptēšana bijusi bezjēdzīga.

Tomēr izskatās, ka ir kompānijas, kas iet šādu ceļu. Tiem Laravel package kājas no kaut kurienes aug.

Lai veiktu user loginu, nav jādekriptē visi ieraksti. Populāra metode ir atsevišķā indeksētā datubāzes laukā glabāt e-pasta hash un login brīdī meklēt pēc tā.

[Grey_Wolf]

Personas datu aizsardzībā nav tādu prasību..  pat ne īsti rekomendācijās..  viņa vispār neregulē, kā jāglabā dati..
- ne formu, ne izskatu neko.. tur  tiek norādītas pa visam citas lietas.. 
/ Datu regula norāda - KUR DATI DRĪKST TIKT  IZMANTOTI, un prasības  ko jāpastāsta datu īpašniekam.. un TIESĪBAS DATU ĪPAŠNIEKAM.. 
Par drošību, vienīgi pateikts kādas darbības jāveic, ja dati nozagti.. - UN NAV SVARĪGI, VAI ŠIFRĒTI VAI NEŠIFRĒTI..  /

Ja glabā Vārdu un uzvārdu atsevišķi (atseviški lauki) , tad vārda kriptēšana vispār zaudē jebkādu nozīmi.. 
Par to ka kāds iegūs DB.. - tur kriptēšana nepalīdzēs.. - jo ja tiek uzlausts serveris- tad paķer līdzi arī visu pārējo ..

Pie tam .. vienīgais kas tiks pasargāts būs klients, bet ne dati.. - pārsvarā jau interesē, cik daudz, un kas nopirkts- bet nevis kāds "Jānis Bērziņš. xxx ielā " .. 
Nu jā vel jautājums, cik sensetīvi ir tie dati... UN VAI VISPĀR DRĪKSTAT TOS GLABĀT..... 
Ja nevar paskaidrot kur legāli tas tiks izmantots tad personas datus glabāt nedrīkst.. teiksim veikalā, bez atļaujas uzkrāt informāciju - kas pirkt utt.. ja vien klients par to netiek informēts .. (patiesībā pat piekrišana īsti nav vajadzīga /bet informēšana obligāta/ - šis gan strīdīgs jautājums, atkarīgs no daudziem faktoriem)  ..
Secinājumi: katrs gadījums ir jāskata atsevišķi.. kādi dati, cik sensetīvi utt.. 

 

[duncanf293]

1 hour ago, Grey_Wolf said:

Personas datu aizsardzībā nav tādu prasību..  pat ne īsti rekomendācijās..  viņa vispār neregulē, kā jāglabā dati..
- ne formu, ne izskatu neko.. tur  tiek norādītas pa visam citas lietas.. 

Tā nav gluži taisnība, kriptēšana ir pieminēta pat vairākas reizes. Tas ir sīkāk izķidāts šajā rakstā: https://www.i-scoop.eu/gdpr-encryption/
Tomēr nav strikti minēts, vai pietiek ar visas datubāzes disk-level encryption, vai arī rekomendē kriptēt individuālus laukus.

Šajā stackoverflow jautājumā (nav gan diez ko daudz atbilžu, no kā izvēlēties), iesaka ne-kriptēt email lauku (dēļ login) bet kriptēt visu pārējo (first name, last name, address) - https://stackoverflow.com/questions/50579646/should-i-encrypt-the-entire-database-or-just-fields-within

[codehighriga]

https://security.stackexchange.com/questions/184519/how-to-handle-emails-as-usernames-under-gdpr

Quote

A term used frequently in the GDPR legislation is that you must take "appropriate technical and organisational measures ... according to risk". Risk in this case refers to the risk posed to the "Data Subject" (person).

So what is appropriate would vary greatly from a gaming platform to a pharmacy (as linking sales to identifiable persons could reveal information about terminal medical conditions).

GDPR does not set any technical requirements, but let it be up to you to determine what is appropriate.

Sliecos piekrist šim viedoklim ^

Tomēr ir arī kompānijas, kas kriptēšanu veic vienīgi dēļ šī iemesla -  "To give a feeling of security by sprinkling some crypto all over the place" - tas izskaidrots šeit: https://security.stackexchange.com/questions/101163/what-fields-should-i-encrypt-in-a-database-containing-user-information

[codehighriga]

On 9/15/2020 at 1:30 PM, duncanf293 said:

Populāra metode ir atsevišķā indeksētā datubāzes laukā glabāt e-pasta hash un login brīdī meklēt pēc tā.

Ar to ir jābūt ļoti uzmanīgiem, jo tāds hash lielā mērā sabojās visu privātuma un kriptēšanas būtību. Ja uzbrucējam ir kādi konkrēti e-pasti, ko gribas sameklēt datubāzes dumpā, tad varēs pielietot dictionary metodi. Ja neinteresē konkrēts e-pasts, nu tad varbūt tāda metode ir pieļaujama.

Edited September 19, 2020 by codehighriga

[briedis]

Ļoti labs teikums:

Quote

Since this is only security theatre, you can most of the time achieve the same kind of psychological effect with an "encoding" that needs not be encryption properly said (e.g. Base64).

Ja tev kods/keys glabājās principā turpat kur enkriptētie dati - tas viss tiešām ir diezgan bezjēdzīgi.

[Grey_Wolf]

On 9/18/2020 at 1:32 PM, duncanf293 said:

Tā nav gluži taisnība, kriptēšana ir pieminēta pat vairākas reizes. 

Personas dati nav tikai elektronisk !!!!
arī atzīme žurnālā, ka esi apmeklējis kādu iestādi - ir personas dati - patiesībā jebkas kur var noteikt konkrēto personu.. - papīrs, digitāls, audio, foto, video.. 
- tā kā lielāko daļu nav iespējam noskriptēt- tad PAMAT LIETĀS TAS NAV NOTEIKTS !!!! .. 
- skriptēšana, vai datu padarīšana par anonīmiem .. ir cits stāsts.. - bet metodes- nav noteiktas- regula vispār nosaka DATU IZMANTOŠANAS KĀRTĪBU..  nevis kā tās jāglabā, jāskriptē utt.. 
- ja tev ir tiesības glabāt tos datus, tad vari glabāt kā vien vēlies, kaut ietotevē sev uz pieres - tik cepure būs jāvelkā- lai citi neredz..
 

[webi]

Par to cepuri labs! :D

[werd]

https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_aes-encrypt - iebūvētā AES_ENCRYPT() MySQL funkcija neder? Izmanto "sāli", lai enkriptētu un dekriptētu - bez sāls neviens nenolasīs to vērtību arī tad, ja iegūs tavu datu bāzi.

[duncanf293]

On 10/9/2020 at 1:08 PM, werd said:

https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_aes-encrypt - iebūvētā AES_ENCRYPT() MySQL funkcija neder? Izmanto "sāli", lai enkriptētu un dekriptētu - bez sāls neviens nenolasīs to vērtību arī tad, ja iegūs tavu datu bāzi.

Šajā gadījumā jautājums nav par to kā to tehniski izdarīt (variantu ir daudz) - jautājums ir par to vai tagad mēs uzskatām jebkādu PII datu kriptēšanu par labo praksi un daram to "by default" pat tad, ja klients neprasa. Nav jau tā, ka veidotos kāds milzīgs overhead kodā dēļ tās PII kriptēšanas... Visiem lielākajiem FW ir tāds vai citāds package, kas procesu padara +- nesāpīgu.