Krav, kvoter och begränsningar för principer för radfilter och kolumnmask

Note

Den här sidan beskriver krav, kvoter och begränsningar för principer för radfilter och kolumnmask. För GRANT policys, se ABAC-policysGRANT.

På den här sidan visas krav, principkvoter och aktuella begränsningar för ABAC-radfilter och kolumnmaskprinciper i Unity Catalog.

Beräkningskrav

Om du vill använda ABAC-principer måste du använda någon av följande beräkningskonfigurationer:

Information om hur du kör arbetsbelastningar som kräver äldre körningar finns i Åtkomst från äldre körningar.

Krav för reglerade taggar

ABAC-principer använder styrda taggar, inte okontrollerade taggar. Reglerade taggar definieras på kontonivå med åtkomstkontroller som avgör vem som kan skapa, tilldela och hantera dem. Fullständig information finns i Reglerade taggar.

Note

När du har tilldelat eller ändrat en tagg kan det ta några minuter innan ändringen börjar gälla.

Policykvoter

Resource Gräns
Policyer per metastore (alla objekt) 10 000
Policyer per metastore, bifogade direkt (Beta) 100
Policys per katalog 100
Policyer per schema 100
Principer per tabell 50
Huvudmän per policy (gäller för TO och EXCEPT klausuler) 20
Kolumnvillkor per MATCH COLUMNS klausul (radfilterpolicyer) 6
Kolumnvillkor per MATCH COLUMNS klausul (kolumnmaskpolicys) 3

Mer information, inklusive kvoter för reglerade taggar, finns i Tjänstgränser.

ABAC-begränsningar

Identitetsattribut i policyvillkor

Och has_identity_attribute_tag_match funktionerna has_identity_attribute_value utvärderar användarens identitetsattribut som kör frågan. De stöds i klausulen WHEN om kolumnmaskpolicys. Följande begränsningar gäller:

  • De stöds inte i klausulen MATCH COLUMNS om kolumnmaskregler.
  • De stöds inte i GRANT eller DENY policys.
  • Policyskapandegränssnittet i Catalog Explorer stöder inte attributfunktioner. Använd SQL för att skapa dessa policyer.

För användningsmönster, se Maskera en kolumn baserad på attribut hos den sökande användaren.

Åtkomst från äldre körningar

Standard och dedikerad beräkning på Databricks Runtime-versioner tidigare än 16.4 kan inte komma åt ABAC-skyddade tabeller. Om du behöver vissa arbetsbelastningar för att fortsätta köras på en äldre körning kan du omfångsbegränsa ABAC-principen till en specifik grupp i stället för att tillämpa den brett. Lägg bara till de användare eller huvudnamn som du vill att principen ska gälla för den gruppen och exkludera det huvudnamn som kör arbetsbelastningen äldre körning med hjälp av EXCEPT -satsen. Användare utanför gruppen behåller fullständig åtkomst till de underliggande tabellerna. Detta gör att arbetsbelastningen kan fortsätta att komma åt tabellerna medan du övergår till en körning som stöds.

ABAC:s policyer kring åsikter

Important

Att tillämpa ABAC-policyer på visningar är i beta. För att använda det måste en administratör för arbetsytan aktivera ABAC i Views preview från sidan Förhandsvisningar av arbetsområdet, och du måste använda Databricks Runtime 19 eller högre. Se Hantera förhandsversioner på arbetsytenivå.

Följande krav och begränsningar gäller för policyer om vyer:

  • Metrikvyer stöds inte: Du kan inte tillämpa ABAC-policyer på metrikvyer.
  • En enda fråga kan lägga på högst 20 policyer: En bastabell kan ha en policy, och varje vy som byggs ovanpå den kan ha sin egen policy. När en fråga läser igenom en vy gäller alla tillämpliga policyer på varje nivå i hierarkin. Om fler än 20 policys skulle gälla misslyckas frågan.
  • CREATE OR REPLACE VIEW Släpper styrda taggar och direkt kopplade policyer: Att ersätta en vy med en CREATE OR REPLACE sats rensar vyns metadata, tillsammans med dess styrda taggar och eventuella direkt kopplade policyer. För att bevara metadata, använd ALTER VIEW istället. Om du använder CREATE OR REPLACEdet, applicera de reglerade taggarna och policyerna igen efteråt.
  • Kolumner med reglerade taggar kan inte tas bort förrän taggarna har tagits bort: Precis som med bastabeller måste reglerade taggar tas bort från en vys kolumn innan den tas bort. Annars kan policyer som är beroende av taggen oavsiktligt försvinna.
  • ABAC-policyer kan inte appliceras på en delad vy på mottagarsidan: När du delar en vy via OpenSharing kan mottagaren inte tillämpa ABAC-policyer på den delade vyn. För att upprätthålla policyer på mottagarsidan, dela bastabellerna istället och låt mottagaren skapa mottagarlokala vyer över dem, med ABAC-policyer på de delade tabellerna. Se Mottagarlokala vyer över delade tabeller.

