Права GDPR быць забытым супраць Datomic

Пачну з хуткай дробязі: ты ведаеш гэтага хлопца?

Калі адказ "так", вялікая верагоднасць знаёмства з гэтай цытатай:

З вялікай сілай ідзе вялікая адказнасць
- Дзядзька Бэн

Заўвага: я ведаю, што паходжанне гэтай цытаты магчыма даходзіць да Вальтэра, але эй, гэта не так прывабна, як чалавек-павук!

Калі вы чытаеце гэта, я мяркую, што вы ўжо знаёмыя з Datomic і любіце функцыю падарожжа ў часе. Гэта проста так магутна! Але, як было адзначана вышэй, гэтая ўлада прыходзіць даражэй. Напрыклад - гэта адпавядае патрабаванням GDPR крыху больш складана.

Так, я ведаю, вы яшчэ раз чыталі пра GDPR. У нас яго ўсё ўжо было, спакою для бязбожных няма. Але нагадаем сабе некаторыя пункты абавязацельстваў, якія ён ускладае на спіну:

  • Абараніць PII (асабістая інфармацыя)
  • Надоўга выдаліце ​​ІПП, калі іх уладальнік просіць нас (права забыцца)
  • Аўдыт доступу PII

Ёсць, вядома, больш рэгламентаў. Тым не менш, яны перапаўняюць сферу гэтага блогу, таму я іх не пакідаю.

Канфлікт інтарэсаў

Такім чынам, праблема, якую мы тут вырашаем, даволі відавочная: з аднаго боку, мы абавязаны выдаляць PII, калі іх уладальнік просіць. З іншага боку, мы маем магчымасць вярнуцца назад у часе да моманту запыту.

Вось, дазвольце паказаць вам на хуткім прыкладзе:

У панядзелак Джон Дой уваходзіць у наш сайт і рэгіструе сябе:

@ (д / транзакцыя
   conn
   [{: user / id 111
     : карыстальнік / імя "Джон Доу"
     : карыстальнік / тэлефон "123456789"}])
=>
{: db-before datomic.db.Db,
 @ 5193c0be: db-after,
 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 сапраўдна]
           #datom [17592186045418 64 "John Doe" 13194139534313 true]
           #datom [17592186045418 65 "123456789" 13194139534313 дакладна]],
 : tempids {-9223301668109598066 17592186045418}}

Давайце возьмем на заметку транзакцыю, якая пераштурхнула новага карыстальніка ў нашу базу дадзеных:

  • Ідэнтыфікатар enitity гэтай транзакцыі - 13194139534313
  • Гэтая здзелка адбылася ў #inst ”2018–06–06T13: 07: 58.664–00: 00”

Ён гуляе з дадаткам на працягу некалькіх дзён. Хоць у пятніцу ён вырашыў, што не задаволены паслугай, таму просіць выдаліць ягоныя дадзеныя. І таму мы выконваем:

