Adgang og sikkerhed

Roller og rettigheder: login er ikke adgangskontrol

En bruger kan være korrekt logget ind og stadig få adgang til den forkerte kundes data, en skjult adminfunktion eller en handling, som rollen ikke må udføre. Sikker autorisation kræver klare regler for både funktion, data og ejerskab – håndhævet dér, hvor handlingen faktisk udføres.

Skeln mellem login og rettigheder

Login bekræfter, hvem brugeren er. Autorisation afgør, hvad den bruger må gøre med en bestemt funktion eller datapost. Begge dele er nødvendige, men de løser ikke det samme problem.

Autentifikation: Er det den bruger, som loginudbyderen siger det er?
Autorisation: Må brugeren udføre netop denne handling på netop disse data?

En skjult knap er ikke en sikkerhedsregel. En bruger kan kalde API'et direkte eller ændre et id i browserens netværkskald. Kontrollér derfor rettigheden på serveren, i databasens politikker eller i platformens Security Rules.

Skriv en adgangsmatrix før reglerne kodes

Start med virksomhedens handlinger og data – ikke med teknologiske rollenavne. En lille matrix gør uklare antagelser synlige og kan senere bruges som grundlag for tests og onboarding.

Handling	Medarbejder	Leder	Systemejer
Se egne sager	Ja	Ja	Ja
Se teamets sager	Nej	Ja, eget team	Ja
Godkende betaling	Nej	Efter beløbsgrænse	Efter virksomhedens regel
Ændre roller	Nej	Nej	Ja, med logning

Eksemplet er ikke en standardskabelon. Jeres matrix skal også angive virksomhed, afdeling, ejerskab, status og eventuelle beløbs- eller godkendelsesgrænser, når de påvirker adgangen.

Roller er nyttige, men sjældent hele svaret

Roller som medarbejder, leder og administrator gør reglerne lettere at administrere. Mange apps skal dog også kontrollere relationen til dataene. To brugere kan have samme rolle, men tilhøre forskellige kunder, teams eller projekter.

Rolle: Hvilke typer handlinger må brugeren udføre?
Virksomhed eller tenant: Hvilken kundes data må brugeren overhovedet ramme?
Ejerskab og relation: Er posten brugerens egen, delt med teamet eller tildelt konkret?
Kontekst: Gælder adgangen kun ved en bestemt status, beløbsgrænse eller godkendelse?

OWASP anbefaler mindst mulig adgang, afvisning som udgangspunkt og kontrol af rettigheder på hver forespørgsel. Det betyder også kontrol af det konkrete objekt: Et gyldigt sags-id giver ikke i sig selv ret til at læse eller ændre sagen.

Håndhæv reglerne i den stack appen allerede bruger

Det rigtige kontrolpunkt afhænger af arkitekturen. Fællesnævneren er, at en klient ikke må kunne tildele sig selv en rolle eller omgå kontrollen ved at kalde datalaget direkte.

Firebase

Firebase Authentication giver brugerens identitet. Firestore og Storage kræver separate Security Rules, som kontrollerer bruger, rolle og dokument. Serverbiblioteker omgår Firestore Security Rules og skal derfor beskyttes med IAM og serverens egen autorisationslogik. Test reglerne automatisk i Local Emulator Suite.

Supabase eller anden PostgreSQL-løsning

Row Level Security kan begrænse hvilke rækker en bruger må læse og ændre. Når RLS er aktiveret, bruger PostgreSQL en afvis-som-standard-politik, hvis ingen politik tillader handlingen. Kontrollér særskilt ejere, servicekonti og roller, som kan omgå RLS, og læg aldrig privilegerede servernøgler i frontend.

Microsoft Entra ID

App roles kan tildeles brugere eller grupper og leveres som rolleclaims i tokens. API'et skal stadig validere tokenet og kontrollere den forventede rolle samt den konkrete datarelation. En Entra-administratorrolle er ikke automatisk det samme som en forretningsrolle i jeres app.

Eget API eller backend-framework

