GDPR on õige unustada vs anatoomiline

Lubage mul alustada kiirete triviatega: kas teate seda meest?

Kui vastus on jaatav, on tõenäoline, et olete selle pakkumisega tuttav:

Suure võimuga kaasneb suur vastutus
- Onu Ben

Märkus. Olen teadlik, et selle tsitaadi päritolu võib jõuda Voltaire'ini, kuid hei, see pole nii meeldejääv kui Ämblikmees!

Kui loete seda, siis arvan, et olete Datomicuga juba tuttav ja ajarännaku funktsionaalsusesse armunud. See on lihtsalt nii võimas! Kuid nagu eespool märgitud, tuleb see võimsus oma kuludega. Näiteks - see muudab GDPR-i järgimise natuke keerukaks.

Jah, ma tean, veel kord, kui loete GDPR-i. Meil kõigil on see juba olnud, õeltele pole puhata. Kuid tuletagem endale meelde mõned täpitähed kohustustest, mis see meile seljale paneb:

  • Kaitse isikuandmeid (isiklik tuvastatav teave)
  • Kustutage PII jäädavalt, kui nende omanik meid palub (õigus olla unustatud)
  • Auditeerib PII juurdepääsu

Muidugi on rohkem määrusi. Kuid nad ületavad selle ajaveebi postituse ulatuse, nii et ma jätan nad sellest välja.

Huvide konflikt

Seega on probleem, millega siin tegeleme, üsna ilmne: ühelt poolt on meil kohustus kustutada isikuandmed, kui nende omanik meid nõuab. Teisest küljest on meil voli rännata tagasi aega enne seda taotlust.

Lubage mul siin teile kiiret näidet näidata:

Esmaspäeval siseneb John Doe meie webappi ja registreerib end:

@ (d / tehing
   konn
   [{: kasutaja / id 111
     : kasutaja / nimi "John Doe"
     : kasutaja / telefon "123456789"}])
