OneLake-säkerhet för SQL-analysslutpunkter

Med OneLake-säkerhet expanderar Microsoft Fabric hur organisationer kan hantera och framtvinga data access mellan arbetsbelastningar. Det här säkerhetsramverket ger administratörer större flexibilitet att konfigurera behörigheter. Administratörer kan välja mellan centraliserad styrning via OneLake eller detaljerad SQL-baserad kontroll i SQL-analysslutpunkten .

Åtkomstlägen i SQL Analytics-slutpunkten

När du använder SQL-analysslutpunkten avgör det valda access läget hur datasäkerhet tillämpas. Fabric har stöd för två distinkta access modeller, som var och en erbjuder olika fördelar beroende på dina drifts- och efterlevnadsbehov:

• Användaridentitetsläge: Framtvingar säkerhet med hjälp av OneLake-roller och principer. I det här läget skickar SQL-analysslutpunkten den inloggade användarens identitet till OneLake och läsåtkomst styrs helt av de säkerhetsregler som definierats i OneLake. Behörigheter på SQL-nivå för icke-dataobjekt (vyer, lagrade procedurer, funktioner) stöds, vilket säkerställer konsekvent styrning mellan verktyg som Power BI, notebook-filer och lakehouse.

• Delegerat identitetsläge: Ger fullständig kontroll via SQL. I det här läget ansluter SQL-analysslutpunkten till OneLake med hjälp av arbetsytans eller objektets ägares identitet, och säkerheten styrs uteslutande av SQL-behörigheter som definierats i databasen. Den här modellen stöder traditionella säkerhetsmetoder som GRANT, REVOKE, anpassade roller, Row-Level Security och Dynamisk datamaskering.

Varje läge stöder olika styrningsmodeller. Att förstå deras konsekvenser är viktigt för att välja rätt metod i din Fabric-miljö.

Jämförelse mellan åtkomstlägen

I följande tabell jämförs hur och var du ställer in säkerhet i användaridentitetsläge jämfört med delegerat identitetsläge, uppdelat efter objekttyp och principer för dataåtkomst:

Användaridentitetsläge i OneLake-säkerhet

I användaridentitetsläge använder SQL-analysslutpunkten en genomströmningsautentiseringsmekanism för att verkställa datatillgång. När en användare ansluter till SQL-analysslutpunkten skickas deras Entra-ID-identitet till OneLake, som utför behörighetskontrollen. Alla läsåtgärder mot tabeller utvärderas med hjälp av säkerhetsreglerna som definierats i OneLake Lakehouse, inte av någon SQL-nivå GRANT eller REVOKE -instruktioner.

Detta läge låter dig hantera säkerheten centralt och säkerställa enhetlig tillämpning i alla Fabric-tjänster, inklusive Power BI, notebooks, lakehouse och SQL-analysändpunkter. Den är utformad för styrningsmodeller där access ska definieras en gång i OneLake och respekteras automatiskt överallt.

I användaridentitetsläge:

• Tabellåtkomst styrs helt av OneLake säkerhet. SQL-instruktioner GRANT/REVOKE ignoreras i tabeller.

• RLS (Row-Level Security), CLS (Column-Level Security) och Object-Level Security definieras alla i OneLake-upplevelsen.

• SQL-behörigheter tillåts för icke-dataobjekt som vyer, lagrade procedurer och funktioner, vilket möjliggör flexibilitet för att definiera anpassad logik eller användarriktade startpunkter för data.

• Skrivåtgärder stöds inte vid SQL-analysslutpunkten. Alla skrivningar måste ske via Lakehouse-sidan i Infrastrukturportalen och styrs av arbetsyteroller (administratör, medlem, deltagare).

Mer information om behörighetsmodellen med användarens identitetsläge finns i dataåtkomstkontrollmodellen för OneLake-säkerhet.

Säkerhetssynkronisering mellan OneLake- och SQL-analysslutpunkt

En viktig komponent i användaridentitetsläget är tjänsten för säkerhetssynkronisering. Den här bakgrundstjänsten övervakar ändringar som gjorts i säkerhetsroller i OneLake och ser till att ändringarna återspeglas i SQL-analysslutpunkten.

Tjänsten för säkerhetssynkronisering ansvarar för följande:

• Identifiera ändringar i OneLake-roller, inklusive nya roller, uppdateringar, användartilldelningar och ändringar i tabeller.

