OneLake-sikkerhed til SQL-analyseslutpunkter

Med OneLake-sikkerhed udvider Microsoft Fabric, hvordan organisationer kan håndtere og håndhæve data access på tværs af arbejdsbelastninger. Dette sikkerhedsrammeværk giver administratorer større fleksibilitet til at konfigurere tilladelser. Administratorer kan vælge mellem centraliseret styring via OneLake eller detaljeret SQL-baseret styring i SQL-analyseslutpunktet .

Access-tilstande i SQL-analyse-endpoint

Når man bruger SQL analytics endpoint, bestemmer den valgte access-tilstand, hvordan datasikkerhed håndhæves. Fabric understøtter to forskellige access-modeller, som hver tilbyder forskellige fordele afhængigt af dine operationelle og compliance-behov:

• Brugeridentitetstilstand: Gennemtvinger sikkerhed ved hjælp af OneLake-roller og -politikker. I denne tilstand sender SQL-analyse-endpointet den indloggede brugers identitet videre til OneLake, og læseadgang styres udelukkende af de sikkerhedsregler, der er defineret i OneLake. SQL-niveau tilladelser på ikke-dataobjekter (visninger, lagrede procedurer, funktioner) understøttes og sikrer ensartet styring på tværs af værktøjer som Power BI, notebooks og lakehouse.

• Delegeret identitetstilstand: Giver fuld kontrol via SQL. I denne tilstand opretter SQL-analyseslutpunktet forbindelse til OneLake ved hjælp af identiteten for arbejdsområdet eller elementejeren , og sikkerheden styres udelukkende af SQL-tilladelser , der er defineret i databasen. Denne model understøtter traditionelle sikkerhedstilgange, herunder GRANT, REVOKE, brugerdefinerede roller, Row-Level Security og Dynamic Data Maskg.

Hver tilstand understøtter forskellige styringsmodeller. Det er vigtigt at forstå deres konsekvenser for at vælge den rigtige tilgang i dit Fabric-miljø.

Sammenligning mellem access-tilstande

Følgende tabel sammenligner, hvordan og hvor du sætter sikkerhed i brugeridentitetstilstand versus delegeret identitetstilstand, opdelt efter objekttype og dataadgangspolitikker:

Brugeridentitetstilstand i OneLake-sikkerhed

I brugeridentitetstilstand bruger SQL-analyseendpointet en passthrough-autentificeringsmekanisme til at håndhæve data access. Når en bruger opretter forbindelse til SQL Analytics-slutpunktet, overføres vedkommendes Entra ID-identitet til OneLake, som udfører tilladelseskontrollen. Alle læseoperationer mod tabeller evalueres ved hjælp af de sikkerhedsregler, der er defineret i OneLake Lakehouse, ikke ved hjælp af SQL-niveau GRANT eller REVOKE udsagn.

Denne tilstand giver dig mulighed for at administrere sikkerhed centralt, hvilket sikrer ensartet håndhævelse på tværs af alle Fabric-oplevelser, herunder Power BI, notesbøger, lakehouse og SQL-analyseslutpunkt. Det er designet til styringsmodeller, hvor access skal defineres én gang i OneLake og automatisk respekteres overalt.

I brugeridentitetstilstand:

• Table access styres fuldstændigt af OneLake-sikkerhed. SQL-sætninger GRANT/REVOKE på tabeller ignoreres.

• Sikkerhed på rækkeniveau (Row-Level Security), CLS (Column-Level Security) og Object-Level Security er alle defineret i OneLake-oplevelsen.

• SQL-tilladelser er tilladt for ikke-dataobjekter som f.eks. visninger, lagrede procedurer og funktioner, hvilket giver fleksibilitet til at definere brugerdefineret logik eller brugervendte indgangspunkter til data.

• Skrivehandlinger understøttes ikke på SQL-analyseslutpunktet. Alle skrivninger skal ske via Lakehouse-siden i Fabric-portalen og styres af workspace-roller (Admin, Medlem, Bidragyder).

For mere information om tilladelsesmodellen med brugerens identitetstilstand, se dataadgangskontrolmodellen for OneLake-sikkerhed.

Sikkerhedssynkronisering mellem OneLake og SQL-analyseslutpunkt

En vigtig komponent i brugeridentitetstilstand er sikkerhedssynkroniseringstjenesten. Denne baggrundstjeneste overvåger ændringer, der foretages af sikkerhedsroller i OneLake, og sikrer, at disse ændringer afspejles i SQL-analyseslutpunktet.

Tjenesten til sikkerhedssynkronisering er ansvarlig for følgende:

