OneLake-säkerhet för SQL-analysslutpunkter

Genom att använda OneLake-säkerhet kan administratörer välja mellan centraliserad styrning via OneLake eller granulär SQL-baserad kontroll inom SQL-analysändpunkten.

Å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: Upprätthåller säkerhet genom att använda OneLake-roller och policyer. 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. Detta läge stödjer SQL-nivåbehörigheter på icke-dataobjekt, såsom vyer, lagrade procedurer och funktioner, vilket säkerställer konsekvent styrning över verktyg som Power BI, anteckningsböcker och lakehouse.

  • Delegerat identitetsläge: Ger fullständig kontroll via SQL. I detta läge ansluter SQL-analysändpunkten till OneLake genom att använda identiteten på arbetsytans eller objektägaren, och säkerheten styrs uteslutande av SQL-behörigheter som definieras i databasen. Denna modell stödjer traditionella säkerhetsmetoder, inklusive GRANT, REVOKE, anpassade roller, radnivåsäkerhet och dynamisk datamaskering.

Varje läge stöder olika styrningsmodeller. Förstå deras konsekvenser så att du kan välja rätt metod för din Fabric-miljö.

Viktigt!

Åtkomst till objektet krävs för att använda SQL-analysens slutpunkt. För att ansluta till och fråga data via en SQL-analysendpoint måste användare ha läsbehörighet på det objekt som är kopplat till endpointen. Om en användare inte har kontrollplansåtkomst till objektet (till exempel behörighet för arbetsyta eller explicit behörighet för objekt), avvisas anslutningen till SQL-analysendpointen, oavsett eventuella SQL-behörigheter som kan finnas för den användaren.

Jämföra å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:

Säkerhetsmål Användaridentitetsläge Delegerat identitetsläge
Tables OneLakes säkerhetsroller styr åtkomst. SQL GRANT/REVOKE är inte tillåtet. Fullständig kontroll med SQL GRANT/REVOKE.
Views Använd SQL GRANT/REVOKE för att tilldela behörigheter. Använd SQL GRANT/REVOKE för att tilldela behörigheter.
Lagrade procedurer Använd SQL GRANT EXECUTE för att tilldela behörigheter. Använd SQL GRANT EXECUTE för att tilldela behörigheter.
Funktioner Använd SQL GRANT EXECUTE för att tilldela behörigheter. Använd SQL GRANT EXECUTE för att tilldela behörigheter.
Säkerhet på radnivå (RLS) Definierad som en del av OneLakes säkerhetsroller. Definieras med SQL CREATE SECURITY POLICY.
Kolumnnivåsäkerhet (CLS) Definierad som en del av OneLakes säkerhetsroller. Definieras med SQL GRANT SELECT med kolumnlista.
DDM (Dynamic Data Masking) Stöds inte i OneLake-säkerhet. Definieras med hjälp av SQL ALTER TABLE med MASKED alternativet .

Byt OneLake-åtkomstläge

Åtkomstläget avgör hur dataåtkomst autentiseras och framtvingas när du frågar OneLake via SQL-analysslutpunkten. Nyligen skapade SQL-analysendpoints startar som standard i delegerat identitetsåtkomstläge. Innan du kan använda OneLake-säkerhet med en endpoint måste en administratör eller medlem byta till användarens identitetsåtkomstläge.

Anmärkning

För att använda OneLake-säkerhet behöver du bara byta till användarens identitetsåtkomstläge en gång per SQL-analysendpoint. Endpoints som du inte byter till användarens identitetsåtkomstläge fortsätter att använda en delegerad identitet för att utvärdera behörigheter.

  1. Gå till SQL-analys-endpointen.

  2. I SQL Analytics-slutpunktsmiljön väljer du fliken Säkerhet .

  3. Välj Visa dataåtkomstläge>Inställningar för dataåtkomstläge.

    Skärmbild som visar hur du navigerar till inställningarna för dataåtkomstläge för en SQL-analysslutpunkt.

  4. Välj användarens identitetsåtkomstläge för att använda den inloggade användarens identitet och upprätthålla OneLake-säkerhetsroller, eller välj Delegerad identitetsåtkomstläge för att använda objektägarens identitet och endast upprätthålla SQL-behörigheter. Välj därefter Tillämpa.

    Skärmbild som visar hur du väljer OneLake-säkerhet (användarens identitetsåtkomstläge) som dataåtkomstläge.

  5. Välj Fortsätt för att bekräfta ditt val.