• Översätta OneLake-definierade principer (RLS, CLS, OLS) till motsvarande SQL-kompatibla databasrollstrukturer.

• Se till att genvägsobjekt (tabeller som kommer från andra sjöhus) verifieras korrekt så att de ursprungliga OneLake-säkerhetsinställningarna respekteras, även när de nås via fjärranslutning.

Den här synkroniseringen säkerställer att OneLake-säkerhetsdefinitioner förblir auktoritativa, vilket eliminerar behovet av manuella åtgärder på SQL-nivå för att replikera säkerhetsbeteende. Eftersom säkerhet tillämpas centralt:

• Du kan inte definiera RLS, CLS eller OLS direkt med T-SQL i det här läget.

• Du kan fortfarande använda SQL-behörigheter för vyer, funktioner och lagrade procedurer med hjälp av GRANT eller EXECUTE -instruktioner.

Säkerhetssynkronisering återförsöksbegränsning

Säkerhetssynkronisering innehåller en återförsöksmekanism för att skydda systemets stabilitet och undvika onödig beräkningsförbrukning:

• Om upprepade fel uppstår när onelake-säkerhetsroller tillämpas på SQL-analysslutpunkten kan systemet tillfälligt pausa automatiska synkroniseringsförsök.

• Synkroniseringen återupptas automatiskt när en befintlig OneLake-säkerhetsroll ändras eller en ny skapas.

Fel och lösning för säkerhetssynkronisering

Genvägsbeteende med säkerhetssynkronisering

OneLake-säkerhet tillämpas vid den ursprungliga informationskällan, vilket innebär att säkerhetssynkronisering inaktiverar ägarskapslänkning för tabeller och vyer som involverar genvägar. Detta säkerställer att källsystembehörigheter alltid utvärderas och respekteras, även för frågor från en annan databas.

Som ett resultat:

• Användarna måste ha giltig åtkomst till både genvägskällan (aktuell Lakehouse eller SQL-analysslutpunkt)ochdestinationen där data finns fysiskt.

• Om användaren saknar behörighet på båda sidor misslyckas frågor med ett åtkomstfel.

• När du utformar program eller vyer som refererar till genvägar kontrollerar du att rolltilldelningarna är korrekt konfigurerade i båda ändar av genvägsrelationen.

Den här designen bevarar säkerhetsintegriteten över gränserna för Lakehouse, men den introducerar scenarier där åtkomstfel kan inträffa om rollerna mellan Lakehouse inte är i linje.

Delegerat läge i OneLake-säkerhet

I delegerat identitetsläge bevarar SQL-analysslutpunkten bakåtkompatibilitet med den traditionella SQL-säkerhetsmodellen. Säkerhet definieras och framtvingas på SQL-motorlagret, och OneLake-säkerhetsroller och åtkomstprinciper överförs inte till åtkomst på tabellnivå. All filtrering och åtkomstkontroll – inklusive åtkomst till scheman och tabeller, Row-Level Security (RLS), Column-Level Security (CLS) och DDM (Dynamic Data Masking) – måste definieras med hjälp av SQL-konstruktioner (GRANT/REVOKE, säkerhetsprinciper och så vidare).

Eftersom OneLake-säkerhetsroller för slutanvändaren inte tillämpas direkt tillämpas inte några säkerhetsregler som definieras i OneLake (till exempel regler som tillämpas av Spark eller andra motorer som läser via OneLake) när samma data efterfrågas via SQL-analysslutpunkten. Välj det här läget när arbetsbelastningen är beroende av SQL-inbyggd säkerhetssemantik eller när befintliga T-SQL-verktyg kräver fullständig kompatibilitet.

När en användare ansluter till SQL-analysslutpunkten och utfärdar en fråga:

• SQL validerar frågan mot de behörigheter som definierats på SQL-lagret.

• Om frågan är auktoriserad fortsätter systemet att få åtkomst till data som lagras i OneLake.

• Den här dataåtkomsten utförs med hjälp av identiteten för lakehouse- eller SQL-analysslutpunktens ägare, även kallat objektkontot, inte den inloggade användaren.

Objektägaren ansvarar därför för att ha tillräcklig behörighet i OneLake för att läsa de underliggande filerna för arbetsbelastningens räkning. Eventuella feljusteringar mellan SQL-behörigheter som beviljats slutanvändare och objektägarens OneLake-åtkomst resulterar i frågefel.