• Registrering af ændringer af OneLake-roller, herunder nye roller, opdateringer, brugertildelinger og ændringer af tabeller.

• Oversættelse af OneLake-definerede politikker (RLS, CLS, OLS) til ækvivalente SQL-kompatible databaserollestrukturer.

• Sikring af, at genvejsobjekter (tabeller fra andre søhuse) valideres korrekt, så de oprindelige OneLake-sikkerhedsindstillinger respekteres, selv når de åbnes eksternt.

Denne synkronisering sikrer, at OneLake-sikkerhedsdefinitioner forbliver autoritative, hvilket eliminerer behovet for manuel indgriben på SQL-niveau for at replikere sikkerhedsadfærd. Fordi sikkerhed håndhæves centralt:

• Du kan ikke definere sikkerhed på rækkeniveau, CLS eller OLS direkte ved hjælp af T-SQL i denne tilstand.

• Du kan stadig anvende SQL-rettigheder på visninger, funktioner og lagrede procedurer ved hjælp af GRANT eller EXECUTE statements.

Sikkerhedssynkroniserings-genstart

Sikkerhedssynkronisering inkluderer en retry backoff-mekanisme for at beskytte systemets stabilitet og undgå unødvendigt beregningsforbrug:

• Hvis gentagne fejl opstår under anvendelsen af OneLake-sikkerhedsroller på SQL-analyse-endpointet, kan systemet midlertidigt pause automatisk synkroniseringsforsøg.

• Synkronisering genoptages automatisk, når en eksisterende OneLake-sikkerhedsrolle ændres eller en ny oprettes.

Sikkerhedssynkroniseringsfejl og løsning

Genvejsfunktion med sikkerhedssynkronisering

OneLake-sikkerhed håndhæves ved kilden til sandheden, så sikkerhedssynkronisering deaktiverer ejerskabskæder for tabeller og visninger, der involverer genveje. Dette sikrer, at kildesystemtilladelser altid evalueres og overholdes, selv for forespørgsler fra en anden database.

Som følge heraf:

• Brugere skal have gyldige access på begge genvejen source (nuværende Lakehouse- eller SQL-analyseendepunkt) ogdestination hvor dataene fysisk befinder sig.

• Hvis brugeren mangler tilladelse på nogen af siderne, fejler forespørgslerne med en adgangsfejl.

• Når du designer applikationer eller visninger, der refererer til genveje, skal du sikre, at rolletildelinger er korrekt konfigureret i begge ender af genvejsforholdet.

Dette design bevarer sikkerhedsintegriteten på tværs af Lakehouse-grænser, men introducerer scenarier, hvor access-fejl kan opstå, hvis rollerne på tværs af Lakehouse ikke er på linje.

Delegeret tilstand i OneLake-sikkerhed

I delegeret identitetstilstand bevarer SQL-analyse-endpointet bagudkompatibilitet med den traditionelle SQL-sikkerhedsmodel. Sikkerhed defineres og håndhæves på SQL-motorlaget, og OneLake-sikkerhedsroller og adgangspolitikker overføres ikke til tabelniveau-adgang. Al filtrering og adgangskontrol – inklusive adgang til skemaer og tabeller, Row-Level Security (RLS), Column-Level Security (CLS) og Dynamic Data Masking (DDM) – skal defineres ved hjælp af SQL-konstruktioner (GRANT/REVOKE, sikkerhedspolitikker osv.).

Fordi OneLake-sikkerhedsroller for slutbrugeren ikke håndhæves direkte, vil eventuelle sikkerhedsregler defineret i OneLake (for eksempel regler håndhævet af Spark eller andre motorer, der læser gennem OneLake) ikke gælde, når de samme data forespørges via SQL-analyse-endpointet. Vælg denne tilstand, når arbejdsbyrden afhænger af SQL-native sikkerhedssemantik, eller når eksisterende T-SQL-værktøjer kræver fuld kompatibilitet.

Når en bruger opretter forbindelse til SQL Analytics-slutpunktet og udsteder en forespørgsel:

• SQL validerer forespørgslen mod de tilladelser, der er defineret på SQL-laget.

• Hvis forespørgslen er autoriseret, fortsætter systemet med at access data, der er gemt i OneLake.

• Denne dataadgang udføres ved at bruge identiteten på ejeren af Lakehouse- eller SQL-analyseendpointet, også kendt som item-kontoen – ikke den indloggede bruger.

Elementejeren er derfor ansvarlig for at have tilstrækkelige tilladelser i OneLake til at læse de underliggende filer på vegne af arbejdsbelastningen. Enhver uoverensstemmelse mellem SQL-tilladelser givet til slutbrugere og item-ejerens OneLake-adgang resulterer i forespørgselsfejl.