@ (д / транзакцыя
   conn
   [[: db.fn / retractEntity [: user / 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 хлусня]
           #datom [17592186045418 64 "John Doe" 13194139534315 false]
           #datom [17592186045418 65 "123456789" 13194139534315 хлусня]],
 : tempids {}}

Мы проста робім апошнюю праверку, каб пераканацца, што ўсё ў парадку:

(->
  (d / db conn)
  (d / entity [: user / id 111]))
=> нуль

Так! Джон Доу сышоў - мы можам вярнуцца да справы, праўда? Ну не. Вы памятаеце нататкі, якія мы зрабілі пра транзакцыю, якая стварыла рахунак Джона Доу? Давайце выкарыстаем яго для падарожжа ў мінулае:

(->
  (d / db conn)
  (д / з 13194139534313)
  (d / entity [: user / id 111]))
=> #: db {: id 17592186045418}

Але эй, мы вярнуліся! Мы гэта высветлілі, і будзем рады падзяліцца ім з вамі.

Калі Платон меў рацыю ...

Уявіце, Атлантыда сапраўды існавала. Уявіце таксама, што яны мелі велізарны абеліск прама ў цэнтры галоўнай плошчы. І менавіта гэты абеліск выгравіраваў ваш уласны нумар тэлефона і любімую глазуру з Dunkin Donuts. Наколькі гэта не адпавядае GDPR? Адказ - гэта цалкам нармальна. Горад знік у паветра (ці вада), і таму ваша таемная цяга да пончыка монстра печыва па-ранейшаму бяспечная паміж вамі і мной (так!)

Проста замкні іх

Добра, але жарты ў бок. Алгарытм нашай праблемы мёртвы просты. Для гэтага мы будзем выкарыстоўваць крыптызацыю.

  1. Стварыце ключ, які будзе выкарыстоўвацца для шыфравання PII. Вы павінны захаваць гэты ключ такім чынам, што дазволіць вам надзейна выдаліць яго пры неабходнасці.
  2. Выкарыстоўвайце ключ для шыфравання дадзеных пра выхад і расшыфроўку на выхадзе.
  3. Калі прыйдзе час, выкіньце ключ.
Чырвоны блок, які вы бачыце вышэй, адлюстроўвае структуру пры выкарыстанні Hashicorp Vault. Вядома, гэта можа мяняцца ў залежнасці ад абранага інструмента.

Дык як вы выкінеце ключ у рэшце рэшт?

Зараз у вас ёсць мноства варыянтаў на выбар. Як і заўсёды, ёсць не адзінае па памеры рашэнне, але дазвольце даць вам некалькі ідэй:

  • : db / акцыз - так, вы маглі б проста прымусіць Datomic цалкам забыцца пра гэты канкрэтны ключ. Але калі вы хочаце, каб вашы дадзеныя былі зашыфраваны належным чынам, вы не можаце захаваць ключ там, дзе вы захоўваеце PII.
  • Асобная база дадзеных з магчымасцямі выдалення - усяго два слупкі: ідэнтыфікатар карыстальніка і крыпта-ключ. Проста так. Але гэта прыкладае шмат намаганняў на вашай спіне - вы павінны падтрымліваць гэтую базу дадзеных, сачыць за яе здароўем і па-ранейшаму застаецца абавязак правераць доступ.
  • Hashicorp Vault - гэта вельмі магутны інструмент, які цалкам адпавядае нашай праблеме. Ён мае глыбока наладжваную палітыку доступу, аўдыт, падзел сакрэтаў, рэжым высокай даступнасці і г.д. Аднак, каб атрымаць усе гэтыя перадачы, трэба шмат канфігурацыі і рэсурсаў. Афіцыйны падручнік для рэжыму высокай даступнасці з выкарыстаннем AWS згадвае 8 асобнікаў! Такім чынам, калі маштаб вашай праблемы апраўдвае ўкладанне намаганняў у Vault - ідзіце!
  • Рашэнні AWS - цяпер ёсць як мінімум тры прадукты, якія могуць быць выкарыстаны ў гэтай праблеме - Служба кіравання ключамі, Дыспетчар сакрэтаў і Менеджэр сістэм-менеджэраў параметраў

Мы вырашылі скарыстацца крамай Parameter па цане (перамагчы яе складана). З-за абмежавання запыту ёсць крытыка, таму што рана ці позна нам трэба будзе перайсці на што-небудзь больш эфектыўнае. Вось чаму можа быць добрай ідэяй паставіць яго за мяжу. Гэта павінна дапамагчы міграваць адносна лёгка.

Але што рабіць, калі ...

Што рабіць, калі я даведаюся, што мае дадзеныя ў небяспецы?

Затым вы хочаце павярнуць ключы шыфравання. У залежнасці ад абранага вамі рашэння, гэта можа быць рашэнне, прапанаванае дызайнам. У адваротным выпадку вы проста хочаце расшыфраваць свае дадзеныя, стварыць новы ключ, зашыфраваць яго зноў новым ключом, захаваць дадзеныя ў Datomic і выдаліць стары ключ.

Што рабіць, калі гучнасць PII занадта вялікая, каб эфектыўна паварочваць клавішы?

Калі шмат сабраных дадзеных лічыцца PII (медыцынскія дадзеныя для аднаго), то ў вас можа паўстаць праблема расшыфраваць усё, захаваць яго ў памяці і звязвацца з ім. Тады вы можаце разгледзець магчымасць увядзення дадатковага кроку для шыфравання: замест аднаго ключа, вы будзеце мець галоўны ключ і эфемерны ключ. Вы выкарыстоўваеце былыя для шыфравання дадзеных, але ніколі не захоўваеце іх у незашыфраваным выглядзе. Вы шыфраваць галоўны ключ з дапамогай эфемернага ключа. Затым, калі вы хочаце павярнуць эфемерны ключ, вы паўтараеце працэс з пункту вышэй, але толькі расшыфроўваеце і паўторна шыфруеце галоўны ключ.

Што рабіць, калі я павінен выдаліць некаторыя часткі PII зараз, а некаторыя пазней?

Уявіце, што вы бухгалтар. Калі кліент просіць вас выдаліць яго ІПП, вы павінны выконваць яго і як мага хутчэй выдаліць яго. Але частка гэтых дадзеных будзе неабходная ў выпадку правядзення падатковых расследаванняў. У такім выпадку вы можаце падзяліць свой PII на некалькі узроўняў. У кожнага з іх будзе асобны ключ крыпты. Астатняе працуе як у вышэйзгаданых пунктах.

І гэта падсумоўвае ...

Аднак трэба мець на ўвазе адно: прадукты ніколі не бываюць і не адпавядаюць GDPR. Гэта кампаніі, якія павінны паважаць PII. Прадукты могуць толькі зрабіць гэтую звычку прасцей і цяжэй.

Калі вы заўважылі недахоп у нашым мысленні, калі ласка, паведаміце нам пра гэта. Калі ў вас ёсць якія-небудзь іншыя каментары, таксама, калі ласка, паведаміце нам пра гэта.

У наступным: я напішу запіс з больш паглыбленым прыкладам выкарыстання крамы параметраў у нашых сетках. Наладзьцеся!