=>
{: db-before datomic.db.Db,
 @ 5193c0be: db-pärast,
 datomic.db.Db @ 43e943fe,
 : tx-data [#datom [13194139534313 50 #inst "2018-06-06T13: 07: 58.664-00: 00" 13194139534313 true]
           #datom [17592186045418 63 111 13194139534313 true]
           #datom [17592186045418 64 "John Doe" 13194139534313 true]
           #datom [17592186045418 65 "123456789" 13194139534313 true]],
 : templid {-9223301668109598066 17592186045418}}

Pangem tähele tehingut, mis viis uue kasutaja meie andmebaasi:

  • Selle tehingu kehtivuse tunnus on 13194139534313
  • See tehing toimus aadressil #inst ”2018–06–06T13: 07: 58.664–00: 00”

Ta mängib rakendusega paar päeva. Ehkki reedel otsustab ta, et pole teenusega rahul, palub ta meil tema andmed kustutada. Ja nii me järgime:

@ (d / tehing
   konn
   [[: db.fn / retractEntity [: kasutaja / id 111]]))
=>
{: db-before datomic.db.Db,
 @ 43e943fe: db-after,
 datomic.db.Db @ 37505082,
 : tx-data [#datom [13194139534315 50 #inst "2018-06-06T13: 15: 23.436-00: 00" 13194139534315 true]
           #datom [17592186045418 63 111 13194139534315 vale]
           #datom [17592186045418 64 "John Doe" 13194139534315 vale]
           #datom [17592186045418 65 "123456789" 13194139534315 vale]],
 : templid {}}

Teeme lihtsalt viimase kontrolli, et veenduda, kas kõik on korras:

(->
  (d / db konn)
  (d / olem [: kasutaja / id 111]))
=> null

Jah! John Doe on kadunud - kas saame tagasi äri juurde, eks? No ei. Kas mäletate märkmeid, mille me John Doe konto loonud tehingu kohta tegime? Kasutagem seda ajas tagasi reisimiseks:

(->
  (d / db konn)
  (d / as 13194139534313)
  (d / olem [: kasutaja / id 111]))
=> #: db {: id 17592186045418}

Aga hei, me saime sinu selja! Oleme selle välja mõelnud ja jagame seda hea meelega teiega.

Kui Platonil oli õigus ...

Kujutage ette, et Atlantis oli tõesti olemas. Kujutage ka ette, et otse nende peaväljaku keskel oli tohutu obelisk. Ja et see obelisk oli graveerinud teie enda telefoninumbri ja lemmikkülma Dunkin Donutsist. Kuidas see GDPR-iga mittevastav on? Vastus on - see on täiesti korras. Linn kadus õhu kätte (või vette) ja seega on teie salajane iha küpsiste koletise järele sõita teie ja minu vahel endiselt turvaline (shhh!)

Pange need lihtsalt lukku

Ok, aga viskan nalja kõrvale. Meie probleemi algoritm on lihtne. Kasutame selleks krüpto-purustamist.

  1. Looge võti, mida kasutate PII krüptimiseks. Peate selle võtme salvestama viisil, mis võimaldab teil seda vajadusel usaldusväärselt kustutada.
  2. Kasutage võtit sissetulevate andmete krüptimiseks ja väljapääsu dekrüptimiseks.
  3. Kui aeg saabub, visake võti ära.
Ülaltoodud punane plokk kujutab Hashicorp Vault'i kasutamisel struktuuri. Muidugi võib see varieeruda sõltuvalt valitud tööriistast.

Kuidas sa siis võtme ära viskad?

Nüüd on siin teil palju võimalusi valida. Nagu alati, pole olemas kõigile sobivat lahendust, kuid lubage mul anda teile mõned ideed:

  • : db / aktsiis - jah, sa võid lihtsalt sundida Datomicu selle konkreetse krüptimisvõtme täielikult unustama. Kuid kui soovite, et teie andmed oleksid korralikult krüptitud, ei saa te võtit hoida samas kohas, kus isiklikku isikutunnistust hoiate.
  • Eraldi kustutamisvõimalustega andmebaas - ainult kaks veergu: kasutajatunnus ja krüptimisvõti. Nii lihtne. Kuid see paneb palju vaeva nägema - peate seda DB säilitama, jälgima selle tervislikku seisundit ja endiselt on juurdepääsute auditeerimise kohustus.
  • Hashicorpi vault - see on väga võimas tööriist, mis sobib ideaalselt meie probleemiga. Sellel on sügavalt konfigureeritavad juurdepääsupoliitikad, audit, saladuste jaotamine, kõrge käideldavuse režiim jne. Kuid kõigi nende käikude keerutamiseks on vaja palju konfiguratsiooni ja ressursse. AWS-i abil kõrge kättesaadavuse režiimi ametlik juhendaja mainib 8 esinemisjuhtu! Nii et kui teie probleemi ulatus õigustab Vaultisse tehtavate investeeringute investeerimist - otsige järele!
  • AWS-lahendused - nüüd on selles probleemis kasutamiseks vähemalt kolm toodet - võtmehaldusteenus, saladusehaldur ja süsteemijuhi parameetrite pood

Otsustasime selle hinnakujunduse kasuks Parameter Store'ist (tasuta on raske läbi lüüa). Taotluste piirangu tõttu on selle kohta kriitikat, nii et varem või hiljem peame üle minema mõne suurema esineja jaoks. Seetõttu võiks olla hea mõte see piiri taha panna. See peaks aitama suhteliselt hõlpsalt rännata.

Aga mis siis, kui ...

Mis saab siis, kui mul tekib arusaam, et minu andmed on ohus?

Siis soovite oma krüptimisvõtmeid pöörata. Sõltuvalt teie valitud lahendusest võib see olla disainilahendus. Muidu soovite lihtsalt oma andmed dekrüpteerida, luua uus võti, krüptida see uue võtmega uuesti tagasi, salvestada andmed Datomicas ja kustutada vana võti.

Mis siis, kui PII maht on klahvide tõhusaks pööramiseks liiga suur?

Kui suurt osa teie kogutud andmetest peetakse PII-ks (ühe isiku meditsiinilised andmed), võib teil tekkida probleem kõike dekrüpteerida, mälus hoida ja sellega segada. Siis võiksite kaaluda krüptimise täiendava sammu juurutamist: ühe krüptimisvõtme asemel on teil põhivõti ja lühiajaline võti. Kasutate endist andmete krüptimiseks, kuid te ei salvesta seda kunagi krüptimata kujul. Krüptite peamise võtme lühiajalise võtme abil. Seejärel, kui soovite oma lühiajalist võtit pöörata, korrake toimingut ülaltoodud punktist, kuid ainult peamise võtme dekrüptimiseks ja uuesti krüptimiseks.

Mis siis, kui ma pean mõne osa PII-st kustutama nüüd ja osa hiljem?

Kujutage ette, et olete raamatupidaja. Kui teie klient palub teil kustutada tema isikuandmed, peate selle järgima ja kustutama selle ASAP-i. Kuid osa neist andmetest on vajalik maksude uurimise korral. Sel juhul võiksite jagada oma PII mitmeks tasandiks. Igal ühel oleks eraldi krüptovõti. Ülejäänud töötab nagu eespool mainitud punktides.

Ja see võtab selle kokku ...

Sellegipoolest peate meeles pidama ühte asja: tooted ei ole ega saa kunagi olema GDPR-iga ühilduvad. PII-d peavad austama ettevõtted. Tooted saavad seda harjumust ainult lihtsamaks või raskemaks muuta.

Kui märkate meie mõttevigasid, palun andke meile sellest teada. Kui teil on veel kommentaare, palun andke meile sellest ka teada.

Järgmisena: kirjutan postituse põhjalikuma näitega Parameter Store'i kasutamisest meie veebis. Pille häälestama!