Denne tilstand understøtter eksisterende T-SQL-værktøjer og praksisser, der anvendes af DBA'er eller applikationer, med fuld kompatibilitet for SQL GRANT/REVOKE på alle objektniveauer samt SQL-definerede RLS, CLS og DDM.

Genvejsadfærd i delegeret tilstand

Fordi delegeret tilstand forbinder til OneLake via vare-ejerens identitet, virker genveje kun, når ejeren har ubegrænset adgang til hele kildetabellen. Hvis kildetabellen har en OneLake-niveau sikkerhedsregel anvendt – såsom Row-Level Security (RLS), Column-Level Security (CLS) – blokerer SQL-analyse-endpointet adgangen til denne genvej.

Som følge heraf:

• Genveje, der peger på kildetabeller uden dataniveau-sikkerhedsregler , fungerer normalt i delegeret tilstand.

• Genveje, der peger på kildetabeller med RLS eller CLS i OneLake-sikkerhed på producenten, er ikke tilgængelige via SQL-analyse-endpointet i delegeret tilstand, selvom slutbrugeren har SQL-tilladelser på genvejsobjektet.

• For at udnytte genveje, hvis kilde har OneLake-sikkerhedspolitikker, skal brugeridentitetstilstand bruges ved forbrugerens endepunkt, så slutbrugerens identitet vurderes i forhold til kildens OneLake-sikkerhedsregler.

Sådan ændrer man OneLake access-tilstanden

Adgangstilstanden bestemmer, hvordan dataadgang autentificeres og håndhæves, når man forespørger OneLake via SQL-analyse-endpointet. Du kan skifte mellem brugeridentitetstilstand og delegeret identitetstilstand ved hjælp af følgende trin:

1. Naviger til dit Fabric-arbejdsområde, og åbn dit søhus. Fra øverste højre hjørne skifter du fra lakehouse til SQL analytics-endpoint.

2. Fra den øverste navigation går du til fanen Sikkerhed og vælger en af følgende OneLake-adgangstilstande:

   • Brugeridentitet – Bruger den brugers identitet, der er logget på. Håndhæver OneLake-roller.

   • Delegeret identitet – Bruger ejerens identitet. Håndhæver kun SQL-tilladelser.

3. Et pop op-vindue åbnes for at bekræfte dit valg. Vælg Ja for at bekræfte ændringen.

Overvejelser ved skift mellem tilstande

Skift til brugeridentitetstilstand

• SQL RLS, CLS og tilladelser på tabelniveau ignoreres.

• OneLake-roller skal konfigureres for at brugerne kan opretholde access.

• Kun brugere med Viewer-rettigheder eller delt skrivebeskyttet adgang er underlagt OneLake-sikkerhed.

• Eksisterende SQL-roller slettes og kan ikke gendannes.

Skift til delegeret identitetstilstand

• OneLake-roller og sikkerhedspolitikker anvendes ikke længere.

• SQL-roller og sikkerhedspolitikker bliver aktive.

• Ejeren af genstanden skal have gyldige OneLake-access, ellers kan alle forespørgsler fejle.

Bemærkninger

• SQL-objekter arver ikke ejerskab: Genveje fungerer som tabeller i SQL-analyse-endpointet, men afviger bevidst fra standard SQL-ejerskabskæde for at opretholde en samlet sikkerhedsposition.

  • Ingen-arvsregel: Afledte SQL-objekter (visninger, lagrede procedurer eller funktioner) arver ikke tilladelser fra objektejeren.

  • Kørselsvalidering: Tilladelser verificeres mod kalderens identitet ved eksekveringstidspunktet, hvilket sikrer, at SQL-abstraktioner ikke kan omgå OneLake-niveau-politikker.

  • Security by design: Sikkerhedspolitikker forbliver konsistente, uanset om data tilgås via SQL, Spark eller Power BI.

• Kontrolplanafhængighed (streng identitetsmatchning): OneLake-sikkerhed kræver, at den identitet, der gives adgang hos producenten, er den samme identitet, der anerkendes under adgangsevaluering i forbrugerens dataplan. Systemet validerer det specifikke princip, der fik adgang ved kilden, og udvider ikke medlemskab af indlejrede grupper eller udleder effektiv adgang gennem indirekte medlemskab.

  • Bogstavelig principal-match: Adgangen vurderes mod det præcise objekt-ID, der er givet hos producenten.

  • Ingen indlejret/effektiv løsning: Indlejret gruppemedlemskab eller indirekte arv betragtes ikke som tilstrækkeligt til håndhævelse. Se callouten i brugeridentitetstilstand i OneLake sikkerhed for et gennemarbejdet eksempel.

