Policyevaluering och körningstidsbeteende

Den här sidan förklarar hur ABAC-principer utvärderas vid frågetillfället, inklusive:

• Så här hanteras konflikter mellan flera principer
• Så här fungerar kolumnmasktypsgjutning
• Vilka skyddsåtgärder förhindrar dataexponering när taggar eller funktioner som en princip är beroende av tas bort

Utvärdering och tillämpning av principer

När en användare frågar en tabell fortsätter ABAC-utvärderingen i två steg: principutvärdering i Unity Catalog och principframtvingande i Databricks Runtime.

Olika användare kan se olika resultat från samma fråga eftersom principutvärderingen beror på användarens identitet, gruppmedlemskap och taggarna på de data de kommer åt. Ändringar av gruppmedlemskap eller taggtilldelningar ändrar dynamiskt gällande principer vid frågetillfället.

Principutvärdering (Unity Catalog)

Unity Catalog utför följande steg med hjälp av skyddsbara metadata (t.ex. reglerade taggtilldelningar) och frågeanvändarens identitets- och gruppmedlemskap:

1. Identifierar alla principer vars omfång täcker den efterfrågade tabellen.
2. För var och en av dessa principer kontrollerar du om den frågande användaren finns i TO listan och inte i EXCEPT listan.
3. För varje princip utvärderas tabell- och kolumnvillkor mot taggarna på det efterfrågade objektet, inklusive ärvda taggar. Kolumnvillkor måste matcha minst en kolumn.
4. Om principen gäller avgör du det effektiva radfiltret eller kolumnmasken och skickar den till Databricks Runtime som en del av tabellmetadata.

Policyns tillämpning (Databricks Runtime)

Databricks Runtime-frågeplaneraren översätter det effektiva radfiltret eller kolumnmasken till en säker vy ovanpå tabellskanningarna som framtvingar filtrering och maskering under frågeexekveringen. Det här är samma tvingande mekanism som används för radfilter på tabellnivå och kolumnmasker.

Design som inte har stängts

ABAC följer en modell som inte är stängd, där Azure Databricks som standard nekar åtkomst om den inte kan verifiera säkerheten. Azure Databricks tillåter endast åtkomst till ABAC-skyddade tabeller när det på ett säkert sätt kan framtvinga alla tillämpliga principer. Detta gäller för beräkningsversioner som inte stöds, specifika åtgärder för underliggande tabelldata och situationer där en princips beroenden (taggar eller funktioner) har tagits bort.

Beräkningsversioner som inte stöds

ABAC-principer kräver Databricks Runtime 16.4 eller senare eller serverlös beräkning. Om en användare försöker komma åt en ABAC-skyddad tabell från en version som inte stöds misslyckas frågan (åtkomst nekas) för att förhindra oskyddad dataexponering.

I dedicerat åtkomstläge delegerar Azure Databricks verkställighet till serverlös beräkning för att garantera att detaljerade åtkomstkontroller tillämpas. Om du vill tillåta användare på äldre körtider att komma åt dessa tabeller måste du uttryckligen undanta dem från policys.

Åtgärder som inte stöds på skyddade data

Vissa åtgärder är inte kompatibla med radfilter eller kolumnmasker. Dessa operationer misslyckas i stället för att kringgå regleringen. För att köra dem måste huvudkontot anges i satsen för EXCEPT varje ABAC-princip som gäller för tabellen. Undantagna huvudprincipaler omfattas inte av policyn, så Azure Databricks behöver inte tillämpa den och kan tryggt tillåta åtgärden.

Åtgärder som kräver undantag för den verkställande huvudprincipalen inkluderar uppdateringar av pipeline, säkerhetskopieringsprocesser och administrativa arbetsflöden, till exempel följande:

• Åtkomst till ABAC-skyddade tabeller från datorer som kör Databricks Runtime-versioner under 16.4
• Frågor om tidsresor
• Djup och ytlig kloning
• Deltadelning, där resursägaren måste undantas från principen och ha nödvändiga deltadelningsbehörigheter. Observera att principen inte styr mottagarens åtkomst.
• Skapa och synkronisera vektorsökningsindex

Mer information om dessa och andra begränsningar finns i ABAC-krav, kvoter och begränsningar.

Principberoenden har tagits bort

ABAC-principer är beroende av reglerade taggar och UDF:er. Om något av dessa beroenden tas bort medan en princip fortfarande refererar till dem, misslyckas förfrågningar mot tabeller inom principens omfång.

Borttagning av styrd tagg

Om du tar bort en styrd tagg som en ABAC-princip refererar till misslyckas alla frågor mot objektet där principen är kopplad och dess underordnade objekt med ett INVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICY fel. Detta inträffar även om taggen inte tillämpades på de efterfrågade tabellerna.

När en styrd tagg tas bort blir den en okontrollerad tagg. De tillåtna värdebegränsningarna tas bort och alla med APPLY TAG kan ändra värden utan ASSIGN behörighet.

Lös felet genom att antingen återställa den borttagna taggen eller uppdatera eller ta bort principen som refererar till den. Se Skapa och hantera reglerade taggar.

Ta bort en kolumn som är taggad

Azure Databricks förhindrar att en kolumn som har en styrd tagg tas bort. Om du vill släppa kolumnen måste en användare med ASSIGN på taggen och APPLY TAG på objektet först ta bort taggen och sedan kan kolumnen tas bort.