Viktigt!

Om säkerhetsläget ändras blir SQL-analysendpoints tillfälligt otillgängliga i hela arbetsytan. Den här åtgärden avbryter alla databasförfrågningar som körs och köas vid alla analytiska SQL-slutpunkter inom den arbetsyta. Ändra lägen endast om det behövs, och helst under kontorstid för att undvika stilleståndstid.

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.

  • OneLake-upplevelsen definierar RLS (radnivåsäkerhet), CLS (kolumnnivåsäkerhet) och objektnivåsäkerhet.

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

Viktigt!

En-till-en-identitetsmappning mellan producent och konsument (hub-and-spoke). När OneLake-säkerhetsprinciper överförs från en producent (källobjektet där rollen definieras) till en konsument (ett målobjekt som kommer åt data via en genväg), måste identiteterna som tilldelats OneLake-säkerhetsroller hos producenten mappas exakt 1:1 hos konsumenten. Samma princip – oavsett om det är en användare eller en grupp – måste ges Fabric Read-tillstånd på konsumentartefakten som den som refereras i producentens säkerhetsroll. Kapslat eller effektivt gruppmedlemskap löses inte över den här gränsen.

Om säkerhetsrollen OneLake på producenten till exempel refererar till user123@microsoft.com måste user123@microsoft.com (det exakta objekt-ID:t) också ha Fabric Read-behörighet på konsumentens lakehouse. På samma sätt, om producentrollen refererar till Group A, måste Group A självt beviljas Fabric Read-behörighet för konsumenten – att bara ge den behörigheten till en medlem i Grupp A uppfyller inte kravet för matchning.

För mer information om behörighetsmodellen med användarens identitetsläge, se Hur OneLake-säkerhet kontrollerar dataåtkomst.

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

Scenario Beteende i användaridentitetsläge Beteende i delegerat läge Korrigeringsåtgärder Noteringar
RLS-principen refererar till en borttagen eller omdöpt kolumn Fel: Säkerhetsprincip på radnivå refererar till en kolumn som inte längre finns. Databasen anger feltillstånd tills principen har åtgärdats. Fel: Ogiltigt kolumnnamn <kolumnnamn> Uppdatera eller ta bort en eller flera berörda roller eller återställ kolumnen som saknas. Uppdateringen måste göras i lakehouse där rollen skapades.
CLS-principen refererar till en borttagen eller omdöpt kolumn Fel: Säkerhetsprincip på kolumnnivå refererar till en kolumn som inte längre finns. Databasen anger feltillstånd tills principen har åtgärdats. Fel: Ogiltigt kolumnnamn <kolumnnamn> Uppdatera eller ta bort en eller flera berörda roller eller återställ kolumnen som saknas. Uppdateringen måste göras i lakehouse där rollen skapades.
RLS/CLS-principen refererar till en borttagen eller omdöpt tabell Fel: Säkerhetsprincip refererar till en tabell som inte längre finns. Inget fel uppstod, frågan misslyckas utan felmeddelande om tabellen saknas. Uppdatera eller ta bort en eller flera berörda roller eller återställ tabellen som saknas. Uppdateringen måste göras i lakehouse där rollen skapades.
DDM-principen (dynamisk datamaskering) refererar till en borttagen eller omdöpt kolumn DDM stöds inte från OneLake-säkerhet; måste implementeras via SQL. Fel: Ogiltigt kolumnnamn <kolumnnamn> Uppdatera eller ta bort en eller flera berörda DDM-regler eller återställ kolumnen som saknas. Uppdatera DDM-principen i SQL-analysslutpunkten.
Systemfel (oväntat fel) Fel: Ett oväntat systemfel inträffade. Försök igen eller kontakta supporten. Fel: Ett internt fel uppstod när tabelländringar tillämpades på SQL. Försök utföra åtgärden igen. Kontakta Microsoft Support om problemet kvarstår. N/A
Användarens huvudnamn stöds inte Fel: Användarens huvudnamn stöds inte. Fel: Användarens huvudnamn stöds inte. Ta bort användaren {username} från rollen DefaultReader. Det här felet uppstår om användaren inte längre är en giltig Entra ID (till exempel om användaren lämnade organisationen eller togs bort). Ta bort dem från rollen för att lösa felet.

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.

Denna design bevarar säkerhetsintegriteten över sjöhusgränser samtidigt som behovet av att duplicera identitetstilldelningar mellan producent- och konsumentvaror minskas.