• Adfærd for godkendelsesevaluering: Godkendelsesevaluering varierer efter tabeltype afhængigt af den nuværende håndhævelsesmodel.

  • Genvejstabeller: Adgang kan nægtes, når de nødvendige autorisationsbetingelser ikke er opfyldt. Dette er et restriktivt håndhævelsesresultat, ikke en rollebaseret DENY-kapacitet i OneLake-sikkerhed.

  • Generel regel: Når håndhævelsen ikke klart kan validere adgang, anvender systemet det mest restriktive resultat.

• Column-Level Sikkerhedsdesign (CLS): CLS opretholder en streng tilladelsesliste af kolonner.

  • Omdøbning eller fjernelse af en tilladt kolonne ugyldiggør sikkerhedsreglen. Selvom reglen består i systemet, forbliver den inaktiv – og nægter al adgang til ressourcen – indtil den oprindelige kolonnenavngivning genoprettes.

  • Synkroniseringsbeskyttelse: Når en politik er ugyldig, blokeres metadata-synkronisering designmæssigt, indtil reglen rettes i OneLake-sikkerhedspanelet.

  • Skemavalidering: Omdøbning af kolonner uden opdatering af sikkerhedspolitikker udløser UI-fejl, der siger, at kolonnen "ikke eksisterer", før konfigurationen er synkroniseret.

• Rolleudbredelse og synkronisering (SLA):

  • OneLake sikkerhedssynkronisering: Når en OneLake-sikkerhedsrolle ændres i brugeridentitetstilstand, sker opdateringen ikke med det samme. Selvom det normalt er hurtigt, kan det tage op til 5 minutter at synkronisere med SQL-analyse-endpointet.

  • Automatisk præfiksering: OneLake-sikkerhedsroller propageres til SQL-analyse-endpointet med præfikset OLS_ .

  • Synkroniseringsprioritet: Sikkerhedssynkroniseringsprocessen opdaterer periodisk rollernes tilstand OLS_ . Manuelle ændringer i disse roller understøttes ikke og overskrives under næste synkroniseringscyklus. Hvis der ikke er ændringer i synkroniseringen, tilsidesætter sikkerhedssynkronisering ikke manuelle ændringer.

• Warehouse SQL-sikkerhed og genveje: Sikkerhedspolitikker defineret ved hjælp af SQL-konstruktioner i et Warehouse – såsom Row-Level Security (RLS), Column-Level Security (CLS) eller Object-Level Security (OLS) – håndhæves kun inden for warehouse's SQL-eksekveringskontekst (TDS-endpoint).

Begrænsninger

• Gælder kun for læsere: OneLake-sikkerhed håndhæves primært for brugere, der tilgår data via Viewer-niveau workspace eller item access. Brugere med bredere arbejdsområder som administrator, medlem eller bidragyder har forhøjet adgang og er ikke det primære mål for OneLakes sikkerhedshåndhævelse.

  • Undtagelser:

    • Genvejsnægte-adfærd: For genvejsbaserede tabeller kan håndhævelsen stadig nægte adgang til administratorer, medlemmer eller bidragydere i specifikke tilfælde.

    • Fejl i sikkerhedssynkronisering: Hvis sikkerhedssynkronisering ikke anvender sikkerheden korrekt for visse tabeller eller roller, kan brugere i Admin-, Medlem- eller Bidragyderroller, som er medlemmer af de berørte roller, også opleve begrænset adgang.

    • RLS i brugeridentitetstilstand: Når Row-Level Security (RLS) konfigureres i brugeridentitetstilstand, håndhæves de definerede sikkerhedsregler for alle brugere, inklusive dem i administrator-, medlem- og bidragyderroller.

• Sikkerhedssynkroniseringsafhængighed: I brugeridentitetstilstand synkroniseres OneLake-sikkerhedsroller til SQL-analyse-endpointet gennem sikkerhedssynkroniseringsprocessen. Indtil synkroniseringen er fuldført, kan SQL midlertidigt evaluere adgangen ved hjælp af den eksisterende SQL-tilladelsestilstand. Når synkroniseringen er færdig, afspejler SQL-endpointet OneLake-sikkerhedskonfigurationen.

• Genvejsgrænsebevidsthed: SQL-analyse-endpointet kan i starten evaluere genvejsbaserede tabeller ved hjælp af standard SQL-objektsemantik. Efter sikkerhedssynkronisering anvendes OneLake-sikkerhedspolitikker for at sikre, at adgangshåndhævelse er i overensstemmelse med artefakt- og arbejdsområdegrænser.

