Identiteet ilma isikuteta

Klient kirjutab kassaväljale e-posti aadressi. Ta läheb poe enda tellimuskirjesse, kuhu ta kuulub, ja hetk hiljem saadab poe server Heatrailile selle tellimuse kohta kontrolli. Aadressi päringus ei ole, ja päringu versiooni, milles ta võiks olla, ei ole. See artikkel räägib sellest, mis selle asemel liigub, ja sellest, mida ta kaitseb.

Omadus

Toored e-posti aadressid ja telefoninumbrid ei jõua kunagi Heatrailini. Kohale jõuab poes arvutatud võtmestatud räsi. Salvestatu on teine võtmestatud räsi, mis arvutatakse ainult API-s, nii et väärtus meie andmebaasis ei ole väärtus, mille pood saatis. E-posti räsi on endiselt isikuandmed, ja me kohtleme teda nii.

Miks see kehtib

Kaks astet kahel masinal

Esimene arvutus toimub poe enda serveris. Ta võtab väärtuse, mida pood juba hoiab, tuletab sellest võtmestatud räsi ja paneb selle päringusse. Sõnastus loeb: see ei ole lubadus, et me aadressi pärast vastuvõtmist ära viskame, ja see ei ole säilituspoliitika. Aadress ei lahku kunagi poe taristust, seega ei ole meie poolel valeseadistust, mis teda vastu võtaks, silumisvõtit, mis teda logitaks, ega tugiprotseduuri, mis teda tagasi loeks. Asi, mis kunagi ei liigu, ei saa juhuslikult kohale jõuda.

Teine arvutus toimub ainult API-s, võtmematerjali all, mida pole kunagi mujal olnud, ja ainult tema väljund kirjutatakse üles. Seega väärtused meie andmebaasis ei ole väärtused, mille ükski pood arvutas, ja andmebaasi koopia ilma selle võtmematerjalita ei ole joondatav sellega, mida pood saadavad. Kaks astet on kahel erineval põhjusel. Esimene on selleks, et kaks poodi tunneksid sama identifikaatori ära ilma kumbki seda meile näitamata. Teine on selleks, et meie hoiu ei oleks hulk väärtusi, mida keegi teine juba hoiab.

Rolle hoitakse tahtlikult lahus, sealhulgas ühte lahutust, mida on kerge mööda vaadata: volitus, millega pood päringuid allkirjastab, ei osale identifikaatorite räsis. Konstruktsioonid ise, väljade vormingud ja see, mida integraator tegelikult ehitab, on dokumenteeritud seal, kus integraator neid vajab, teegi viites ja API viites. See leht räägib omadusest, mis jääb tõeseks ükskõik kuidas mehhanism on ehitatud.

Joonis 1

Väärtus juhtmestikul ei ole aadress, ja väärtus andmebaasis ei ole väärtus juhtmestikul. Kumbki masin ei hoia mõlemat võtit.

Tühi keelatakse, mitte ei räsi

Suurem osa räsitud identifikaatori kasust tuleb igavast eeldusest: kaks erinevat inimest toodavad kaks erinevat väärtust. See eeldus murdub hetkel, mil keegi räsib tühja.

Kiusatus on päris ja heatahtlik. Poodil, kellel telefoninumbrit ei ole, tahaks payloadi kuju püsivana hoida, seega räsib ta tühja stringi või kohatäidet, mille kassa puutumata väljale paneb, ja saadab selle. Tulemus on üks väärtus, mida jagavad kõik külaliskassad võrgustikus, mida süsteem loeks üheks erakordselt hõivatud kliendiks, kes seoks tuhandeid seosetuid tellimusi kümnetes poodides. See oleks graafi suurim ja enesekindlaim jama, sündinud abivalmist mugavusest.

Seega keelatakse ta mõlemal poolel. Kliendifunktsioon ei tagasta midagi tühja väärtuse, tühiku, tuntud kohatäite ega millegi kohta, mida ta ei suuda parsida, ja leping on, et väli jäetakse päringust üldse välja, mitte ei saadeta tühja stringina. API keeldub saabumisel eraldi tuntud kohatäiteväärtustest, sest lepingust saab piir alles siis, kui üks pool lõpetab eeldamise, et teine sai õigesti. Pood, kellel telefoninumbrit ei ole, ei saada telefonivälja. See on kogu lugu.

Mida räsi ostab, ja mida mitte

