Basisconcepten voor op kenmerken gebaseerd toegangsbeheer (ABAC)

Op kenmerken gebaseerd toegangsbeheer (ABAC) is een toegangsbeheermodel dat beheerde tags en beleidsregels gebruikt om machtigingen te verlenen op basis van objectkenmerken in plaats van machtigingen per object. Op deze pagina worden de bouwstenen gedefinieerd: beheerde tags, de drie ABAC-beleidstypen (rijfilter, kolommasker en GRANT beleid), de machtigingen die nodig zijn om ze te configureren en de scheiding van taken die ABAC mogelijk maakt voor teams.

Zie Op kenmerken gebaseerd toegangsbeheer in Unity Catalog voor een overzicht van alle ABAC-onderwerpen, waaronder zelfstudies, beleidsbeheer, best practices en beperkingen.

Wat is ABAC?

Op kenmerken gebaseerd toegangsbeheer (ABAC) is een dynamisch toegangsbeheermodel waarbij toegangsbeslissingen worden gebaseerd op beleid dat wordt geëvalueerd op kenmerken die zijn gekoppeld aan beveiligbare objecten. In Unity Catalog worden deze kenmerken weergegeven via beheerde tags. Deze beheerde tags worden gebruikt in beleidsvoorwaarden om gegevensobjecten binnen een bepaald bereik te vinden, zoals een catalogus of een schema. Hierdoor kan één beleid automatisch worden toegepast op meerdere gegevensobjecten die voldoen aan de voorwaarden.

Een ABAC-beleid kan bijvoorbeeld alle kolommen maskeren die zijn gelabeld PII voor tabellen binnen schema's HR. Wanneer er nieuwe gegevensobjecten worden gemaakt en gelabeld, wordt het beleid automatisch toegepast zonder afzonderlijke beleidsdefinities voor elk object te vereisen.

ABAC biedt ondersteuning voor beveiliging op rij- en kolomniveau via beleid voor rijfilters en kolommaskerbeleid voor tabellen, gerealiseerde weergaven en streamingtabellen. Beleidsregels voor rijfilters beperken welke rijen een gebruiker kan zien. Beleidsregels voor kolommaskers bepalen hoe kolomwaarden worden gepresenteerd aan gebruikers. Voor een vergelijking met rijfilters en kolommaskers op tabelniveau, zie Wanneer u ABAC versus rijfilters en kolommaskers op tabelniveau gebruikt.

ABAC ondersteunt ook dynamische machtigingsverleningen via GRANT beleidsregels voor ondersteunde beveiligbare typen. Zie ABAC-beleidGRANT.

Beheerde tags

In Unity Catalog worden kenmerken geïmplementeerd als beheerde tags. Beheerde tags zijn sleutel-waardeparen die zijn gedefinieerd op accountniveau en worden toegepast op beveiligbare objecten van Unity Catalog, zoals catalogi, schema's, tabellen, kolommen, modellen en volumes, naast werkruimteobjecten. Ze vertegenwoordigen kenmerken zoals gevoeligheid, classificatie of bedrijfsdomein.

Securables nemen standaard tags over van hun bovenliggende catalogus of schema. U kunt overgenomen tags op elk niveau overschrijven, behalve op kolomniveau: kolomtags nemen niet over van de bovenliggende tabel en moeten rechtstreeks worden toegepast.

Er kan worden verwezen naar beheerde tags in beleidsvoorwaarden met behulp van ingebouwde functies zoals has_tag() en has_tag_value(), waarmee wordt gecontroleerd of een bepaalde tag aanwezig is op het doelgegevensobject, rechtstreeks of via overname van tags.

Beheerde tags worden gedefinieerd op het accountniveau. Dit betekent dat u dezelfde tagtaxonomie kunt gebruiken voor uw hele gegevensdomein in een account, inclusief meerdere metastores.

Zie Beheerde tags en Tags toepassen op beveiligbare objecten van Unity Catalog voor meer informatie.

