Rijfilters, kolommaskers en ABAC

Wanneer toegang op schemaniveau te grof is

De readergroep ziet de hele tabel. Vaak is dat fout. Een regiomanager hoort de rijen van zijn regio te zien. Een supportmedewerker moet de klant zien, maar van het telefoonnummer alleen de laatste vier cijfers. De tabel per doelgroep kopiëren lost het slecht op: meer tabellen, meer drift, meer plekken waar persoonsgegevens kunnen lekken.

Unity Catalog regelt dit binnen de tabel, op querytijd. In deze les behandelen we rijfilters en kolommaskers, wanneer je de nieuwere attribuutgebaseerde policies kiest en welke beperkingen je controleert voor je je vastlegt. Dynamic views behandelen we niet uitgebreid.

Rijfilters

De documentatie beschrijft een rijfilter als een SQL user-defined function die aan een tabel is gebonden. De functie neemt waarden van een of meer kolommen en geeft een Boolean terug. Rijen waarvoor ze true teruggeeft, zijn zichtbaar voor de gebruiker die de query draait. Je bindt de functie aan de tabel met ALTER TABLE ... SET ROW FILTER ... ON (...).

Het eigen patroon uit de documentatie ziet er zo uit:

CREATE FUNCTION salary_filter(dept STRING) RETURNS BOOLEAN
RETURN dept IS NULL;
 
ALTER TABLE employees SET ROW FILTER salary_filter ON (department);

Dat filter is een kale illustratie van het mechanisme. In de praktijk controleert de functie groepslidmaatschap. De volgende listing toont de bedoeling in onze naamconventie: leden van de financegroep zien elke rij en iedereen anders ziet alleen de rijen van de regio waaraan zijn groep gekoppeld is.

-- Schematisch rijfilter. Controleer functienamen en parameterregels in de actuele referentie.
CREATE FUNCTION prd_finance.security.region_filter(region STRING)
RETURNS BOOLEAN
RETURN is_account_group_member('grp-uc-prd-finance-all-regions')
    OR (region = 'NL' AND is_account_group_member('grp-uc-prd-finance-region-nl'))
    OR (region = 'BE' AND is_account_group_member('grp-uc-prd-finance-region-be'));
 
ALTER TABLE prd_finance.gold.invoices
  SET ROW FILTER prd_finance.security.region_filter ON (region);

De documentatie noemt is_account_group_member() als voorbeeld van een functie om dynamic views mee af te schermen. Omdat rechten de Entra ID-groepen volgen, ziet iemand die lid wordt van de regiogroep de rijen zonder dat iemand de tabel aanraakt.

Kolommaskers

Een kolommasker is een SQL-functie die aan één kolom is gebonden. Ze krijgt de kolomwaarde en geeft de waarde terug die de gebruiker mag zien. De documentatie zegt dat het retourtype gelijk moet zijn aan het kolomtype of ernaar te casten moet zijn. Je bindt het met ALTER TABLE ... ALTER COLUMN ... SET MASK.

-- Schematisch kolommasker: toon de laatste vier tekens aan iedereen behalve de bevoorrechte groep.
CREATE FUNCTION prd_finance.security.mask_phone(phone STRING)
RETURNS STRING
RETURN CASE
  WHEN is_account_group_member('grp-uc-prd-finance-pii-reader') THEN phone
  ELSE CONCAT('******', RIGHT(phone, 4))
END;
 
ALTER TABLE prd_finance.gold.customers
  ALTER COLUMN phone SET MASK prd_finance.security.mask_phone;

Houd masker- en filterfuncties in een apart security-schema met strikte rechten, want wie de functie kan wijzigen, wijzigt het beleid. Zet de functiedefinities in de repository en rol ze uit via de pipeline.

Typeveiligheid telt

De documentatie waarschuwt dat parametertypen bij kolomtypen moeten passen. Met ANSI-modus uitgeschakeld worden waarden die niet te casten zijn stilletjes NULL, wat in een policy tot foute resultaten kan leiden. Ze raadt aan ANSI-modus in te schakelen:

SET spark.sql.ansi.enabled = true;

