Microsoft har en række sikkerhedsfunktioner i SQL Server 2017, der er nyttige til forskellige formål, afhængigt af hvad du forsøger at beskytte og hvilke trusler du forsøger at beskytte mod. Nogle af disse sikkerhedsfunktioner kan have ydeevneimplikationer, som du bør være opmærksom på, når du beslutter dig for, hvilke du vil implementere. Som en introduktion vil jeg dække nogle af højdepunkterne i flere af disse sikkerhedsfunktioner.
Transparent Database Encryption (TDE)
Transparent Data Encryption (TDE) er SQL Servers form for kryptering i hvile, hvilket betyder, at dine datafiler, logfil, tempdb-filer og din SQL Server fulde, differentielle og log backup vil blive krypteret, når du aktiverer TDE på en brugerdatabase . Dette beskytter dine data mod, at nogen får adgang til disse database- eller databasesikkerhedskopieringsfiler, så længe denne person ikke også har adgang til dine krypteringscertifikater og -nøgler.
Den indledende TDE-krypteringsscanning for en brugerdatabase vil bruge én baggrunds-CPU-tråd pr. datafil i databasen (hvis datafilerne er placeret på separate logiske drev), til langsomt at læse hele indholdet af datafilen ind i hukommelsen med en hastighed på ca. 52MB/sekund pr. datafil (hvis datafilerne er placeret på separate logiske drev).
Dataene krypteres derefter med din valgte krypteringsalgoritme og skrives derefter tilbage til datafilen med ca. 55MB/per sekund (pr. datafil, hvis de er på separate logiske drev). Disse sekventielle læse- og skrivehastigheder ser ud til at være bevidst begrænset og er konsistente i mine tests på flere systemer med forskellige typer lager.
Den indledende TDE-krypteringsproces sker på sideniveau, under SQL Server, så den forårsager ikke låsning eller genererer transaktionslogaktivitet, som du ville se ved genopbygning af et indeks. Du kan sætte en TDE-krypteringsscanning på pause ved at aktivere global TF 5004 og annullere pausen ved at deaktivere TF 5004 og køre din ALTER DATABASE dbNAME SET ENCRYTION ON-kommando igen uden tab af fremskridt.
CPU-påvirkningen af kryptering/dekryptering er stærkt reduceret på SQL Server 2016 og nyere, hvis du har en processor, der understøtter AES-NI-hardwareinstruktioner. På serverområdet blev disse introduceret i Intel Xeon 5600-produktfamilien (Westmere-EP) til to-socket-servere og Intel Xeon E7-4800/8800-produktfamilien (Westmere-EX) til fire- og otte-socket-servere. Enhver nyere Intel-produktfamilie vil også have AES-NI-understøttelse. Hvis du er i tvivl om, hvorvidt din processor understøtter AES-NI, kan du kigge efter "AES" i instruktionsfeltet output fra CPU-Z, som du ser i figur 1.
Figur 1:CPU-Z-output, der viser AES-instruktionsunderstøttelse
Efter du har krypteret en database med TDE, er runtime-påvirkningen af TDE svær at forudsigeligt kvantificere, fordi den helt afhænger af din arbejdsbyrde. Hvis f.eks. din arbejdsbyrde passer helt ind i SQL Server-bufferpuljen, vil der i det væsentlige være nul overhead fra TDE. Hvis din arbejdsbyrde på den anden side udelukkende bestod af tabelscanninger, hvor siden læses og derefter skylles næsten øjeblikkeligt, ville det pålægge den maksimale straf. Den maksimale straf for en I/O-flygtig arbejdsbelastning er typisk mindre end 5 % med moderne hardware og med SQL Server 2016 eller nyere.
Det ekstra arbejde med TDE-kryptering sker, når du læser data ind i bufferpuljen fra lageret, og det ekstra arbejde med TDE-kryptering sker, når du skriver dataene tilbage til lageret. At sikre, at du ikke er under pres på hukommelsen, ved at have en stor nok bufferpulje og ved at lave indeks- og forespørgselsindstilling vil naturligvis reducere TDEs ydeevnepåvirkning. TDE krypterer ikke FILESTREAM-data, og en TDE-krypteret database vil ikke bruge øjeblikkelig filinitialisering til sine datafiler.
Før SQL Server 2016 fungerede TDE og native backup-komprimering ikke godt sammen. Med SQL Server 2016 og nyere kan du bruge TDE og native backup-komprimering sammen, så længe du angiver en MAXTRANSFERSIZE, der er større end 64K i backup-kommandoen. Det er også meget vigtigt, at du er opdateret med dine kumulative opdateringer, da der har været flere vigtige TDE-relaterede hotfixes til både SQL Server 2016 og SQL Server 2017. Endelig er TDE stadig og Enterprise Edition eneste funktion, selv efter SQL Server 2016 SP1 (som føjede mange Enterprise-only-funktioner til Standard Edition).
Row-Level Security (RLS)
Row-Level Security (RLS) begrænser læseadgang og det meste på skriveniveau baseret på brugerens attributter. RLS bruger det, der kaldes prædikatbaseret adgangskontrol. SQL Server anvender adgangsbegrænsningerne i databaseniveauet, og de vil blive anvendt, hver gang der forsøges dataadgang fra et hvilket som helst niveau.
RLS fungerer ved at skabe en prædikatfunktion, der begrænser rækkerne, som en bruger kan få adgang til, og derefter bruge en sikkerhedspolitik og et sikkerhedsprædikat til at anvende denne funktion på en tabel.
Der er to typer sikkerhedsprædikater, som er filterprædikater og blokprædikater. Filterprædikater vil lydløst filtrere rækkerne, der er tilgængelige til at læse operationer (SELECT, UPDATE og DELETE), ved i det væsentlige at tilføje en WHERE-sætning, der forhindrer de filtrerede rækker i at blive vist i resultatsættet. Filterprædikater anvendes, mens dataene fra basistabellen læses, og brugeren eller applikationen ved ikke, at rækker filtreres fra resultaterne. Det er vigtigt ud fra et præstationsperspektiv at have et rækkelagerindeks, der dækker dit RLS-filterprædikat.
Blokerprædikater eksplicit (med en fejlmeddelelse) blokskrivningsoperationer (EFTER INSERT, EFTER UPDATE, FØR OPDATERING og FØR SLETT), som ville overtræde blokprædikatet.
Filter- og blokprædikater oprettes som inline-tabel-værdisatte funktioner. Du skal også bruge CREATE SECURITY POLICY T-SQL-erklæringen for at anvende og aktivere filtreringsfunktionen på den relevante basistabel
RLS blev tilføjet i SQL Server 2016 og er tilgængelig i alle udgaver af SQL Server 2016 og nyere. RLS fungerer ikke med Filestream, Polybase og indekserede visninger. RLS kan skade ydeevnen af fuldtekstsøgning, og det kan tvinge kolonnelagerindeksforespørgsler til at ende med at bruge rækketilstand i stedet for batchtilstand. Dette Microsoft blogindlæg har flere oplysninger om virkningen af RLS's ydeevne. Et godt eksempel på, hvordan du bruger Query Store til at tune RLS-ydeevne er her.
Dynamic Data Masking (DDM)
Dynamisk datamaskering (DDM) kan hjælpe med at begrænse eksponering af følsomme data ved at maskere den til ikke-privilegerede brugere. DDM anvendes på tabelniveau, så alle forespørgsler påvirkes af datamaskeringen, mens de faktiske maskeringsregler anvendes i individuelle kolonner i tabellen.
Der er fire typer datamasker, som du kan bruge, som inkluderer standard, e-mail, brugerdefineret streng og tilfældig. En standardmaske giver fuld standardmaskering af dataene afhængigt af datatypen. For eksempel vil en strengdatatype få en maske på 'XXXX' i stedet for de faktiske data. En e-mail-maske vil returnere det første bogstav i den faktiske e-mailadresse, efterfulgt af [email protected], uanset det faktiske domænesuffiks. En brugerdefineret strengmaske viser det første og sidste bogstav i strengen med en brugerdefineret polstring i midten. Endelig bruges en tilfældig maske til at maskere numeriske data og give en tilfældig værdi i et defineret område. Datamasker kan oprettes i en CREATE TABLE-sætning eller med en ALTER COLUMN-sætning.
Dynamisk datamaskering giver ingen maskering for privilegerede brugere, som stadig kan forespørge direkte i dine tabeller og se de afmaskede data. Maskeringsregler kan ikke bruges med krypterede kolonner (altid krypteret), beregnede kolonner eller med Filestream-data. Hvis der er eksisterende indekser på en kolonne, som du vil maskere, bliver du nødt til at droppe indekset, oprette masken på kolonnen og derefter genskabe indekset. Det er også muligt at udlede værdierne for maskerede datakolonner ved at skrive forespørgsler, der tillader brugeren til sidst at gætte en værdi for en maskeret kolonne.
Dynamic Data Masking blev introduceret i SQL Server 2016, og den er tilgængelig i alle udgaver af SQL Server. DDM er ikke beregnet til at være en stærk sikkerhedsforanstaltning som faktisk kryptering, men på den anden side ser dens ydeevnepåvirkning ud til at være ret ubetydelig.