Hvad er row-level security (RLS)?

Row-level security (RLS) er en metode til at styre adgang til data på rækkeniveau i en database, et datalager eller et BI-værktøj. I stedet for at give en bruger adgang til hele tabeller, sikrer RLS, at brugeren kun kan se (og evt. ændre) de rækker, som vedkommende er autoriseret til ud fra regler som team, region, kunde eller rolle.

Hvad består row-level security (RLS) af?

RLS er ikke én “feature” alene, men et sæt mekanismer, der tilsammen håndhæver adgangskontrol helt nede på datarækken. Typisk består en RLS-implementering af:

• Identitet og autentificering: Hvem er brugeren (fx via SSO, AD/Entra ID, IAM-roller eller applikationslogin)?
• Roller og rettigheder: Hvilken rolle har brugeren, og hvilke handlinger må rollen udføre (read/write/admin)?
• RLS-politikker/regler: Logik der afgør, hvilke rækker en given bruger må se (fx “region = brugerens region”).
• Mapping mellem bruger og data: En tabel/claim/attribute, der forbinder brugere til fx kunde-id, kontor, afdeling eller projekt.
• Håndhævelse i datalaget: Politikkerne skal eksekveres dér, hvor data tilgås (database, view, semantic layer eller BI-model) – ikke kun i UI.
• Audit og logging: Mulighed for at dokumentere og spore dataadgang (vigtigt for compliance og incident response).

Det centrale er, at RLS flytter sikkerhed fra “hvem må se tabellen?” til “hvem må se hvilke rækker i tabellen?”.

Hvordan fungerer row-level security (RLS)?

RLS fungerer ved at filtrere resultater dynamisk baseret på den aktuelle bruger (eller servicekonto), der udfører en forespørgsel. I praksis sker der typisk én af følgende tilgange:

• Policy-baseret filtrering i databasen: Databasen har indbyggede RLS-politikker, som automatisk tilføjer et filter til SELECT/UPDATE/DELETE afhængigt af brugerens identitet.
• Views med sikkerhedslogik: Du eksponerer data gennem views, der indeholder WHERE-betingelser, som refererer til brugerens rolle/claims eller en mappingtabel.
• BI/semantic layer RLS: BI-laget (fx en datamodel) anvender regler, der begrænser, hvilke rækker en rapportbruger ser.

En klassisk regel kan være: “En sælger må kun se de kunder, hvor customer.owner_id = current_user_id” eller “En region manager må se alle rækker med region IN (brugerens regioner)”.

Det afgørende er, at du designer RLS, så reglerne er konsistente på tværs af rapporter, API-kald og eksport. Ellers ender du med, at sikkerheden kun gælder i én kanal.

Hvorfor er row-level security (RLS) vigtigt for B2B-virksomheder?

I B2B er data ofte delt på tværs af teams, markeder og kundesegmenter – og det skaber et reelt behov for at begrænse adgang uden at bremse forretningen. RLS er især vigtigt, når du:

• Har flere teams på samme datasæt: Salg, Customer Success og marketing arbejder ofte i samme CRM/BI, men skal ikke nødvendigvis se samme kundedata.
• Arbejder på tværs af lande/regioner: Lovgivning, kontrakter og interne retningslinjer kan kræve segmenteret adgang.
• Har følsomme felter i “normale” tabeller: Omsætning, rabatter, pipeline, kontaktpersoner og supporthistorik kan være forretningskritiske.
• Kører selvbetjent analytics: Jo mere du giver organisationen adgang til dashboards og udforskning, jo vigtigere er sikkerhed i bunden.
• Vil reducere risikoen for datalæk: Mange datalæk sker ikke via “hack”, men via for brede rettigheder, exports og delte rapportlinks.

RLS hjælper dig med at balancere datademokratisering og kontrolleret adgang. Det gør det lettere at skalere rapportering og datadrevne processer uden at skabe et sikkerhedsmæssigt efterslæb.

Hvordan bruges row-level security (RLS) i praksis?

RLS giver mest værdi, når du tager udgangspunkt i dine forretningsprocesser og datamodeller – ikke kun i tekniske roller. Her er typiske praktiske scenarier i B2B:

1) Sælger- og account-beskyttelse i CRM- og pipeline-data

Du kan sikre, at hver sælger kun ser egne accounts og deals, mens ledere ser hele teamets portefølje. Det reducerer intern friktion og mindsker risikoen for, at data bliver brugt forkert eller lækket ved fejl.

2) Kundesegmentering i BI og dashboards

Hvis du deler dashboards bredt, kan RLS sikre, at en bruger kun ser rækker for sin afdeling, sin region eller sine kundekonti. Det er især relevant, hvis du har “globalt” datagrundlag, men “lokalt” ansvar.

3) Multi-tenant SaaS og portaler

Driver du en platform med flere kunder i samme database, er RLS et vigtigt lag for at sikre, at kunde A aldrig kan tilgå kunde B’s data. Her bør RLS kombineres med tenant-id, stærk autentificering og klare adgangsmønstre i applikationslaget.

4) Adgangsstyring ved eksport og integrationer