See, mida ta ostab, on kitsas ja väärt omamist. Keegi, kes võtaks kõik, mida me hoiame, hoiaks hulka väärtusi, mida ei saa lugeda, millele ei saa kirjutada ja mida ei saa helistada. Heatraili kompromiteerimine ei anna kontaktnimekirja. See on lause, mille tõeseks tegemiseks kogu korraldus on olemas.

Räsimine ei muuda andmeid anonüümseks. Pood, kes juba hoiab kliendi aadressi, saab arvutada selle esimese astme väärtuse ja vaadata, kas see on nende hulgas, mida ta meile saatis. See ei ole disainile peale kinnitatud nõrkus, see on sama omadus, mis teeb poodidevahelise äratundmise üldse võimalikuks: väärtus, mida igaüks originaaliga saab taastoota, on pseudonüümne, mitte anonüümne. See on ka põhjus, miks iga artikkel selles kogus kohtleb räsitud identifikaatorit läbivalt isikuandmetena, ja miks räsi ilmub siin kaitsemeetmena, mitte vabastusena millestki.

Esimesest astmest tuleneb üks piir, ja turvaleht ütleb ta samade sõnadega. See aste on võtmestatud materjaliga, mida jagavad osalevad poed, sest just jagatud materjal teeb ühe inimese identifikaatori kahele neist samaks. Ta istub seega konstruktsiooni järgi iga osaleva poe serveris, ja poodidevaheline äratundmine on nii tugev, kui on selle materjali hoie kogu võrgustikus. Teine aste hoiab Heatraili enda salvestuse sellest sõltuvusest väljas: ta jookseb ainult API peal, võtmematerjaliga, mis ei ole kunagi kusagil mujal olnud.

Kuidas kontrollida

Kaks kontrolli. Esimene ebaõnnestub enne, kui autentimine üldse loeb, sest identifikaatori väli võtab räsi ja mitte midagi muud: toores aadress on valideerimisviga, mitte väärtus, mille me sisse võtame ja siis lubame unustada.

# Sign this the way the reference shows, and send a real Idempotency-Key:
# both are checked before the payload is, so a placeholder signature answers
# 401 and a missing key answers 400 rather than the error being demonstrated.
curl -s -X POST https://api.heatrail.eu/v1/check \
  -H "Content-Type: application/json" \
  -H "Authorization: HR1 {key id}:{signature}" \
  -H "Idempotency-Key: chk-verify-hashing-boundary-01" \
  -d '{"order_ref":"ord-1","ip":"203.0.113.42",
       "email_h":"mari.tamm@example.ee"}'

# 422 invalid_payload. The details name email_h: the field takes a
# stage-one hash, and an address is not one.

Teine on lugemine, mitte kutse. Klient on avaldatud kood, seega avage tema identifikaatorite räsi funktsioon ja kinnitage, mida ta tühjaga teeb: tühi väärtus, tühik ja tuntud kohatäide tulevad kõik tagasi null-ina, ja dokumenteeritud leping on, et väli jäetakse siis välja. Kui ta tagastaks seal väärtuse, omandaks võrgustik ülal kirjeldatud tohutu jagatud sõlme, mis teeb temast selle lehe ühe funktsiooni, mida tasub ise lugeda. Ta on teegi viites, ja sama garantii on API kohta öeldud API viites.

Õiguslik alus

Võtmestatud räsi on pseudonüümimise meede GDPR artikli 4(5) tähenduses, ja asjakohane tehniline meede artiklite 25 ja 32 alusel. Ta ei vii andmeid määrusest välja, mis on täpselt põhjus, miks iga teine artikkel siin kohtleb räsitud identifikaatoreid isikuandmetena ja miks miski sellel saidil ei kirjelda neid anonüümsena. Toorete kontaktväljade keeld API piiril on andmete minimeerimine artikli 5(1)(c) alusel, jõustatud skeemiga, mitte poliitikaga: väli väljaspool aktsepteeritud hulka on valideerimisviga, seega minimeerimist ei saa heatahtlik liides tagasi pöörata. Vt andmetöötluslepingut ja usalduskeskust.

Jäljed, millesse need väärtused seotakse, kui nad kohale jõuavad, ja miks see on ajaloo omadus, mitte kirje isiku kohta.
Miks võrku ei saa loetleda, sama argumendi teine pool: räsitud identifikaatorist on ründajale vähe kasu, kui ta ei saa meilt ka tema kohta küsimusi esitada.
Unustamine ajakava järgi, kui kaua neid väärtusi hoitakse ja mis need kustutab.
Teegi viide, mehhanismile, mida see artikkel tahtlikult kirjeldab ainult omadusena.