Op kenmerken gebaseerd toegangsbeheer van Unity Catalog (ABAC)

Op deze pagina wordt op kenmerken gebaseerd toegangsbeheer (ABAC) in Unity Catalog beschreven.

Wat is ABAC?

ABAC is een gegevensbeheermodel dat flexibel, schaalbaar en gecentraliseerd toegangsbeheer biedt in Azure Databricks. ABAC vormt een aanvulling op het bestaande bevoegdheidsmodel van Unity Catalog doordat beleidsregels kunnen worden gedefinieerd op basis van beheerde tags, die worden toegepast op gegevensassets. Dit vereenvoudigt governance en versterkt de beveiliging.

Gebruikers met MANAGE machtigingen of objecteigendom hoeven slechts één keer beleidsregels te definiëren en kunnen ze consistent toepassen op veel gegevensassets. Beleidsregels worden gekoppeld op catalogus-, schema- of tabelniveau en worden automatisch toegepast op alle tabellen binnen dat bereik. Wanneer beleidsregels op hogere niveaus zijn gedefinieerd, worden beleidsregels doorgegeven aan onderliggende objecten. Beheerde tags voor gegevensassets bepalen welke beleidsregels worden afgedwongen, zodat toegangsbeheer dynamisch kan worden aangepast.

Voordelen van ABAC

• Schaalbaarheid: Beheer toegangsbeheer op schaal door gebruik te maken van tags in plaats van afzonderlijke machtigingen.
• Flexibiliteit: Pas eenvoudig governance aan door tags of beleidsregels bij te werken zonder elke gegevensasset te wijzigen.
• Gecentraliseerd beheer: Vereenvoudig beleidsbeheer via een geïntegreerd model dat catalogi, schema's en tabellen omvat.
• Verbeterde beveiliging: Dynamisch afdwingen van fijngranulaire toegangscontrole op basis van gegevenskenmerken.
• Controlebaarheid: Houd realtime inzicht in gegevenstoegang via uitgebreide auditlogboeken.

Hoe ABAC werkt

