Flowchart for anmodning om dataadgang (fra anmodning til tilbagekaldelse)
Flowchart for anmodning om dataadgang: angiv formålet, læs datasættets klassifikation, lad dataejeren beslutte, kør persondatatjekkene, tildel tidsbegrænset adgang, og recertificer eller tilbagekald.
Hvad er flowchart for anmodning om dataadgang (fra anmodning til tilbagekaldelse)?
Anmodninger om data bliver som regel behandlet, som var de anmodninger om software. Der kommer en sag ind om adgang til datawarehouset, den, der har rettighederne, giver den, og en person, der havde brug for én tabel til at besvare ét spørgsmål, ender med at kunne læse hvert eneste skema på klyngen, også dem med lønninger, patientidentifikatorer eller kortnumre. Tre vaner står for det meste af skaden. Godkenderen vælges efter, hvem der teknisk kan give adgangen, frem for efter, hvem der er ansvarlig for oplysningerne. Anmodningen nævner et system i stedet for et formål, så der er ikke noget at holde mindste privilegium op imod. Og tildelingen har ingen slutdato, så den overlever projektet, siden teamskiftet og af og til ansættelsen. Dataadgang er desuden den ene form for adgang, hvor et mindre svar næsten altid findes (en maskeret kolonne, et rækkefilter, en foraggregeret tabel), og ingen tilbyder det, fordi det tager længere tid at tilbyde end at udlevere den rå tabel. Resultatet er et landskab, hvor ingen kan sige, hvem der kan læse hvad, og hvor ikke én eneste enkeltanmodning nogensinde var urimelig.
Dette diagram handler om datasæt, ikke om konti. Har en medarbejder, der allerede er i huset, brug for endnu et system, og er spørgsmålet, hvem der godkender, og hvem der tildeler, er det den generelle proces for adgangsanmodninger på /da/templates/adgangsanmodning-proces, og den udgave, der udløses af en tiltrædelse eller et rolleskift i HR-systemet, ligger på /da/templates/medarbejder-adgangsanmodning-proces. Selve identiteten (kontoen, gruppen i kataloget, licensen) oprettes, ændres og lukkes i processen for brugerprovisionering på /da/templates/brugerprovisionering-proces; alt her forudsætter, at ansøgeren allerede har en fungerende konto, og spørger kun, hvad den konto må læse. Det er heller ikke en anmodning udefra: beder en person om indsigt i sine egne personoplysninger, udløser det en lovbestemt frist med sine egne identitetstjek og sine egne afslagsgrunde, og det forløb er tegnet på /da/templates/indsigtsanmodning-gdpr-proces. Og er oplysninger allerede havnet et sted, de ikke burde, er dette det forkerte diagram: inddæmning, vurderingen af risikoen for de registrerede og beslutningen om anmeldelse inden for 72 timer ligger på /da/templates/haandtering-af-databrud. Tilbage står noget snævert og præcist: en intern person, et navngivet datasæt, et angivet formål og en ejer, der beslutter.
De beslutninger, som de fleste nedskrevne procedurer for dataadgang overlader til vanen, er tegnet eksplicit her. 'Katalogiseret med navngiven ejer?' ligger før enhver vurdering, fordi et datasæt uden ejer ikke kan godkendes af nogen, og den ærlige tilstand i de fleste organisationer er, at den første anmodning mod en tabel er det, der endelig får den klassificeret; nej-grenen løber tilbage gennem katalogiseringen frem for at eskalere til den, der tilfældigvis byggede pipelinen. 'Hvilken adgang kræver formålet?' er en trevejsforgrening frem for et ja eller nej, så den maskerede eller aggregerede vej står på diagrammet og skal aktivt vælges fra i stedet for aldrig at blive nævnt. Og forløbet slutter ikke ved tildelingen: 'Recertificeret inden udløbsdatoen?' gør udløb til standarden og fornyelse til undtagelsen, hvilket er det stik modsatte af, hvordan adgang faktisk holdes, mens 'Er rolle eller formål ændret?' giver ejeren endnu en anledning til at tilbagekalde, der ikke venter på en reviewdato. Nødvejen er tegnet af samme grund: en udvikler med en produktionshændelse når frem til oplysningerne på den ene eller den anden måde, så 'Er der givet efterfølgende godkendelse?' lægger bekræftelse og tilbagekaldelse bag break-glass-adgangen, altså nødadgangen uden om den normale godkendelsesvej, i stedet for at lade som om, den ikke sker.
Hvad dette flowchart dækker
I denne skabelon
- Fem swimlanes (Ansøger, Dataforvalter, Dataejer, Databeskyttelse og Dataplatformsteam) fordelt på fem faser: Anmodning, Klassifikation, Ejerens vurdering, Tildeling samt Gennemgang og tilbagekaldelse
- En anmodning, der skal bære en begrundelse: 'Opret anmodning med angivet formål' er den eneste almindelige vej ind, mens grenen 'Nødadgang under hændelse?' sender produktionshændelser direkte videre til 'Giv logget break-glass-adgang' frem for at lade dem ske uden for diagrammet. Den tildeling møder derefter 'Er der givet efterfølgende godkendelse?' og ender ved 'Nødadgang tilbagekaldt og eskaleret', hvis ingen bekræfter den
- 'Katalogiseret med navngiven ejer?' i Dataforvalter-banen, hvis nej-gren kører 'Klassificer det, og udpeg en dataejer' og løber tilbage til opslaget i kataloget, så et datasæt uden ejer ikke kan godkendes som standard
- Dataejeren har beslutningen frem for IT: 'Vurder formål og mindste privilegium', derefter 'Berettiger formålet adgangen?', hvis nej-gren ender ved 'Anmodning afvist med begrundelse registreret', og 'Indgår der persondata?', der ruter videre til Databeskyttelse-banen
- En persondatagren med reelt indhold: 'Registrer hjemmel, og minimer felter' og derefter en trevejsbeslutning, 'Godkender databeskyttelse anvendelsen?', der enten godkender anmodningen, afviser den mod den samme afvisningsende eller sender den gennem 'Gennemfør DPIA, og fastsæt vilkår' og tilbage til et nyt svar, når restrisikoen er kendt
- En trevejsbeslutning, 'Hvilken adgang kræver formålet?': Maskeret eller aggregeret, Rå fortrolige data (som tilføjer 'Underskriv aftalen om databrug') eller Rå interne data, der alle mødes i 'Tildel adgang med udløbsdato', forespørgselslogning og en post i registret. 'Er rolle eller formål ændret?' og 'Recertificeret inden udløbsdatoen?' løber derefter tilbage til en ny tildeling eller ud til 'Adgang tilbagekaldt og register opdateret'
Hvornår du skal bruge skabelonen
- I skal skrive adgangsafsnittet i en politik for datastyring eller dataforvaltning for et datawarehouse, en lakehouse eller et rapporteringslag og har brug for én side, der viser, at dataejeren beslutter frem for det team, der har rettighederne
- Jeres analytikere sidder med adgange, der blev givet til projekter, som sluttede for to år siden, og I vil have udløb og recertificering bygget ind i processen i stedet for at køre det som en årlig oprydning, ingen glæder sig til
- I skal konfigurere anmodningsflowet i et datakatalog eller et access governance-værktøj og vil have godkendelsesvejen og tærsklerne for klassifikation aftalt, før de kodes ind
- Udviklerne har en break-glass-vej ind i produktionsdata, som ingen ser efter bagefter, og I har brug for, at bekræftelsen og tilbagekaldelsen står tegnet et sted, hvor både dataejerne og vagtordningen kan se dem
- Jeres databeskyttelsesfunktion og jeres dataplatformsteam bliver ved med at være uenige om, hvem der bestemmer over persondata, og I vil have hjemmel, minimering og DPIA placeret inde i flowet frem for skruet på til sidst
Sådan fungerer det
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.
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.
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.
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.
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.
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.