Maskering [1] (tilsløring [2] ) af data er en måde at beskytte fortrolig information mod uautoriseret adgang ved at erstatte de originale data med fiktive data eller vilkårlige tegn. Samtidig ser den maskerede information realistisk og konsistent ud og kan bruges i softwaretestprocessen. I de fleste tilfælde bruges maskering til at beskytte personlige data og fortrolige oplysninger om organisationen.
Brugen af datamaskering er mest almindelig i applikationsudviklingsprocessen . Samtidig er det almindelig praksis at bruge produktionsdata på alle udviklingsstadier: ved oprettelse af applikationer og udvidelser , ved test- og fejlretningsstadier .
Hovedproblemet set fra ledelsen af virksomheder [3] og organisationer er, at applikationsudviklere ikke altid udsættes for verifikation af virksomhedernes sikkerhedstjenester, før de får adgang til produktionsdata. Denne praksis kan føre til alvorlige sikkerhedssårbarheder, da data kan kopieres af uautoriserede brugere, og sikkerhedsforanstaltninger på forskellige stadier af produktionen let kan omgås.
Den generelle datamaskeringspraksis på organisationsniveau bør være tæt forbundet med kontrolsystemernes testpraksis [4] og kernemetoden og bør omfatte processer til distribution af test af delmængder af maskerede data [5] .
Maskerede data skal opfylde følgende kriterier:
Udskiftning er en af de mest effektive maskeringsteknikker til at bevare dataens oprindelige udseende. For eksempel, hvis den originale databasetabel indeholder poster med oplysninger om kunder, så kan rigtige navne og efternavne erstattes med navne og efternavne taget fra en specielt oprettet (forberedt) fil. Så i det første trin af maskeringen kan alle kundenavne erstattes med vilkårlige mandsnavne, og på det andet trin kan kvindenavne indsættes i de celler, der svarer til kvindelige kunder (ved at filtrere kundelisten efter celle med køn). Ved at anvende denne tilgang til maskering kan du sikre korrekt anonymitet af posterne og bevare kønsforholdet mellem klienter i den maskerede tabel. Det er vigtigt, at databasen samtidig ser realistisk ud, og det at maskere information er ikke indlysende.
Erstatningsmetoden kan bruges til databasefelter, der indeholder data af forskellig art: for eksempel telefonnumre, postnumre, numre på betalingskort, forsikringsbeviser osv. Det er vigtigt, at fiktive numre ved plastikkortnumre skal lykkes. bestå checken i henhold til algoritmen Moon .
I de fleste tilfælde bør dummy-datafiler være store nok til at tillade så meget variation som muligt, samtidig med at der er mulighed for selvkompilering af erstatningsdatasæt. Disse kriterier er nøglen, når du vælger en softwareløsning til datamaskering.
Blanding er en meget almindelig måde at maskere data på. Det ligner erstatningsmetoden beskrevet ovenfor, men når der blandes, tages erstatningsdataene fra den samme tabelkolonne som de originale data. Kort sagt blandes dataene i en kolonne tilfældigt.
Camouflage alene ved brug af denne metode har dog alvorlige ulemper. En angriber, der har adgang til nogle af de rigtige oplysninger, kan gendanne resten af dataene gennem analyse ved hjælp af "hvad nu hvis?"-metoden. Derudover kan blanding vendes ved at dechifrere dens algoritme.
På trods af dens mangler er blandingsmetoden en fantastisk tilføjelse til andre datamaskeringsmetoder og kan give nogle fordele i visse tilfælde. For at maskere regnskaber kan du f.eks. erstatte leverandørnavne og derefter blande kontonumre i hele databasen. Samtidig er det yderst usandsynligt, at nogen, selv med begrænset adgang til de originale data, vil være i stand til at gendanne dem.
Varians (scatter) metoden bruges, når der arbejdes med databasefelter, der indeholder økonomiske oplysninger og datoer. Denne metode består i at afvige den maskerede numeriske værdi fra den oprindelige med et vist beløb. For eksempel, når du maskerer celler, der indeholder medarbejderløndata, kan afvigelsen fra den oprindelige værdi være ± 10 %, så den maskerede information ser ret realistisk og logisk ud.
Det samme gælder for kolonner i databasetabeller, der indeholder datoer. Hvis maskering er påkrævet for at bevare integriteten af demografiske og aktuarmæssige oplysninger, så vil anvendelse af en afvigelse på ± 120 dage til kalenderdatofelter bevare deres forhold i tabellen, men det vil ikke være muligt at fastslå en persons identitet efter dato for fødsel for eksempel.
Kryptering er den mest sofistikerede måde at maskere data på. Krypteringsalgoritmen antager normalt tilstedeværelsen af en "nøgle", der er nødvendig for at dekryptere og se de originale data.
Ved første øjekast er kryptering en ideel løsning på problemet med at begrænse adgangen til information, men i praksis kan "nøglen" overføres til en medarbejder, der ikke har tilstrækkelige rettigheder til at se dataene, og det annullerer alle bestræbelser på at skjule .
Kryptering kan også ledsages af konvertering af de originale data til en binær form, hvilket kan forårsage problemer i applikationer. For at identificere og eliminere konflikter inden for applikationer er det nødvendigt at udføre test med overførsel af indledende information til testere, og dette indebærer igen kontrol af de it-specialister, der er involveret i test af sikkerhedstjenesten. En god idé i teorien, når den implementeres i praksis, forårsager mange vanskeligheder: kryptering tager meget tid at teste og eliminere de identificerede mangler.
For nylig er problemerne forbundet med kryptering blevet erkendt af softwareudviklere og det videnskabelige samfund. Resultatet af forskning på dette område var fremkomsten af nye krypteringsalgoritmer, der giver dig mulighed for at gemme det originale dataformat - FPE (formatbeskyttelseskryptering) .
Nogle gange bruges en forenklet datamaskeringsmetode, som består i at erstatte tegn i en databasepost med nuller eller vilkårlige tegn (f.eks. stjerner eller "X"). Denne metode giver dig naturligvis kun mulighed for at skjule, ikke maskere den oprindelige værdi. I næsten alle tilfælde reducerer denne tilgang graden af dataintegritet, fordi den forårsager problemer med datavalidering af applikationer. Derudover indikerer "unaturlige" værdier i databaseposterne tydeligt, at maskering er blevet anvendt på tabellen.
Oftest bruges denne maskeringsmetode i processen med at arbejde med betalingskort. For eksempel kan callcenteroperatører af onlinebutikker kun se de sidste fire cifre i en kundes kreditkortnummer (XXXX XXXX XXXX 6789), men efter at have bekræftet dataene, sender faktureringssystemet det fulde kortnummer til betalingssystemet .
Dette system er ikke særlig effektivt til testsystemer, men nyttigt til faktureringsscenariet beskrevet ovenfor. Det er også almindeligt kendt som en måde at maskere data dynamisk på [6] .
Der er to hovedtyper af datamaskering: statisk og dynamisk maskering.
Statisk datamaskering bruges typisk, når en database skal overdrages til test (for eksempel ved outsourcet ). Databaseadministratoren opretter en kopi af produktionsdatabasen, uploader den til en separat server, reducerer mængden af information, der er indeholdt i den, efterlader kun den information, der er nødvendig for at udføre specifikke test, anvender derefter maskering, foretager de nødvendige ændringer i programkoden, og sender den maskerede kopi af databasen til udviklere eller testere.
Dynamisk maskering (realtidsmaskering, on-the-fly maskering) forekommer i processen med at overføre produktionsdata til udviklere uden mellemliggende optagelse til noget lagermedie .
Denne type maskering er den bedste løsning for organisationer , der bruger kontinuerlig integration og ikke har tid til at oprette og downloade databasebackups . Med kontinuerlig integration er det vigtigt konstant at kunne skubbe små sæt produktionsdata til udviklere til test.
Dynamisk maskering sker baseret på attributter og definerede politikker. For eksempel:
Dynamisk maskering kan også bruges sammen med datakryptering i realtid , især ved brug af formatbevarende kryptering.
I de senere år er cloud-baseret applikationsudvikling blevet stadig mere populær, uanset om disse applikationer kører direkte i skyen eller på en lokal computer. Der er forskellige metoder til at oprette testcases og flytte dem fra lokale databaser til "skyen" eller mellem forskellige miljøer inden for "skyen". Datamaskering bliver uundgåeligt en del af softwarens livscyklus .
|