OneLake-säkerhet för SQL-analysslutpunkter (förhandsversion)

Med OneLake-säkerhet expanderar Microsoft Fabric hur organisationer kan hantera och framtvinga data access mellan arbetsbelastningar. Det här nya 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 access styrs helt av de säkerhetsregler som definieras i OneLake. Behörigheter på SQL-nivå för tabeller stöds, vilket säkerställer konsekvent styrning över 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

Här är en tydlig och koncis jämförelsetabell som fokuserar på hur och var du ställer in säkerhet i användaridentitetsläge jämfört med delegerat identitetsläge – uppdelat efter objekttyp och data access principer:

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ågra GRANT- eller REVOKE-instruktioner på SQL-nivå.

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 GRANT/REVOKE-instruktioner i tabeller ignoreras.

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

Arbetsytans rollbeteende

Användare med rollen Administratör, Medlem eller Deltagare på arbetsytenivå omfattas inte av OneLake-säkerhet. Dessa roller har förhöjda privilegier och kringgår helt RLS-, CLS- och OLS-policyer. Följ dessa krav för att säkerställa att OneLake-säkerheten respekteras:

• Tilldela användare rollen Betraktare på arbetsytan, eller

• Dela Lakehouse- eller SQL-analysslutpunkten med användare med skrivskyddade behörigheter. Endast användare med skrivskyddad åtkomst får sina frågor filtrerade enligt OneLake-säkerhetsroller.

Rollprioritet: Den mest tillåtna åtkomsten vinner

Om en användare tillhör flera OneLake-roller, definierar den mest tillåtande rollen deras effektiva åtkomst. Till exempel:

• Om en roll beviljar fullständig access till en tabell och en annan tillämpar RLS för att begränsa rader, tillämpas inte RLS.

• Den bredare åtkomstrollen har företräde. Det här beteendet säkerställer att användarna inte oavsiktligt blockeras, men det kräver noggrann rolldesign för att undvika konflikter. Vi rekommenderar att du behåller restriktiva och tillåtande roller ömsesidigt uteslutande när du framtvingar åtkomstkontroller på rad- eller kolumnnivå.

Mer information finns i data access control modell 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.

Fel vid säkerhetssynkronisering och lösning

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 queries med ett access fel.

• När du utformar dina 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 använder SQL-analysslutpunkten samma säkerhetsmodell som finns idag i Microsoft Fabric. Säkerhet och behörigheter hanteras helt på SQL-lagret och OneLake-roller eller access principer tillämpas inte för access på tabellnivå. När en användare ansluter till SQL-analysslutpunkten och utfärdar en fråga:

• SQL verifierar access baserat på SQL-behörigheter (GRANT, REVOKE, RLS, CLS, DDM, roller osv.).

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

• Denna dataåtkomst utförs med hjälp av identiteten för lakehouse- eller SQL-analysslutpunktens ägare – även kallat objektkontot.

I den här modellen:

• Den inloggade användaren skickas inte till OneLake.

• All tillämpning av access antas hanteras på SQL-skiktet.

• Objektägaren ansvarar för att ha tillräcklig behörighet i OneLake för att läsa de underliggande filerna för arbetsbelastningens räkning.

Eftersom det här är ett delegerat mönster resulterar eventuella feljusteringar mellan SQL-behörigheter och OneLake-access för ägaren i frågefel. Det här läget ger fullständig kompatibilitet med:

• SQL GRANT/REVOKE på alla objektnivåer

• SQL-definierad Radsäkerhet, Kolumnsäkerhet och Dynamisk datamaskering

• Befintliga T-SQL-verktyg och metoder som används av dbas eller program

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

Åtkomstläget avgör hur dataåtkomst autentiseras och tillämpas när du gör förfrågningar mot OneLake via SQL-analysändpunkten. 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. Överst till höger växlar du från lakehouse till SQL-analysslutpunkten.

2. I det övre navigeringsfältet går du till fliken Security och väljer något av följande OneLake-access lägen:

   • Användaridentitet – Använder den inloggade användarens identitet. Det framtvingar OneLake-roller.

   • 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 visningsbehörighet eller delad skrivskyddad åtkomst omfattas 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.

Begränsningar

