Dynamisk datamaskering i fabric-datalager
Gäller för:✅ SQL-analysslutpunkt och lager i Microsoft Fabric
Med dynamisk datamaskering begränsas exponeringen av känsliga data genom att de maskeras för icke-privilegierade användare. Det kan användas för att förenkla design och kodning av säkerhet i ditt program.
Dynamisk datamaskning hjälper till att förhindra obehörig visning av känsliga data genom att göra det möjligt för administratörer att ange hur mycket känsliga data som ska avslöjas, med minimal effekt på programskiktet. Dynamisk datamaskning kan konfigureras för avsedda databasfält för att dölja känsliga data i resultatuppsättningarna med frågor. Med dynamisk datamaskering ändras inte data i databasen, så de kan användas med befintliga program eftersom maskeringsregler tillämpas på frågeresultat. Många program kan maskera känsliga data utan att ändra befintliga frågor.
- En central datamaskeringsprincip fungerar direkt på känsliga fält i databasen.
- Utse privilegierade användare eller roller som har åtkomst till känsliga data.
- Dynamisk datamaskering har funktioner för fullständig maskering och partiell maskering och en slumpmässig mask för numeriska data.
- Enkla Transact-SQL-kommandon definierar och hanterar masker.
Syftet med dynamisk datamaskering är att begränsa exponeringen av känsliga data, vilket hindrar användare som inte ska ha åtkomst till data från att visa dem. Dynamisk datamaskering syftar inte till att förhindra att databasanvändare ansluter direkt till databasen och kör uttömmande frågor som exponerar delar av känsliga data.
Dynamisk datamaskering kompletterar andra säkerhetsfunktioner i Infrastrukturresurser som säkerhet på kolumnnivå och säkerhet på radnivå. Vi rekommenderar starkt att du använder dessa dataskyddsfunktioner tillsammans för att skydda känsliga data i databasen.
Definiera en dynamisk datamask
En maskeringsregel kan definieras på en kolumn i en tabell för att dölja data i den kolumnen. Det finns fyra typer av masker tillgängliga.
Function | beskrivning | Exempel |
---|---|---|
Standardvärde | Fullständig maskering enligt datatyperna för de avsedda fälten. För strängdatatyper använder du XXXX (eller färre) om fältets storlek är mindre än 4 tecken (tecken, nchar, varchar, nvarchar, text, ntext).För numeriska datatyper använder du ett nollvärde (bigint, bit, decimal, int, money, numerisk, smallint, smallmoney, tinyint, float, real). För datatyper för datum och tid använder du (datum, datetime2, datetime, datetimeoffset, smalldatetime, time). 1900-01-01 00:00:00.0000000 För binära datatyper använder du en enda byte ASCII-värde 0 (binär, varbinär, bild). |
Exempel på kolumndefinitionssyntax: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL Exempel på ändringssyntax: ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()') |
Maskeringsmetod som exponerar den första bokstaven i en e-postadress och det konstanta suffixet ".com" i form av en e-postadress. aXXX@XXXX.com . |
Exempel på definitionssyntax: Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL Exempel på ändringssyntax: ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()') |
|
Slumpmässig | En slumpmässig maskeringsfunktion för användning på valfri numerisk typ för att maskera det ursprungliga värdet med ett slumpmässigt värde inom ett angivet intervall. | Exempel på definitionssyntax: Account_Number bigint MASKED WITH (FUNCTION = 'random([start range], [end range])') Exempel på ändringssyntax: ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)') |
Anpassad sträng | Maskeringsmetod som exponerar de första och sista bokstäverna och lägger till en anpassad utfyllnadssträng i mitten. prefix,[padding],suffix Om det ursprungliga värdet är för kort för att slutföra hela masken exponeras inte en del av prefixet eller suffixet. |
Exempel på definitionssyntax: FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(prefix,[padding],suffix)') NULL Exempel på ändringssyntax: ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') Detta omvandlar ett telefonnummer som 555.123.1234 till 5XXXXXXX . Ytterligare exempel: ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)') Detta omvandlar ett telefonnummer som 555.123.1234 till 555.1XXXXXXX . |
Fler exempel finns i Implementera dynamisk datamaskering i Synapse Data Warehouse.
Behörigheter
Användare utan behörigheten Administratör, Medlem eller Deltagare på arbetsytan och utan utökade behörigheter på informationslagret ser maskerade data.
Du behöver ingen särskild behörighet för att skapa en tabell med en dynamisk datamask, bara standard CREATE TABLE
- och ALTER
schemabehörigheter.
Att lägga till, ersätta eller ta bort masken för en kolumn kräver behörighet och ALTER ANY MASK
ALTER
behörighet i tabellen. Det är lämpligt att bevilja ALTER ANY MASK
en säkerhetstjänsteman.
Användare med SELECT
behörighet i en tabell kan visa tabelldata. Kolumner som definieras som maskerade visar maskerade data. UNMASK
Ge en användare behörighet att göra det möjligt för dem att hämta omaskerade data från de kolumner som maskering har definierats för.
Behörigheten CONTROL
för databasen innehåller både behörigheten ALTER ANY MASK
och UNMASK
som gör att användaren kan visa omaskerade data. Administrativa användare eller roller som Administratör, Medlem eller Deltagare har kontrollbehörighet för databasen avsiktligt och kan visa omaskerade data som standard. Utökade behörigheter på informationslagret innehåller CONTROL
behörighet.
Säkerhetsövervägande: kringgå maskering med hjälp av slutsatsdragning eller brute-force-tekniker
Dynamisk datamaskning är utformat för att förenkla programutvecklingen genom att begränsa dataexponeringen i en uppsättning fördefinierade frågor som används av programmet. Dynamisk datamaskering kan också vara användbart för att förhindra oavsiktlig exponering av känsliga data vid direkt åtkomst till data, men det är viktigt att observera att användare med frågebehörigheter som inte är privilegierade kan använda tekniker för att få åtkomst till faktiska data.
Tänk dig till exempel en användare som har tillräcklig behörighet för att köra frågor på lagret och försöker "gissa" underliggande data och slutligen härleda de faktiska värdena. Anta att vi har en mask definierad i [Employee].[Salary]
kolumnen, och den här användaren ansluter direkt till databasen och börjar gissa värden, så småningom härleds [Salary]
värdet i Employees
tabellen:
SELECT ID, Name, Salary FROM Employees
WHERE Salary > 99999 and Salary < 100001;
Resulterar i:
ID | Name | Lön |
---|---|---|
62543 | Jane Doe | 0 |
91245 | John Svensson | 0 |
Detta visar att dynamisk datamaskering inte ska användas ensamt för att helt skydda känsliga data från användare med frågeåtkomst till lager- eller SQL-analysslutpunkten. Det är lämpligt för att förhindra exponering av känsliga data, men skyddar inte mot skadliga avsikter för att härleda underliggande data.
Det är viktigt att hantera säkerhet på objektnivå korrekt med SQL-detaljerade behörigheter och att alltid följa principen för minsta nödvändiga behörigheter.
Relaterat innehåll
- Arbetsyteroller i infrastrukturdatalager
- Säkerhet på kolumnnivå i fabric-datalager
- Säkerhet på radnivå i fabric-datalager
- Säkerhet för datalagerhantering i Microsoft Fabric