ABAC-principer för materialiserade vyer och strömmande tabeller

När en pipeline uppdaterar en materialiserad vy eller streamingtabell utvärderar den policyer med pipelineägarens eller run-as-identitet. Om den identiteten omfattas av en ABAC-policy innehåller den materialiserade vyn eller strömningstabellen permanent maskerad eller filtrerad data. För att undvika detta, lägg till pipeline-ägaren eller kör-som-identiteten i EXCEPT klausulen av ABAC-policyer som är kopplade till alla tabeller som läses under pipelineuppdateringen. TO Använd -satsen för att ange vilka användare och grupper som ska ta emot maskerade eller filtrerade data.

ÖppnaSharing-tabeller med ABAC-principer eller vyer som refererar till dem

Tabeller med ABAC-principer eller vyer som refererar till tabeller med ABAC-principer kan bara delas via OpenSharing om resursägaren är undantagen från principen (anges i EXCEPT satsen). Principen styr inte mottagarens åtkomst. Mottagarna kan tillämpa sina egna ABAC-principer på delade tabeller för att framtvinga åtkomstkontroll på sin sida.

Mer information om hur du använder OpenSharing med ABAC finns i OpenSharing och ABAC.

Kloning av tabeller med ABAC-policys

Djupa och grunda kloner stöds inte på tabeller med ABAC-policys. För att klona en tabell, använd en tjänsteprincip eller grupp som finns listad i EXCEPT klausulen i varje policy som gäller för tabellen.

Important

Undantagna huvudnamn ser ofiltrerade, omaskerade data. Undanta endast betrodda identiteter, till exempel tjänsthuvudnamn som används för ETL- eller pipelinearbetsbelastningar.

Till exempel maskerar följande policy PII-kolumner för alla användare utom etl_service_principal, som kan klona tabellen:

CREATE POLICY mask_pii
ON CATALOG prod
COLUMN MASK prod.governance.mask_value
TO `account users`
EXCEPT `etl_service_principal`
FOR TABLES
MATCH COLUMNS
  has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn;

AI Search-index och ABAC-principer

ABAC-principer i en källtabell gäller inte för AI Search-index som skapats från den tabellen. Indexet synkroniserar alla rader från källtabellen och tillämpar inte principer för radfilter eller kolumnmask när frågor skickas.

För tabeller med kolumnmasker kan du exkludera maskerade kolumner från indexet med hjälp av inställningen kolumner för synkronisering .

Flera principer i samma tabell eller kolumn för samma användare

Endast ett distinkt radfilter kan matchas vid körning för en viss tabell och en viss användare, och endast en distinkt kolumnmask kan matchas för en viss kolumn och en viss användare. Du kan definiera flera principer, men när en användare frågar tabellen måste endast en princips villkor matcha. Om flera distinkta radfilter eller kolumnmasker gäller för samma användare och tabell eller kolumn blockerar Azure Databricks åtkomst och returnerar ett fel. Flera principer tillåts om de matchar samma radfilter eller kolumnmask UDF med samma argument.

För detaljer, se Konflikterande filter och masker.

ABAC på dedikerad beräkning

Begränsningar för ABAC för dedikerad beräkning finns i Begränsningar.

Begränsningar som är gemensamma för ABAC och radfilter på tabellnivå och kolumnmasker

Allmänna begränsningar för radfilter och kolumnmasker som gäller för både ABAC - och radfilter på tabellnivå och kolumnmasker finns i Begränsningar.

  • Uppdaterades senast