Tillatelsesmodell
Microsoft Fabric har en fleksibel tillatelsesmodell som gir deg mulighet til å kontrollere tilgangen til data i organisasjonen. Denne artikkelen forklarer de ulike typene tillatelser i Fabric og hvordan de arbeider sammen for å kontrollere tilgangen til data i organisasjonen.
Et arbeidsområde er en logisk enhet for gruppering av elementer i Fabric. Arbeidsområderoller definerer tilgangstillatelser for arbeidsområder. Selv om elementer er lagret i ett arbeidsområde, kan de deles med andre brukere på tvers av Fabric. Når du deler Fabric-elementer, kan du bestemme hvilke tillatelser du vil gi brukeren du deler elementet med. Enkelte elementer, for eksempel Power BI-rapporter, tillater enda mer detaljert kontroll av data. Rapporter kan konfigureres slik at brukere som viser dem, bare ser en del av dataene de har, avhengig av tillatelsene sine.
Arbeidsområderoller
Arbeidsområderoller brukes til å kontrollere tilgang til arbeidsområder og innholdet i dem. En Fabric-administrator kan tilordne arbeidsområderoller til individuelle brukere eller grupper. Arbeidsområderoller er begrenset til et bestemt arbeidsområde og gjelder ikke for andre arbeidsområder, kapasiteten arbeidsområdet er i, eller leieren.
Det finnes fire arbeidsområderoller, og de gjelder for alle elementer i arbeidsområdet. Brukere som ikke har noen av disse rollene, får ikke tilgang til arbeidsområdet. Rollene er:
Visningsprogram – Kan vise alt innhold i arbeidsområdet, men kan ikke endre det.
Bidragsyter – Kan vise og endre alt innhold i arbeidsområdet.
Medlem – Kan vise, endre og dele alt innhold i arbeidsområdet.
Administrator – Kan vise, endre, dele og administrere alt innhold i arbeidsområdet, inkludert administrasjon av tillatelser.
Denne tabellen viser et lite sett med funksjonene hver rolle har. Hvis du vil ha en fullstendig og mer detaljert liste, kan du se microsoft Fabric-arbeidsområderoller.
| Funksjonalitet | Administrator | Medlem | Bidragsyter | Visningsprogram |
|---|---|---|---|---|
| Slette arbeidsområdet | ✅ | ❌ | ❌ | ❌ |
| Legg til administratorer | ✅ | ❌ | ❌ | ❌ |
| Legg til medlemmer | ✅ | ✅ | ❌ | ❌ |
| Skrive data | ✅ | ✅ | ✅ | ❌ |
| Opprette elementer | ✅ | ✅ | ✅ | ❌ |
| Lese data | ✅ | ✅ | ✅ | ✅ |
Elementtillatelser
Elementtillatelser brukes til å kontrollere tilgang til individuelle stoffelementer i et arbeidsområde. Elementtillatelser er begrenset til et bestemt element og gjelder ikke for andre elementer. Bruk elementtillatelser til å kontrollere hvem som kan vise, endre og behandle enkeltelementer i et arbeidsområde. Du kan bruke elementtillatelser til å gi en bruker tilgang til ett enkelt element i et arbeidsområde som de ikke har tilgang til.
Når du deler elementet med en bruker eller gruppe, kan du konfigurere elementtillatelser. Deling av et element gir brukeren lesetillatelsen for elementet som standard. Lesetillatelser gjør det mulig for brukere å se metadataene for elementet og vise eventuelle rapporter som er knyttet til det. Lesetillatelser tillater imidlertid ikke brukere å få tilgang til underliggende data i SQL eller OneLake.
Ulike stoffelementer har forskjellige tillatelser. Hvis du vil lære mer om tillatelsene for hvert element, kan du se:
Databehandlingstillatelser
Tillatelser kan også angis i en bestemt databehandlingsmotor i Fabric, spesielt gjennom SQL Analytics-endepunktet eller i en semantisk modell. Databehandlingsmotortillatelser aktiverer en mer detaljert datatilgangskontroll, for eksempel sikkerhet på tabell- og radnivå.
SQL Analytics-endepunktet – SQL Analytics-endepunktet gir direkte SQL-tilgang til tabeller i OneLake, og kan ha sikkerhet konfigurert opprinnelig gjennom SQL-kommandoer. Disse tillatelsene gjelder bare for spørringer som er gjort via SQL.
Semantisk modell – Semantiske modeller tillater at sikkerhet defineres ved hjelp av DAX. Begrensninger som er definert ved hjelp av DAX, gjelder for brukere som spør gjennom semantisk modell eller Power BI-rapporter som er bygd på den semantiske modellen.
Du finner mer informasjon i disse artiklene:
OneLake-tillatelser (datatilgangsroller)
OneLake har sine egne tillatelser for å styre tilgang til filer og mapper i OneLake gjennom OneLake-datatilgangsroller. OneLake-datatilgangsroller gjør det mulig for brukere å opprette egendefinerte roller i et lakehouse og gi lesetillatelser bare til de angitte mappene når de får tilgang til OneLake. For hver OneLake-rolle kan brukere tilordne brukere, sikkerhetsgrupper eller gi en automatisk tilordning basert på arbeidsområderollen.
Mer informasjon om OneLake Data Access Control Model og vis veiledningene for fremgangsmåte.
Rekkefølgen på operasjonen
Fabric har tre forskjellige sikkerhetsnivåer. En bruker må ha tilgang på hvert nivå for å få tilgang til dataene. Hvert nivå evalueres sekvensielt for å avgjøre om en bruker har tilgang. Sikkerhetsregler som Microsoft Information Protection-policyer evalueres på et gitt nivå for å tillate eller forby tilgang. Rekkefølgen på operasjonen ved evaluering av stoffsikkerhet er:
- Entra-godkjenning: Kontrollerer om brukeren kan godkjenne til Microsoft Entra-leieren.
- Stofftilgang: Kontrollerer om brukeren har tilgang til Microsoft Fabric.
- Datasikkerhet: Kontrollerer om brukeren kan utføre den forespurte handlingen i en tabell eller fil.
Eksempler
Denne delen inneholder to eksempler på hvordan tillatelser kan konfigureres i Fabric.
Eksempel 1: Konfigurere gruppetillatelser
Wingtip Toys er konfigurert med én leier for hele organisasjonen, og tre kapasiteter. Hver kapasitet representerer et annet område. Wingtip Toys opererer i USA, Europa og Asia. Hver kapasitet har et arbeidsområde for hver avdeling i organisasjonen, inkludert salgsavdelingen.
Salgsavdelingen har en leder, en salgsgruppeleder og salgsteammedlemmer. Wingtip Toys ansetter også én analytiker for hele organisasjonen.
Tabellen nedenfor viser kravene for hver rolle i salgsavdelingen og hvordan tillatelser er konfigurert for å aktivere dem.
| Role | Forutsetninger | Oppsett |
|---|---|---|
| Overordnet | Vise og endre alt innhold i salgsavdelingen i hele organisasjonen | En medlemsrolle for alle salgsarbeidsområdene i organisasjonen |
| Teamleder | Vise og endre alt innhold i salgsavdelingen i et bestemt område | En medlemsrolle for salgsarbeidsområdet i området |
| Medlem av salgsteam | ||
| Analytiker | Vis alt innhold i salgsavdelingen i hele organisasjonen | En visningsrolle for alle salgsarbeidsområdene i organisasjonen |
Wingtip har også en kvartalsrapport som viser salgsinntekten per salgsmedlem. Denne rapporten lagres i et finansarbeidsområde. Ved hjelp av sikkerhet på radnivå konfigureres rapporten slik at hvert salgsmedlem bare kan se sine egne salgstall. Teamledere kan se salgstallene for alle salgsmedlemmene i området, og salgssjefen kan se salgstall for alle salgsmedlemmene i organisasjonen.
Eksempel 2: Tillatelser for arbeidsområde og element
Når du deler et element eller endrer tillatelsene, endres ikke arbeidsområderoller. Eksemplet i denne delen viser hvordan arbeidsområde- og elementtillatelser samhandler.
Veronica og Marta jobber sammen. Veronica er eieren av en rapport hun ønsker å dele med Marta. Hvis Veronica deler rapporten med Marta, vil Marta kunne få tilgang til den uavhengig av arbeidsområderollen hun har.
La oss si at Marta har en seerrolle i arbeidsområdet der rapporten er lagret. Hvis Veronica bestemmer seg for å fjerne Martas elementtillatelser fra rapporten, vil Marta fortsatt kunne vise rapporten i arbeidsområdet. Marta kan også åpne rapporten fra arbeidsområdet og vise innholdet. Dette er fordi Marta har visningstillatelser til arbeidsområdet.
Hvis Veronica ikke vil at Marta skal vise rapporten, er det ikke nok å fjerne Martas elementtillatelser fra rapporten. Veronica må også fjerne Martas visningstillatelser fra arbeidsområdet. Uten tillatelsene for visningsprogrammet for arbeidsområdet kan ikke Marta se at rapporten finnes fordi hun ikke får tilgang til arbeidsområdet. Marta vil heller ikke kunne bruke koblingen til rapporten, fordi hun ikke har tilgang til rapporten.
Nå som Marta ikke har en arbeidsområdevisningsrolle, hvis Veronica bestemmer seg for å dele rapporten med henne igjen, vil Marta kunne se den ved hjelp av koblingen Veronica deler med henne, uten å ha tilgang til arbeidsområdet.
Eksempel 3: Power BI App-tillatelser
Når du deler Power BI-rapporter, vil du ofte at mottakerne bare skal ha tilgang til rapportene og ikke til elementer i arbeidsområdet. For dette kan du bruke Power BI-apper eller dele rapporter direkte med brukere.
I tillegg kan du begrense visningstilgangen til data ved hjelp av sikkerhet på radnivå (RLS), med RLS kan du opprette roller som har tilgang til bestemte deler av dataene, og begrense resultatene som returnerer bare det brukerens identitet har tilgang til.
Dette fungerer fint når du bruker importmodeller når dataene importeres i den semantiske modellen, og mottakerne har tilgang til dette som en del av appen. Med DirectLake leser rapporten dataene direkte fra Lakehouse, og rapportmottakeren må ha tilgang til disse filene i sjøen. Du kan gjøre dette på flere måter:
- Gi
ReadDatatillatelse på Lakehouse direkte. - Bytt legitimasjonen for datakilden fra Enkel pålogging (SSO) til en fast identitet som har tilgang til filene i sjøen.
Fordi RLS er definert i semantisk modell, leses dataene først, og deretter filtreres radene.
Hvis noen sikkerhet er definert i SQL Analytics-endepunktet som rapporten er bygget på, faller spørringene automatisk tilbake til DirectQuery-modus. Hvis du ikke vil ha denne standard tilbakefallsvirkemåten, kan du opprette et nytt Lakehouse ved hjelp av snarveier til tabellene i det opprinnelige Lakehouse og ikke definere RLS eller OLS i SQL på det nye Lakehouse.