Data Security binnen een DWH of database

Hoe zorgen we ervoor dat we als developers kunnen voldoen aan de eisen rondom data security & privacy? GDPR staat al om de hoek, bescherming van (eigen) data wordt steeds belangrijker en moet je nog wel iedereen toegang geven tot alle data? Gelukkig heeft SQL Server een gereedschapskist vol met tools om data te beveiligen.

Voor een overzicht van alle SQL Server security features klik dan hier:
https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-encryption



 


 


 


 

Scenario: Receiving raw data via flat files
Zoals bij veel DWH landschappen gaan we in dit scenario ervan uit dat we onze data ontvangen in de vorm van ruwe data (waarschijnlijk in CSV-formaat). Deze ruwe data wordt ingelezen in de Staging-database.

Hieronder een voorbeeld van de ‘Customer’-dataset (AdventureWorks):



 


 


 


 


 


 

Hoe slaan we deze Customer-dataset op in onze Staging-database?
Let’s go, laten we een aantal features toepassen op deze dataset:
– Random Data Masking op [StoreID]
– Partial Data Masking op [Territory] en [AccountNumber]
Data Encryption (by passphrase) op [Group]

Stel je voor dat [Group] BSN-nummers bevat van particulieren klanten of zelfs creditcard nummers. Ook deze data wil je eigenlijk niet leesbaar opslaan voor Administrators :) Hiervoor gaan we Data Encryption gebruiken (ENCRYPTBYPASSPHRASE()).

Op de andere kolommen passen we verschillende vormen van Dynamic Data Masking toe (Random en Partial Data Masking). Wil je meer weten over Dynamic Data Masking? Klik hier.

 


 

Indien we alles toepassen, ziet een ‘normale‘ gebruiker het volgende:



 


 


 


Kijk goed naar de bovenstaande data:
– [StoreID] heeft andere numerieke waardes gekregen, een voorbeeld dat je kunt toepassen op financiële bedragen
– [Territoy] en [AccountNumber] hebben beide Partial Data Masking, of te wel ‘XXXX’ om het onleesbaar te maken
– [Group] is totaal onleesbaar gemaakt door middel van encryptie

 


 

Dynamic Data Masking is toegepast op de data, maar vergeet niet dat een Administrator standaard voldoende rechten heeft om de échte onderliggende data te zien:



 


 


 


 


 

Zoals je waarschijnlijk al opvalt, kunnen beide type gebruikers niet de waardes lezen in [Group] (in ons voorbeeld: BSN-nummers of creditcard nummers). Deze waardes moeten we decrypten vóórdat ze weer leesbaar zijn:



 


 


 


 


 


 

Stel je dus voor dat vanaf Staging alle gevoelige gegevens encrypt en deze pas in de presentatie-laag (rapport, cube, dashboard of website) decrypt, super secure! kleine catch, in tegenstelling tot Dynamic Data Masking, de encrypte waardes zijn niet bruikbaar om op te filteren bijvoorbeeld (indien je de échte waarde weet).

Om toch bijvoorbeeld een specifiek klantenrecord op te kunnen vragen, zou je aan hash (SHA2_512) kunnen toevoegen op basis van de echte waarde. Een hash kan niet decrypt worden en alleen met dezelfde waarde krijg je dezelfde hash. Dit bied je de mogelijkheid om dus via een omweg te kunnen queryen, laten we bijvoorbeeld zoeken naar de klant met AccountNumber ‘AW00000008’:

WHERE [AccountNumber_HashedSHA2_512] = CONVERT(char(128),HASHBYTES('SHA2_512','AW00000008'),(2))

Het resultaat met en zonder Dynamic Data Masking:



 


 

Meer info?
Nieuwsgierig naar de beveiligingsmogelijkheden binnen SQL Server 2016 / Azure SQL Database? Wellicht een demo?
Stuur dan een e-mail naar clint.huijbers@monkeyrecruitment.nl