Dynamisk datamaskering i Fabric-datawarehousing
Gælder for:✅ SQL Analytics-slutpunkt og warehouse i Microsoft Fabric
Dynamiske datamaskering begrænser eksponeringen af følsomme data ved at maskere dem til brugere, der ikke erprivilegerede. Det kan bruges til at forenkle designet og kodningen af sikkerhed i dit program betydeligt.
Dynamisk datamaskering hjælper med at forhindre uautoriseret visning af følsomme data ved at gøre det muligt for administratorer at angive, hvor mange følsomme data der skal vises, med minimal effekt på programlaget. Dynamisk datamaskering kan konfigureres på angivne databasefelter for at skjule følsomme data i resultatsæt af forespørgsler. Med dynamisk datamaskering ændres dataene i databasen ikke, så de kan bruges sammen med eksisterende programmer, da der anvendes maskeringsregler for forespørgselsresultater. Mange programmer kan maskere følsomme data uden at ændre eksisterende forespørgsler.
- En central politik til maskering af data fungerer direkte på følsomme felter i databasen.
- Angiv privilegerede brugere eller roller, der har adgang til de følsomme data.
- Dynamisk datamaskering indeholder funktioner til fuld maskering og delvis maskering og en tilfældig maske til numeriske data.
- Enkle Transact-SQL-kommandoer definerer og administrerer masker.
Formålet med dynamisk datamaskering er at begrænse eksponeringen af følsomme data, hvilket forhindrer brugere, der ikke skal have adgang til dataene, i at få dem vist. Dynamisk datamaskering har ikke til formål at forhindre databasebrugere i at oprette direkte forbindelse til databasen og køre udtømmende forespørgsler, der viser dele af de følsomme data.
Dynamisk datamaskering supplerer andre Fabric-sikkerhedsfunktioner, f.eks . sikkerhed på kolonneniveau og sikkerhed på rækkeniveau. Det anbefales på det kraftigste at bruge disse databeskyttelsesfunktioner sammen for at beskytte de følsomme data i databasen.
Definer en dynamisk datamaske
Der kan defineres en maskeregel for en kolonne i en tabel for at sløre dataene i den pågældende kolonne. Der er fire typer masker tilgængelige.
Funktion | Beskrivelse | Eksempler |
---|---|---|
Standard | Fuld maskering i henhold til datatyperne for de angivne felter. I forbindelse med strengdatatyper skal du bruge XXXX (eller færre), hvis feltets størrelse er mindre end 4 tegn (tegn, nchar, varchar, nvarchar, tekst, ntext).Til numeriske datatyper skal du bruge en nulværdi (bigint, bit, decimal, int, penge, numerisk, smallint, smallmoney, tinyint, float, real). For datatyper for dato og klokkeslæt skal du bruge (dato, datetime2, datetime, datetimeoffset, smalldatetime, klokkeslæt). 1900-01-01 00:00:00.0000000 I forbindelse med binære datatyper skal du bruge en enkelt byte med ASCII-værdien 0 (binær, varbinary, image). |
Eksempel på kolonnedefinitionssyntaks: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL Eksempel på altersyntaks: ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()') |
Mailadresse | Maskeringsmetode, der viser det første bogstav i en mailadresse og det konstante suffiks ".com" i form af en mailadresse. aXXX@XXXX.com . |
Eksempel på definitionssyntaks: Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL Eksempel på altersyntaks: ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()') |
Tilfældig | En tilfældig maskefunktion til brug på en hvilken som helst numerisk type til at maskere den oprindelige værdi med en vilkårlig værdi inden for et angivet område. | Eksempel på definitionssyntaks: Account_Number bigint MASKED WITH (FUNCTION = 'random([start range], [end range])') Eksempel på altersyntaks: ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)') |
Brugerdefineret streng | Maskeringsmetode, der viser det første og sidste bogstav og tilføjer en brugerdefineret margenstreng i midten. prefix,[padding],suffix Hvis den oprindelige værdi er for kort til at fuldføre hele masken, vises en del af præfikset eller suffikset ikke. |
Eksempel på definitionssyntaks: FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(prefix,[padding],suffix)') NULL Eksempel på altersyntaks: ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') Dette forvandler et telefonnummer som 555.123.1234 til 5XXXXXXX . Yderligere eksempel: ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)') Dette forvandler et telefonnummer som 555.123.1234 til 555.1XXXXXXX . |
Du kan få flere eksempler under Sådan implementerer du dynamisk datamaskering i Fabric Data Warehouse.
Tilladelser
Brugere uden rettigheder som administrator, medlem eller bidragyder i arbejdsområdet og uden administratorrettigheder på lageret får vist maskerede data.
Du behøver ikke nogen særlig tilladelse til at oprette en tabel med en dynamisk datamaske, kun standard CREATE TABLE
- og ALTER
skematilladelser.
Tilføjelse, erstatning eller fjernelse af masken for en kolonne kræver ALTER ANY MASK
tilladelse og ALTER
tilladelse til tabellen. Det er passende at give ALTER ANY MASK
til en sikkerhedsofficer.
Brugere med SELECT
tilladelse til en tabel kan få vist tabeldataene. Kolonner, der er defineret som maskeret, viser maskerede data. Giv en UNMASK
bruger tilladelse til at gøre det muligt for brugeren at hente ikke-maskede data fra de kolonner, der er defineret maskering for.
Tilladelsen CONTROL
til databasen indeholder både tilladelsen ALTER ANY MASK
og UNMASK
, der gør det muligt for brugeren at få vist ikke-maskede data. Administrative brugere eller roller, f.eks. administrator, medlem eller bidragyder, har kontroltilladelser til databasen som design og kan som standard få vist ikke-afmaskede data. Udvidede tilladelser til lageret omfatter CONTROL
tilladelser.
Sikkerhedsovervejelse: Omgå maskering ved hjælp af inferens- eller brute-force-teknikker
Dynamisk datamaskering er designet til at forenkle programudvikling ved at begrænse dataeksponering i et sæt foruddefinerede forespørgsler, der bruges af programmet. Selvom dynamisk datamaskering også kan være nyttigt for at forhindre utilsigtet eksponering af følsomme data, når der opnås direkte adgang til data, er det vigtigt at bemærke, at brugere uden forespørgselstilladelser kan anvende teknikker til at få adgang til de faktiske data.
Overvej f.eks. en bruger, der har tilstrækkelige rettigheder til at køre forespørgsler på lageret, og forsøger at 'gætte' de underliggende data og i sidste ende udlede de faktiske værdier. Antag, at der er defineret en maske i [Employee].[Salary]
kolonnen, og at denne bruger opretter forbindelse direkte til databasen og begynder at gætte værdier og til sidst udlede værdien [Salary]
i tabellen Employees
:
SELECT ID, Name, Salary FROM Employees
WHERE Salary > 99999 and Salary < 100001;
Resultater i:
Id | Navn | Månedsløn |
---|---|---|
62543 | Jane Doe | 0 |
91245 | John Smith | 0 |
Dette viser, at dynamisk datamaskering ikke skal bruges alene til fuldt ud at sikre følsomme data fra brugere med forespørgselsadgang til lager- eller SQL-analyseslutpunktet. Det er velegnet til at forhindre eksponering af følsomme data, men beskytter ikke mod ondsindet hensigt at udlede de underliggende data.
Det er vigtigt at administrere sikkerhed på objektniveau korrekt med SQL-detaljerede tilladelser og altid følge princippet om minimale påkrævede tilladelser.
Relateret indhold
- Arbejdsområderoller i Fabric-datawarehousing
- Sikkerhed på kolonneniveau i Fabric-datawarehousing
- Sikkerhed på rækkeniveau i Fabric-datawarehousing
- Sikkerhed i forbindelse med datawarehousing i Microsoft Fabric