Dynamisk datamaskering i datalager for stoff

  • Artikkel

Gjelder for: SQL Analytics-endepunkt og Warehouse i Microsoft Fabric

Dynamisk datamaskering begrenser sensitiv dataeksponering ved å maskere den til ikke-privilegerte brukere. Den kan brukes til å forenkle utformingen og kodingen av sikkerhet i programmet.

Dynamisk datamaskering bidrar til å forhindre uautorisert visning av sensitive data ved å gjøre det mulig for administratorer å angi hvor mye sensitive data som skal avsløres, med minimal effekt på programlaget. Dynamisk datamaskering kan konfigureres på angitte databasefelt for å skjule sensitive data i resultatsettene med spørringer. Med dynamisk datamaskering endres ikke dataene i databasen, slik at de kan brukes med eksisterende programmer siden maskeringsregler brukes på spørringsresultater. Mange programmer kan maskere sensitive data uten å endre eksisterende spørringer.

  • En sentral policy for datamaskering fungerer direkte på sensitive felt i databasen.
  • Angi privilegerte brukere eller roller som har tilgang til sensitive data.
  • Dynamisk datamaskering har fullstendige maskerings- og delvise maskeringsfunksjoner, og en tilfeldig maske for numeriske data.
  • Enkle Transact-SQL-kommandoer definerer og administrerer masker.

Formålet med dynamisk datamaskering er å begrense eksponeringen av sensitive data, noe som hindrer brukere som ikke skal ha tilgang til dataene fra å vise dem. Dynamisk datamaskering tar ikke sikte på å hindre databasebrukere i å koble direkte til databasen og kjøre uttømmende spørringer som viser deler av sensitive data.

Dynamisk datamaskering er komplementært til andre fabric-sikkerhetsfunksjoner, for eksempel sikkerhet på kolonnenivå og sikkerhet på radnivå. Det anbefales på det sterkeste å bruke disse databeskyttelsesfunksjonene sammen for å beskytte sensitive data i databasen.

Definer en dynamisk datamaske

En maskeringsregel kan defineres på en kolonne i en tabell for å skjule dataene i denne kolonnen. Fem typer masker er tilgjengelige.

Function Bekrivelse Eksempler
Default Fullstendig maskering i henhold til datatypene for de angitte feltene.

Bruk (eller færre) for strengdatatyper XXXX hvis størrelsen på feltet er færre enn 4 tegn (tegn, nchar, varchar, nvarchar, text, ntext).

For numeriske datatyper bruker du en nullverdi (bigint, bit, desimal, int, penger, numerisk, smallint, smallmoney, tinyint, float, real).

For datatyper for dato og klokkeslett bruker 1900-01-01 00:00:00.0000000 du (dato, datetime2, datetime, datetimeoffset, smalldatetime, time).

For binære datatyper bruker du én byte med ASCII-verdi 0 (binær, varbinær, bilde).		 Eksempel på kolonnedefinisjonssyntaks: Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL

Eksempel på endringssyntaks: ALTER COLUMN Gender ADD MASKED WITH (FUNCTION = 'default()')
Email Maskeringsmetode som viser den første bokstaven i en e-postadresse og konstant suffikset ".com", i form av en e-postadresse. aXXX@XXXX.com. Eksempel på definisjonssyntaks: Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL

Eksempel på endringssyntaks: ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()')
Tilfeldig En tilfeldig maskefunksjon for bruk på en hvilken som helst numerisk type for å maskere den opprinnelige verdien med en tilfeldig verdi innenfor et angitt område. Eksempel på definisjonssyntaks: Account_Number bigint MASKED WITH (FUNCTION = 'random([start range], [end range])')

Eksempel på endringssyntaks: ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)')
Egendefinert streng Maskeringsmetode som viser de første og siste bokstavene og legger til en egendefinert utfyllingsstreng i midten. prefix,[padding],suffix

Hvis den opprinnelige verdien er for kort til å fullføre hele masken, vises ikke en del av prefikset eller suffikset.		 Eksempel på definisjonssyntaks: FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(prefix,[padding],suffix)') NULL

Eksempel på endringssyntaks: ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)')

Dette gjør et telefonnummer som 555.123.1234 om til 5XXXXXXX.

Tilleggseksempel:

ALTER COLUMN [Phone Number] ADD MASKED WITH (FUNCTION = 'partial(5,"XXXXXXX",0)')

Dette gjør et telefonnummer som 555.123.1234 om til 555.1XXXXXXX.

Hvis du vil ha flere eksempler, kan du se Slik implementerer du dynamisk datamaskering i Synapse Data Warehouse.

Tillatelser

Brukere uten administrator-, medlems- eller bidragsyterrettigheter i arbeidsområdet, og uten utvidede tillatelser på lageret, vil se maskerte data.

Du trenger ingen spesiell tillatelse til å opprette en tabell med en dynamisk datamaske, bare standard CREATE TABLE - og ALTER skjematillatelser.

Hvis du legger til, erstatter eller fjerner masken for en kolonne, må du ha ALTER ANY MASK tillatelse og ALTER tillatelse i tabellen. Det er riktig å gi ALTER ANY MASK til en sikkerhetsoffiser.

Brukere med SELECT tillatelse i en tabell kan vise tabelldataene. Kolonner som er definert som maskerte, viser maskerte data. UNMASK Gi tillatelse til en bruker for å gjøre dem i stand til å hente umaskerte data fra kolonnene som maskering er definert for.

Tillatelsen CONTROL for databasen inneholder både ALTER ANY MASK og UNMASK tillatelsen som gjør det mulig for brukeren å vise umaskerte data. Administrative brukere eller roller som administrator, medlem eller bidragsyter har KONTROLL-tillatelse i databasen ved å utforme og kan vise umaskerte data som standard. Utvidede tillatelser på lageret inkluderer CONTROL tillatelse.

Sikkerhetshensyn: omgå maskering ved hjelp av slutning eller brute-force teknikker

Dynamisk datamaskering er utformet for å forenkle programutviklingen ved å begrense dataeksponering i et sett med forhåndsdefinerte spørringer som brukes av programmet. Dynamisk datamaskering kan også være nyttig for å forhindre utilsiktet eksponering av sensitive data når du får tilgang til data direkte, men det er viktig å være oppmerksom på at uprivilegerte brukere med spørringstillatelser kan bruke teknikker for å få tilgang til de faktiske dataene.

Som et eksempel kan du vurdere en bruker som har tilstrekkelige rettigheter til å kjøre spørringer på lageret, og prøver å "gjette" de underliggende dataene og til slutt utlede de faktiske verdiene. Anta at vi har en maske som er definert i [Employee].[Salary] kolonnen, og at denne brukeren kobler direkte til databasen og begynner å gjette verdier, og etter hvert utleder [Salary] verdien i Employees tabellen:

SELECT ID, Name, Salary FROM Employees
WHERE Salary > 99999 and Salary < 100001;

Resulterer i:

ID Name Lønn
62543 Jane Doe 0
91245 John Smith 0

Dette viser at dynamisk datamaskering ikke bør brukes alene for å sikre sensitive data fra brukere med spørringstilgang til endepunktet lager- eller SQL-analyse. Det er egnet for å forhindre sensitiv dataeksponering, men beskytter ikke mot ondsinnede hensikter for å utlede de underliggende dataene.

Det er viktig å behandle sikkerhet på objektnivå på riktig måte med SQL-detaljerte tillatelser, og alltid følge prinsippet om minimale nødvendige tillatelser.

Relatert innhold

Neste trinn

Slik implementerer du dynamisk datamaskering i Synapse Data Warehouse