Grundläggande begrepp för attributbaserad åtkomstkontroll (ABAC)

Attributbaserad åtkomstkontroll (ABAC) är en åtkomstkontrollmodell som använder styrda taggar och principer för att bevilja behörigheter baserat på objektattribut i stället för bidrag per objekt. Den här sidan definierar byggstenarna: styrda taggar, de tre ABAC-principtyperna (radfilter, kolumnmask och GRANT principer), de behörigheter som krävs för att konfigurera dem och uppdelningen av uppgifter som ABAC möjliggör mellan team.

Se Attributbaserad åtkomstkontroll i Unity Catalog för en översikt över alla ABAC-ämnen, inklusive självstudier, principhantering, metodtips och begränsningar.

Vad är ABAC?

Attributbaserad åtkomstkontroll (ABAC) är en modell för dynamisk åtkomstkontroll där åtkomstbeslut baseras på principer som utvärderas mot attribut som är associerade med skyddsbara objekt. I Unity Catalog representeras dessa attribut via reglerade taggar. Dessa reglerade taggar används i principvillkor för att matcha dataobjekt inom ett visst omfång, till exempel en katalog eller ett schema. På så sätt kan en enskild princip tillämpas automatiskt på flera dataobjekt som uppfyller dess villkor.

En ABAC-princip kan till exempel maskera alla kolumner som är taggade PII för tabeller i scheman som är taggade HR. När nya dataobjekt skapas och taggas tillämpas principen automatiskt utan att det krävs separata principdefinitioner för varje objekt.

ABAC stöder säkerhet på rad- och kolumnnivå via radfilterprinciper och kolumnmaskprinciper för tabeller, materialiserade vyer och strömmande tabeller. Radfilterprinciper begränsar vilka rader en användare kan se. Kolumnmaskprinciper styr hur kolumnvärden visas för användare. En jämförelse med radfilter och kolumnmasker på tabellnivå finns i När du ska använda ABAC jämfört med radfilter på tabellnivå och kolumnmasker.

ABAC stödjer också dynamiska privilegiebeviljanden genom GRANT policyer på stödda säkerhetsbara typer. Se ABAC:s GRANT policys.

Reglerade taggar

I Unity Catalog implementeras attribut som reglerade taggar. Reglerade taggar är nyckel/värde-par som definierats på kontonivå och tillämpas på skyddsbara objekt i Unity Catalog, till exempel kataloger, scheman, tabeller, kolumner, modeller och volymer, utöver arbetsyteobjekt. De representerar egenskaper som känslighet, klassificering eller affärsdomän.

Som standard ärver skyddsbara objekt taggar från den överordnade katalogen eller schemat. Du kan åsidosätta ärvda taggar på alla nivåer förutom kolumnnivån: kolumntaggar ärver inte från den överordnade tabellen och måste tillämpas direkt.

Reglerade taggar kan refereras i principvillkor med hjälp av inbyggda funktioner som has_tag() och has_tag_value(), som kontrollerar om en viss tagg finns på måldataobjektet, antingen direkt eller via taggarv.

Reglerade taggar definieras på kontonivå. Det innebär att du kan använda samma taggtaxonomi i hela dataegendomen i ett konto, inklusive i flera metaarkiv.

Mer information finns i Reglerade taggar och Tillämpa taggar på skyddsbara objekt i Unity Catalog.

Policies

Principer är kopplade till skyddsbara objekt i Unity Catalog för att definiera åtkomstkontrollregler baserat på taggvillkor. Nedan visas ett exempel:

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
    RETURN '***';

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

Varje princip anger:

