Ballerup: KMD overtrådte dataaftale - flyttede persondata til hacket udviklingsserver

Hvordan skal jeg teste min kode op i mod rigtig data, hvis ikke jeg må bruge rigtig data?

Først så spørger du ejeren af rigtigt data om du må bruge den

Derefter søger du for af test mijjøet har samme sikkerhed som produktionsmiljøet

Testmiljøet er derfor lige så sikkert som produktion og kan derfor fint indeholde rigtige data.

Det er altså ikke korrekt. Det drejer sig AFAIK primært om HVEM der har adgang til data (seperation of duties) - og udviklere skal IKKE have adgang til rigtig personfølsom data - men de har behov for (til test formål) at kunne en masse ting i test som ville give dem adgang til PII data, som de ikke må have adgang til - såfremt test systemet indeholdt rigtig PII data.

Staging skal være 100% identisk med produktion så det rent faktisk kan agere stand-in for produktion hvis det skal være nødvendigt

Men grunden til at dette ikke sker ved KMD, er sikkert at det det tager tid (dyrt), kræver mandskab og indsigt (dyrt) og er besværligt (dyrt).

Også længe at GDPR bøder ikke koster på bundlinjen, så kan det ikke betale sig. Det koster sikkert også bonuser til chefer, også længe at sikkerhed ikke giver bonuser, så sker det ikke noget.

Hvis GDPR indholdt mulighed for fængselstraf, og meget store personlige børder, til ledelse og ansvarlige, i grove eller gentagelse tilfælde. Så ville vi ikke se sådan noget, som det her.

Hvorfor skal man bruge et hastigt opsat (læs: fyldt med sikkerhedshuller) system til test?

Jeg plejer at kunne få gennemtrumfet et miljø med test, staging og produktion i samme sikre opsætning. Serverne er principielt sat helt ens op og er derfor lige sikre, hvilket de også skal være for at være så identiske som muligt med produktion. Staging skal være 100% identisk med produktion så det rent faktisk kan agere stand-in for produktion hvis det skal være nødvendigt. Testmiljøet er derfor lige så sikkert som produktion og kan derfor fint indeholde rigtige data.

IMHO - så BØR det være således at man til udvikling og test, har designet sit system, så man kan genere alle de data typer man har behov for (inkl. hvad man tror kan fejle osv. osv. - istedet for at stole på at "virkeligheden" - er repræsentativ for alle fejl).

Derudover, så kan man have et staging system - hvor man snapshot'er produktionsdata til - og kører opgraderingen der først og tester på faktiske prod data (som de så ud ved snapshot tid).

Staging setup'et skal selvfølgelig have samme beskyttelse som prod - så man ikke bare forbindet til det, fra de andre miljøer.

Giver slet ikke mening i min verden - Så må de jo ansætte en skoledreng tiul at oprette fiktive personer i deres TEST database.

Tja vi tester da absaolut også på vores udviklingsplatforme - Men det er med en testdatabase og ikke en produktionsdatabase - med reelle data.

Kan da slet ikke se hvorfor det overhovedet er lovligt at flytte de data over til et udviklingsmiljø? Er da abolut klar over det vil koste nogle timer - men efter det er oprettet en gang behøves dette ikke mere. Og hvis deres test består af 25 personer - giver det sgu slet ikke ,mening at det er nødvendigt at kopiere LIVE data

Hørt Bjarne.

Det er så nemt at opsætte regler og gemme sig bag en lov - men det er teknikerne der typisk skal rode trådene ud, fordi man ikke har tænkt konsekvensen af lovgivningen igennem.

Test data der ikke afgiver et realistisk billede af virkeligheden, er ikke realistisk data og derfor ubrugelig i selv samme test.

Der findes metoder og værktøjer til anonymisering af testdata, ...

Kan du give nogle pointere?

Jeg er særligt interesseret i hvilke "sikkerhedsgarantier", som de kan stille (og på hvilken baggrund de stiller dem), og i særlig grad, hvordan de håndterer den iboende modstrid imellem at jo sværere reidentifikation er, jo mindre interessant er data.

Er der f.eks. tale om omkodning af udvalgte identifikatorer (PII), for så taler vi næppe om reelt anonymitet, men snarere om pseudonymitet? Er der tale om, at man helt fjerner PII, for selv der er der stor risiko for reidentifikation.

Jeg mangler kort sagt stadig at se et eksempel på, hvordan man har formået at bringe risikoen for reidentifikation ned på et acceptabelt niveau uden at datasættet samtidigt ville blive betragtet som værende værdiløst; jeg kender til gengæld adskillige eksempler på, at man har påstået det, men at man var stoppet alt for tidligt i processen.