Policies

Beleidsregels worden gekoppeld aan beveiligbare objecten in Unity Catalog om toegangsbeheerregels te definiëren op basis van tagvoorwaarden. Hieronder ziet u een voorbeeld:

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;

Elk beleid geeft het volgende op:

• Bereik: het beveiligbare object waaraan het beleid is gekoppeld, opgegeven door de ON component. Als u een beleid aan een beveiligbaar object koppelt, worden de beleidsvoorwaarden geëvalueerd voor alle objecten van het type dat in de FOR component is opgegeven, voor dat object en alle onderliggende objecten.
  • Voor beleid voor rijfilters en kolommaskers zijn de ondersteunde beleidsbereiken CATALOG, SCHEMA of TABLE. Voor GRANT beleidsregels zijn de ondersteunde beleidsscopes CATALOG en SCHEMA.
  • Tabellen, waaronder stroomtabellen en gematerialiseerde weergaven, zijn het enige ondersteunde beveiligingstype voor rijfilter- en kolommaskerbeleid, gespecificeerd met behulp van de FOR TABLES clausule. GRANT beleidsregels zijn van toepassing op modellen, modeldiensten, modelaanbiedersdiensten, MCP-diensten en agentdiensten, en gebruik de GRANT <privilege> FOR <securable_type> clausule. Voor de volledige lijst van ondersteunde securable types en privileges, zie Supported securable types and privileges.
  • Een beleidsregel die aan een catalogus is gekoppeld, wordt geëvalueerd voor alle securables van het type dat is opgegeven in de FOR-clausule binnen die catalogus. Een beleid dat aan een schema is gekoppeld, evalueert tegen alle securables van dat type binnen dat schema. Een beleid dat aan een tabel is gekoppeld, evalueert alleen op basis van die tabel.

• Principals: op wie het beleid van toepassing is en op wie is vrijgesteld. Met TO de component worden de gebruikers, groepen of service-principals opgegeven die onder het beleid vallen. De optionele EXCEPT component sluit specifieke principals uit van dit beleid.
• Acties: Geeft aan of het beleid een rijfilter, een kolommasker of een bevoegdheid toekent. Beleidsregels voor rijfilters en kolommaskers maken gebruik van een door de gebruiker gedefinieerde functie (UDF) om de filter- of maskeringslogica te implementeren. GRANT beleidsregels maken geen gebruik van UDF's. Zie Beleidstypen.
• Voorwaarden: expressies op basis van tags die bepalen welke tabellen of kolommen de beleidsdoelen zijn. Zie Voorwaarden en ingebouwde functies.

Beleidsregels worden gemaakt en beheerd via de gebruikersinterface of programmatisch met SQL-instructies, zoals CREATE POLICY, DROP POLICY, SHOW POLICIESof DESCRIBE POLICYREST API's, Databricks SDK's of Terraform. Zie ABAC-beleid maken en beheren voor de volledige syntaxis en voorbeelden.

Beleidstypen

ABAC ondersteunt drie beleidstypen: rijfilterbeleid, kolommaskerbeleid en GRANT beleidsregels. Beleid voor rijfilters en kolommaskers vereist het gebruik van UDF's om de filter- of maskerlogica te implementeren. GRANT beleidsregels gebruiken geen UDF's en verlenen in plaats daarvan bevoegdheden wanneer de voorwaarde op basis van tags overeenkomt met de kenmerken van het doelobject.

Beleid voor rijfilters

Beleidsregels voor rijfilters beperken welke rijen een gebruiker in een tabel kan zien op basis van waarden in kolommen die worden geïdentificeerd door tags die overeenkomen met de voorwaarden en ingebouwde functies. Het beleid verwijst naar een UDF die elke rij evalueert. Rijen waarvoor de functie FALSE retourneert, worden uitgesloten van de queryresultaten. Argumenten worden via de USING COLUMNS component doorgegeven aan de UDF.