• Omfattning: Det säkringsbara objekt som policyn är kopplad till, vilket anges av satsen ON. Att koppla en princip till ett skyddsbart objekt innebär att principvillkoren utvärderas för alla objekt av den typ som anges i FOR -satsen, över objektet och alla dess underordnade objekt.
  • För policyer för radfiltrering och kolumnmaskering stöds policyomfattningarna CATALOG, SCHEMA eller TABLE. För GRANT-policyer är policyomfattningarna som stöds CATALOG och SCHEMA.
  • Tabeller, inklusive strömningstabeller och materialiserade vyer, är den enda stödda säkerhetstypen för radfilter- och kolumnmaskpolicyer, specificerade med hjälp av klausulen FOR TABLES . GRANT policyer gäller för modeller, modelltjänster, modellleverantörstjänster, MCP-tjänster och agenttjänster, och använd klausulen GRANT <privilege> FOR <securable_type> . För den fullständiga listan över säkerställbara typer som stöds och privilegier, se Säkerställbara typer som stöds och privilegier.
  • En policy kopplad till en katalog utvärderar mot alla securables av den typ som anges i klausulen FOR inom katalogen. En princip som är kopplad till ett schema utvärderas mot alla skyddsbara objekt av den typen i schemat. En princip som är kopplad till en tabell utvärderas endast mot den tabellen.

• Principaler: Vem policyn gäller för och vem som är undantagen. Satsen TO anger vilka användare, grupper eller tjänsthuvudnamn som omfattas av principen. Den valfria EXCEPT satsen exkluderar specifika principer från den här policyn.
• Åtgärder: Om principen tillämpar ett radfilter, en kolumnmask eller ett behörighetsbidrag. Principer för radfilter och kolumnmask använder en användardefinierad funktion (UDF) för att implementera logiken för filtrering eller maskering. GRANT policyer använder inte UDF:er. Se Principtyper.
• Villkor: Taggbaserade uttryck som avgör vilka tabeller eller kolumner som principmålen ska vara. Se Villkor och inbyggda funktioner.

Principer skapas och hanteras via användargränssnittet eller programmatiskt med SQL-instruktioner, till exempel CREATE POLICY, DROP POLICY, SHOW POLICIESeller DESCRIBE POLICY, REST-API:er, Databricks SDK:er eller Terraform. Se Skapa och hantera ABAC-principer för fullständig syntax och exempel.

Policytyper

ABAC stöder tre policytyper: radfilterpolicyer, kolumnmaskpolicyer och GRANT policyer. Principer för radfilter och kolumnmask kräver UDF:er för att implementera logiken för filtrering eller maskering. GRANT principer använder inte UDF:er och beviljar i stället behörigheter när deras taggbaserade villkor matchar målobjektets attribut.

Principer för radfilter

Radfilterprinciper begränsar vilka rader en användare kan se i en tabell baserat på värden i kolumner som identifieras av taggar som matchar villkor och inbyggda funktioner. Principen refererar till en UDF som utvärderar varje rad. Rader där funktionen returnerar FALSE undantas från frågeresultat. Argument skickas till UDF via USING COLUMNS -satsen.

Exempel på användningsfall: För en försäljningskatalog kontrollerar du att EMEA-teamet endast ser EMEA-försäljningsposter i alla tabeller som har en kolumn taggad region.

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

Principer för kolumnmaskering

Kolumnmaskprinciper styr vilka värden en användare ser för specifika kolumner som identifieras av taggar som matchar villkor och inbyggda funktioner. Principen refererar till en UDF som tar kolumnvärdet som indata och returnerar det ursprungliga värdet eller en maskerad version. Det maskerade kolumnvärdet binds automatiskt som det första argumentet från ON COLUMN -satsen, och ytterligare argument kan skickas via USING COLUMNS. Returtypen måste matcha eller kan typomvandlas till kolumnens datatyp.

Exempel på användningsfall: Maskera SSN-kolumner taggade med pii : ssn så att användarna ser ***-**-XXXX (endast de fyra sista siffrorna) om de inte finns i en efterlevnadsgrupp som är undantagen från principen.

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

Satsen USING COLUMNS skickar argument till UDF. Den accepterar alias för kolumner som matchar ett taggbaserat uttryck eller konstanta värden (citerade strängar, numeriska literaler, booleska värden (TRUE/FALSE) eller NULL), som anges i den ordning som funktionen förväntar sig dem. Den accepterar även taggens introspektionsfunktioner, som extraherar en taggs värde vid frågetillfället och skickar det till UDF. För kolumnmaskprinciper är dessa ytterligare argument utanför den maskerade kolumnen (som automatiskt binds från ON COLUMN). Detta gör att en enda UDF kan återanvändas mellan principer med olika parametrar.

