Flowchart for anmodning om dataadgang (fra anmodning til tilbagekaldelse)

Sådan fungerer det

1. Omdøb banerne, så de passer til jeres organisation

   Erstat Ansøger, Dataforvalter, Dataejer, Databeskyttelse og Dataplatformsteam med de roller, I reelt har. Hold dataejeren adskilt fra platformsteamet, også når den samme person i dag gør begge dele — det er sammenlægningen, der producerer en proces, hvor den, der tildeler, også er den, der godkender. Har I ingen databeskyttelsesfunktion, så sæt navn på den person, der bærer ansvaret, frem for at slette banen, og er dataforvaltningen uformel, så læg den fagansvarlige ind der, og skriv det ned.

2. Skriv jeres klassifikationsmodel ind i diagrammet

   'Læs klassifikation og håndteringsregler' er tomt, indtil niveauerne findes. Navngiv dem — offentlig, intern, fortrolig, strengt fortrolig, eller hvad jeres model bruger — og notér ved hvert af dem, hvad det tillader: kun forespørgsel på stedet, udtræk tilladt, maskering obligatorisk, underskrevet aftale påkrævet. Sig derefter, hvilket niveau der udløser grenen med aftalen om databrug, og hvilket der aldrig må forlade analysemiljøet. Uden den tabel bliver hver anmodning diskuteret fra bunden, og svarene skrider fra godkender til godkender.

3. Få formålsbeskrivelsen til at gøre reelt arbejde

   Definer det mindste, en anmodning skal sige: hvilket spørgsmål der besvares, hvilke tabeller og kolonner der er brug for, hvis oplysninger der indgår, hvor længe adgangen ønskes, og hvor et eventuelt udtræk gemmes. 'Til analyse' skal sendes retur, ikke godkendes. Det er den billigste kontrol på siden, for et ordentligt skrevet formål gør vurderingen af mindste privilegium, beslutningen om maskering og udløbsdatoen næsten mekaniske, mens et løst formål gør alle tre vilkårlige.

4. Sæt standardlængder for udløb efter klassifikation

   Hæng en standard på 'Tildel adgang med udløbsdato' for hvert niveau: for eksempel hændelsens varighed for break-glass, halvfems dage for fortrolige data, seks eller tolv måneder for interne data og projektets slutdato, hvor der er et projekt. Lad ansøgerne bede om kortere, og gør alt længere end standarden til en eksplicit beslutning hos ejeren. Udløbet er den kontrol, der overlever omorganiseringer, værktøjsskift og at alle glemmer, at processen fandtes.

5. Aftal nødvejen, før I får brug for den

   Beslut, hvem der må aktivere break-glass-adgang, hvad den giver, hvilken konto den kører fra, hvordan sessionen logges, og hvem der alarmeres i det øjeblik adgangen gives. Sæt derefter fristen for bekræftelse — et lille antal arbejdsdage — og, vigtigere endnu, beslut, hvad der sker, når ingen bekræfter. Automatisk tilbagekaldelse på fristen er den eneste udgave, der holder, for en kø af efterfølgende godkendelser uden konsekvens er blevet et permanent efterslæb inden for et kvartal.

6. Gå diagrammet igennem, og udgiv en version

   Tag det færdige diagram med til en dataejer, en analytiker der ofte anmoder om adgang, den platformsingeniør der udfører tildelingerne, og den der håndterer databeskyttelse, og test det mod tre rigtige anmodninger fra sidste kvartal — heriblandt en, der blev afvist, og en, der gik gennem break-glass. Ret diagrammet til det, der faktisk skete, frem for til det, politikken siger. Udgiv så den revision, behold de tidligere, og link til den fra politikken for datastyring, så læserne ved, hvilken version de sidder med.

Ofte stillede spørgsmål

Hvilke trin består en proces for anmodning om dataadgang af?

Opret en anmodning, der angiver formålet frem for systemet; find datasættet i kataloget, og læs dets klassifikation og håndteringsregler; bekræft, at det har en navngiven ejer, og klassificer det først, hvis det ikke har; lad ejeren vurdere formålet op imod mindste privilegium og beslutte; indgår der persondata, så registrer hjemlen, minimer felterne og før anmodningen gennem et databeskyttelsesreview eller en DPIA; tilbyd en maskeret eller aggregeret visning, før I giver rå adgang; læg en underskrevet aftale om databrug oveni ved fortrolige data; tildel adgangen med en udløbsdato; slå forespørgselslogning til; registrer rettigheden i adgangsregistret; og recertificer den derefter inden udløb eller tilbagekald den — straks, hvis personens rolle eller formålet ændrer sig. De trin, der oftest mangler i praksis, er det maskerede alternativ, udløbsdatoen og udløseren, der tilbagekalder ved rolleskift.