Voorbeeld van use case: Voor een verkoopcatalogus moet u ervoor zorgen dat het EMEA-team alleen EMEA-verkooprecords ziet in alle tabellen met een kolom die is gelabeld 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');

Beleid voor kolommasker

Beleidsregels voor kolommaskers bepalen welke waarden een gebruiker ziet voor specifieke kolommen die worden geïdentificeerd door tags die overeenkomen met de voorwaarden en ingebouwde functies. Het beleid verwijst naar een UDF die de kolomwaarde als invoer gebruikt en retourneert de oorspronkelijke waarde of een gemaskeerde versie. De gemaskeerde kolomwaarde wordt automatisch gebonden als het eerste argument van de ON COLUMN clausule, en aanvullende argumenten kunnen worden doorgegeven via USING COLUMNS. Het retourtype moet overeenkomen met of castbaar zijn naar het gegevenstype van de kolom.

Voorbeeld van gebruiksgeval: SSN-kolommen die zijn gelabeld met pii : ssn, maskeren zodat gebruikers ***-**-XXXX (alleen de laatste vier cijfers) zien, tenzij ze zich bevinden in een nalevingsgroep die is vrijgesteld van het beleid.

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);

De USING COLUMNS component geeft argumenten door aan de UDF. Het accepteert aliassen voor kolommen die overeenkomen met een op tags gebaseerde expressie of constante waarden (tekenreeksen tussen aanhalingstekens, numerieke letterlijke waarden, booleaanse waarden (TRUE/FALSE) of NULL), die zijn opgegeven in de volgorde waarin de functie ze verwacht. Het accepteert ook tagintrospection-functies, waarmee de waarde van een tag tijdens de query wordt geëxtraheerd en doorgegeven aan de UDF. Voor beleid voor kolommaskers zijn dit aanvullende argumenten buiten de gemaskeerde kolom (die automatisch afhankelijk is van ON COLUMN). Hierdoor kan één UDF opnieuw worden gebruikt in verschillende beleidsregels met verschillende parameters.

SQL UDF's worden aanbevolen voor betere prestaties. Python UDF's geregistreerd in Unity Catalog worden ook ondersteund, hoewel de query optimizer ze niet kan inlijnen of optimaliseren zoals bij SQL UDF's. Zie Prestatieoverwegingen voor richtlijnen voor het selecteren van UDF-talen.

GRANT beleidsregels

GRANT beleidsregels verlenen dynamisch een Unity Catalog-bevoegdheid wanneer hun voorwaarde op basis van tags overeenkomt met de tags van een beveiligbaar object. Telkens wanneer een gebruiker toegang probeert te krijgen tot een beveiligbaar object, identificeert Unity Catalog alle GRANT beleidsregels waarvan het bereik het object omvat, controleert of de gebruiker zich in de TO lijst bevindt en niet in de EXCEPT lijst staat en evalueert de voorwaarde van het beleid op basis van WHEN de tags op het beveiligbare, inclusief overgenomen tags. Als het beleid van toepassing is, verleent Unity Catalog de bevoegdheid. GRANT beleidsregels gebruiken hetzelfde evaluatiemodel als beleidsregels voor rijfilters en kolommaskers, behalve dat ze geen UDF's gebruiken. De voorwaarde wordt rechtstreeks in de beleidsdefinitie opgenomen.

De effectieve machtigingen voor een object zijn de combinatie van rechtstreeks toegekende machtigingen en alle toepasselijke GRANT beleidsregels. Een principal heeft de bevoegdheid als een GRANT beleid binnen het bereik van toepassing is op die principal of een directe GRANT van dezelfde bevoegdheid van toepassing is. GRANT beleid voegt alleen toegang toe. Ze kunnen de toegang die rechtstreeks is verleend, niet intrekken.

Voorwaarden en ingebouwde functies

Voorwaarden zijn op tags gebaseerde expressies die bepalen op welke tabellen en kolommen een beleid binnen zijn bereik gericht is.