SQL UDF:er rekommenderas för bättre prestanda. Python UDF:er som registrerats i Unity Catalog stöds också, men frågeoptimeraren kan inte infoga eller optimera dem på det sätt som sql-UDF:er kan användas. Se Prestandaöverväganden för vägledning om val av UDF-språk.

GRANT Politik

GRANT principer beviljar dynamiskt en Unity Catalog-behörighet när deras taggbaserade villkor matchar ett skyddsbart objekts taggar. Varje gång en användare försöker komma åt ett skyddsbart objekt identifierar Unity Catalog alla GRANT principer vars omfång täcker objektet, kontrollerar om användaren finns i TO listan och inte i EXCEPT listan och utvärderar principens WHEN villkor mot taggarna på skyddsbara, inklusive ärvda taggar. Om principen gäller beviljar Unity Catalog behörigheten. GRANT principer använder samma utvärderingsmodell som radfilter- och kolumnmaskprinciper, förutom att de inte använder UDF:er. Villkoret uttrycks direkt i policydefinitionen.

De effektiva privilegierna för ett objekt är en union av direkta bidrag och eventuella tillämpliga GRANT principer. Ett säkerhetsobjekt har behörigheten om en GRANT policy inom omfånget gäller för det säkerhetsobjektet eller om en direkt GRANT tilldelning av samma behörighet gäller. GRANT principer lägger bara till åtkomst. De kan inte återkalla åtkomst som beviljats direkt.

Villkor och inbyggda funktioner

Villkor är taggbaserade uttryck som avgör vilka tabeller och kolumner som en princip har som mål inom dess omfång.

• Tabellvillkor (WHEN sats): Booleska uttryck som matchar tabeller baserat på deras taggar. Om det utelämnas används standardvärdet TRUE, vilket innebär att principen gäller för alla tabeller i omfånget.
• Kolumnvillkor (MATCH COLUMNS sats): Ett eller flera kommaavgränsade booleska uttryck som identifierar vilka kolumner som principmålen är. Varje uttryck kan vara en enda inbyggd funktion som has_tag('pii'), eller en kombination med logiska operatorer som has_tag_value('pii', 'ssn') AND has_tag('sensitive'). Varje uttryck kan tilldelas ett alias (som anges efter AS) som refereras i ON COLUMN och USING COLUMNS-satserna. En princip kan innehålla upp till 3 kolumnuttryck och alla måste matcha för att principen ska gälla.

Båda satstyperna använder följande inbyggda funktioner som utvärderas av Unity Catalog mot säkra metadata:

För att matcha på attributen hos användaren som kör frågan istället för på resurstaggar, se Identitetsattributfunktioner.

För att matcha på kontexten för en förfrågan, såsom den anropande applikationen, se Context-attributfunktioner.

Taggar sprids inte från tabeller till kolumner. Att använda has_tag() i en MATCH COLUMNS villkor matchar bara taggar på kolumnnivå, inte taggar på föräldertabellen eller dess föregångare.

Exempel: använda två kolumnvillkor. Ett customers schema har tabeller med en e-postkolumn taggad pii : email och en medgivandekolumn taggad consent_to_contact. Principen maskerar e-postadresser om inte kunden har samtyckt till att bli kontaktad. Den använder två kolumnvillkor:

1. has_tag_value('pii', 'email') identifierar kolumnen som innehåller e-postadresser (kolumnen som ska maskeras).
2. has_tag('consent_to_contact') identifierar kolumnen som innehåller medgivandeinformation (som används av UDF för att avgöra om den ska maskeras).

CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

Den här principen gäller endast för tabeller som har både en kolumn taggad pii : email och en kolumn taggad consent_to_contact. Om en tabell inte har kolumner som matchar båda villkoren gäller inte principen och data returneras avmaskerade.