Det här läget stöder befintliga T-SQL-verktyg och metoder som används av DBA:er eller program, med fullständig kompatibilitet för SQL GRANT/REVOKE på alla objektnivåer och SQL-definierade RLS, CLS och DDM.

Genvägsbeteende i delegerat läge

Eftersom delegerat läge ansluter till OneLake med objektägarens identitet fungerar genvägar endast när ägaren har obegränsad åtkomst till hela källtabellen. Om källtabellen har någon säkerhetsregel på OneLake-nivå tillämpad, till exempel Row-Level Security (RLS), Column-Level Security (CLS), blockerar SQL-analysslutpunkten åtkomsten till genvägen.

Som ett resultat:

• Genvägar som pekar på källtabeller utan säkerhetsregler på datanivå fungerar normalt i delegerat läge.

• Genvägar som pekar på källtabeller med RLS eller CLS i OneLake-säkerhet på producenten är inte tillgängliga via SQL-analysslutpunkten i delegerat läge, även om slutanvändaren har SQL-behörigheter för genvägsobjektet.

• Om du vill använda genvägar vars källa har OneLake-säkerhetsprinciper använder du användaridentitetsläget på konsumentslutpunkten så att slutanvändarens identitet utvärderas mot källans OneLake-säkerhetsregler.

Så här ändrar du OneLake-access läge

Åtkomstläget avgör hur dataåtkomst autentiseras och framtvingas när du frågar OneLake via SQL-analysslutpunkten. Du kan växla mellan användaridentitetsläge och delegerat identitetsläge med hjälp av följande steg:

1. Gå till din Fabric-arbetsyta och öppna ditt sjöhus. Från det övre högra hörnet växlar du från lakehouse till SQL-analysslutpunkten.

2. I det övre navigeringsfönstret går du till fliken Säkerhet och väljer något av följande OneLake-åtkomstlägen:

   • Användaridentitet – Använder den inloggade användarens identitet. Implementerar roller för OneLake.

   • Delegerad identitet – Använder objektägarens identitet. Tillämpar endast SQL-behörigheter.

3. Ett popup-fönster startas för att bekräfta ditt val. Välj Ja för att bekräfta ändringen.

Överväganden vid växling mellan lägen

Växla till användaridentitetsläge

• Behörigheter på SQL RLS-, CLS- och tabellnivå ignoreras.

• OneLake-roller måste konfigureras för att användarna ska kunna underhålla access.

• Endast användare med läsbehörighet eller delad skrivskyddad åtkomst styrs av OneLake-säkerhet.

• Befintliga SQL-roller tas bort och kan inte återställas.

Växla till delegerat identitetsläge

• OneLake-roller och säkerhetsprinciper tillämpas inte längre.

• SQL-roller och säkerhetspolicyer blir aktiva.

• Objektets ägare måste ha giltiga OneLake-access, annars kan alla frågor misslyckas.

Anmärkningar

• SQL-objekt ärver inte ägarskap: Genvägar fungerar som tabeller i SQL-analysslutpunkten men avviker avsiktligt från sql-ägarskapslänkning av standardtyp för att upprätthålla en enhetlig säkerhetsstatus.

  • Regel utan arv: Härledda SQL-objekt (vyer, lagrade procedurer eller funktioner) ärver inte behörigheter från objektägaren.

  • Körningsverifiering: Behörigheter verifieras mot anroparens identitet vid körningstillfället, vilket säkerställer att SQL-abstraktioner inte kan kringgå principer på OneLake-nivå.

  • Säkerhet efter design: Säkerhetsprinciper förblir konsekventa oavsett om data nås via SQL, Spark eller Power BI.

• Kontrollplansberoende (strikt identitetsmatchning): OneLake-säkerhet kräver att identiteten som beviljas åtkomst hos producenten är samma identitet som identifieras under åtkomstutvärderingen på konsumentdataplanet. Systemet validerar det specifika huvudkontot som har beviljats åtkomst vid källan och expanderar inte kapslat gruppmedlemskap eller härleder effektiv åtkomst via indirekt medlemskap.

  • Exakt matchning av huvudobjekt: Åtkomst utvärderas mot det exakta objekt-ID som beviljats hos producenten.

  • Ingen kapslad/effektiv lösning: Kapslat gruppmedlemskap eller indirekt arv behandlas inte som tillräckligt för verkställighet. Se pratbubblan i användaridentitetsläge i OneLake-säkerhet för ett fungerat exempel.