En efterhånden klassisk artikel, som illustrerer udfordringerne, er denne:https://science.sciencemag.org/content/347/6221/536.full

Her viser man, at der er betydeligt potentiale for reidentifikation i et "anonymiseret" datasæt over kreditkortkøb (fire tilfældigt valgte tid/sted for en person var nok til unikt at udpege 90% af individerne, og dermed afsløre alle deres køb).

Der er klart, jo mere man ved, jo bedre er man stillet, og at kende ca. beløbet øger sandsynligheden for reidentifikation - men allerede ved bare to tid/sted koordinater (uden beløb), så er 40% af individerne i datasættet unikt udpeget.

Der kigges også på, hvad der sker, hvis nøjagtigheden af tid/sted falder, og ja, det gør det sværere, men selv ved unøjagtige koordinater er det muligt at udpege betydende andele af individerne i datasættet.

Dette studie er ikke enestående- en anden klassiker er Netflix/IMDB sagen. Australien er også kommet i problemer med "anonyme" sundhedsdata.

Og lige nu sidder jeg og læser en artikel om en forsker, som sagsøgte staten Californien for at få udleveret "anonymiserede" datasæt over advokater med møderet til hans forskning - selvom forskeren (med hjælp fra såkaldte "anonymiseringseksperter") havde foreslået fire forskellige "anonymiseringsmetoder", som tog direkte udgangspunkt i kendskab til det konkrete domæne, og havde sat parametrene usædvanligt højt (f.eks. binstørrelse på 11), så viser artiklen at det var utilstrækkeligt. Ironisk nok var en af kilderne til alment tilgængelige eksterne data, som de brugte til reidentifikation, forskerens egen tidligere offentliggjorde forskning.

Kort sagt, bare fordi at man siger at det er anonymt, betyder ikke at det faktisk er det.

Og derfor tror jeg meget mere på pre-prod miljøer og trinvis udrulning, end jeg tror på "anonymiserede" produktionsdata i udviklingsmiljøerne.

At bruge produktionsdata med personhenførbare oplysninger til test er en gammel uskik i IT som GDPR heldigvis har sat en stopper for.

Som udvikler/tester kan jeg sagtens følge at man synes det er nemmere med kopi af produktion (er selv testmgr), men som kunde eller borger er jeg ikke interesseret i at alle mulige tilfældige personer har adgang til at kigge på min personlige data og normalt er der heller ikke givet tilsagn til at data må bruges til test formål.

Et element af testdesign er at forholdes sig til hvordan man håndterer de personfølsomme data hvis testdata kopieres fra produktion til test

Der findes metoder og værktøjer til anonymisering af testdata, men det koster penge og tid så er noget man skal vænne sig at disponere med at det indgår.

Det er min erfaring at testsystemer er et mega stort problem når det handler om persondata.

Det er muligt at anonymisere data, når man flytter produktionsdata over til et testmiljø, men det er besværligt. Og så springer man tit over hvor gærdet er for lavt og tager en rå kopi. Men så skal man pinedød have eksakt samme adgangsstyring, firewalls, logning og alle mulige andre sikkerhedsforanstaltninger på sit testsystem. Og det har man ofte ikke, fordi det er besværligt.

Udviklere og testere vil ikke have besvær. Men hvis et system indeholder produktionsdata så skal det håndteres som et produktionssystem. Og det er tydeligvis ikke sket her.

Hvis de alle hedder Test Testsen på testgade nr. 1, så får vi jo ikke testet de hundehoveder der bruger & tegn i deres titel, som vores parser måske ikke lige har taget hånd om. (endnu)

Få kunden til at oprette et preprod miljø (eller hvad du nu vil kalde det), hvor driften implementere den ændring/test du ønsker afviklet. Ja der skal være noget debug/logging slået til så den fejl der måtte komme kan blive rapporteret til dig.

• Jo flere love, jo flere lov brud

Hvordan skal jeg teste min kode op i mod rigtig data, hvis ikke jeg må bruge rigtig data?

Vi kopier PROD data ned i UAT og QA flere gange om året. Samtidig overskiver vi kunders email adresser i de to miljøer. Men hvis vi overskrev andet, ville mange af vores integrations tests da miste deres værdi.

Hvis de alle hedder Test Testsen på testgade nr. 1, så får vi jo ikke testet de hundehoveder der bruger & tegn i deres titel, som vores parser måske ikke lige har taget hånd om. (endnu) Eller en anden dum ting, vi først finder i PROD, når vi ruller ud.

ps. Det er fedt han lige tilføjer de ændrede adgangskoden til miljøerne, for at øge sikkerheden. Fordi; jo tierer man ændrer adgangskode, jo mere sikker er man.