• Tabelvoorwaarden (WHEN clausule): Booleaanse expressies die tabellen op basis van hun tags matchen. Als u dit weglaat, wordt standaard ingesteld op TRUE, wat betekent dat het beleid van toepassing is op alle tabellen binnen het bereik.
• Kolomvoorwaarden (MATCH COLUMNS clausule): Een of meer door komma's gescheiden booleaanse expressies die aangeven welke kolommen het beleid beoogt. Elke expressie kan één ingebouwde functie zijn, zoals has_tag('pii'), of een combinatie met logische operators zoals has_tag_value('pii', 'ssn') AND has_tag('sensitive'). Aan elke expressie kan een alias (opgegeven na AS) worden toegewezen waarnaar kan worden verwezen in de ON COLUMN en USING COLUMNS componenten. Een beleid kan maximaal drie kolomexpressies bevatten en alle moeten overeenkomen om het beleid toe te passen.

Beide componenttypen maken gebruik van de volgende ingebouwde functies, geëvalueerd door Unity Catalog op basis van beveiligbare metagegevens:

Om te matchen op de attributen van de gebruiker die de query uitvoert in plaats van op resourcetags, zie Identiteitsattribuutfuncties.

Om te matchen op de context van een verzoek, zoals de aanroepende applicatie, zie Context-attribuutfuncties.

Tags worden niet doorgegeven van tabellen naar kolommen. Het gebruik van has_tag() in een MATCH COLUMNS clausule komt alleen overeen met de tags op kolomniveau, niet met tags op de bovenliggende tabel of haar voorouders.

Voorbeeld: twee kolomvoorwaarden gebruiken. Een customers schema bevat tabellen met een e-mailkolom die is gelabeld pii : email en een toestemmingskolom met de tag consent_to_contact. Het beleid maskert e-mailadressen, tenzij de klant toestemming heeft gegeven om contact op te maken. Er worden twee kolomvoorwaarden gebruikt:

1. has_tag_value('pii', 'email') identificeert de kolom die e-mailadressen bevat (de kolom die moet worden gemaskeerd).
2. has_tag('consent_to_contact') identificeert de kolom die toestemmingsgegevens bevat (gebruikt door de UDF om te bepalen of ze moeten worden gemaskeerd).

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);

Dit beleid is alleen van toepassing op tabellen die zowel een kolom met een label pii : email als een kolom consent_to_contacthebben. Als een tabel geen kolommen bevat die overeenkomen met beide voorwaarden, is het beleid niet van toepassing en worden de gegevens niet gemaskeerd.

Identiteitsattribuutfuncties (Beta)

Identiteitsattribuutfuncties evalueren eigenschappen van de gebruiker die de query uitvoert, zoals departement, land of functie. Deze attributen kunnen worden ingesteld door uw identiteitsprovider en direct worden vermeld in de polisvoorwaarden. Dit stelt je in staat om flexibelere voorwaarden uit te drukken zonder voor elke combinatie van identiteitseigenschappen aparte groepen te creëren. Wanneer identiteitsinformatie verandert in je identiteitsprovider, gebruiken beleidsregels de bijgewerkte attribuutwaarden, net zoals ze een bijgewerkt groepslidmaatschap gebruiken.

Deze functies worden ondersteund in de WHEN clausule van kolommaskerbeleid.

Houd het volgende gedrag in gedachten wanneer je beleidsregels schrijft die ze gebruiken:

• Een ontbrekend attribuut lost op tot false. Als de gebruiker geen waarde voor het attribuut heeft, helemaal geen attributen heeft, of het attribuut niet bestaat, geeft de functie terug false in plaats van een foutmelding te geven. Formuleer de voorwaarden zo dat dit false resultaat de toegang beperkt. Zie Identiteitsattribuutvoorwaarden.
• Attribuutsleutels en -waarden zijn hoofdlettergevoelig en worden exact vergeleken: Finance en finance komen niet overeen.
• Attribuutwijzigingen zijn niet direct. Wijzigingen in je identiteitsprovider worden niet direct gesynchroniseerd met Azure Databricks. Zie identiteitsattributen voor meer informatie.

