Adgang og sikkerhed

Hold kunders data adskilt i en flerbruger-app

Når flere virksomheder bruger samme app, er et gyldigt login ikke nok. Appen skal bevise ved hver relevant handling, hvilken virksomhed brugeren handler for, og kun åbne den virksomheds data. Grænsen skal også gælde filer, cache, rapporter og jobs – ikke kun de lister, brugeren kan se på skærmen.

Udgivet 19. september 2026 · Ca. 10 minutters læsetid

En bruger, en rolle og en virksomhed er tre forskellige ting

En tenant er den kunde, virksomhed eller organisation, hvis data og ressourcer skal holdes adskilt fra andre. Den samme person kan være medlem af flere virksomheder, og rollen “administrator” bør normalt kun gælde inden for den valgte virksomhed. Derfor kan hverken login eller rollen alene afgøre, hvilke data der må læses og ændres.

Spørgsmål	Eksempel	Kontrol
Hvem er personen?	En indlogget medarbejder	Valideret session eller token
Hvilken virksomhed handles der for?	Virksomhed A	Aktuelt, serververificeret medlemskab
Hvad må personen gøre dér?	Læse sager, men ikke eksportere	Rolle, handling og konkret datapost

Kortlæg hele tenantgrænsen

En databaseforespørgsel er kun én vej til kundedata. Skriv alle steder ned, hvor en virksomhed vælges, data gemmes eller et resultat genbruges. OWASP fremhæver blandt andet database, cache, filer, API'er og asynkront arbejde som selvstændige grænser, der kan lække på tværs af kunder.

Brugerflade og API: Lister, detaljer, søgning, ændringer, sletning, rapporter og administratorfunktioner.
Datalag: Tabeller, dokumenter, views, databasefunktioner, søgeindeks og analysekopier.
Filer: Lagerstier, metadata, previews, downloadlinks og midlertidige eksportfiler.
Delt drift: Cache, sessionsdata, køer, baggrundsjob, websockets og notifikationer.
Integrationer: Webhooks, regnskab, CRM, email og andre systemer, der modtager tenantens data.

Lad klienten vælge – men aldrig bevise – virksomheden

En virksomheds-id i URL, header, formular eller local storage kan være praktisk som valg, men værdien kommer fra en klient, som kan ændres. Serveren skal forbinde den valgte virksomhed med den validerede identitet og kontrollere et aktuelt medlemskab, før tenantkonteksten bruges videre.

Valider identiteten: Kontrollér session eller token, udsteder, modtager og udløb efter loginløsningens model.
Slå medlemskabet op: Bevis på serveren, at personen eller servicekontoen må handle for den valgte virksomhed.
Fastlås konteksten: Send den verificerede tenant videre gennem requestet; lad ikke senere kode erstatte den med et ubekræftet felt.
Kontrollér objektet: Find sagen, filen eller ordren inden for tenantens område – ikke kun efter objektets id.

Et UUID er ikke adgangskontrol. OWASP beskriver ændring af et objekt-id som en almindelig vej til brudt adgang på objektniveau. Tilfældige id'er kan gøre gæt sværere, men serveren skal stadig kontrollere ejerforhold og handling.

Vælg isolation efter data og risiko

Der findes ikke én rigtig lagermodel. Microsoft beskriver isolation som et spektrum: Nogle løsninger deler app og database, andre giver hver kunde sin database eller en hel deployment, og en hybrid kan isolere udvalgte kunder eller datatyper stærkere. Valget påvirker sikkerhed, pris, drift, skalering og muligheden for at flytte kunder.

Model	Typisk grænse	Det skal stadig bevises
Delt database	Tenantfelt, scoped adgang og eventuelt datalagspolitik	At alle læse- og skriveveje altid anvender grænsen
Separat schema eller database	Routing fra verificeret tenant til korrekt datalager	At forbindelser, backup, jobs og administration ikke krydses
Separat deployment	Egen app- og dataressource for kunden	At fælles identitet, drift og integrationer bevarer grænsen

Håndhæv grænsen dér, hvor alle dataveje passerer

Isolationsreglen bør ligge i en fælles, obligatorisk adgangsvej – eksempelvis et repository-lag, en API-policy, Security Rules eller Row Level Security – så en ny skærm ikke er afhængig af, at en udvikler husker endnu et filter. Et ekstra lag i databasen kan begrænse skaden, hvis applikationskoden laver en fejl, men mekanismen afhænger af stacken.

PostgreSQL: Row Level Security kan begrænse rækker ved læsning og skrivning. Superbrugere, roller med BYPASSRLS og normalt også tabelens ejer omgår dog politikkerne, så appens normale requestrolle skal kontrolleres.
Cloud Firestore: Klientforespørgsler skal passe til Security Rules; reglerne filtrerer ikke et for bredt resultat. Serverbiblioteker omgår Security Rules og skal i stedet sikres med IAM og serverens egen adgangslogik.
Andre datalagre: Brug platformens dokumenterede mekanisme, eller en fælles server-side adgangsvej, og verificér særskilt læsning, oprettelse, ændring og sletning.

Tværgående rapportering og platformadministration må ikke blive en skjult undtagelse. Giv den en særskilt identitet, mindst mulige rettigheder, tydelig brugeroplevelse og et revisionsspor, der viser hvem der åbnede hvilken kundes data og hvorfor.