Detta är relevant för deklarativa pipelines och andra automatiserade arbetsflöden som ändrar tabellscheman. Om en pipeline försöker släppa en taggad kolumn misslyckas åtgärden. Om du vill avblockera pipelinen måste en användare med nödvändiga taggbehörigheter ta bort taggen, köra pipelinen så att schemaändringen lyckas och sedan tillämpa taggen på de relevanta kolumnerna igen. Om taggen inte tillämpas igen kommer förfrågningar mot databasen att misslyckas eftersom policyn fortfarande omfattas men den förväntade taggen inte längre finns på objektet.

Principreferenserad funktionsborttagning

Om en UDF som refereras till av en princip tas bort medan principen fortfarande finns i omfånget misslyckas frågor mot tabeller i det omfånget med UC_DEPENDENCY_DOES_NOT_EXIST. Lös problemet genom att antingen återställa funktionen eller uppdatera principen för att referera till en annan UDF.

Regler för flera filter och masker

Endast ett distinkt radfilter kan tillämpas vid frågetillfället för en viss tabell och användare. På samma sätt kan endast en distinkt kolumnmask per kolumn lösas vid körning för en viss kolumn och användare. Detta förhindrar tvetydiga resultat.

Om flera distinkta filter eller masker gäller för samma användare och tabell (eller kolumn) blockerar Azure Databricks åtkomst och returnerar ett fel. Som exempel:

• Ett filter eller mask på tabellnivå står i konflikt med en ABAC-princip. En tabell eller kolumn som redan har ett manuellt tillämpat radfilter eller en kolumnmask står i konflikt med alla ABAC-definierade filter eller masker på samma mål.
• Ett radfilters sats USING COLUMNS refererar till ett MATCH COLUMNS alias som matchar flera kolumner. Satsen USING COLUMNS skickar kolumnvärden till UDF. Om ett MATCH COLUMNS alias i USING COLUMNS -satsen matchar mer än en kolumn kan motorn inte avgöra vilken kolumn som ska skickas till UDF och frågan misslyckas med ett fel.
• En maskerad kolumn refereras till i USING COLUMNS klausulen i en annan policy. Om en kolumn maskeras av en princip kan den inte användas som indataargument i satsen för USING COLUMNS en annan princip.

Flera ABAC-principer kan samexistera för samma tabell eller kolumn om de resulterar i samma effektiva filter eller mask. Till exempel, två policyer som refererar till samma UDF med samma argument resulterar i samma filter eller mask och är inte i konflikt.

Felsöka principkonflikter

När Azure Databricks identifierar flera distinkta filter eller masker under principutvärderingen för en viss användare returnerar ett fel INVALID_PARAMETER_VALUE.UC_ABAC_MULTIPLE_ROW_FILTERS eller COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS och blockerar åtkomsten till tabellen tills konflikten har lösts.

Så här diagnostiserar du och löser:

1. Använd SHOW EFFECTIVE POLICIES för att se alla principer som gäller för tabellen.
2. Kontrollera INFORMATION_SCHEMA.ROW_FILTERS och INFORMATION_SCHEMA.COLUMN_MASKS identifiera eventuella radfilter på tabellnivå eller kolumnmasker som kan vara i konflikt.
3. Kontrollera vilka principer som överlappar i sina TO/EXCEPT principaler och WHEN/MATCH COLUMNS villkor.
4. Lös med:
   • Förfina principvillkor. Uppdatera WHEN eller MATCH COLUMNS satser för att vara mer specifika så att distinkta principer riktar sig mot olika tabeller eller kolumner.
   • Justera reglerade taggar. Granska taggtilldelningar för kolumner eller tabeller som utlöser oönskade principmatchningar och ta bort eller uppdatera dem.
   • Justera huvudkomponenter. Uppdatera TO/EXCEPT satser så att varje användare omfattas av högst en princip per tabell (för radfilter) eller per kolumn (för kolumnmasker).
   • Omstruktureringspolicyer. Konsolidera överlappande principer i en enda princip eller dela upp breda principer i separata, uttryckligen riktade principer.

Automatisk typgjutning för kolumnmasker

Azure Databricks konverterar automatiskt både indata och utdata för kolumnmaskfunktioner som löses från ABAC-principer. Värdet för indatakolumnen är gjutet för att matcha maskfunktionens parametertyp, och funktionsutdata skickas för att matcha målkolumnens datatyp. Detta säkerställer typkonsekvens och tillförlitligt frågebeteende vid maskering av kolumner. Automatisk gjutning fungerar på följande sätt:

1. Maskeringsfunktionskörning: När principutvärderingen fastställer att maskering gäller körs maskeringsfunktionen på matchande kolumnvärden.
2. Automatisk typgjutning: Azure Databricks omvandlar indatakolumnvärdet så att det matchar funktionens parametertyp och omvandlar funktionsutdata så att det matchar målkolumnens datatyp.
3. Resultatretur: Det korrekt inskrivna resultatet returneras till frågan.

Om indata- eller utdatatyperna inte är kompatibla misslyckas casten och frågan returnerar ett körningsfel. Casting följer ANSI SQL-standarder för CAST åtgärder (fullständig kompatibilitetsinformation), med ett tillägg: på Databricks Runtime 18.1 och senare kan ABAC-kolumnmaskprinciper omvandla structs till VARIANT, vilket inte stöds i allmänt SQL.

Du måste se till att maskfunktioner returnerar typer som är kompatibla med målkolumner. Se Cast-kompatibla maskeringsfunktioner för exempel och VARIANT-metoden för flexibel maskering mellan kolumntyper.