• Beteende för utvärdering av behörigheter: Behörighetsutvärderingen varierar beroende på tabelltyp baserat på den aktuella tvingande modellen.

  • Genvägstabeller: Åtkomst kan nekas när nödvändiga auktoriseringsvillkor inte uppfylls. Det här är ett restriktivt verkställighetsresultat, inte en rollbaserad DENY-funktion i OneLake-säkerhet.

  • Allmän regel: När tillämpningen inte tydligt kan verifiera åtkomsten tillämpar systemet det mest restriktiva resultatet.

• Column-Level Security (CLS) design: CLS upprätthåller en strikt lista över tillåtna kolumner.

  • Om du byter namn på eller tar bort en tillåten kolumn ogiltigförklaras säkerhetsregeln. Regeln kvarstår i systemet, men den förblir inaktiv – nekar all åtkomst till resursen – tills den ursprungliga kolumnnamngivningen har återställts.

  • Synkroniseringsskydd: När en princip är ogiltig blockeras metadatasynkronisering avsiktligt tills regeln har korrigerats i Säkerhetspanelen i OneLake.

  • Schemavalidering: Om du byter namn på kolumner utan att uppdatera säkerhetsprinciper utlöses användargränssnittsfel som anger att kolumnen "inte finns" förrän konfigurationen har synkroniserats.

• Rollspridning och synkronisering (SLA):

  • OneLake-säkerhetssynkronisering: När en OneLake-säkerhetsroll ändras i användaridentitetsläget är uppdateringen inte omedelbar. Även om det vanligtvis är snabbt kan det ta upp till 5 minuter att synkronisera med SQL-analysslutpunkten.

  • Automatisk prefixning: OneLake-säkerhetsrollerna förs vidare till SQL-analysslutpunkten med prefixet OLS_.

  • Synkroniseringsprioritet: Säkerhetssynkroniseringsprocessen uppdaterar regelbundet rollernas OLS_ tillstånd. Manuella ändringar av dessa roller stöds inte och skrivs över under nästa synkroniseringscykel. Om det inte finns några ändringar att synkronisera åsidosätter inte säkerhetssynkronisering manuella ändringar.

• Sql-säkerhet och genvägar för lager: Säkerhetsprinciper som definierats med SQL-konstruktioner i ett lager – till exempel Row-Level Security (RLS), Column-Level Security (CLS) eller Object-Level Security (OLS) – tillämpas endast inom SQL-körningskontexten för lagret (TDS-slutpunkten).

Begränsningar

• Gäller endast för läsare: OneLake-säkerhet framtvingas främst för användare som kommer åt data via arbetsytan på visningsnivå eller objektåtkomst. Användare med bredare arbetsyteroller som Administratör, Medlem eller Deltagare behåller förhöjd åtkomst och är inte det primära målet för OneLake-säkerhetstillämpning.

  • Undantag:

    • Genvägsnekande beteende: För genvägsbaserade tabeller kan implementeringen fortfarande neka åtkomst till Administratörer, Medlemmar eller Deltagare i specifika fall.

    • Felfall vid säkerhetssynkronisering: Om säkerhetssynkroniseringen inte tillämpar säkerheten korrekt för vissa tabeller eller roller kan användare i administratörs-, medlems- eller deltagarroller som är medlemmar i de berörda rollerna också få begränsad åtkomst.

    • RLS i användaridentitetsläge: När Row-Level Security (RLS) har konfigurerats i användaridentitetsläge tillämpas de definierade säkerhetsreglerna för alla användare, inklusive de i roller som administratör, medlem och deltagare.

• Beroende av säkerhetssynkronisering: I användaridentitetsläge synkroniseras OneLake-säkerhetsroller till SQL-analysslutpunkten via säkerhetssynkroniseringsprocessen. Tills synkroniseringen är klar kan SQL tillfälligt utvärdera åtkomsten med hjälp av det befintliga SQL-behörighetstillståndet. När synkroniseringen är klar återspeglar SQL-slutpunkten OneLake-säkerhetskonfigurationen.

• Genvägsgränsmedvetenhet: SQL-analysslutpunkten kan ursprungligen utvärdera genvägsbaserade tabeller med hjälp av standard-SQL-objektsemantik. När säkerhetssynkroniseringen har inträffat tillämpas OneLake-säkerhetsprinciper för att säkerställa att åtkomsttillämpningen överensstämmer med artefakt- och arbetsytegränser.