En overset faldgrube er, at sikkerhed kan omgås via dataeksport eller API. Hvis du tilbyder eksportfunktioner, bør du sikre, at de samme RLS-regler gælder for “download som CSV” som for skærmvisning. Tilsvarende ved integrationer: servicekonti bør begrænses og scopes bør afspejle mindst mulige privilegier.

Hvis du arbejder med import/eksport i dataprocesser, kan det være relevant at have klare retningslinjer for, hvordan data håndteres i praksis. Se fx mulighederne for import og export i en lead- og dataproces.

5) RLS i forbindelse med målgruppe- og ICP-arbejde

Selv i marketing- og leadgenereringsflows kan der være behov for at afgrænse adgang: fx hvis forskellige forretningsenheder arbejder med hver deres segmenter, eller hvis eksterne partnere kun må se et udsnit af data. Når du definerer segmenter ud fra kontostruktur og ICP, er det oplagt at lade de samme segmentregler understøtte sikkerhed og adgangsstyring. Du kan fx tage udgangspunkt i din ideelle kundeprofil og sikre, at segmenteringen ikke blot er marketinglogik, men også en styringsmekanisme for adgang.

Fordele og ulemper

• Fordele: Højere datasikkerhed, mindre risiko for intern datalæk, enklere deling af dashboards, bedre compliance og mulighed for at skalere selvbetjent dataadgang uden at oprette mange separate datasæt.
• Ulemper: Mere kompleksitet i datamodellen, risiko for fejlkonfiguration (som kan give for bred eller for snæver adgang), performance-overhead ved komplekse regler og et større behov for governance, test og audit.

Praktisk tommelfingerregel: Jo flere brugergrupper og adgangsscenarier du har, jo mere skal du investere i dokumentation og automatiserede tests af RLS-regler.

Typiske misforståelser

• “RLS er det samme som kolonne-sikkerhed.” Nej. RLS styrer hvilke rækker du ser. Kolonne-sikkerhed styrer hvilke felter du ser. Ofte har du brug for begge dele.
• “Hvis det virker i dashboardet, er vi sikre.” Ikke nødvendigvis. Hvis eksport, API eller direkte databaseadgang ikke håndhæver samme regler, kan data stadig slippe ud.
• “Vi kan bare lave separate rapporter til hvert team.” Det kan fungere i lille skala, men bliver hurtigt svært at vedligeholde og giver ofte inkonsistente tal og KPI’er.
• “En admin-bruger er ok til integrationer.” Servicekonti med for brede rettigheder er en klassisk kilde til sikkerhedsbrist. Brug scopes, separate roller og mindst mulige privilegier.
• “RLS er kun relevant for store virksomheder.” Mindre B2B-virksomheder kan have lige så høj risiko, især hvis de deler rapporter bredt eller har eksterne samarbejdspartnere.

FAQ

Hvad er forskellen på row-level security og role-based access control (RBAC)?

RBAC handler om, hvilke funktioner og ressourcer en rolle må tilgå (fx “må se rapport X”). RLS handler om, hvilke rækker i data en bruger må se (fx “må kun se kunder i region Y”). I praksis kombinerer du ofte RBAC og RLS.

Hvor bør RLS implementeres: i databasen eller i BI-laget?

Det afhænger af dit setup, men den mest robuste tilgang er at håndhæve RLS så tæt på datakilden som muligt, så reglerne gælder uanset om data tilgås via dashboards, API eller andre værktøjer. BI-lags RLS kan være fint, men bør vurderes ift. eksport og alternative adgangsveje.

Kan RLS påvirke performance?

Ja. Især hvis dine politikker involverer komplekse join, store mappingtabeller eller ikke-indekserede felter. Du bør teste performance på realistiske forespørgsler og sikre korrekt indeksering og enkel regel-logik, hvor det er muligt.

Hvordan tester man RLS korrekt?

Du tester ved at simulere forskellige brugere/roller og verificere, at de ser præcis de rækker, de skal – og intet andet. Det bør inkludere tests af rapporter, API-kald og eksport. Logning og audit bør bruges aktivt til at opdage afvigelser.

Hvordan hænger RLS sammen med leadmotorer og datadrevne salgsflows?

Når du arbejder datadrevet med segmentering, eksport til marketing automation og salgsaktivering, er det vigtigt, at de rigtige personer kun får adgang til de rigtige konti og kontaktdata. Hvis du fx aktiverer leads i eksterne systemer, bør adgang og scopes afspejle segmenter og ansvar. Du kan se, hvordan en datadrevet proces kan bygges op med Cohertas leadmotor, og hvordan platformen typisk fungerer i praksis.

Få styr på dataadgang, segmenter og aktivering uden at bremse salget

Hvis du vil skalere din B2B-leadgenerering, bliver governance og adgangsstyring hurtigt en forudsætning – især når flere teams arbejder i de samme datakilder, dashboards og exports. RLS er et stærkt greb, men det virker bedst, når det hænger sammen med din segmentering, ICP og aktivering i marketing- og salgsstacken.

Vil du sikre, at de rigtige leads lander de rigtige steder (uden at dele for meget data), kan du fx se, hvordan du kan sende leads til ActiveCampaign som en del af et kontrolleret og skalerbart setup.