Een policy die bij een mislukte cast stil NULL teruggeeft, kan rijen verbergen of een waarde lekken, afhankelijk van hoe je haar schreef. Test policies met randwaarden: nulls, lege strings en vreemde formaten.

Attribuutgebaseerde toegangscontrole

Voor veel tabellen schaalt het niet om per tabel een functie te binden. De documentatie zegt dat Databricks attribute-based access control (ABAC)-policies aanbeveelt voor consistente regels over veel tabellen en tabelniveaucontroles voor tabelspecifieke logica.

ABAC verleent of beperkt toegang door attributen op securable objects te evalueren. De attributen zijn governed tags. Een policy gebruikt tagvoorwaarden om de data te identificeren die ze beschermt, zodat één policy elke kolom met de tag persoonsgegevens in een catalog of schema kan dekken. Evaluatie is dynamisch: een nieuwe tabel met de juiste tag is beschermd zodra hij bestaat.

De documentatie noemt deze policytypen: rijfilter- en kolommaskerpolicies, GRANT-policies die dynamisch privileges geven en DENY-policies. Policies hechten op catalog-, schema- of tabelniveau en op metastore-niveau in Beta. De documentatie labelt specifieke functies als Beta: policies op metastore-niveau, ondersteuning voor views, DENY-policies en time travel met ABAC. Ze noemt geen totaalstatus voor de functie, dus controleer de releasenotes voor jouw regio.

Hier betaalt les 1 zich uit. Draagt elke kolom met persoonsgegevens een tag zoals pii, dan maskeert één policy ze allemaal. Ons artikel over ABAC op views en time travel betoogt dat policytests een releasepoort moeten zijn en dat geldt zodra je voor privacy op policies leunt.

Kiezen tussen de opties

Een filter verbergt rijen van een tabel die mensen kunnen bereiken. Mag een doelgroep de tabel nooit aanraken, vertrouw dan niet op een filter maar gebruik toegangsbeheer en een apart schema.

Beperkingen om te controleren voor je je vastlegt

De documentatie noemt beperkingen voor filters en maskers op tabelniveau. Degene die ontwerpen bepalen:

• Ze worden niet ondersteund op runtimes onder 12.2 LTS, waar queries geen data teruggeven.
• Je kunt ze niet toepassen op views.
• Delta Lake-API's worden niet ondersteund.
• Tabellen met filters of maskers op tabelniveau kunnen niet via OpenSharing worden gedeeld (les 6).
• Time travel wordt niet ondersteund met controles op tabelniveau. ABAC-time travel is Beta.
• Deep en shallow clones worden niet ondersteund.
• De dedicated access mode heeft runtimeregels: niet ondersteund op 15.3 of lager, alleen-lezen van 15.4 tot en met 16.2, schrijven vanaf 16.3.
• Kolommaskers kunnen niet op kolommen die door gegenereerde kolommen worden gebruikt.

Controleer de actuele pagina voor je ontwerpt, want beperkingen veranderen. Wil je een tabel delen, dan kan de beperking bij delen alleen al een fysiek gemaskeerde kopie in een gold-schema het betere ontwerp maken.

Test de policy

Een policy is code, dus test haar als code. Schrijf per policy testcases voor een lid van elke groep en voor een niet-lid en controleer rijaantallen en gemaskeerde waarden. Draai de tests in de pipeline met testidentiteiten in test en acc. Test nooit met productie-persoonsgegevens in dev of test. Gebruik synthetische of gemaskeerde data.

Veelgemaakte fouten

• Een filter waar een schemagrens nodig was.
• Eén maskerfunctie per tabel, gekopieerd. Gebruik ABAC en tags.
• Geen tests. Een policy die alles teruggeeft ziet er goed uit tot een audit.
• De beperkingen bij delen en time travel negeren.
• Een functie die iedereen kan wijzigen. Zet het security-schema op slot.

Samenvatting

Gebruik rijfilters en kolommaskers voor toegang binnen een tabel en ABAC-policies op governed tags wanneer dezelfde regel voor veel tabellen geldt. Houd functies in een afgesloten schema, schakel ANSI-modus in, test met echte identiteiten en controleer eerst de gedocumenteerde beperkingen.

Volgende les: lineage, auditlogs en systeemtabellen, het bewijs dat governance werkt.