Saml kontrollerne i fælles middleware eller en autorisationsfunktion, men vurder stadig hver handling og datapost. Filtrér både input og output, så en bruger ikke kan sende et ekstra role-felt eller modtage følsomme felter, som brugerfladen skjuler.

Test afslag – ikke kun den glade vej

En rettighedstest er først nyttig, når den beviser både det tilladte og det forbudte. Kør testene mod API, regler eller databasepolitik – ikke kun gennem de synlige knapper.

Ingen session: Kan en udlogget bruger læse eller ændre noget beskyttet?
Forkert rolle: Kan en almindelig bruger kalde en adminhandling direkte?
Forkert virksomhed: Hvad sker der, hvis et id fra en anden kunde sættes i URL eller request?
Forkert objekt: Kan brugeren ændre en kollegas post, selv om begge har samme rolle?
Manipuleret input: Kan klienten indsende rolle, ejer-id, pris eller godkendelsesstatus, som serveren selv bør bestemme?
Fratrådt bruger: Forsvinder adgangen også fra aktive sessioner, grupper, invitationer og servicekonti?

Drift kræver ejerskab og en adgangsproces

Korrekt kode løser ikke gamle brugere og glemte administratorer. Udpeg en systemejer, som kan godkende adgang, fjerne den igen og forklare, hvorfor privilegerede roller findes.

Onboarding: Tildel den mindste rolle, der løser arbejdsopgaven, og undgå delte konti.
Ændringer: Log hvem der tildelte eller fjernede en privilegeret rolle, hvornår og hvorfor.
Offboarding: Fjern adgang samme sted som den gives, og kontrollér aktive tokens, grupper, API-nøgler og ejerskab.
Gennemgang: Sammenhold jævnligt aktive brugere og roller med virkelige medarbejdere, kunder og leverandører.

Typiske fejl

Alle indloggede brugere behandles ens: Login bliver fejlagtigt brugt som fuld adgangskontrol.
Adminlinket er bare skjult: Endpointet virker stadig, hvis nogen kalder det direkte.
Rollen ligger i et redigerbart profilfelt: Brugeren kan opgradere sig selv gennem klienten eller et direkte request.
Kun rollen kontrolleres: En medarbejder kan læse en anden kundes post ved at ændre id.
Én bred regel overlapper de smalle: Den brede tilladelse gør de efterfølgende begrænsninger uden effekt.
Servicekontoen kan alt: En backendnøgle omgår datalagets normale politikker uden tilsvarende kontrol i serverkoden.
Kun tilladelser testes: Ingen test beviser, at den forkerte bruger faktisk får afslag.

Tjekliste før medarbejdere eller kunder får adgang

☐ Login og autorisation er beskrevet som to separate kontroller.
☐ En adgangsmatrix forbinder roller med handlinger, data og relevante grænser.
☐ Ukendte roller, nye endpoints og manglende regler giver afslag som udgangspunkt.
☐ Rettigheder kontrolleres på serveren, i databasen eller i platformens Security Rules.
☐ Hver forespørgsel kontrollerer både handlingen og den konkrete datapost.
☐ Klienten kan ikke selv ændre rolle, tenant, ejer eller andre privilegerede felter.
☐ Servicekonti, server-SDK'er og administratorroller har særskilt afgrænset adgang.
☐ Tests dækker udlogget bruger, forkert rolle, forkert kunde, forkert objekt og manipuleret input.
☐ Ændringer i privilegerede roller logges uden at gemme tokens eller unødige persondata.
☐ En navngiven systemejer håndterer onboarding, rolleændringer, offboarding og adgangsgennemgang.

Relaterede guides

Firebase Authentication til sikker identitet Microsoft SSO med Entra ID API-nøgler og secrets til serviceadgang Logning og overvågning af sikkerhedshændelser Se hele guidebiblioteket

Officielle kilder

Autorisationsmodellen skal tilpasses appens datamodel, arkitektur og forretningsregler. Kontrollér altid den valgte platforms aktuelle dokumentation og test reglerne i jeres konkrete løsning før produktion.