Filtrera känsliga tabelldata med hjälp av radfilter och kolumnmasker
Den här artikeln innehåller vägledning och exempel för användning av radfilter, kolumnmasker och mappningstabeller för att filtrera känsliga data i dina tabeller. De här funktionerna kräver Unity Catalog.
Vad är radfilter?
Med radfilter kan du använda ett filter i en tabell så att frågor endast returnerar rader som uppfyller filtervillkoren. Du implementerar ett radfilter som en SQL-användardefinierad funktion (UDF). Python och Scala UDF:er stöds också, men endast när de är inslagna i SQL UDF:er.
Vad är kolumnmasker?
Med kolumnmasker kan du använda en maskeringsfunktion i en tabellkolumn. Maskeringsfunktionen utvärderas vid frågekörning och ersätter varje referens i målkolumnen med resultatet av maskeringsfunktionen. För de flesta användningsfall avgör kolumnmasker om det ursprungliga kolumnvärdet ska returneras eller redigeras baserat på den anropande användarens identitet. Kolumnmasker är uttryck som skrivs som SQL UDF:er eller som Python- eller Scala-UDF:er omslutna i SQL UDF:er.
Varje tabellkolumn kan bara ha en maskeringsfunktion tillämpad på den. Maskeringsfunktionen tar det omaskerade värdet för kolumnen som indata och returnerar det maskerade värdet som resultat. Returvärdet för maskeringsfunktionen ska vara samma typ som kolumnen som maskeras. Maskeringsfunktionen kan också ta ytterligare kolumner som indataparametrar och använda dem i maskeringslogik.
Vad är skillnaden mellan dessa filter och dynamiska vyer?
Med dynamiska vyer, radfilter och kolumnmasker kan du använda komplex logik för tabeller och bearbeta deras filtreringsbeslut vid frågekörning.
En dynamisk vy är en abstrakt, skrivskyddad vy över en eller flera källtabeller. Användaren kan komma åt en dynamisk vy utan direkt åtkomst till källtabellerna. När du skapar en dynamisk vy definieras ett nytt tabellnamn som inte får matcha namnet på källtabeller eller andra tabeller och vyer som finns i samma schema.
Om du å andra sidan kopplar ett radfilter eller en kolumnmask till en måltabell tillämpas motsvarande logik direkt på själva tabellen utan att nya tabellnamn introduceras. Efterföljande frågor kan fortsätta att referera direkt till måltabellen med dess ursprungliga namn.
Använd dynamiska vyer om du behöver använda transformeringslogik, till exempel filter och masker, för skrivskyddade tabeller och om det är acceptabelt för användare att referera till dynamiska vyer med hjälp av olika namn. Om du vill filtrera data när du delar dem med deltadelning måste du använda dynamiska vyer. Använd radfilter och kolumnmasker om du vill filtrera eller beräkna uttryck över specifika data, men ändå ge användarna åtkomst till tabellerna med sina ursprungliga namn.
Innan du börjar
Om du vill lägga till radfilter och kolumnmasker i tabeller måste du ha:
- En arbetsyta som är aktiverad för Unity Catalog.
- En funktion som är registrerad i Unity Catalog. Den här funktionen kan vara en SQL UDF, eller en Python- eller Scala UDF som är registrerad i Unity Catalog och innesluten i en SQL UDF. Mer information finns i Vad är användardefinierade funktioner (UDF:er)?, Kolumnmask-sats och ROW FILTER-sats.
Du måste också uppfylla följande krav:
- Om du vill tilldela en funktion som lägger till radfilter eller kolumnmasker i en tabell måste du ha behörigheten
EXECUTE
för funktionen,USE SCHEMA
i schemat ochUSE CATALOG
i den överordnade katalogen. - Om du lägger till filter eller masker när du skapar en ny tabell måste du ha behörigheten
CREATE TABLE
för schemat. - Om du lägger till filter eller masker i en befintlig tabell måste du vara tabellägare.
För att få åtkomst till en tabell som har radfilter eller kolumnmasker måste beräkningsresursen uppfylla något av följande krav:
Ett SQL-lager.
Läget för delad åtkomst på Databricks Runtime 12.2 LTS eller senare.
Åtkomstläge för en användare på Databricks Runtime 15.4 LTS eller senare.
Du kan inte läsa radfilter eller kolumnmasker med hjälp av beräkning som konfigurerats med åtkomstläge för en användare i Databricks Runtime 15.3 eller lägre.
Om du vill dra nytta av datafiltreringen som anges i Databricks Runtime 15.4 LTS och senare måste du också kontrollera att arbetsytan är aktiverad för serverlös beräkning, eftersom funktionerna för datafiltrering som stöder radfilter och kolumnmasker körs på serverlös beräkning. Du kan debiteras för serverlösa beräkningsresurser när du använder beräkning som konfigurerats som enkel användaråtkomstläge för att läsa tabeller som använder radfilter eller kolumnmasker. Se Detaljerad åtkomstkontroll för beräkning av en användare.
Använda ett radfilter
Om du vill skapa ett radfilter skriver du en funktion (UDF) för att definiera filterprincipen och sedan tillämpa den på en tabell. Varje tabell kan bara ha ett radfilter. Ett radfilter accepterar noll eller fler indataparametrar där varje indataparameter binder till en kolumn i motsvarande tabell.
Du kan använda ett radfilter med hjälp av Catalog Explorer- eller SQL-kommandon. Instruktionerna i Katalogutforskaren förutsätter att du redan har skapat en funktion och registrerat den i Unity Catalog. SQL-instruktionerna innehåller exempel på hur du skapar en radfilterfunktion och tillämpar den på en tabell.
Katalogutforskaren
- På din Azure Databricks-arbetsyta klickar du på Katalog.
- Bläddra eller sök efter den tabell som du vill filtrera.
- På fliken Översikt klickar du på Radfilter: Lägg till filter.
- I dialogrutan Lägg till radfilter väljer du den katalog och det schema som innehåller filterfunktionen och väljer sedan funktionen.
- I den expanderade dialogrutan visar du funktionsdefinitionen och väljer de tabellkolumner som matchar kolumnerna som ingår i funktionssatsen.
- Klicka på Lägg till.
Om du vill ta bort filtret från tabellen klickar du på fx Row-filtret och klickar på Ta bort.
SQL
Om du vill skapa ett radfilter och sedan lägga till det i en befintlig tabell använder du CREATE FUNCTION
och använder funktionen med hjälp av ALTER TABLE
. Du kan också använda en funktion när du skapar en tabell med .CREATE TABLE
Skapa radfiltret:
CREATE FUNCTION <function_name> (<parameter_name> <parameter_type>, ...) RETURN {filter clause whose output must be a boolean};
Använd radfiltret på en tabell med ett kolumnnamn:
ALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<column_name>, ...);
Ytterligare syntaxexempel:
Använd radfiltret på en tabell med en konstant literal som matchar en funktionsparameter:
ALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<constant_literal>, ...);
Ta bort ett radfilter från en tabell:
ALTER TABLE <table_name> DROP ROW FILTER;
Ändra ett radfilter:
Run a DROP FUNCTION statement to drop the existing function, or use CREATE OR REPLACE FUNCTION to replace it.
Ta bort ett radfilter:
ALTER TABLE <table_name> DROP ROW FILTER; DROP FUNCTION <function_name>;
Kommentar
Du måste utföra
ALTER TABLE ... DROP ROW FILTER
kommandot innan du släpper funktionen. Om du inte gör det är tabellen i ett otillgängligt tillstånd.Om tabellen blir otillgänglig på det här sättet ändrar du tabellen och släpper den överblivna radfilterreferensen med hjälp av
ALTER TABLE <table_name> DROP ROW FILTER;
.
Se även ROW FILTER-sats.
Exempel på radfilter
Det här exemplet skapar en SQL-användardefinierad funktion som gäller för medlemmar i gruppen admin
i regionen US
.
När den här exempelfunktionen tillämpas på sales
tabellen kan medlemmar i admin
gruppen komma åt alla poster i tabellen. Om funktionen anropas av en icke-administratör misslyckas villkoret RETURN_IF
region='US'
och uttrycket utvärderas och tabellen filtreras för att endast visa poster i US
regionen.
CREATE FUNCTION us_filter(region STRING)
RETURN IF(IS_ACCOUNT_GROUP_MEMBER('admin'), true, region='US');
Använd funktionen på en tabell som ett radfilter. Efterföljande frågor från sales
tabellen returnerar sedan en delmängd rader.
CREATE TABLE sales (region STRING, id INT);
ALTER TABLE sales SET ROW FILTER us_filter ON (region);
Inaktivera radfiltret. Framtida användarfrågor från sales
tabellen returnerar sedan alla rader i tabellen.
ALTER TABLE sales DROP ROW FILTER;
Skapa en tabell med funktionen tillämpad som ett radfilter som en del av -instruktionen CREATE TABLE
. Framtida frågor från tabellen sales
returnerar sedan en delmängd rader.
CREATE TABLE sales (region STRING, id INT)
WITH ROW FILTER us_filter ON (region);
Använda en kolumnmask
Om du vill använda en kolumnmask skapar du en funktion (UDF) och tillämpar den på en tabellkolumn.
Du kan använda en kolumnmask med hjälp av Catalog Explorer- eller SQL-kommandon. Instruktionerna i Katalogutforskaren förutsätter att du redan har skapat en funktion och registrerat den i Unity Catalog. SQL-instruktionerna innehåller exempel på hur du skapar en kolumnmaskfunktion och tillämpar den på en tabellkolumn.
Katalogutforskaren
- På din Azure Databricks-arbetsyta klickar du på Katalog.
- Bläddra eller sök efter tabellen.
- På fliken Översikt letar du reda på den rad som du vill använda kolumnmasken på och klickar på ikonen Maskeringsredigering.
- I dialogrutan Lägg till kolumnmask väljer du katalogen och schemat som innehåller filterfunktionen och väljer sedan funktionen.
- I den expanderade dialogrutan visar du funktionsdefinitionen. Om funktionen innehåller några parametrar utöver den kolumn som maskeras väljer du de tabellkolumner där du vill omvandla de ytterligare funktionsparametrarna.
- Klicka på Lägg till.
Om du vill ta bort kolumnmasken från tabellen klickar du på fx Kolumnmask på tabellraden och klickar på Ta bort.
SQL
Om du vill skapa en kolumnmask och lägga till den i en befintlig tabellkolumn använder CREATE FUNCTION
du och använder maskeringsfunktionen med hjälp av ALTER TABLE
. Du kan också använda en funktion när du skapar en tabell med .CREATE TABLE
Du använder SET MASK
för att använda maskeringsfunktionen.
MASK
I -satsen kan du använda någon av de inbyggda Funktionerna i Azure Databricks eller anropa andra användardefinierade funktioner. Vanliga användningsfall är att inspektera identiteten för den anropande användare som kör funktionen med hjälp current_user( )
av eller hämta de grupper som de är medlemmar i med .is_account_group_member( )
Mer information finns i Kolumnmasksats och Inbyggda funktioner.
Skapa en kolumnmask:
CREATE FUNCTION <function_name> (<parameter_name> <parameter_type>, ...) RETURN {expression with the same type as the first parameter};
Använd kolumnmasken på en kolumn i en befintlig tabell:
ALTER TABLE <table_name> ALTER COLUMN <col_name> SET MASK <mask_func_name> USING COLUMNS <additional_columns>;
Ytterligare syntaxexempel:
Använd kolumnmasken på en kolumn i en befintlig tabell med en konstant literal som matchar en funktionsparameter:
ALTER TABLE <table_name> ALTER COLUMN <col_name> SET MASK <mask_func_name> USING COLUMNS (<constant_name>, ...);
Ta bort en kolumnmask från en kolumn i en tabell:
ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;
Ändra en kolumnmask, antingen
DROP
den befintliga funktionen eller användCREATE OR REPLACE TABLE
.Ta bort en kolumnmask:
ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK; DROP FUNCTION <function_name>;
Kommentar
Du måste utföra
ALTER TABLE
kommandot innan du släpper funktionen, annars är tabellen i ett otillgängligt tillstånd.Om tabellen blir otillgänglig på det här sättet ändrar du tabellen och släpper referensen för den överblivna masken med hjälp av
ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;
.
Exempel på kolumnmask
I det här exemplet skapar du en användardefinierad funktion som maskerar ssn
kolumnen så att endast användare som är medlemmar i gruppen kan visa värden i den HumanResourceDept
kolumnen.
CREATE FUNCTION ssn_mask(ssn STRING)
RETURN CASE WHEN is_member('HumanResourceDept') THEN ssn ELSE '***-**-****' END;
Använd den nya funktionen i en tabell som en kolumnmask. Du kan lägga till kolumnmasken när du skapar tabellen eller senare.
--Create the `users` table and apply the column mask in a single step:
CREATE TABLE users (
name STRING,
ssn STRING MASK ssn_mask);
--Create the `users` table and apply the column mask after:
CREATE TABLE users
(name STRING, ssn STRING);
ALTER TABLE users ALTER COLUMN ssn SET MASK ssn_mask;
Frågor i tabellen returnerar nu maskerade ssn
kolumnvärden när den frågande användaren inte är medlem i HumanResourceDept
gruppen:
SELECT * FROM users;
James ***-**-****
Så här inaktiverar du kolumnmasken så att frågor returnerar de ursprungliga värdena i ssn
kolumnen:
ALTER TABLE users ALTER COLUMN ssn DROP MASK;
Använda mappningstabeller för att skapa en lista med åtkomstkontroll
För att uppnå säkerhet på radnivå kan du överväga att definiera en mappningstabell (eller åtkomstkontrolllista). En omfattande mappningstabell kodar vilka datarader i den ursprungliga tabellen som är tillgängliga för vissa användare eller grupper. Mappningstabeller är användbara eftersom de erbjuder enkel integrering med dina faktatabeller via direkta kopplingar.
Den här metoden hanterar många användningsfall som innehåller anpassade krav. Exempel:
- Införa begränsningar baserat på den inloggade användaren och samtidigt anpassa olika regler för specifika användargrupper.
- Att skapa invecklade hierarkier, till exempel organisationsstrukturer, som kräver olika uppsättningar regler.
- Replikera komplexa säkerhetsmodeller från externa källsystem.
Genom att använda mappningstabeller kan du utföra dessa utmanande scenarier och säkerställa robusta säkerhetsimplementeringar på radnivå och kolumnnivå.
Mappa tabellexempel
Använd en mappningstabell för att kontrollera om den aktuella användaren finns i en lista:
USE CATALOG main;
Skapa en ny mappningstabell:
DROP TABLE IF EXISTS valid_users;
CREATE TABLE valid_users(username string);
INSERT INTO valid_users
VALUES
('fred@databricks.com'),
('barney@databricks.com');
Skapa ett nytt filter:
Kommentar
Alla filter körs med definierarens rättigheter förutom funktioner som kontrollerar användarkontexten CURRENT_USER
(till exempel funktionerna och IS_MEMBER
) som körs som anropare.
I det här exemplet kontrollerar funktionen om den aktuella användaren finns i tabellen valid_users
. Om användaren hittas returnerar funktionen true.
DROP FUNCTION IF EXISTS row_filter;
CREATE FUNCTION row_filter()
RETURN EXISTS(
SELECT 1 FROM valid_users v
WHERE v.username = CURRENT_USER()
);
Exemplet nedan använder radfiltret när tabellen skapas. Du kan också lägga till filtret senare med hjälp av en ALTER TABLE
instruktion. När du tillämpar den på en hel tabell använder du syntaxen ON ()
. För en viss rad använder du ON (row);
.
DROP TABLE IF EXISTS data_table;
CREATE TABLE data_table
(x INT, y INT, z INT)
WITH ROW FILTER row_filter ON ();
INSERT INTO data_table VALUES
(1, 2, 3),
(4, 5, 6),
(7, 8, 9);
Välj data från tabellen. Detta bör endast returnera data om användaren finns i valid_users
tabellen.
SELECT * FROM data_table;
Skapa en mappningstabell som består av konton som alltid ska ha åtkomst för att visa alla rader i tabellen, oavsett kolumnvärden:
CREATE TABLE valid_accounts(account string);
INSERT INTO valid_accounts
VALUES
('admin'),
('cstaff');
Skapa nu en SQL UDF som returnerar true
om värdena för alla kolumner på raden är mindre än fem eller om den anropande användaren är medlem i mappningstabellen ovan.
CREATE FUNCTION row_filter_small_values (x INT, y INT, z INT)
RETURN (x < 5 AND y < 5 AND z < 5)
OR EXISTS(
SELECT 1 FROM valid_accounts v
WHERE IS_ACCOUNT_GROUP_MEMBER(v.account));
Tillämpa slutligen SQL UDF på tabellen som ett radfilter:
ALTER TABLE data_table SET ROW FILTER row_filter_small_values ON (x, y, z);
Support och begränsningar
Radfilter och kolumnmasker stöds inte med alla Azure Databricks-funktioner eller på alla beräkningsresurser. I det här avsnittet visas funktioner och begränsningar som stöds.
Funktioner och format som stöds
Den här listan över funktioner som stöds är inte fullständig. Vissa objekt visas eftersom de inte stöds under den offentliga förhandsversionen.
Databricks SQL- och Databricks-notebook-filer för SQL-arbetsbelastningar stöds.
DML-kommandon från användare med
MODIFY
behörighet stöds. Filter och masker tillämpas på data som läss avUPDATE
- ochDELETE
-instruktioner och tillämpas inte på data som skrivs (inklusiveINSERT
).Dataformat som stöds:
- Delta och Parquet för hanterade och externa tabeller.
- Flera andra dataformat för utländska tabeller som registrerats i Unity Catalog med Hjälp av Lakehouse Federation.
Principparametrar kan innehålla konstanta uttryck (strängar, numeriska, intervall, booleska värden, nullvärden).
SQL, Python och Scala UDF:er stöds som radfilter- eller kolumnmaskfunktioner om de är registrerade i Unity Catalog. Python- och Scala-UDF:er måste vara omslutna i en SQL UDF.
Du kan skapa vyer på tabeller som refererar till kolumnmasker eller radfilter, men du kan inte lägga till kolumnmasker eller radfilter i en vy.
Delta Lake-ändringsdataflöden stöds om schemat är kompatibelt med radfilter och kolumnmasker som gäller för måltabellen.
Sekundärtabeller stöds.
Tabellsampling stöds.
MERGE
-instruktioner stöds när källtabeller, måltabeller eller både använder radfilter och kolumnmasker. Detta inkluderar tabeller med radfilterfunktioner som innehåller enkla underfrågor. Begränsningar visas i följande avsnitt.Databricks SQL-materialiserade vyer och Databricks SQL-strömningstabeller stöder radfilter och kolumnmasker (offentlig förhandsversion):
- Du kan lägga till radfilter och kolumnmasker i en materialiserad Databricks SQL-vy eller en strömmande tabell. Du måste lägga till masker deklarativt när den materialiserade vyn eller strömningstabellen har definierats. Se SKAPA MATERIALISERAD VY ELLER SKAPA DIREKTUPPSPELNINGSTABELL.
- Du kan definiera databricks SQL-materialiserade vyer eller strömmande tabeller på tabeller som innehåller radfilter och kolumnmasker.
Materialiserade vyer och strömmande tabeller som deklarerats och publicerats i Delta Live Tables stöder radfilter eller kolumnmasker (offentlig förhandsversion):
- Du kan lägga till radfilter och kolumnmasker i en materialiserad vy eller en strömmande tabell i Delta Live Tables.
- Du kan definiera materialiserade vyer eller strömmande tabeller i tabeller som innehåller radfilter och kolumnmasker.
prestandarekommendationer
Radfilter och kolumnmasker styr datasynligheten genom att se till att användarna inte kan visa innehållet i värdena i bastabellerna innan de filtrerar och maskerar åtgärder. De fungerar bra som svar på frågor i vanliga användningsfall. I mindre vanliga program, där frågemotorn måste välja mellan att optimera frågeprestanda och skydda mot läckande information från filtrerade/maskerade värden, kommer den alltid att fatta det säkra beslutet på bekostnad av viss påverkan på frågeprestanda. Använd följande rekommendationer för att minimera prestandapåverkan:
- Använd enkla principfunktioner: Principfunktioner med färre uttryck presterar ofta bättre än mer komplexa uttryck. Undvik att använda mappningstabeller och uttrycksunderfrågor till förmån för enkla CASE-funktioner.
- Minska antalet funktionsargument: Azure Databricks kan inte optimera bort kolumnreferenser till källtabellen till följd av principfunktionsargument, även om dessa kolumner inte används i frågan. Använd principfunktioner med färre argument eftersom frågorna från dessa tabeller presterar bättre.
-
Undvik att lägga till radfilter med för många OCH-bindningar: Eftersom varje tabell endast stöder tillägg av högst ett radfilter är en vanlig metod att kombinera flera önskade principfunktioner med
AND
. För varje konjunkt ökar dock risken för att konjunkterna inkluderar komponenter som nämns någon annanstans i den här tabellen som kan påverka prestanda (till exempel mappningstabeller). Använd färre bindningar för att förbättra prestandan. -
Använd deterministiska uttryck som inte kan utlösa fel i tabellprinciper och frågor från dessa tabeller: Vissa uttryck kan utlösa fel om de angivna indata inte är giltiga, till exempel ANSI-division. I sådana fall får SQL-kompilatorn inte push-överföra åtgärder med dessa uttryck (till exempel filter) för långt ned i frågeplanen för att undvika risken för fel som "division by zero" som visar information om värden innan filtrering och/eller maskeringsåtgärder. Använd deterministiska uttryck som aldrig utlöser fel, till exempel
try_divide
i det här exemplet. - Kör testfrågor över tabellen för att mäta prestanda: Skapa realistiska frågor som representerar den arbetsbelastning du förväntar dig för tabellen med radfilter och/eller kolumnmasker och mäta prestanda. Gör små ändringar i principfunktionerna och observera deras effekter tills du når en bra balans mellan prestanda och uttrycksfullhet i filtrerings- och maskeringslogik.
Begränsningar
- Databricks Runtime-versioner under 12.2 LTS stöder inte radfilter eller kolumnmasker. Dessa körningar misslyckas på ett säkert sätt, vilket innebär att om du försöker komma åt tabeller från versioner som inte stöds av dessa körningar returneras inga data.
- Deltadelning fungerar inte med säkerhet på radnivå eller kolumnmasker.
- Du kan inte använda säkerhet på radnivå eller kolumnmasker i en vy.
- Tidsresor fungerar inte med säkerhet på radnivå eller kolumnmasker.
- Sökvägsbaserad åtkomst till filer i tabeller med principer stöds inte.
- Principer för radfilter eller kolumnmask med cirkulära beroenden tillbaka till de ursprungliga principerna stöds inte.
- Djupa och grunda kloner stöds inte.
-
MERGE
-instruktioner stöder inte tabeller med radfilter- eller kolumnmaskprinciper som innehåller kapsling, sammansättningar, fönster, gränser eller icke-deterministiska funktioner. - Delta Lake-API:er stöds inte.
Beräkningsbegränsning för en användare
Du kan inte komma åt en tabell med radfilter eller kolumnmasker från en enda användarberäkningsresurs på Databricks Runtime 15.3 eller lägre. Du kan använda åtkomstläge för en användare på Databricks Runtime 15.4 LTS eller senare, om din arbetsyta är aktiverad för serverlös beräkning. Mer information finns i Detaljerad åtkomstkontroll för beräkning av enskilda användare.