Identitetsattributfunktioner (Beta)

Identitetsattributfunktioner utvärderar egenskaper hos användaren som kör frågan, såsom avdelning, land eller jobbroll. Dessa attribut kan tillhandahållas från din identitetsleverantör och refereras direkt i policyvillkoren. Detta låter dig uttrycka mer flexibla villkor utan att skapa separata grupper för varje kombination av identitetsegenskaper. När identitetsinformation ändras i din identitetsleverantör använder policyer de uppdaterade attributvärdena, precis som de använder uppdaterat gruppmedlemskap.

Dessa funktioner stöds i WHEN-klausulen för kolumnmaskeringspolicyer.

Tänk på följande beteende när du skriver policyer som använder dem:

• Ett saknat attribut resulterar i false. Om användaren inte har något värde för attributet, inte har några attribut alls, eller om attributet inte existerar, returnerar false funktionen istället för att ge ett fel. Formulera villkoren så att det här false resultatet begränsar åtkomst. Se Identitetsattributvillkor.
• Attributnycklar och värden är kasuskänsliga och jämförs exakt: Finance och finance matchar inte.
• Attributändringar är inte omedelbara. Ändringar i din identitetsleverantör synkas inte omedelbart till Azure Databricks. Se identitetsattribut för mer information.

För vilka attribut Azure Databricks stöder och hur de provisioneras, se identitetsattribut. För exempel på hur man använder identitetsattribut i policyer, se Mask en kolumn baserad på attribut från den sökande användaren.

Kontextattributfunktioner (Beta)

Kontextattribut används för att begränsa dataåtkomst för förfrågningar som görs på användarens vägnar via en OAuth-applikation. Denna uppsättning kan användas för att begränsa agenter från att komma åt data när de agerar på en användares vägnar, samtidigt som samma data hålls tillgänglig om användaren frågar direkt i arbetsytan.

Den täcker alla OAuth-applikationer, oavsett om det är en inbyggd app som Azure Databricks CLI eller en anpassad OAuth-app. Det finns två olika kontextattribut:

• request.is_on_behalf_of: strängen 'true' eller 'false'. Indikerar om förfrågan utförs för en användares räkning via en OAuth-app. Varje förfrågan från en OAuth-app har detta värde satt till 'true'.
• request.client_id: OAuth-klient-ID:t. Detta kan användas för att rikta in sig på en specifik OAuth-klient, antingen en inbyggd OAuth-app (till exempel databricks-cli) eller en anpassad OAuth-app. client_id kan visas på sidan Appanslutningar i kontokonsolen. För Databricks Apps kan det också observeras på appens sida för auktorisationsdetaljer , under OAuth2 App Client ID. Eller så kan den efterfrågas från identity_metadata.acting_resource fältet i revisionsloggarna.

Dessa attribut kan inte ändras av användaren och tillhandahålls uttryckligen av systemet; En uppringare påverkar dem endast genom hur de autentiserar. Dessa attribut kan användas för att identifiera externa agenter, inte Genie-agenter.

Kontextattribut kan användas genom följande funktioner:

Attributnycklar är inte skiftlägeskänsliga, och värden är skiftlägeskänsliga.

För att lära dig hur man använder dessa kontextattribut för att kontrollera åtkomst från externa agenter, se Begränsa åtkomst för externa agenter som agerar på uppdrag av en användare.

Användardefinierade funktioner (UDF:er)

Principer för radfilter och kolumnmask använder användardefinierade funktioner (UDF: er) för att implementera filtrerings- eller maskeringslogik. Se SQL och Python användardefinierade funktioner (UDF: er) i Unity Catalog för att se hur du skapar och hanterar UDF:er och Vanliga mönster för radfiltrering och kolumnmaskering, till exempel.

Introspektionsfunktioner för taggar