• Tidsåtvisning för åtkomst mellan artefakter: Åtkomst till tabeller som backas upp av OneLake-genvägar som refererar till data från andra artefakter framtvingas via synkroniserade OneLake-säkerhetsroller. Tills synkroniseringen sker kan SQL-auktorisering tillfälligt återspegla det tidigare behörighetstillståndet.

• Ägarskapsändringar i genvägsbaserade tabeller: Genvägsbaserade tabeller representeras som SQL-objekt i SQL-analysslutpunkten och stöder därför standardåtgärder för SQL-ägarskap. Administrativa kommandon som ALTER AUTHORIZATION kan ändra ägaren till en genvägsbaserad tabell. I vissa scenarier kan detta tillåta ägarskapslänkningsbeteende som kringgår OneLake-säkerhetsprinciper och ger oavsiktlig åtkomst till underliggande data. Tills ytterligare tillämpningsmekanismer införs bör administratörer undvika att ändra ägarskapet för genvägsbaserade tabeller.

• Stilleståndstid för målverifiering: När ett genvägsmål ändras (till exempel namnbyte eller URL-uppdatering) går databasen kort in i läget för en användare medan systemet validerar det nya målet. Under den här perioden blockeras frågor. Dessa åtgärder är vanligtvis snabba, men beroende på interna processer kan det ta upp till 5 minuter att synkronisera.

  • Att skapa schemagenvägar kan orsaka ett känt fel som påverkar validering och fördröjer metadatasynkronisering.

• Cachelagring av token i delegerat läge: I delegerat läge cachelagrar SQL-analysslutpunkten lagringsåtkomsttoken som används för att hämta data från OneLake för ägaridentitetens räkning. Om ägarens behörigheter ändras kan en tidigare utfärdad token vara giltig tills den upphör att gälla. Det innebär att åtkomständringar som är kopplade till ägaridentiteten kanske inte börjar gälla omedelbart och kan sparas tills token upphör att gälla, vanligtvis upp till 30–60 minuter.

• Ändringar i OneLake-säkerhetsprinciper för tillåtelse och avslag genomförs omedelbart och påverkas inte av cachelagring av token.

• Aktiv frågeavbrytning: För att upprätthålla dataintegritet och säkerhet kan aktiva frågor avbrytas automatiskt om en konfigurationsändring sker under exekveringen.

• Row-Level Security (RLS)-begränsningar:

  • För offentlig förhandsversion stöds endast tabeller med ett enda uttryck. Dynamisk RLS och Multi-Table RLS är inte tillgängliga.

  • Om du släpper en kolumn som används i ett filteruttryck stoppas metadatasynkroniseringen tills RLS har åtgärdats i Säkerhetspanelen för OneLake.

• Rollkomplexitet och metadatasynkronisering: Hög komplexitet i säkerhetsroller – särskilt de som involverar många korsningar och föreningssemantik med RLS – kan orsaka att säkerhetssynkroniseringen misslyckas. En misslyckad säkerhetssynkronisering förhindrar att säkerhetsprinciper tillämpas och blockerar möjligheten att synkronisera metadata.

• Schema- och rollbegränsningar:

  • Byter namn: OneLake-säkerhetsroller är knutna till tabellnamnet. Om du byter namn på en tabell bryts associationen och principerna migreras inte automatiskt. Detta kan leda till oavsiktlig dataexponering tills principer tillämpas på nytt.

  • Teckengränser: OneLake-säkerhetsrollnamn får inte överstiga 124 tecken. Annars misslyckas rollskapandet eller synkroniseringen på SQL-analysslutpunkten.

  • OLS_ rolländringar: Användarändringar i OLS_ roller stöds inte och kan orsaka oväntade beteenden.

• Identiteter som inte stöds: E-postaktiverade säkerhetsgrupper och distributionslistor stöds inte för närvarande.

• Krav för Lakehouse-ägare:

  • Ägaren till lakehouse måste vara medlem i arbetsyterollerna Administratör, Medlem eller Deltagare. Annars tillämpas inte säkerhet på SQL-analysslutpunkten.

  • Ägaren till lakehouse kan inte vara tjänstens huvudnamn för att säkerhetssynkroniseringen ska fungera.

Relaterat innehåll

• Metodtips för att skydda data i OneLake
• OneLakes säkerhets- och åtkomstkontrollmodell