Hvem bør godkende adgang til et datasæt — IT eller dataejeren?

Dataejeren, altså den ansvarlige i det forretningsområde, oplysningerne beskriver — ikke det team, der driver platformen, de ligger på. Vurderingen, der skal foretages, er, om netop dette formål berettiger netop disse data, og den kan kun træffes af en, der forstår, hvad posterne betyder. Platformsteamet udfører tildelingen, sætter udløbet og slår logningen til; det bør ikke også afgøre, hvem der må læse løn-, patient- eller kundeoplysninger. En godkendelse fra nærmeste leder er værd at lægge ind som første port, fordi den bekræfter, at anmodningen hører til personens arbejde, men den erstatter ikke ejerens beslutning. Har et datasæt reelt ingen ejer, er det i sig selv et fund, og derfor lægger dette diagram 'Katalogiseret med navngiven ejer?' før vurderingen frem for efter.

Hvor længe bør en dataadgang vare, før den udløber?

Længe nok til det angivne formål og ikke længere, med standarden sat af klassifikationen frem for forhandlet pr. anmodning. Et mønster, der virker, er hændelsens varighed for break-glass-adgang, omkring halvfems dage for fortrolige data og persondata, seks til tolv måneder for almindelige interne data, og projektets slutdato, hvor anmodningen hænger på et projekt. Mekanismen betyder mere end tallene: en udløbsdato gør fjernelse til standarden og fornyelse til den bevidste handling, så adgangen henfalder af sig selv, når processen bliver forsømt. Adgang uden udløb hober sig derimod op. Når I beder en ejer om at recertificere, så send forespørgselstallene med — en rettighed, ingen har brugt i seks måneder, bliver fjernet uden diskussion, mens en liste med navne og ingen brugsdata næsten altid bliver godkendt i ét hug.

Hvornår kræver en anmodning om dataadgang en DPIA?

Efter databeskyttelsesforordningen (GDPR) artikel 35 skal der laves en konsekvensanalyse vedrørende databeskyttelse — en DPIA — når behandlingen sandsynligvis indebærer en høj risiko for de registreredes rettigheder, og den forventes i særdeleshed ved behandling af følsomme oplysninger i stor skala, ved systematisk overvågning og ved automatiske afgørelser med retsvirkning eller tilsvarende betydelig virkning. Tilsynsmyndighederne offentliggør desuden hver deres liste over behandlinger, der altid kræver en DPIA; i Danmark er det Datatilsynets liste. For en intern analyseanmodning er de ærlige udløsere som regel omfanget af den berørte personkreds, om der er tale om følsomme oplysninger eller oplysninger om strafbare forhold, om de registrerede med rimelighed ville forvente denne anvendelse, og om resultatet føder en afgørelse om dem. To ting hjælper i praksis: screen hver eneste anmodning med persondata frem for at vente på, at nogen rejser en bekymring, og behandl resultatet som vilkår på tildelingen — de maskerede kolonner, opbevaringsperioden, forbuddet mod at genidentificere — frem for som et dokument, der arkiveres og glemmes.

Hvordan adskiller siden sig fra en almindelig proces for adgangsanmodninger?

Den generelle proces for adgangsanmodninger på /da/templates/adgangsanmodning-proces dækker systemer og applikationer: nogen har brug for en rolle i et forretningssystem, nærmeste leder og systemejeren godkender, der køres en kontrol af funktionsadskillelse, og IT tildeler adgangen. Denne side dækker datasæt, og tre ting ændrer sig som følge heraf. Godkenderen er dataejeren frem for systemejeren, fordi spørgsmålet handler om, hvad posterne betyder, snarere end om, hvad en applikation gør. Et klassifikationstrin ligger midt i forløbet, fordi svaret afhænger af, hvad der står i tabellen. Og der findes et maskeret eller aggregeret alternativ, som ikke har nogen pendant i applikationsadgang — I kan ikke give nogen tres procent af et økonomimodul, men I kan give dem en visning, hvor identifikatorerne er pillet ud. Skal I designe en servicedeskformular til applikationsadgang, så start med den generelle proces; skal I styre, hvem der må forespørge i datawarehouset, så start her.