Taggintrospektionsfunktioner extraherar värdet av en styrd tagg och vidarebefordrar det till en UDF via USING COLUMNS-satsen. Eftersom UDF tar emot taggvärdet som ett argument kan en enskild princip och UDF hantera flera taggvärden i stället för att kräva en separat princip för varje taggvärde. Dessa funktioner är endast tillgängliga för principer för radfilter och kolumnmask eftersom GRANT principer inte använder UDF:er.

För att skapa en princip som använder dessa funktioner krävs Databricks Runtime 18 LTS eller senare. Det här kravet gäller endast vid skapande av policyer, inte för att köra frågor mot de reglerade tabellerna.

Vid frågetillfället utvärderar Unity Catalog dessa funktioner mot taggarna i tabellen eller kolumnerna som principen matchar: get_tag_value() läser från tabellen som uppfyller villkoret WHEN och get_column_tag_value() läser från kolumnerna som identifieras av MATCH COLUMNS. De kan bara visas i USING COLUMNS -satsen, inte i WHEN eller MATCH COLUMNS villkor.

Båda funktionerna tar taggnyckeln som en strängliteral. Taggen måste vara en styrd tagg och get_column_tag_value() måste referera till ett alias som finns i principens -sats MATCH COLUMNS . Om taggen inte styrs eller om aliaset inte är giltigt misslyckas principskapandet. Om en refererad tagg inte längre omfattas av styrning när en fråga körs, misslyckas frågor mot principens måltabeller under körning.

Exempel: En princip för alla PII-typer

Utan tagginspektion krävs det en separat princip och UDF för varje taggvärde för att maskera varje typ av personidentifierande information (e-post, SSN, telefon). Med get_column_tag_value()skickar en enskild princip den matchade kolumnens pii taggvärde till en UDF. UDF:en förgrenar sig beroende på det värdet:

CREATE FUNCTION mask_pii(col STRING, pii_type STRING)
RETURNS STRING
RETURN CASE
  WHEN pii_type = 'email' THEN regexp_replace(col, '(^[^@]+)', '***')
  WHEN pii_type = 'ssn' THEN '***-**-' || right(col, 4)
  WHEN pii_type = 'phone' THEN '***-***-' || right(col, 4)
  ELSE col
END;

CREATE POLICY mask_all_pii
ON CATALOG main
COLUMN MASK mask_pii
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS col
ON COLUMN col
USING COLUMNS (get_column_tag_value(col, 'pii'));

För varje maskerad kolumn get_column_tag_value(col, 'pii') matchar den kolumnens pii taggvärde (email, ssn, phone, osv.) och mask_pii tillämpar matchande transformering. Ett nytt taggvärde kräver bara en ny gren i UDF, inte en ny princip.

Uppdelning av uppgifter och behörigheter

Att konfigurera ABAC omfattar flera steg, var och en med sina egna behörighetskrav. Organisationer kan distribuera dessa uppgifter mellan specialiserade grupper beroende på hur de väljer att separera uppgifter. En organisation kan till exempel definiera en taggtaxonomi centralt, sedan låta dataförvaltare klassificera data, styrningsadministratörer skriva principer, skapa dataskapare objekt inom reglerade omfång och datakonsumenter få åtkomst till de reglerade objekten.

1. Skapa taggtaxonomi. Definiera de reglerade taggnycklarna och deras tillåtna värden innan någon tillämpar dem eller skriver principer. Skapa till exempel en sensitivity tagg med kontrollerade värden (public, , internalconfidential, restricted) eller en pii tagg med värden som ssn, emailoch phone_number. Se Standardisera attribut och namngivning för rekommendationer om namngivningskonventioner och taxonomidesign.

   • Nödvändiga behörigheter: Kontoadministratör eller en användare med CREATE behörighet för taggar på kontonivå.

2. Tagga datatillgångar. Ett dataförvaltare, dataskapare eller AI-klassificeringssystem tillämpar reglerade taggar på skyddsbara objekt i Unity Catalog, till exempel kataloger, scheman, tabeller, kolumner, modeller och volymer. Tagga till exempel kolumner som innehåller personligt identifierbar information med pii : ssneller tagga en modell med lifecycle : production. Korrekt taggning är det viktigaste första steget för att ABAC-principer ska tillämpas.

   • Nödvändiga behörigheter: ASSIGN på taggen och APPLY TAG på objektet.