Delegerat läge i OneLake-säkerhet

I delegerat identitetsläge bevarar SQL-analysslutpunkten bakåtkompatibilitet med den traditionella SQL-säkerhetsmodellen. Du definierar och upprätthåller säkerhet på SQL-motorlagret, och OneLakes säkerhetsroller och åtkomstpolicyer överförs inte till tabellnivååtkomst. Du måste definiera all filtrering och åtkomstkontroll – inklusive åtkomst till scheman och tabeller, radnivåsäkerhet (RLS), kolumnnivåsäkerhet (CLS) och Dynamic Data Masking (DDM) – genom att använda SQL-konstruktioner (GRANT/REVOKE, säkerhetspolicyer 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 genom att använda objektägarens identitet, fungerar genvägar bara när ägaren har obegränsad åtkomst till hela källtabellen. Om källtabellen har någon OneLake-nivå säkerhetsregel applicerad – såsom radnivåsäkerhet (RLS) eller kolumnnivåsäkerhet (CLS) – blockerar SQL-analysändpunkten åtkomst till den 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.

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

Viktigt!

Växling mellan användaridentitet och delegerade lägen (i båda riktningarna) tar för närvarande bort infogade metadataobjekt, inklusive tabellvärdesfunktioner (TVF:er) och skalärvärdesfunktioner. Det här beteendet påverkar endast metadatadefinitioner. underliggande data i OneLake påverkas inte.

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

  • Kontrollplansberoende och effektiv identitetsutvärdering: Användare måste ha den nödvändiga Fabric-artefaktbehörigheten innan de kan ansluta till SQL-analysändpunkten. Dataauktorisation utvärderar sedan den inloggade användaren och användarens effektiva medlemskap i stödda Microsoft Entra-grupper mot OneLakes säkerhetspolicyer vid källan.

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

  • Design för säkerhet på kolumnnivå (CLS): CLS bygger på 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.

    Anmärkning

    I SQL-analysslutpunkten framtvingas OneLake-säkerhet för dataåtkomst, medan schemametadata fortsätter att följa SQL-motorns beteende. Användare kan se kolumner i Object Explorer eller sys.columns till och med när kolumnnivåsäkerhet hindrar dem från att läsa dessa kolumner. Det här beteendet är förväntat och avsiktligt.

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

  • Warehouse-SQL-säkerhet och genvägar: Säkerhetspolicyer som definieras med hjälp av SQL-konstruktioner i ett lager – såsom radnivåsäkerhet (RLS), kolumnnivåsäkerhet (CLS) eller objektnivåsäkerhet (OLS) – upprätthålls endast inom lagrets SQL-exekveringskontext (TDS-endpoint).

Viktigt!

När du får tillgång till data från ett lager via genvägar i OneLake översätts inte dessa SQL-säkerhetssemantiker till OneLakes säkerhetspolicyer. Som ett resultat kan användare som får tillgång till data via en genväg se hela lagredatan, oavsett vilka SQL-säkerhetspolicyer som är konfigurerade i producentlagret.

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 radnivåsäkerhet (RLS) konfigureras i användaridentitetsläge upprätthålls de definierade säkerhetsreglerna för alla användare, inklusive de som har rollerna Admin, Medlem och Bidragsgivare.

  • Schemasynlighet i objektmetadata: SQL-analysslutpunkten returnerar alltid alla schemanamn i objektmetadata, oavsett användarens behörigheter på tabellnivå. Tabeller där användaren inte har någon behörighet filtreras bort och visas inte i listan.

    • Därför kan användare se scheman som inte innehåller några synliga tabeller i objektutforskaren eller i INFORMATION_SCHEMA/sys katalogfrågor.

  • Säkerhetssynkroniseringsberoende: I användaridentitetsläge synkroniserar säkerhetssynkroniseringsprocessen OneLakes säkerhetsroller till SQL-analysändpunkten. Tills synkroniseringen är klar kan SQL tillfälligt utvärdera åtkomst genom att använda det befintliga SQL-behörighetstillståndet för alla tabeller, inklusive genvägstabeller från andra objekt. När synkroniseringen är klar speglar SQL-analysändpunkten OneLakes säkerhetskonfiguration.

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

  • Säkerhetsbegränsningar på radnivå (RLS):

    • Endast tabeller med ett uttryck stöds. Dynamisk RLS och RLS för flera tabeller ä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.

Relaterat innehåll

  • Last updated on