ABAC in Unity Catalog maakt gebruik van beheerde tags, beleidsregels en door de gebruiker gedefinieerde functies (UDF's) om dynamisch toegangsbeheer op basis van kenmerken af te dwingen. De volgende onderdelen en mechanismen zijn centraal in ABAC:

• Beheerde tags: Beheerde tags worden gedefinieerd op accountniveau met behulp van tagbeleid. Deze tags vertegenwoordigen kenmerken zoals gegevensgevoeligheid, classificatie of bedrijfsdomein en worden toegewezen aan tabellen, schema's of catalogi in Unity Catalog. Ze fungeren als de kenmerken die het afdwingen van beleid stimuleren. Zie Beheerde tags en Tags toepassen op beveiligbare objecten van Unity Catalog.

• Beleid: Beleidsregels worden gemaakt en beheerd op drie hiërarchische niveaus in Unity Catalog:

  • Catalogusniveau: Pas brede beleidsregels toe die van invloed zijn op alle ingesloten schema's en tabellen.
  • Schemaniveau: Beleidsregels toepassen die specifiek zijn voor een schema en de bijbehorende tabellen.
  • Tabelniveau: Pas nauwkeurig beleid rechtstreeks toe op afzonderlijke tabellen.

  Beleidsregels volgen een overnamemodel: wanneer een beleid wordt gedefinieerd op catalogus- of schemaniveau, wordt dit automatisch toegepast op alle onderliggende objecten, schema's en tabellen binnen dat bereik. Hierdoor kunnen beheerders efficiënt beheer implementeren door één beleid toe te passen dat grote sets gegevensassets beheert. Overgenomen beleidsregels verminderen redundantie en bevorderen consistente afdwinging in de gegevenshiërarchie. Databricks raadt aan beleidsregels te definiëren op het hoogste toepasselijke niveau, meestal de catalogus, om de efficiëntie van governance te maximaliseren en administratieve overhead te verminderen. Zie AbAC-beleid (Op kenmerken gebaseerd toegangsbeheer) maken en beheren.

• Door de gebruiker gedefinieerde functies (UDF's): UDF's zijn aangepaste functies die zijn gedefinieerd op schemaniveau en kunnen wereldwijd worden verwezen in de Unity Catalog-naamruimte. UDF's worden binnen beleidsregels gebruikt om complexe logica uit te drukken, zoals het filteren van rijen of het maskeren van kolomwaarden op basis van kenmerken. Een UDF met de naam filter_region kan bijvoorbeeld worden gebruikt in een rijfilterbeleid om alleen rijen te retourneren waar region = 'EMEA'. Zie door de gebruiker gedefinieerde functies (UDF's) in Unity Catalog.

• Dynamische afdwinging: Wanneer een gebruiker probeert toegang te krijgen tot een getagde gegevensasset, evalueert Unity Catalog het toepasselijke beleid op basis van de tags en dwingt de gedefinieerde toegangsbeheer af.

  Gebruikers die expliciet zijn uitgesloten van een beleid, kunnen acties blijven uitvoeren, zoals diep en ondiep klonen en tijdreizen op de onderliggende gegevens. Gebruikers die niet zijn uitgesloten van ABAC-beleid, zijn echter onderhevig aan dezelfde beperkingen die van toepassing zijn op gedetailleerd toegangsbeheer.

• Auditlogboekregistratie: Alle bewerkingen op gelabelde gegevensassets worden vastgelegd en geregistreerd in de tabel van het auditlogboeksysteem, waardoor uitgebreide zichtbaarheid en nalevingstracering mogelijk zijn. Raadpleeg auditlogboeken.

Zie zelfstudie: ABAC configureren voor meer informatie over het configureren van ABAC.

Zie Discover Attribute-Based Access Control (ABAC) met Unity Catalog voor een demo van het configureren van ABAC.

Beleidstypen

Er worden twee typen ABAC-beleid ondersteund:

• Beleidsregels voor rijfilters beperken de toegang tot afzonderlijke rijen in een tabel op basis van hun inhoud. Een filter-UDF evalueert of elke rij zichtbaar moet zijn voor een gebruiker. Deze beleidsregels zijn handig wanneer toegang afhankelijk is van gegevenskenmerken.

  Voorbeeld van use case: Alleen rijen weergeven in een tabel met klanttransacties waarbij de regiokolom overeenkomt met een beheerde tag, zoals region=EMEA. Hierdoor kunnen regionale teams alleen gegevens zien die relevant zijn voor hun regio.

• Beleidsregels voor kolommaskers bepalen welke waarden gebruikers in specifieke kolommen zien. Een maskerings-UDF kan de werkelijke waarde of een gecensureerde versie retourneren, op basis van beheerde labels.

  Voorbeeld van use case: Masker een kolom met telefoonnummers, tenzij de tabel is gelabeld sensitivity=low of de gebruiker die de aanvraag indient zich in een nalevingsgroep bevindt. Gebruikers zonder toegang zien een null- of tijdelijke aanduidingswaarde, zoals XXX-XXX-XXXX.

Zie AbAC-beleid (Op kenmerken gebaseerd toegangsbeheer) maken en beheren.

Beperkingen

• U moet gebruikmaken van compute op Databricks Runtime 16.4 of hoger, of van serverloze compute, om toegang te krijgen tot een tabel die wordt beveiligd door ABAC. Gebruikers die niet onder het beleid vallen, kunnen runtime gebruiken.
• U kunt ABAC-beleid niet rechtstreeks toepassen op weergaven. Wanneer u echter een query uitvoert op een weergave die is gebaseerd op tabellen met ABAC-beleid, worden de identiteit en machtigingen van de eigenaar van de weergave gebruikt om het beleid te evalueren. Dit betekent:
  • De eigenaar van de weergave moet over de juiste machtigingen beschikken voor de onderliggende met ABAC beveiligde tabellen.
  • Gegevenstoegang wordt geëvalueerd op basis van de machtigingen van de weergave-eigenaar. Wanneer gebruikers een query uitvoeren op de weergave, zien ze de gefilterde of gemaskeerde gegevens zoals deze aan de eigenaar van de weergave worden weergegeven.
  • Het gedrag kan variëren, afhankelijk van uw rekenconfiguratie. Zie Vereisten voor het raadplegen van weergaven voor details.
• Beleidsregels voor gerealiseerde weergaven en streamingtabellen worden alleen ondersteund wanneer de eigenaar van de pijplijn is uitgesloten van het beleid.
• Gebruikers kunnen Delta-tabellen delen die zijn beveiligd door ABAC-beleid als ze over de vereiste machtigingen voor Delta-delen beschikken en zijn vrijgesteld van het ABAC-beleid. Het beleid is niet van toepassing op de toegang van de ontvanger. Voor shareproviders, zie Tabellen en schema's die zijn beveiligd door ABAC-beleid toevoegen aan een share. Zie ABAC-beveiligde gegevens lezen en ABAC-beleid toepassen voor geadresseerden die delen ontvangen.
• Slechts één afzonderlijk rijfilter kan tijdens runtime worden omgezet voor een bepaalde tabel en een bepaalde gebruiker. U kunt meerdere beleidsregels voor rijfilters definiëren, maar wanneer een gebruiker een query op de tabel opvraagt, moeten de voorwaarden van één beleid overeenkomen. Als meerdere afzonderlijke rijfilters van toepassing zijn op dezelfde gebruiker en tabel, blokkeert Azure Databricks de toegang en treedt er een fout op. Meerdere beleidsregels zijn toegestaan als ze resulteren in hetzelfde filter (bijvoorbeeld dezelfde UDF met dezelfde argumenten). Zie Problemen met meerdere filters of maskers oplossen.
• Slechts één afzonderlijk kolommasker kan tijdens runtime worden opgelost voor een bepaalde kolom en een bepaalde gebruiker. U kunt beleid voor meerdere kolommen maskeren definiëren, maar wanneer een gebruiker een query op de tabel opvraagt, moeten de voorwaarden van één beleid overeenkomen voor elke kolom. Als meerdere afzonderlijke kolommaskers van toepassing zijn op dezelfde kolom voor dezelfde gebruiker, blokkeert Azure Databricks de toegang en genereert een fout. Meerdere beleidsregels zijn toegestaan als ze resulteren in hetzelfde masker (bijvoorbeeld dezelfde UDF met dezelfde argumenten). Zie Problemen met meerdere filters of maskers oplossen.
• Een ABAC-beleid kan maximaal drie kolomvoorwaarden bevatten in de MATCH COLUMNS component.
• Tijdreizen werkt niet met ABAC-beleid, tenzij de gebruiker expliciet van het beleid wordt uitgesloten.
• Diepe en ondiepe klonen worden niet ondersteund in tabellen met ABAC-beleid, tenzij de gebruiker expliciet wordt uitgesloten van het beleid.
• U kunt geen vectorzoekindex maken op basis van een tabel waarop rijfilters of kolommaskers zijn toegepast via ABAC-beleid.
• Er is geen informatieschematabel voor ABAC-beleid. In de information_schema.row_filters en information_schema.column_masks tabellen worden alleen rijfilters en kolommaskers weergegeven die rechtstreeks op tabellen worden toegepast. Ze tonen geen ABAC-beleidsdefinities of de filters en maskers die tijdens runtime zijn afgeleid van ABAC-beleid.
• Zie Beperkingen voor de beperkingen van ABAC op dedicated rekenkracht.

Zie Beperkingen voor beperkingen van rijfilters en kolommaskers.