3. Skapa en policy. En styrningsadministratör skapar en policy i ett omfång, till exempel en katalog eller ett schema. Principen anger vem den gäller för, vilka villkor den utvärderar och vilken åtgärd som ska tillämpas, till exempel ett radfilter, en kolumnmask eller ett behörighetsbidrag.

   • Nödvändiga behörigheter: MANAGE behörighet eller objektägarskap för det skyddsbara objekt som principen är associerad med. För principer för radfilter och kolumnmaskering krävs även EXECUTE behörighet för UDF.

4. Skapa dataobjekt. Dataskapare skapar skyddsbara objekt som tabeller, modeller eller volymer inom de omfång som de har beviljats åtkomst till. Nya objekt ärver taggar från överordnade kataloger och scheman. Dataskapare har APPLY TAG också automatiskt på objekt som de skapar, så att de kan använda ytterligare taggar. De kan också förlita sig på automatisk dataklassificering för att hantera taggning. Om en organisation förlitar sig på att dataskapare ska tagga sina egna objekt bör den upprätta tydliga taggningsmetoder. Dataskapare behöver inte konfigurera några åtkomstkontroller om principer anges på högre nivåer, vilket Azure Databricks rekommenderar.

   • Nödvändiga behörigheter: CREATE TABLE eller andra relevanta skaparbehörigheter på det överordnade objektet.

5. Åtkomst till reglerade objekt. När en användare försöker komma åt ett skyddsbart objekt inom en princips omfång utvärderar Unity Catalog tillämpliga principer automatiskt. För principer för radfilter och kolumnmask ser användaren filtrerade eller maskerade data om tabellen eller kolumnerna matchar principens villkor och användaren inte är undantagen. För GRANT policyer får användaren den beviljade privilegien om villkoren stämmer överens och användaren är i TO och inte i EXCEPT.

   • Nödvändiga behörigheter: För principer för radfilter och kolumnmasker måste användarna beviljas behörigheter i tabellen, till exempel SELECT, via ett direkt objektbidrag. Dessa policyer filtrerar poster eller maskerar kolumner i tabeller som användaren redan har åtkomst till. De beviljar inte behörigheter på egen hand. GRANT Policyer ger själva privilegiet och förening med eventuella direkta bidrag på samma sekurerbara konto.

Fördelar med ABAC

• Återanvändbara principer baserat på attribut: En enskild princip kan tillämpas på flera dataobjekt som matchar samma attributbaserade villkor i stället för att vara knutna till ett specifikt objekt.

• Automatiskt program till nya objekt: När nya dataobjekt skapas inom omfånget och taggas med relevanta attribut gäller befintliga ABAC-principer utan ytterligare konfiguration. Principer fungerar som framtida bidrag, vilket innebär att åtkomstkontroller tillämpas automatiskt när nya data skapas och taggas på lämpligt sätt.

• Konsekvent tillämpning inom ett omfång: Principer som är kopplade på katalog- eller schemanivå utvärderas dynamiskt mot matchande dataobjekt i det omfånget, vilket tar bort skillnader i hur liknande data filtreras eller maskeras.

• Lägre löpande underhåll: Ändringar kan göras genom att uppdatera principlogik eller styrda taggar, i stället för att gå tillbaka till varje enskilt objekt som krävs med radfilter på tabellnivå och kolumnmasker.

• Centraliserad styrning: Eftersom principer kan definieras en gång och tillämpas på många matchande dataobjekt kan styrningsteam hantera kontroller över större delar av dataegendomen med färre principdefinitioner.

Ytterligare resurser

• Styrda taggar
• SKAPA PRINCIP
• Hantera behörigheter i Unity Catalog
• Radfilter och kolumnmasker
• Tabellreferens för granskningsloggsystem
• Krav, kvoter och begränsningar för principer för radfilter och kolumnmask