Voor de attributen die Azure Databricks ondersteunt en hoe deze worden ingesteld, zie identiteitsattributen. Zie Een kolom maskeren op basis van de attributen van de gebruiker die de query uitvoert voor voorbeelden van het gebruik van identiteitsattributen in beleidsregels.

Functies voor contextattributen (Bèta)

Contextattributen worden gebruikt om de toegang tot gegevens te beperken voor verzoeken die namens een gebruiker worden gedaan via een OAuth-applicatie. Deze opstelling kan worden gebruikt om agenten te beperken die toegang krijgen tot data wanneer zij namens een gebruiker handelen, terwijl diezelfde data toegankelijk blijft als de gebruiker deze direct in de werkruimte opvraagt.

Het dekt elke OAuth-applicatie, of het nu een ingebouwde app is zoals de Azure Databricks CLI of een aangepaste OAuth-app. Er zijn twee verschillende contextattributen:

• request.is_on_behalf_of: de tekenreeks 'true' of 'false'. Geeft aan of het verzoek namens een gebruiker wordt uitgevoerd via een OAuth-app. Elk verzoek van een OAuth-app heeft deze waarde ingesteld op 'true'.
• request.client_id: de OAuth-client-ID. Dit kan worden gebruikt om een specifieke OAuth-client te targeten, hetzij een ingebouwde OAuth-app (bijvoorbeeld databricks-cli) of een aangepaste OAuth-app. De client_id kan worden bekeken op de pagina App-verbindingen in de accountconsole. Voor Databricks-apps is dit ook te zien op de pagina Autorisatiedetails van de app, onder OAuth2 App Client ID. Of het kan worden opgezocht vanuit het identity_metadata.acting_resource veld in de auditlogboeken.

Deze attributen zijn niet door de gebruiker aanpasbaar en worden expliciet door het systeem verstrekt; Een beller beïnvloedt hen alleen door hoe ze zich authenticeren. Deze attributen kunnen worden gebruikt om externe agenten te identificeren, niet Genie-agenten.

Contextattributen kunnen worden gebruikt via de volgende functies:

Attribuutsleutels zijn niet hoofdlettergevoelig en de waarden zijn hoofdlettergevoelig.

Om te leren hoe je deze contextattributen gebruikt om toegang van externe agenten te controleren, zie Toegang beperken voor externe agenten die namens een gebruiker handelen.

