Sikre Dine Data i Fabric: En Introduksjon til RLS og CLS

Når du jobber med data i Microsoft Fabric, enten det er i et Warehouse eller via SQL Endpoint i et Lakehouse, er det avgjørende å ha kontroll på hvem som ser hva. Ikke alle brukere skal ha tilgang til all informasjon. Hvordan kan du effektivt begrense tilgangen på en sikker og robust måte?

Svaret ligger ofte i to kraftige sikkerhetsfunksjoner: Row-Level Security (RLS) og Column-Level Security (CLS). Hos TrendMe hjelper vi bedrifter med å implementere nettopp slike mekanismer for å beskytte sensitive data. La oss se nærmere på hva RLS og CLS er og hvordan de fungerer i Fabric.

Utfordringen: Kontrollert Datadeling

Moderne dataanalyse handler om å gjøre data tilgjengelig for beslutningstakere. Men dette må balanseres mot behovet for sikkerhet og personvern (compliance). Ulike roller og avdelinger har ofte legitime behov for å se ulike deler av det samme datasettet:

• En selger trenger kun å se salgsdata for sine egne kunder.
• En regionsjef trenger å se data for alle selgere i sin region, men ikke andre regioner.
• HR-avdelingen trenger kanskje å se ansattinformasjon, men lønnskolonner skal kun være synlige for lønnsansvarlige.
• Finansavdelingen trenger tilgang til økonomiske nøkkeltall, men ikke nødvendigvis detaljerte produksjonslogger.

Å administrere dette manuelt med ulike rapporter eller visninger for hver brukergruppe kan fort bli uhåndterlig og feilutsatt.

Hva er Row-Level Security (RLS)?

Row-Level Security (RLS), eller radnivåsikkerhet, lar deg definere regler som filtrerer hvilke rader en bruker får se i en tabell, basert på hvem brukeren er eller hvilken rolle de tilhører.

Tenk deg en stor salgstabell med data fra alle selgere. Med RLS kan du sette opp en regel som sier: "Hvis brukeren som logger på er 'selger@firma.no', vis kun radene der kolonnen 'SelgerEpost' er lik 'selger@firma.no'". En salgssjef kan ha en annen regel som gir tilgang til alle rader.

Logikken ligger sentralt i databasen (Warehouse/SQL Endpoint), så filtreringen skjer automatisk uansett hvordan brukeren kobler seg til dataene (f.eks. via Power BI, SQL-klienter).

Hva er Column-Level Security (CLS)?

Column-Level Security (CLS), eller kolonnenivåsikkerhet, lar deg kontrollere hvilke spesifikke kolonner i en tabell en bruker har lov til å se.

Hvis du har en tabell med kundeinformasjon som inkluderer sensitive data som personnummer eller kredittkortdetaljer, kan du bruke CLS til å skjule disse kolonnene for brukere som ikke trenger å se dem (f.eks. markedsføringsavdelingen), mens autoriserte brukere (f.eks. i finansavdelingen) fortsatt har tilgang.

Igjen, dette håndteres i databasen, noe som gir en robust og konsistent sikkerhetsmodell.

Fordeler med RLS og CLS i Fabric:

• Granulær Kontroll: Gir presis styring over datatilgang ned på rad- og kolonnenivå.
• Sentralisert Logikk: Sikkerhetsreglene defineres og håndheves i databaselaget (Warehouse/SQL Endpoint), ikke i hver enkelt rapport eller applikasjon.
• Robust Sikkerhet: Reduserer risikoen for utilsiktet datalekkasje, da reglene anvendes konsistent.
• Forenklet Design: Kan redusere behovet for å lage mange separate visninger eller rapporter for ulike brukergrupper. Én rapport kan tjene flere formål.
• Compliance: Hjelper med å møte krav til personvern og dataminimering (f.eks. GDPR).

Hvordan Implementeres RLS og CLS i Fabric (Forenklet)?

Både RLS og CLS konfigureres ved hjelp av T-SQL-kommandoer direkte mot ditt Fabric Warehouse eller Lakehouse SQL Endpoint.

• For RLS:
  1. Man lager en liten T-SQL-funksjon (en "inline table-valued function") som fungerer som en sjekk (predikat). Funksjonen returnerer typisk 'sant' hvis brukeren (identifisert via funksjoner som SUSER_SNAME() eller USER_NAME()) skal ha tilgang til en gitt rad, og 'usant' ellers.
  2. Man oppretter en "Security Policy" (sikkerhetspolicy) med CREATE SECURITY POLICY som knytter denne funksjonen til den aktuelle tabellen.
  3. Tilgang styres ofte ved å legge brukere inn i spesifikke Workspace-roller (f.eks. Viewer, Member) eller Microsoft Entra ID (tidligere Azure AD) sikkerhetsgrupper, som funksjonen kan sjekke mot.
• For CLS:
  1. Man bruker den vanlige T-SQL GRANT-kommandoen.
  2. I stedet for å gi SELECT-tilgang til hele tabellen, gir man SELECT-tilgang kun på de *spesifikke kolonnene* brukeren eller gruppen skal få se: GRANT SELECT ON DinTabell (Kolonne1, Kolonne3) TO [BrukerEllerGruppeNavn].
  3. Tilgang styres typisk ved å gi brukere/grupper tilgang via Microsoft Entra ID sikkerhetsgrupper og dele SQL Endpoint med dem (pass på å *ikke* gi unødvendige "Additional Permissions" under deling som kan overstyre CLS).

Selv om det krever litt T-SQL, er konseptene relativt enkle når man forstår prinsippene.

Når Bruke Hva? RLS vs. CLS

• Bruk RLS når ulike brukere skal se forskjellige rader fra den samme tabellen basert på deres rolle eller tilhørighet (f.eks. selgere ser egne salg, avdelingsledere ser sin avdelings data).
• Bruk CLS når du trenger å skjule sensitive kolonner for visse brukere, selv om de har tilgang til andre kolonner i de samme radene (f.eks. skjule lønn, personnummer).

Det er også fullt mulig og ofte nyttig å bruke RLS og CLS sammen på samme tabell for enda mer finmasket kontroll.

TrendMe Kan Hjelpe Med Datasikkerhet i Fabric

Å sette opp RLS og CLS korrekt er essensielt for god dataforvaltning og sikkerhet. Hos TrendMe har vi ekspertisen til å hjelpe deg med å designe og implementere robuste sikkerhetsmodeller i Microsoft Fabric Warehouse og Lakehouse SQL Endpoints.

Enten du trenger hjelp med strategi, implementering eller optimalisering av datasikkerheten din, ta kontakt med oss i TrendMe for en uforpliktende samtale.

Sørg for at dine verdifulle data er både tilgjengelige og sikre!