• Tidspunktet for håndhævelse af adgang på tværs af artefakter: Adgang til tabeller understøttet af OneLake-genveje, som refererer til data fra andre artefakter, håndhæves gennem synkroniserede OneLake-sikkerhedsroller. Indtil synkronisering sker, kan SQL-autorisation midlertidigt afspejle den tidligere tilladelsestilstand.

• Ejerskabsændringer på genvejsbaserede tabeller: Genvejsbaserede tabeller repræsenteres som SQL-objekter i SQL-analyse-endpointet og understøtter derfor standard SQL-ejerskabsoperationer. Administrative kommandoer som ALTER AUTHORIZATION kan ændre ejeren af en genvejs-tabel. I visse scenarier kan dette muliggøre ejerskabskædeadfærd, der omgår OneLakes sikkerhedspolitikker og giver utilsigtet adgang til de underliggende data. Indtil yderligere håndhævelsesmekanismer indføres, bør administratorer undgå at ændre ejerskab på genvejsbaserede tabeller.

• Målvalideringsnedetid: Når et genvejsmål ændres (for eksempel omdøbning eller URL-opdatering), går databasen kortvarigt ind i single-user-tilstand , mens systemet validerer det nye mål. I denne periode blokeres forespørgsler. Disse operationer er typisk hurtige, men afhængigt af interne processer kan de tage op til 5 minutter at synkronisere.

  • Oprettelse af skemagenveje kan medføre en kendt fejl, der påvirker validering og forsinker synkronisering af metadata.

• Token caching i delegeret tilstand: I delegeret tilstand cacher SQL-analyse-endpointet det lagringsadgangstoken, der bruges til at hente data fra OneLake på vegne af ejerens identitet. Hvis ejerens tilladelser ændres, kan et tidligere udstedt token forblive gyldigt, indtil det udløber. Som følge heraf træder adgangsændringer knyttet til ejeridentiteten måske ikke i kraft med det samme og kan vare ved indtil tokenets udløb, typisk op til 30–60 minutter.

• Ændringer i OneLakes sikkerheds-GRANT/DENY-politikker håndhæves straks og forsinkes ikke af cachelagring af lagringstoken.

• Aktiv forespørgselsannullering: For at opretholde dataintegritet og sikkerhed kan aktive forespørgsler automatisk annulleres, hvis en genvejskonfiguration ændres under eksekveringen.

• Row-Level Sikkerhedsbegrænsninger (RLS):

  • For Public Preview understøttes kun enkeltudtrykstabeller. Dynamisk RLS og Multi-Table RLS er ikke tilgængelige.

  • At fjerne en kolonne, der bruges i et filterudtryk, forsinker metadatasynkroniseringen, indtil RLS er fikset i OneLake-sikkerhedspanelet.

• Rollekompleksitet og metadata-synkronisering: Høj kompleksitet i sikkerhedsroller – specifikt dem der involverer adskillige krydsninger og union-semantik ved brug af RLS – kan få sikkerhedssynkroniseringen til at fejle. En fejlslagen sikkerhedssynkronisering forhindrer sikkerhedspolitikker i at blive anvendt og blokerer muligheden for at synkronisere metadata.

• Skema- og rollebegrænsninger:

  • Omdøbninger: OneLake sikkerhedsroller er knyttet til tabelnavnet. At omdøbe en tabel bryder associationen, og politikker migrerer ikke automatisk. Dette kan resultere i utilsigtet dataeksponering, indtil politikker genanvendes.

  • Tegnbegrænsninger: OneLakes sikkerhedsrollenavne må ikke overstige 124 tegn; ellers fejler rolleoprettelse eller synkronisering på SQL-analyse-endpointet.

  • OLS_ Rolleændringer: Brugerændringer på OLS_ roller understøttes ikke og kan forårsage uventede adfærdsmønstre.

• Uunderstøttede identiteter: Mail-aktiverede sikkerhedsgrupper og distributionslister understøttes ikke i øjeblikket.

• Krav til søhusejere:

  • Ejeren af søhuset skal være medlem af Admin-, Medlem- eller Bidragyder-arbejdsområderne; ellers anvendes sikkerhed ikke på SQL-analyse-endpointet.

  • Ejeren af søhuset kan ikke være tjenesteprincipal, for at sikkerhedssynkronisering kan fungere.

Relateret indhold

• Bedste praksis for at sikre data i OneLake
• OneLake sikkerheds access control model