Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Med OneLake-sikkerhet utvider Microsoft Fabric hvordan organisasjoner kan administrere og håndheve datatilgang på tvers av arbeidsbelastninger. Dette nye sikkerhetsrammeverket gir administratorer større fleksibilitet til å konfigurere tillatelser. Administratorer kan velge mellom sentralisert styring gjennom OneLake eller detaljert SQL-basert kontroll i SQL-analyseendepunktet .
Tilgangsmoduser i SQL-analyseendepunkt
Når du bruker SQL-analyseendepunktet, bestemmer den valgte tilgangsmodusen hvordan datasikkerhet håndheves. Fabric støtter to forskjellige tilgangsmodeller, som hver tilbyr forskjellige fordeler avhengig av drifts- og samsvarsbehovene dine:
Brukeridentitetsmodus: Håndhever sikkerhet ved hjelp av OneLake-roller og -policyer. I denne modusen sender SQL-analyseendepunktet den påloggede brukerens identitet til OneLake, og lesetilgangen styres helt av sikkerhetsreglene som er definert i OneLake. Tillatelser på SQL-nivå for tabeller støttes, noe som sikrer konsekvent styring på tvers av verktøy som Power BI, notatblokker og lakehouse.
Delegert identitetsmodus: Gir full kontroll gjennom SQL. I denne modusen kobler SQL-analyseendepunktet til OneLake ved hjelp av identiteten til arbeidsområdet eller elementeieren , og sikkerheten styres utelukkende av SQL-tillatelser som er definert i databasen. Denne modellen støtter tradisjonelle sikkerhetstilnærminger, inkludert GRANT, REVOKE, egendefinerte roller, Row-Level Security og Dynamic Data Maskg.
Hver modus støtter ulike styringsmodeller. Å forstå implikasjonene er avgjørende for å velge riktig tilnærming i Fabric-miljøet ditt.
Sammenligning mellom tilgangsmoduser
Her er en klar og konsis sammenligningstabell som fokuserer på hvordan og hvor du angir sikkerhet i brukeridentitetsmodus kontra delegert identitetsmodus – inndelt etter objekttype og policyer for datatilgang:
| Sikkerhetsmål | Modus for brukeridentitet | Delegert identitetsmodus |
|---|---|---|
| Tabeller | Tilgang styres av OneLake-sikkerhetsroller. SQL GRANT/REVOKE er ikke tillatt. |
Full kontroll ved hjelp av SQL GRANT/REVOKE. |
| Visninger | Bruk SQL GRANT/REVOKE til å tilordne tillatelser. | Bruk SQL GRANT/REVOKE til å tilordne tillatelser. |
| Lagrede prosedyrer | Bruk SQL GRANT EXECUTE til å tilordne tillatelser. | Bruk SQL GRANT EXECUTE til å tilordne tillatelser. |
| Funksjoner | Bruk SQL GRANT EXECUTE til å tilordne tillatelser. | Bruk SQL GRANT EXECUTE til å tilordne tillatelser. |
| Row-Level sikkerhet (RLS) | Definert i OneLake-brukergrensesnittet som en del av OneLake-sikkerhetsroller. | Definert ved hjelp av SQL CREATE SECURITY POLICY. |
| Column-Level sikkerhet (CLS) | Definert i OneLake-brukergrensesnittet som en del av OneLake-sikkerhetsroller. | Definert ved hjelp av SQL GRANT SELECT med kolonneliste. |
| Dynamisk datamaskering (DDM) | Støttes ikke i OneLake-sikkerhet. | Definert ved hjelp av SQL ALTER TABLE med MASKED opsjon. |
Brukeridentitetsmodus i OneLake-sikkerhet
I brukeridentitetsmodus bruker SQL-analyseendepunktet en direktegodkjenningsmekanisme for å håndheve datatilgang. Når en bruker kobler til SQL Analytics-endepunktet, sendes Entra ID-identiteten til OneLake, som utfører tillatelseskontrollen. Alle leseoperasjoner mot tabeller evalueres ved hjelp av sikkerhetsreglene som er definert i OneLake Lakehouse, ikke av noen GRANT- eller REVOKE-setninger på SQL-nivå.
Med denne modusen kan du administrere sikkerhet sentralt, noe som sikrer konsekvent håndhevelse på tvers av alle Fabric-opplevelser, inkludert Power BI, notatblokker, lakehouse og SQL-analyseendepunkt. Den er utformet for styringsmodeller der tilgang skal defineres én gang i OneLake og automatisk respekteres overalt.
I brukeridentitetsmodus:
Bordtilgang styres helt av OneLake-sikkerhet. SQL GRANT/REVOKE-setninger på tabeller ignoreres.
RLS (Row-Level Security), CLS (Column-Level Security) og Object-Level Security er alle definert i OneLake-opplevelsen.
SQL-tillatelser er tillatt for ikke-dataobjekter som visninger, lagrede prosedyrer og funksjoner, noe som gir fleksibilitet for å definere egendefinert logikk eller brukerrettede inngangspunkter til data.
Skriveoperasjoner støttes ikke på SQL-analyseendepunktet. Alle skrivinger må skje gjennom Lakehouse-brukergrensesnittet og styres av arbeidsområderoller (administrator, medlem, bidragsyter).
Viktig!
SQL Analytics-endepunktet krever en én-til-én-tilordning mellom elementtillatelser og medlemmer i en OneLake-sikkerhetsrolle for å synkronisere riktig. Hvis du gir en identitet tilgang til en OneLake-sikkerhetsrolle, må den samme identiteten også ha Fabric Read-tillatelse til lakehouse. Hvis en bruker for eksempel tilordner "user123@microsoft.com" til en OneLake-sikkerhetsrolle, må "user123@microsoft.com" også tilordnes til dette innsjøhuset.
Virkemåte for arbeidsområderolle
Brukere med rollen Administrator, Medlem eller Bidragsyter på arbeidsområdenivå er ikke underlagt OneLake-sikkerhetshåndhevelse. Disse rollene har forhøyede rettigheter og vil omgå RLS-, CLS- og OLS-policyer helt. Følg disse kravene for å sikre at OneLake-sikkerheten respekteres:
Tilordne brukere Seer-rollen i arbeidsområdet, eller
Del Lakehouse- eller SQL-analyseendepunktet med brukere ved hjelp av skrivebeskyttede tillatelser. Bare brukere med skrivebeskyttet tilgang har spørringene sine filtrert i henhold til OneLake-sikkerhetsroller.
Rolleprioritet: Mest tillatte tilgang vinner
Hvis en bruker tilhører flere OneLake-roller, definerer den mest tillatte rollen den effektive tilgangen. Eksempel:
Hvis én rolle gir full tilgang til en tabell og en annen bruker RLS for å begrense rader, vil ikke RLS bli håndhevet.
Den bredere tilgangsrollen har forrang. Denne virkemåten sikrer at brukere ikke blokkeres utilsiktet, men det krever nøye rolleutforming for å unngå konflikter. Det anbefales å holde restriktive og tillatte roller gjensidig utelukkende når du håndhever tilgangskontroller på rad- eller kolonnenivå.
Hvis du vil ha mer informasjon, kan du se modellen for datatilgangskontroll for OneLake-sikkerhet.
Sikkerhetssynkronisering mellom OneLake og SQL-analyseendepunkt
En kritisk komponent i brukeridentitetsmodus er sikkerhetssynkroniseringstjenesten. Denne bakgrunnstjenesten overvåker endringer som gjøres i sikkerhetsroller i OneLake, og sikrer at disse endringene gjenspeiles i SQL-analyseendepunktet.
Sikkerhetssynkroniseringstjenesten er ansvarlig for følgende:
Oppdage endringer i OneLake-roller, inkludert nye roller, oppdateringer, brukertilordninger og endringer i tabeller.
Oversettelse av OneLake-definerte policyer (RLS, CLS, OLS) til tilsvarende SQL-kompatible databaserollestrukturer.
Sikre at snarveisobjekter (tabeller hentet fra andre innsjøhus) er riktig validert slik at de opprinnelige OneLake-sikkerhetsinnstillingene respekteres, selv når de åpnes eksternt.
Denne synkroniseringen sikrer at OneLake-sikkerhetsdefinisjoner forblir autoritative, noe som eliminerer behovet for manuell intervensjon på SQL-nivå for å replikere sikkerhetsatferd. Fordi sikkerhet håndheves sentralt:
Du kan ikke definere RLS, CLS eller OLS direkte ved hjelp av T-SQL i denne modusen.
Du kan fortsatt bruke SQL-tillatelser på visninger, funksjoner og lagrede prosedyrer ved hjelp av GRANT- eller EXECUTE-setninger.
Sikkerhetssynkroniseringsfeil og -løsning
| Scenario | Virkemåte i brukeridentitetsmodus | Virkemåte i delegert modus | Korrigerende tiltak | Notater |
|---|---|---|---|---|
| RLS-policy refererer til en slettet kolonne eller en ny navn | Feil: *Sikkerhetspolicy på radnivå refererer til en kolonne som ikke lenger finnes.*Databasen går inn i feiltilstand til policyen er løst. | Feil: Ugyldig kolonnenavn for kolonnenavn <> | Oppdater eller fjern én eller flere berørte roller, eller gjenopprett den manglende kolonnen. | Oppdateringen må gjøres i lakehouse der rollen ble opprettet. |
| CLS-policy refererer til en slettet eller omdøpt kolonne | Feil: *Sikkerhetspolicy på kolonnenivå refererer til en kolonne som ikke lenger finnes.*Databasen går inn i feiltilstand til policyen er løst. | Feil: Ugyldig kolonnenavn for kolonnenavn <> | Oppdater eller fjern én eller flere berørte roller, eller gjenopprett den manglende kolonnen. | Oppdateringen må gjøres i lakehouse der rollen ble opprettet. |
| RLS/CLS-policy refererer til en slettet eller omdøpt tabell | Feil: Sikkerhetspolicyen refererer til en tabell som ikke lenger finnes. | Ingen feil dukket opp; Spørringen mislykkes stille hvis tabellen mangler. | Oppdater eller fjern én eller flere berørte roller, eller gjenopprett den manglende tabellen. | Oppdateringen må gjøres i lakehouse der rollen ble opprettet. |
| DDM-policy (dynamisk datamaskering) refererer til en kolonne som er slettet eller har fått nytt navn | DDM støttes ikke fra OneLake Security, må implementeres gjennom SQL. | Feil: Ugyldig kolonnenavn for kolonnenavn <> | Oppdater eller fjern én eller flere berørte DDM-regler, eller gjenopprett den manglende kolonnen. | Oppdater DDM-policyen i SQL Analytics-endepunktet. |
| Systemfeil (uventet feil) | Feil: Det oppstod en uventet systemfeil. Prøv på nytt eller kontakt kundestøtte. | Feil: Det har oppstått en intern feil under bruk av tabellendringer i SQL. | Prøv å bruke på nytt; Hvis problemet vedvarer, kan du kontakte Microsoft Kundestøtte. | I/T |
| Brukeren har ikke tillatelse til artefakten | Feil: Brukeren har ikke tillatelse til artefakten | Feil: Brukeren har ikke tillatelse til artefakten | Gi brukeren objectID {objectID}-tillatelse til artefakten. | Objekt-ID-en må være et nøyaktig samsvar mellom OneLake-sikkerhetsrollemedlemmet og Fabric-elementtillatelsene. Hvis en gruppe legges til i rollemedlemskapet, må den samme gruppen gis tillatelsen Fabric Read. Å legge til et medlem fra den gruppen i elementet teller ikke som et direkte treff. |
| Brukerkontohaver støttes ikke. | Feil: Brukerkontohaver støttes ikke. | Feil: Brukerkontohaver støttes ikke. | Vennligst fjern bruker {brukernavn} fra rollen DefaultReader | Denne feilen oppstår hvis brukeren ikke lenger er en gyldig Entra-ID, for eksempel hvis brukeren har forlatt organisasjonen eller blitt slettet. Fjern dem fra rollen for å løse denne feilen. |
Snarveier med sikkerhetssynkronisering
OneLake-sikkerhet håndheves ved sannhetskilden, så sikkerhetssynkronisering deaktiverer eierskapskjeting for tabeller og visninger som involverer snarveier. Dette sikrer at kildesystemtillatelser alltid evalueres og respekteres, selv for spørringer fra en annen database.
Som et resultat:
Brukere må ha gyldig tilgang til bådesnarveiskilden (gjeldende Lakehouse- eller SQL-analyseendepunkt) ogmålet der dataene fysisk befinner seg.
Hvis brukeren mangler tillatelse på en av sidene, vil spørringer mislykkes med en tilgangsfeil.
Når du utformer programmer eller visninger som refererer til snarveier, må du sørge for at rolletilordninger er riktig konfigurert i begge ender av snarveisrelasjonen.
Denne utformingen bevarer sikkerhetsintegriteten på tvers av Lakehouse-grenser, men den introduserer scenarioer der tilgangsfeil kan oppstå hvis roller på tvers av Lakehouse ikke er justert.
Delegert modus i OneLake-sikkerhet
I delegert identitetsmodus bruker SQL-analyseendepunktet den samme sikkerhetsmodellen som finnes i dag i Microsoft Fabric. Sikkerhet og tillatelser administreres utelukkende på SQL-laget, og OneLake-roller eller tilgangspolicyer håndheves ikke for tilgang på tabellnivå. Når en bruker kobler til SQL-analyseendepunktet og utsteder en spørring:
SQL validerer tilgang basert på SQL-tillatelser (GRANT, REVOKE, RLS, CLS, DDM, roller, etc.).
Hvis spørringen er autorisert, fortsetter systemet med å få tilgang til data som er lagret i OneLake.
Denne datatilgangen utføres ved hjelp av identiteten til eieren av Lakehouse- eller SQL Analytics-endepunktet – også kjent som varekontoen.
I denne modellen:
Den påloggede brukeren sendes ikke videre til OneLake.
All håndhevelse av tilgang antas å bli håndtert på SQL-laget.
Elementeieren er ansvarlig for å ha tilstrekkelige tillatelser i OneLake til å lese de underliggende filene på vegne av arbeidsbelastningen.
Fordi dette er et delegert mønster, resulterer enhver feiljustering mellom SQL-tillatelser og OneLake-tilgang for eieren i spørringsfeil. Denne modusen gir full kompatibilitet med:
SQL GRANT/REVOKE på alle objektnivåer
SQL-definert Row-Level sikkerhet, Column-Level sikkerhet og dynamisk datamaskering
Eksisterende T-SQL-verktøy og -praksis som brukes av DBA-er eller applikasjoner
Slik endrer du OneLake-tilgangsmodus
Tilgangsmodusen bestemmer hvordan datatilgang godkjennes og håndheves når du spør OneLake gjennom SQL-analyseendepunkt. Du kan bytte mellom brukeridentitetsmodus og delegert identitetsmodus ved hjelp av følgende trinn:
Naviger til Fabric-arbeidsområdet og åpne innsjøhuset. Bytt fra øverste høyre hjørne fra innsjøhus til SQL-analyseendepunkt.
Fra den øverste navigasjonen, gå til Sikkerhet-fanen og velg en av følgende OneLake-tilgangsmoduser:
Brukeridentitet – Bruker identiteten til den påloggede brukeren. Det håndhever OneLake-roller.
Delegert identitet – Bruker vareeierens identitet. håndhever bare SQL-tillatelser.
Et popup-vindu åpnes for å bekrefte valget ditt. Velg Ja for å bekrefte endringen.
Hensyn når du bytter mellom moduser
Bytte til brukeridentitetsmodus
SQL RLS-, CLS- og tabellnivåtillatelser ignoreres.
OneLake-roller må konfigureres for at brukere skal opprettholde tilgang.
Bare brukere med seertillatelser eller delt skrivebeskyttet tilgang styres av OneLake-sikkerhet.
Eksisterende SQL-roller slettes og kan ikke gjenopprettes.
Bytte til delegert identitetsmodus
OneLake-roller og sikkerhetspolicyer brukes ikke lenger.
SQL-roller og sikkerhetspolicyer blir aktive.
Vareeieren må ha gyldig OneLake-tilgang, ellers kan alle spørringer mislykkes.
Begrensninger
Gjelder bare lesere: OneLake Security styrer brukere som får tilgang til data som seere. Brukere i andre arbeidsområderoller (administratormedlem eller bidragsyter) omgår OneLake-sikkerhet og beholder full tilgang.
SQL-objekter arver ikke eierskap: Snarveier vises i SQL Analytics-endepunktet som tabeller. Når du får tilgang til disse tabellene, direkte eller gjennom visninger, har ikke lagrede prosedyrer og andre avledede SQL-objekter eierskap på objektnivå. Alle tillatelser kontrolleres under kjøring for å forhindre sikkerhetsomgåelse.
Snarveisendringer utløser nedetid for validering: Når et snarveismål endres (for eksempel endre navn, URL-oppdatering), går databasen kort inn i enkeltbrukermodus mens systemet validerer det nye målet. I løpet av denne perioden blokkeres spørringer, disse operasjonene er ganske raske, men noen ganger kan det ta opptil 5 minutter å synkronisere avhengig av forskjellige interne prosesser.
- Oppretting av skjemasnarveier kan føre til en kjent feil som påvirker validering og forsinker metadatasynkronisering.
Forsinket overføring av tillatelser: Tillatelsesendringer er ikke umiddelbare. Bytte mellom sikkerhetsmoduser (brukeridentitet vs. delegert) kan ta tid å spre seg før det trer i kraft, men bør ta mindre enn 1 minutt.
Kontrollplanavhengighet: Tillatelser kan ikke brukes på brukere eller grupper som ikke allerede finnes i kontrollplanet for arbeidsområdet. Du må enten dele kildeelementet, eller brukeren må være medlem av rollen Seer-arbeidsområde. Merk at nøyaktig samme objekt-ID må være på begge steder. En gruppe og et medlem av den gruppen teller ikke som en match.
Mest tillatte tilgang gjelder: Når brukere tilhører flere grupper eller roller, respekteres den mest tillatte effektive tillatelsen Eksempel: Hvis en bruker har både DENY gjennom én rolle og GRANT gjennom en annen, har GRANT forrang.
Begrensninger for delegert modus: I delegert modus kan metadatasynkronisering på snarveistabeller mislykkes hvis kildeelementet har OneLake-sikkerhetspolicyer som ikke gir full tabelltilgang til elementeieren.
DENY-virkemåte: Når flere roller gjelder for én enkelt snarveistabell, følger skjæringspunktet mellom tillatelser SQL Server-semantikk: DENY overstyrer GRANT. Dette kan gi uventede tilgangsresultater.
Forventede feiltilstander: Brukere kan støte på feil i scenarioer som:
Snarveismål har fått nytt navn eller er ugyldig
- Eksempel: Hvis kilden til tabellen ble slettet.
RLS (Row-Level Security) feilkonfigurasjon
Noen uttrykk for RLS-filtrering støttes ikke i OneLake, og det kan tillate uautorisert datatilgang.
Hvis du slipper kolonnen som brukes på filteruttrykket, ugyldiggjøres RLS, og metadatasynkronisering vil være foreldet til RLS er løst på OneLake-sikkerhetspanelet.
For offentlig forhåndsversjon støtter vi bare tabeller med enkeltuttrykk. Dynamisk RLS og flerbords RLS støttes ikke for øyeblikket.
Begrensninger for Column-Level Security (CLS)
CLS fungerer ved å vedlikeholde en tillatelsesliste over kolonner. Hvis en tillatt kolonne fjernes eller får nytt navn, blir CLS-policyen ugyldig.
Når CLS er ugyldig, blokkeres metadatasynkronisering til CLS-regelen er løst i OneLake-sikkerhetspanelet.
Synkronisering av metadata eller tillatelser mislyktes
- Hvis det er endringer i tabellen, for eksempel å gi nytt navn til en kolonne, replikeres ikke sikkerheten på det nye objektet, og du får feil i brukergrensesnittet som viser at kolonnen ikke finnes.
Endring av navn på tabeller bevarer ikke sikkerhetspolicyer: Hvis OneLake Security (OLS)-roller er definert på skjemanivå, forblir disse rollene bare i kraft så lenge tabellnavnet er uendret. Hvis du gir nytt navn til tabellen, brytes tilknytningen, og sikkerhetspolicyer overføres ikke automatisk. Dette kan føre til utilsiktet dataeksponering inntil policyer tas i bruk på nytt.
OneLake-sikkerhetsroller kan ikke ha navn som er lengre enn 124 tegn. Ellers kan ikke sikkerhetssynkronisering synkronisere rollene.
OneLake-sikkerhetsroller overføres på SQL Analytics-endepunktet med OLS_-prefikset.
Brukerendringer på de OLS_ rollene støttes ikke, og kan forårsake uventet virkemåte.
E-postaktiverte sikkerhetsgrupper og distribusjonslister støttes ikke.
Eieren av innsjøhuset må være medlem av arbeidsområderollene administrator, medlem eller bidragsyter. Ellers brukes ikke sikkerhet på SQL Analytics-endepunktet.
Eieren av lakehouse kan ikke være tjenestekontohaver for at sikkerhetssynkronisering skal fungere.