<< Klik for at vise indholdsfortegnelsen >> Navigation: Sikkerhed > Styring af rettigheder |
For at styre adgang til data, i særdeleshed CPR-data, i LIFA-databaserne, er der indført rollestyring efter LUA-princippet (least-privileged user account). Se eksempler på praktiske beskrivelser/udfordringer af LUA- eller MUA-princippet her.
Det betyder, at man tildeler brugere (eller AD-grupper), den mindste rettighed de har behov for til at udføre deres arbejde. Brugere kan få tildelt en eller flere roller, som hver især kun giver rettighed til at udføre bestemte handlinger på databaserne.
Implementeringen i LIFA's databaser betyder, at man kan tildele brugere meget detaljerede rettigheder, ved brug af et overskueligt antal roller, som er oprettet på databaserne, og rettighederne er brudt ned, så der kan styres adgang helt ned på enkelte felter i en given tabel. Der kan således være behov for at én ansat kan få lov at se CPR-nummer på en ejer på en ejendom, hvis vedkommende skal skrive digitalt til ejeren. Samtidig skal en anden ansat kun have lov til at se navnet på ejeren, men ikke yderligere oplysninger. Da disse oplysninger er samlet i én tabel i Grunddatamodellen, er der behov for at kunne styre denne adgang meget granuleret. Nedenstående beskriver den model, som vil kunne opfylde disse behov.
De første tre roller er primært rettet mod at styre adgangen til data - især persondata.
De samme roller benyttes på tværs af LIFA’s databaser, men i nedenstående eksempel er de eksemplificeret med adgangen til LOIS-databasen.
Anvendes til: Almindelige ansatte – der ikke skal have adgang til persondata overhovedet.
Opsætning i databasen: En bruger som er tildelt denne rolle, vil ikke kunne se/spørge på tabeller/views/procedurer som indeholder persondata.
Anvendes til: Ansatte der skal kunne sende digital post. Det vil sige, at de skal kunne se eksempelvis CPR-nummer, status, navn, adresse, postnummer og by, men ikke øvrige personoplysninger.
Opsætning i databasen: En bruger som er tildelt denne rolle vil kunne se/spørge på visse tabeller/views/procedurer som indeholder persondata.
Anvendes til: Ansatte der skal arbejde med personoplysninger, enten direkte eller i forbindelse med analyser.
Opsætning i databasen: En bruger som er tildelt denne rolle, vil kunne se/spørge på alle tabeller/views/procedurer som indeholder udvidede persondata f.eks. ægtefælle, børn m.m.
De næste roller er primært rettet mod administration af af opgaver eller selve databasen.
Anvendes til: Ansatte der skal foretage stikprøvekontrol af den logning der sker på forespørgsler på persondata.
Opsætning i databasen: En bruger som er tildelt denne rolle, vil kunne se/spørge på de tabeller/views som indeholder logningsdata.
Anvendes til: Ansatte der skal kunne styre abonnement på personer i CPR-registret. Det gælder både oprettelse, opsigelse og ændring af abonnement. Se mere om servicen her.
Opsætning i databasen: En bruger som er tildelt denne rolle vil kunne spørge og ændre i de data som styrer abonnementer ifht. Serviceplatformen. Dette kan enten være ved at rette direkte i tabellen eller gennem et program/webservicekald.
Anvendes til: Ansatte der manuelt skal vedligeholde oplysninger om ejere med beskyttet adresse. Dette er en rolle som vil forsvinde, når dette kan ske automatisk.
Opsætning i databasen: En bruger som er tildelt denne rolle, vil kunne spørge og ændre i de data som styrer adgangen til ejere med beskyttet adresse.
Anvendes til: Ansatte der skal være superbrugere - typisk GIS-administratorer. Svarer til SQL-serverens db_ddladmin rolle.
Opsætning i databasen: En bruger som er tildelt denne rolle, vil kunne oprette/slette og redigere skemaer, views og tabeller på databasen, men skal kombineres med Rolle 1-3 for at kunne se data.
Anvendes til: Ansatte der skal administrere databasen - typisk IT-administratorer. Svarer til SQL-serverens indbyggede db_owner rolle.
Opsætning i databasen: En bruger som er tildelt denne rolle, vil have fulde rettigheder på databasen.