Basisconcepten voor op kenmerken gebaseerd toegangsbeheer (ABAC)

Op deze pagina maakt u kennis met ABAC, hoe deze gebruikmaakt van beheerde tags, beleidsregels en door de gebruiker gedefinieerde functies om te bepalen welke rijen gebruikers kunnen zien en hoe kolomwaarden worden weergegeven en wat de voordelen zijn. Deze pagina bevat ook de machtigingen die nodig zijn voor het instellen van ABAC en de scheiding van taken die het mogelijk maakt voor alle 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 kenmerken. 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.

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 Unity Catalog-beveiligbare objecten, zoals catalogi, schema's, tabellen en kolommen, naast werkruimteobjecten. Ze vertegenwoordigen kenmerken zoals gevoeligheid, classificatie of bedrijfsdomein.

Tags nemen standaard over van bovenliggende catalogi en schema's naar tabellen, maar niet van tabellen naar kolommen. U kunt overgenomen tags op elk niveau overschrijven, maar tags op kolomniveau 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 object dat beveiligd kan worden waaraan het beleid is gekoppeld, opgegeven door de ON clausule. Als u een beleid aan een beveiligbaar object koppelt, worden de beleidsvoorwaarden geëvalueerd voor alle objecten van het type dat in de FOR clausule is opgegeven, voor dat beveiligbare object en al zijn afgeleiden.
  • Vandaag zijn de ondersteunde beleidsbereiken CATALOG, SCHEMA, of TABLE.
  • Tabellen, waaronder streamingtabellen en gerealiseerde weergaven, zijn momenteel het enige ondersteunde beveiligbare type, dat is opgegeven met behulp van de FOR TABLES component.
  • Een beleid dat aan een catalogus is gekoppeld, evalueert op basis van alle tabellen in die catalogus. Een beleid dat aan een schema is gekoppeld, evalueert op basis van alle tabellen in 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: Of het beleid een rijfilter of een kolommasker toepast. De actie wordt geïmplementeerd door een door de gebruiker gedefinieerde functie (UDF) die de filter- of maskeringslogica definieert. 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 twee beleidstypen: beleid voor rijfilters en beleid voor kolommaskers. Beide vereisen UDF's om de filter- of maskeringslogica te implementeren.

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

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:

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.

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

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 een tagtaxonomie centraal definiëren en vervolgens gegevensstewards laten classificeren, governancebeheerders schrijven beleidsregels, makers van gegevens maken objecten binnen beheerde bereiken en gegevensgebruikers voeren query's uit op de resultaten.

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, gegevensmaker of AI-classificatiesysteem past beheerde tags toe op catalogi, schema's, tabellen of kolommen. Gebruik bijvoorbeeld de pii : ssn-tag om kolommen te markeren die persoonsgegevens bevatten. 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 geeft aan op wie het van toepassing is, op welke voorwaarden wordt geëvalueerd en de UDF waarmee de filter- of maskeringslogica wordt geïmplementeerd.

   • Vereiste machtigingen: MANAGE machtiging of objecteigendom voor de beveiligbare locatie waaraan het beleid is gekoppeld (catalogus, schema of tabel) en EXECUTE bevoegdheden voor de UDF.

4. Gegevensobjecten maken. Gegevensmakers maken tabellen binnen de omvang waaraan ze toegang hebben gekregen. Nieuwe tabellen nemen tags over van bovenliggende objecten, zoals 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. Gegevens opvragen. Wanneer een gegevensgebruiker een query op een tabel binnen het bereik van het beleid opvraagt, wordt het beleid automatisch geëvalueerd. Als de tabel of kolommen overeenkomen met de voorwaarden van het beleid en de gebruiker niet is uitgesloten, ziet de consument gefilterde of gemaskeerde gegevens.

   • Vereiste machtigingen: aan gebruikers moeten machtigingen voor de tabel worden verleend, bijvoorbeeld SELECTvia een directe objecttoekenning. Het ABAC-beleid voor rijfilters en kolommaskering verleent op zichzelf geen machtigingen. Ze filteren alleen records of maskeren kolommen voor tabellen waartoe een gebruiker al toegang heeft.

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.

Meer informatie

• Beheerde tags
• BELEID MAKEN
• Bevoegdheden beheren in Unity Catalog
• Rijfilters en kolommaskers
• Referentie voor systeemtabel auditlogboek
• ABAC-vereisten, quota en beperkingen