Før tenantkonteksten med gennem filer, cache og jobs

De skjulte lækager opstår ofte efter det oprindelige API-kald. Behandl tenant som en del af sikkerhedskonteksten hele vejen, og kontrollér den igen dér, hvor arbejdet udføres eller resultatet udleveres.

Cache: Medtag tenant og andre adgangsrelevante værdier i nøglen. Kontrollér stadig adgang før et beskyttet cachefund bruges.
Filer: Gem håndhævet ejerskab i metadata eller sti, og kontrollér tenant før upload, preview, download, deling og sletning.
Baggrundsjob: Læg en verificerbar tenantreference i jobbet, og genetablér identitet og rettighed i workeren i stedet for at stole blindt på køens payload.
Eksport: Anvend samme afgrænsning ved generering og igen ved download af den færdige fil; brug kort levetid efter behov.
Søgning og analyse: Indeks, dashboards og aggregeringer skal have en dokumenteret tenantgrænse, også når de ligger uden for hoveddatabasen.

Bevis afslag med to realistiske virksomheder

En test med én virksomhed kan kun bevise, at den tilladte vej virker. Opret to isolerede testvirksomheder med brugere, roller, poster og filer, og genbrug de samme API-kald og forbindelsesformer som appen anvender i drift.

Log ind som bruger i virksomhed A, og erstat virksomhed, objekt-id, fil-id og job-id med værdier fra virksomhed B.
Test både detaljevisning, lister, søgning, opdatering, sletning, eksport, download og delbare links.
Skift virksomhed i samme session, browserfane og genbrugte databaseforbindelse, og kontrollér at gammel kontekst ikke hænger fast.
Kør testen som appens almindelige database- eller serviceidentitet; en privilegeret testkonto kan skjule eller forvrænge den virkelige politik.
Tilføj en ny tenant-ejet tabel eller filtype, og kontrollér at en test eller klassifikation fejler, indtil grænsen er besluttet.
Bekræft, at afvisningen hverken ændrer data, starter et job, sender en notifikation eller afslører om objektet findes.

Log grænsebrud uden at lave en ny datalæk

Registrér afviste og uventede forsøg med request-id, verificeret tenant, handling, ressource-type og resultat. Alarmér på gentagne mønstre og pludselige skift, men undgå at kopiere dokumentindhold, tokens eller følsomme persondata ind i loggen. En administratorvej på tværs af virksomheder bør være eksplicit og kunne revideres.

Typiske fejl

“Alle er logget ind”: Login beviser identitet, men ikke adgang til den valgte virksomhed eller datapost.
Tenant-id kommer fra browseren: Headeren eller URL'en bruges direkte som databasefilter uden medlemskontrol.
Filteret kopieres overalt: Én ny endpoint, rapport eller databasefunktion glemmer grænsen.
Kun tabellerne er sikret: Filer, cache, søgeindeks, eksporter eller jobresultater kan stadig krydse kunder.
Servicekontoen kan alt: Serverkode eller worker omgår datalagets politik uden en tilsvarende, testet kontrol.
Support er permanent superbruger: Tværgående adgang mangler sag, tidsgrænse, tydelig tilstand og revisionsspor.
Kun tilladt adgang testes: Ingen har prøvet samme request med en anden virksomheds id.

Tjekliste før flere virksomheder bruger appen

☐ Tenant betyder én klart defineret kunde, virksomhed eller organisation i datamodellen.
☐ Identitet, virksomhedstilknytning og rolle er adskilte og serververificerede.
☐ Klientens tenant-id bruges kun som valg – aldrig som bevis på adgang.
☐ API, database, filer, cache, søgning, køer, eksport og integrationer er kortlagt.
☐ Hver tenant-ejet ressource har en håndhævet forbindelse til den rette virksomhed.
☐ En fælles adgangsvej eller datalagspolitik beskytter alle normale læse- og skriveveje.
☐ Privilegerede roller og servicekonti er mindst muligt afgrænsede og kan ikke skjult omgå kontrollen.
☐ Support og tværgående administration er særskilt autoriseret, synlig og reviderbar.
☐ Testvirksomhed A kan ikke læse, ændre, eksportere eller starte arbejde for virksomhed B.
☐ Tests bruger samme roller, forbindelser og serverveje som den udgivne app.
☐ Afviste grænseforsøg kan opdages uden at følsomme data kopieres til logs.

Relaterede guides

Roller, rettigheder og adgang til den enkelte datapost API-sikkerhed og server-side kontrol Supabase, RLS og sikker dataadgang Firebase Authentication og Security Rules Sikker supportadgang på tværs af brugere

Officielle kilder

Den konkrete håndhævelse afhænger af appens arkitektur og datalager. Kontrollér den aktuelle dokumentation for de teknologier, løsningen allerede bruger.

Virker appen, men er grænsen mellem kunder ikke bevist?

I Startklar gennemgår vi den eksisterende identitet, datamodel og de faktiske adgangsveje. Målet er en tenantgrænse og negative tests, der passer til appens nuværende stack – uden at tvinge løsningen over på en bestemt platform.

Se Startklar-forløbet