Door de gebruiker gedefinieerde functies (UDF's)

Beleidsregels voor rijfilters en kolommaskers maken gebruik van door de gebruiker gedefinieerde functies (UDF's) om hun filter- of maskeringslogica te implementeren. Zie SQL en Python door de gebruiker gedefinieerde functies (UDF's) in Unity Catalog voor het maken en beheren van UDF's en algemene patronen voor het filteren van rijen en kolommaskering voor voorbeelden.

Functies voor tagintrospectie

Functies voor tagintrospectie extraheren de waarde van een beheerde tag en geven deze via de USING COLUMNS-clausule door aan een UDF. Omdat de UDF de tagwaarde als argument ontvangt, kunnen één beleid en UDF meerdere tagwaarden verwerken in plaats van een afzonderlijk beleid voor elke tagwaarde te vereisen. Deze functies zijn alleen beschikbaar voor beleidsregels voor rijfilters en kolommaskers, omdat GRANT beleidsregels geen UDF's gebruiken.

Voor het maken van een beleid dat gebruikmaakt van deze functies is Databricks Runtime 18 LTS of hoger vereist. Deze vereiste geldt alleen voor het maken van beleid, niet voor het uitvoeren van query's op de beheerde tabellen.

Tijdens query's evalueert Unity Catalog deze functies op basis van de tags in de tabel of kolommen die overeenkomen met het beleid: get_tag_value() leest uit de tabel die voldoet aan de WHEN voorwaarde en get_column_tag_value() leest uit de kolommen die zijn geïdentificeerd door MATCH COLUMNS. Ze kunnen alleen voorkomen in de USING COLUMNS clausule, niet in de WHEN- of MATCH COLUMNS-condities.

Beide functies nemen de tagsleutel als letterlijke tekenreeks. De tag moet een beheerde tag zijn en get_column_tag_value() moet verwijzen naar een alias die bestaat in de component van MATCH COLUMNS het beleid. Als de tag niet wordt beheerd of de alias ongeldig is, mislukt het maken van het beleid. Als een tag waarnaar wordt verwezen niet meer wordt beheerd wanneer een query wordt uitgevoerd, mislukken query's op de doeltabellen van het beleid tijdens runtime.

Voorbeeld: Één beleid voor alle PII-typen

Zonder tag-introspectie vereist het maskeren van elk type persoonlijk identificeerbare informatie (e-mail, SSN, telefoon) voor elke tagwaarde een apart beleid en een aparte UDF. Met get_column_tag_value()één beleid wordt de tagwaarde van pii de overeenkomende kolom doorgegeven aan één UDF. De UDF vertakt op basis van die waarde:

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'));

Voor elke gemaskeerde kolom verwijst get_column_tag_value(col, 'pii') naar de pii-tagwaarde van die kolom (email, ssn, phone, enzovoort), en mask_pii past de overeenkomende transformatie toe. Een nieuwe tagwaarde vereist alleen een nieuwe vertakking in de UDF, niet een nieuw beleid.

Scheiding van taken en machtigingen

Het instellen van ABAC omvat verschillende stappen, elk met zijn eigen machtigingsvereisten. Organisaties kunnen deze taken verdelen over gespecialiseerde groepen, afhankelijk van hoe ze ervoor kiezen om taken te scheiden. Een organisatie kan bijvoorbeeld centraal een tagtaxonomie definiëren, waarna datastewards gegevens classificeren, governancebeheerders beleidsregels opstellen, gegevensproducenten objecten maken binnen beheerde scopes en gegevensgebruikers toegang hebben tot de beheerde objecten.

1. Maak de tagtaxonomie. Definieer de beheerde tagsleutels en de toegestane waarden voordat iemand deze toepast of beleidsregels schrijft. Maak bijvoorbeeld een sensitivity tag met gecontroleerde waarden (public, internal, confidential, restricted) of een pii tag met waarden zoals ssn, emailen phone_number. Zie Kenmerken en naamgeving standaardiseren voor aanbevelingen over naamconventies en taxonomieontwerp.

   • Vereiste machtigingen: accountbeheerder of een gebruiker met CREATE machtigingen voor tags op accountniveau.

2. Gegevensassets taggen. Een gegevenssteward, datacreator of AI-classificatiesysteem past beheerde tags toe op beveiligbare objecten in Unity Catalog, zoals catalogi, schema's, tabellen, kolommen, modellen en volumes. Tag bijvoorbeeld kolommen die persoonsgegevens bevatten met pii : ssn, of tag een model met lifecycle : production. Juiste taggen is de essentiële eerste stap voor ABAC-beleid dat moet worden toegepast.

   • Vereiste machtigingen: ASSIGN voor de tag en APPLY TAG voor het object.

3. Maak een beleid. Een governance beheerder maakt een beleid binnen een bereik, zoals een catalogus of schema. Het beleid specificeert op wie het van toepassing is, welke voorwaarden worden geëvalueerd en welke actie wordt toegepast, zoals een rijfilter, een kolommasker of de toekenning van een bevoegdheid.

   • Vereiste machtigingen: MANAGE-machtiging of objecteigendom op het beveiligbare object waaraan het beleid is gekoppeld. Voor beleid voor rijfilters en kolommaskers is ook het EXECUTE privilege op de UDF vereist.

4. Gegevensobjecten maken. Makers van data maken beveiligbare objecten, zoals tabellen, modellen of volumes, binnen de scopes waarvoor ze toegang hebben gekregen. Nieuwe objecten nemen tags over van bovenliggende catalogi en schema's. Makers van gegevens hebben ook APPLY TAG automatisch op objecten die ze maken, zodat ze extra tags kunnen toepassen. Ze kunnen ook afhankelijk zijn van automatische gegevensclassificatie voor het afhandelen van tags. Als een organisatie afhankelijk is van gegevensmakers om hun eigen objecten te taggen, moeten er duidelijke tagprocedures worden vastgesteld. Makers van gegevens hoeven geen toegangscontroles te configureren als beleid op hogere niveaus is ingesteld, wat Azure Databricks aanbeveelt.

   • Vereiste machtigingen: CREATE TABLE of andere relevante bevoegdheden om het bovenliggende object te creëren.

5. Toegang tot beheerde objecten. Wanneer een gebruiker toegang probeert te krijgen tot een beveiligbaar object binnen het bereik van een beleid, evalueert Unity Catalog automatisch toepasselijke beleidsregels. Voor beleid voor rijfilters en kolommaskers ziet de gebruiker gefilterde of gemaskeerde gegevens als de tabel of kolommen overeenkomen met de voorwaarden van het beleid en de gebruiker niet is uitgesloten. Voor GRANT beleidsregels krijgt de gebruiker het toegekende privilege als de voorwaarden overeenkomen en de gebruiker in TO en niet in EXCEPTis.

   • Vereiste machtigingen: Voor beleid voor rijfilters en kolommaskers moeten aan gebruikers machtigingen voor de tabel worden verleend, zoals SELECT, via een rechtstreekse objectmachtiging. Met deze beleidsregels worden records gefilterd of kolommen gemaskeerd voor tabellen die de gebruiker al kan openen. Ze verlenen zelf geen machtigingen. GRANT Beleidsregels verlenen zelf het recht, samen met eventuele rechtstreekse toekenningen voor hetzelfde beveiligbare object.

Voordelen van ABAC

• Herbruikbare beleidsregels op basis van kenmerken: Eén beleid kan worden toegepast op meerdere gegevensobjecten die overeenkomen met dezelfde voorwaarden op basis van kenmerken, in plaats van aan één specifiek object te zijn gekoppeld.

• Automatische toepassing op nieuwe objecten: Wanneer nieuwe gegevensobjecten binnen het bereik worden gemaakt en worden gelabeld met de relevante kenmerken, zijn bestaande ABAC-beleidsregels van toepassing zonder extra configuratie. Beleidsregels fungeren als toekomstige subsidies, wat betekent dat toegangsbeheer automatisch wordt toegepast wanneer nieuwe gegevens worden gemaakt en op de juiste manier worden gelabeld.

• Consistente afdwinging binnen een bereik: Beleidsregels die zijn gekoppeld op catalogus- of schemaniveau, worden dynamisch geëvalueerd op basis van overeenkomende gegevensobjecten in dat bereik, waardoor verschillen worden verwijderd in hoe vergelijkbare gegevens worden gefilterd of gemaskeerd.

• Lager doorlopend onderhoud: Wijzigingen kunnen worden aangebracht door beleidslogica of beheerde tags bij te werken, in plaats van elk afzonderlijk object opnieuw te bezoeken zoals vereist is met rijfilters en kolommaskers op tabelniveau.

• Gecentraliseerd beheer: Omdat beleidsregels eenmaal kunnen worden gedefinieerd en toegepast op veel overeenkomende gegevensobjecten, kunnen governanceteams besturingselementen beheren in grotere delen van de gegevensomgeving met minder beleidsdefinities.

Aanvullende informatiebronnen

• Beheerde tags
• BELEID MAKEN
• Bevoegdheden beheren in Unity Catalog
• Rijfilters en kolommaskers
• Referentie voor systeemtabel auditlogboek
• Vereisten, quota en beperkingen voor beleid voor rijfilters en kolommaskers