• Gäller endast för läsare: OneLake-säkerhet styr användare som kommer åt data som tittare. Användare i andra arbetsyteroller (administratör, medlem eller deltagare) kringgår OneLake-säkerhet och behåller fullständiga access.

• SQL-objekt ärver inte ägarskap: Genvägar visas i SQL-analysslutpunkten som tabeller. Vid åtkomst till dessa tabeller, direkt eller via vyer, har lagrade procedurer och andra härledda SQL-objekt inget ägarskap på objektnivå. Alla behörigheter kontrolleras vid körning för att förhindra att säkerheten kringgås.

• Kortkommandoändringar utlöser valideringsavbrott: När ett genvägsmål ändras (till exempel namnbyte, 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 ganska snabba, men ibland kan det ta upp till 5 minuter att synkronisera beroende på olika interna processer.

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

• Fördröjd behörighetsspridning: Behörighetsändringar sker inte omedelbart. Växling mellan säkerhetslägen (användaridentitet jämfört med delegerad) kan kräva tid för att spridas innan det börjar gälla, men bör ta mindre än 1 minut.

• Kontrollplansberoende: Behörigheter kan inte tillämpas på användare eller grupper som inte redan finns i arbetsytans kontrollplan. Du måste antingen dela källobjektet eller så måste användaren vara medlem i Viewer-rollen. Observera att exakt samma objekt-ID måste finnas på båda platserna. En grupp och en medlem i den gruppen räknas inte som en matchning.

• Most-permissive access råder: När användare tillhör flera grupper eller roller respekteras den mest tillåtande effektiva behörigheten Exempel: Om en användare har både NEKA genom en roll och BEVILJA via en annan, har BEVILJA företräde.

• Delegerade lägesbegränsningar: I delegerat läge kan metadatasynkronisering på genvägstabeller misslyckas om källobjektet har OneLake-säkerhetsprinciper som inte beviljar fullständig tabell access till objektets ägare.

• DENY-beteende: När flera roller gäller för en enda genvägstabell följer skärningspunkten mellan behörigheter SQL Server semantik: DENY åsidosätter GRANT. Detta kan ge oväntade åtkomstresultat.

• Förväntade feltillstånd: Användare kan stöta på fel i scenarier som:

  • Genvägens mål har bytt namn eller är ogiltigt

    • Exempel: Om tabellens källa har tagits bort.

  • Felkonfiguration av RLS (Row-Level Security)

    • Vissa uttryck för RLS-filtrering stöds inte i OneLake och det kan tillåta obehörig dataåtkomst.

    • Om kolumnen som används i filteruttrycket tas bort blir RLS- och Metadata Sync inaktuella tills RLS har åtgärdats på säkerhetspanelen i OneLake.

    • För offentlig förhandsversion stöder vi endast tabeller med enkla uttryck. Dynamisk RLS och Multi-Table RLS stöds inte för tillfället.

  • Begränsningar för säkerhet på kolumnnivå (CLS)

    • CLS fungerar genom att upprätthålla en lista över tillåtna kolumner. Om en tillåten kolumn tas bort eller byter namn blir CLS-principen ogiltig.

    • När CLS är ogiltigt blockeras metadatasynkronisering tills CLS-regeln har åtgärdats i Säkerhetspanelen onelake.

  • Metadata- eller behörighetssynkroniseringsfel

    • Om det finns ändringar i tabellen, som att byta namn på en kolumn, replikeras inte säkerheten på det nya objektet, och du får användargränssnittsfel som visar att kolumnen inte finns.

• Tabellbyten bevarar inte säkerhetsprinciper: Om OLS-roller (OneLake Security) definieras på schemanivå gäller dessa roller endast så länge tabellnamnet är oförändrat. Om du byter namn på tabellen bryts associationen och säkerhetsprinciperna migreras inte automatiskt. Detta kan leda till oavsiktlig dataexponering tills principer tillämpas på nytt.

• OneLake-säkerhetsroller kan inte ha namn som är längre än 124 tecken. Annars kan inte säkerhetssynkronisering synkronisera rollerna.

• OneLake-säkerhetsroller sprids på SQL-analysslutpunkten med prefixet OLS_.

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

• E-postaktiverade säkerhetsgrupper och distributionslistor stöds inte.

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