Microsoft har ett antal säkerhetsfunktioner i SQL Server 2017 som är användbara för olika ändamål, beroende på vad du försöker skydda och vilka hot du försöker skydda dig mot. Vissa av dessa säkerhetsfunktioner kan ha prestandaimplikationer som du bör vara medveten om när du bestämmer dig för vilka du vill implementera. Som en introduktion kommer jag att täcka några av höjdpunkterna i flera av dessa säkerhetsfunktioner.
Transparent Databas Encryption (TDE)
Transparent Data Encryption (TDE) är SQL Servers form av kryptering i vila, vilket innebär att dina datafiler, loggfil, tempdb-filer och din SQL Server fullständiga, differentiella och loggbackuper kommer att krypteras när du aktiverar TDE i en användardatabas . Detta skyddar dina data från att någon får tillgång till dessa databas- eller databassäkerhetskopieringsfiler så länge den personen inte också har tillgång till dina krypteringscertifikat och nycklar.
Den initiala TDE-krypteringsskanningen för en användardatabas kommer att använda en bakgrunds-CPU-tråd per datafil i databasen (om datafilerna finns på separata logiska enheter), för att långsamt läsa in hela innehållet i datafilen i minnet med en hastighet av cirka 52 MB/sekund per datafil (om datafilerna finns på separata logiska enheter).
Data krypteras sedan med din valda krypteringsalgoritm och skrivs sedan tillbaka till datafilen med cirka 55 MB/per sekund (per datafil, om de finns på separata logiska enheter). Dessa sekventiella läs- och skrivhastigheter verkar vara avsiktligt strypta och är konsekventa i mina tester på flera system med olika typer av lagring.
Den initiala TDE-krypteringsprocessen sker på sidnivå, under SQL Server, så den orsakar inte låsning eller genererar transaktionsloggaktivitet som du skulle se när du återuppbyggde ett index. Du kan pausa en TDE-krypteringsskanning genom att aktivera global TF 5004 och ta upp paus genom att inaktivera TF 5004 och köra ditt ALTER DATABASE dbNAME SET ENCRYTION ON-kommando igen, utan förlust av framsteg.
CPU-effekten av kryptering/dekryptering minskar kraftigt på SQL Server 2016 och nyare om du har en processor som stöder AES-NI-hårdvaruinstruktioner. I serverutrymmet introducerades dessa i produktfamiljen Intel Xeon 5600 (Westmere-EP) för servrar med två sockel och produktfamiljen Intel Xeon E7-4800/8800 (Westmere-EX) för servrar med fyra och åtta socker. Alla nyare Intel-produktfamiljer kommer också att ha AES-NI-stöd. Om du är osäker på om din processor stöder AES-NI, kan du leta efter "AES" i instruktionersfältet från CPU-Z, som du ser i figur 1.
Figur 1:CPU-Z-utgång som visar AES-instruktionsstöd
Efter att du har krypterat en databas med TDE är körtidseffekten av TDE svår att förutsäga kvantifiera eftersom det helt beror på din arbetsbelastning. Om till exempel din arbetsbelastning passar helt och hållet i SQL Server-buffertpoolen skulle det i princip finnas noll overhead från TDE. Om din arbetsbelastning å andra sidan helt bestod av tabellskanningar där sidan läses och sedan spolas nästan omedelbart, skulle det innebära maxstraffet. Den maximala straffavgiften för en I/O flyktig arbetsbelastning är vanligtvis mindre än 5 % med modern hårdvara och med SQL Server 2016 eller senare.
Det extra arbetet med TDE-kryptering sker när du läser in data i buffertpoolen från lagring, och det extra arbetet med TDE-kryptering händer när du skriver tillbaka data till lagring. Att se till att du inte är under minnespress, genom att ha en tillräckligt stor buffertpool och genom att göra index- och frågejustering kommer uppenbarligen att minska prestandapåverkan av TDE. TDE krypterar inte FILESTREAM-data, och en TDE-krypterad databas kommer inte att använda omedelbar filinitiering för sina datafiler.
Före SQL Server 2016 fungerade inte TDE och native backup-komprimering bra tillsammans. Med SQL Server 2016 och senare kan du använda TDE och native backup-komprimering tillsammans så länge du anger en MAXTRANSFERSIZE som är större än 64K i backup-kommandot. Det är också mycket viktigt att du är uppdaterad med dina kumulativa uppdateringar, eftersom det har funnits flera viktiga TDE-relaterade snabbkorrigeringar för både SQL Server 2016 och SQL Server 2017. Slutligen, TDE är fortfarande och endast Enterprise Edition-funktionen, även efter SQL Server 2016 SP1 (som lade till många Enterprise-only-funktioner till Standard Edition).
Row-Level Security (RLS)
Row-Level Security (RLS) begränsar läsåtkomst och de flesta skrivnivååtkomster baserat på användarens attribut. RLS använder det som kallas predikatbaserad åtkomstkontroll. SQL Server tillämpar åtkomstbegränsningarna i databasnivån, och de kommer att tillämpas varje gång dataåtkomst försöks från valfri nivå.
RLS fungerar genom att skapa en predikatfunktion som begränsar raderna som en användare kan komma åt och sedan använda en säkerhetspolicy och ett säkerhetspredikat för att tillämpa den funktionen på en tabell.
Det finns två typer av säkerhetspredikat, som är filterpredikat och blockpredikat. Filterpredikat kommer tyst att filtrera raderna som är tillgängliga för att läsa operationer (SELECT, UPDATE och DELETE), genom att i huvudsak lägga till en WHERE-sats som förhindrar att de filtrerade raderna visas i resultatuppsättningen. Filterpredikat tillämpas när data från bastabellen läses, och användaren eller applikationen kommer inte att veta att rader filtreras från resultaten. Det är viktigt ur ett prestandaperspektiv att ha ett radlagerindex som täcker ditt RLS-filterpredikat.
Blockera predikat explicit (med ett felmeddelande) blockskrivningsoperationer (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE och BEFORE DELETE) som skulle bryta mot blockpredikatet.
Filter- och blockpredikat skapas som inline-tabellvärdade funktioner. Du måste också använda CREATE SECURITY POLICY T-SQL-satsen för att tillämpa och aktivera filtreringsfunktionen på den relevanta bastabellen
RLS lades till i SQL Server 2016 och är tillgänglig i alla utgåvor av SQL Server 2016 och nyare. RLS fungerar inte med Filestream, Polybase och indexerade vyer. RLS kan skada prestandan för fulltextsökning och det kan tvinga kolumnbutiksindexfrågor att sluta använda radläge istället för batchläge. Det här Microsoft-blogginlägget har mer information om effekten av RLS. Ett bra exempel på hur du använder Query Store för att justera RLS-prestanda finns här.
Dynamic Data Masking (DDM)
Dynamisk datamaskering (DDM) kan hjälpa till att begränsa exponeringen av känslig data genom att maskera den till icke-privilegierade användare. DDM tillämpas på tabellnivå så att alla frågor påverkas av datamaskeringen, medan de faktiska maskeringsreglerna tillämpas i enskilda kolumner i tabellen.
Det finns fyra typer av datamasker som du kan använda, som inkluderar standard, e-post, anpassad sträng och slumpmässig. En standardmask ger fullständig standardmaskering av data beroende på datatyp. Till exempel skulle en strängdatatyp få en mask av "XXXX" istället för den faktiska datan. En e-postmask kommer att returnera den första bokstaven i den faktiska e-postadressen, följt av [email protected], oavsett det faktiska domänsuffixet. En anpassad strängmask visar de första och sista bokstäverna i strängen, med en anpassad stoppning i mitten. Slutligen används en slumpmässig mask för att maskera numeriska data och tillhandahålla ett slumpmässigt värde inom ett definierat område. Datamasker kan skapas i en CREATE TABLE-sats eller med en ALTER COLUMN-sats.
Dynamisk datamaskering ger ingen maskering för privilegierade användare som fortfarande direkt kan fråga dina tabeller och se de omaskerade data. Maskeringsregler kan inte användas med krypterade kolumner (alltid krypterade), beräknade kolumner eller med Filestream-data. Om det finns befintliga index på en kolumn som du vill maskera, måste du släppa indexet, skapa masken på kolumnen och sedan återskapa indexet. Det är också möjligt att härleda värdena för maskerade datakolumner genom att skriva frågor som gör att användaren så småningom kan gissa ett värde för en maskerad kolumn.
Dynamic Data Masking introducerades i SQL Server 2016, och den är tillgänglig i alla utgåvor av SQL Server. DDM är inte tänkt att vara en stark säkerhetsåtgärd som faktisk kryptering, men å andra sidan verkar dess prestandapåverkan vara ganska försumbar.