OneLake-sikkerhet for SQL-analyseendepunkter (forhåndsversjon)

Med OneLake-sikkerhet utvider Microsoft Fabric hvordan organisasjoner kan administrere og håndheve data access 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 .

Access-moduser i SQL-analyseendepunkt

Når man bruker SQL analytics endpoint, avgjør den valgte access-modusen hvordan datasikkerhet håndheves. Fabric støtter to distinkte access-modeller, som hver gir ulike fordeler avhengig av dine operative og compliance-behov:

• Brukeridentitetsmodus: Håndhever sikkerhet ved hjelp av OneLake-roller og -policyer. I denne modusen sender SQL-analyseendepunktet den innloggede brukerens identitet til OneLake, og read access styres helt av sikkerhetsreglene 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 access-moduser

Her er en klar og konsis sammenligningstabell med fokus på hvordan og hvor du setter sikkerhet i brukeridentitetsmodus versus delegert identitetsmodus—delt opp etter objekttype og data-access-policyer:

Brukeridentitetsmodus i OneLake-sikkerhet

I brukeridentitetsmodus bruker SQL-analyseendepunktet en passthrough-autentiseringsmekanisme for å håndheve data access. 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 designet for styringsmodeller der access skal defineres én gang i OneLake og automatisk respekteres overalt.

I brukeridentitetsmodus:

• Table access styres helt av OneLake-sikkerheten. 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 via Lakehouse-siden i Fabric-portalen og styres av arbeidsområdets roller (Admin, Medlem, Bidragsyter).

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. Kun brukere med skrivebeskyttet access får sine spørringer filtrert etter OneLake-sikkerhetsroller.

Rolleprioritet: Mest permissive access vinner

Hvis en bruker tilhører flere OneLake-roller, definerer den mest tillatende rollen deres effektive access. Eksempel:

• Hvis én rolle gir full access til en tabell og en annen anvender RLS for å begrense rader, vil ikke RLS bli håndhevet.

• Den bredere access-rollen 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 tillatende roller gjensidig utelukkende når man håndhever rad- eller kolonnenivå access-kontroller.

For mer informasjon, se data access control-modellen 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

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 gyldige access på begge snarveien source (nåværende Lakehouse- eller SQL-analyseendepunkt) ogdestinasjon hvor dataene fysisk befinner seg.

• Hvis brukeren mangler tillatelse på noen av sidene, vil queries feile med en access feil.

• 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.

Dette designet bevarer sikkerhetsintegriteten på tvers av Lakehouse-grensene, men introduserer scenarier der access-feil kan oppstå hvis roller på tvers av Lakehouse ikke er på linje.

Delegert modus i OneLake-sikkerhet

I Delegated Identity Mode bruker SQL-analyseendepunktet samme sikkerhetsmodell som eksisterer i dag i Microsoft Fabric. Sikkerhet og tillatelser administreres helt på SQL-laget, og OneLake-roller eller access-policyer håndheves ikke for tabellnivå-access. Når en bruker kobler til SQL-analyseendepunktet og utsteder en spørring:

• SQL validerer access basert på SQL-tillatelser (GRANT, REVOKE, RLS, CLS, DDM, roller, osv.).

• Hvis spørringen er autorisert, går systemet videre til å access dataene lagret i OneLake.

• Disse dataene utføres access ved bruk av identiteten til eieren av Lakehouse- eller SQL-analyseendepunktet—også kjent som item-kontoen.

I denne modellen:

• Den påloggede brukeren sendes ikke videre til OneLake.

• All håndheving av access antas å håndteres på SQL-laget.

• Elementeieren er ansvarlig for å ha tilstrekkelige tillatelser i OneLake til å lese de underliggende filene på vegne av arbeidsbelastningen.

Siden dette er et delegert mønster, fører enhver feiljustering mellom SQL-tillatelser og OneLake-access for eieren til 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

Hvordan endre OneLake access-modus

access-modusen avgjør hvordan data-access autentiseres og håndheves når man spør OneLake via SQL-analyse-endpoint. Du kan bytte mellom brukeridentitetsmodus og delegert identitetsmodus ved hjelp av følgende trinn:

1. Naviger til Fabric-arbeidsområdet og åpne innsjøhuset. Bytt fra øverste høyre hjørne fra innsjøhus til SQL-analyseendepunkt.

2. Fra toppnavigasjonen, gå til fanen Security og velg en av følgende OneLake access-moduser:

   • Brukeridentitet – Bruker identiteten til den påloggede brukeren. Det håndhever OneLake-roller.

   • Delegert identitet – Bruker vareeierens identitet. håndhever bare SQL-tillatelser.

3. 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 brukerne skal kunne opprettholde access.

• Kun brukere med visningstillatelser eller delt skrivebeskyttet access vil være underlagt 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.

• Eieren av varen må ha gyldig OneLake-access, ellers kan alle søk feile.

Begrensninger

• Gjelder kun for lesere: OneLake-sikkerhet styrer brukere som får tilgang til data som Viewers. Brukere i andre arbeidsområderoller (administrator, medlem eller bidragsyter) omgår OneLake-sikkerheten og beholder full access.

• 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 tillatende access gjelder: Når brukere tilhører flere grupper eller roller, respekteres den mest tillatende effektive tillatelsen Eksempel: Hvis en bruker har både DENY gjennom én rolle og GRANT gjennom en annen, har GRANT forrang.

• Delegated mode-begrensninger: I Delegated mode kan metadata-synkronisering på snarveitabeller feile hvis kildeelementet har OneLake-sikkerhetspolicyer som ikke gir full tabell-access til elementeieren.

• FORNEKT atferd: Når flere roller gjelder for én enkelt snarveitabell, følger skjæringspunktet av tillatelser SQL Server semantikk: NIKKE overstyrer GRANT. Dette kan gi uventede access-resultater.

• 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 data access.

    • Å fjerne kolonnen som brukes i filteruttrykket ugyldiggjør RLS, og Metadata Sync vil være utdatert inntil RLS er fikset på OneLake sikkerhetspanel.

    • 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 metadata-synkronisering inntil CLS-regelen er fikset 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.

• Tabellomdøping bevarer ikke sikkerhetspolicyer: Hvis OneLake sikkerhetsroller (OLS) defineres på skjemanivå, forblir disse rollene gyldige bare 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.

Relatert innhold

• Beste praksis for å sikre data i OneLake
• OneLake sikkerhetsmodell access control modell