Microsoft heeft een aantal beveiligingsfuncties in SQL Server 2017 die nuttig zijn voor verschillende doeleinden, afhankelijk van wat u probeert te beschermen en tegen welke bedreiging(en) u zich probeert te beschermen. Sommige van deze beveiligingsfuncties kunnen gevolgen hebben voor de prestaties waarvan u zich bewust moet zijn wanneer u beslist welke u wilt implementeren. Als inleiding zal ik enkele hoogtepunten van verschillende van deze beveiligingsfuncties bespreken.
Transparante databaseversleuteling (TDE)
Transparante gegevenscodering (TDE) is de vorm van codering van SQL Server in rust, wat betekent dat uw gegevensbestanden, logbestand, tempdb-bestanden en uw volledige, differentiële en logback-ups van SQL Server worden gecodeerd wanneer u TDE inschakelt voor een gebruikersdatabase . Dit beschermt uw gegevens tegen iemand die toegang krijgt tot die database of databaseback-upbestanden, zolang die persoon niet ook toegang heeft tot uw versleutelingscertificaten en sleutels.
De initiële TDE-coderingsscan voor een gebruikersdatabase gebruikt één CPU-thread op de achtergrond per gegevensbestand in de database (als de gegevensbestanden zich op afzonderlijke logische stations bevinden), om langzaam de volledige inhoud van het gegevensbestand in het geheugen te lezen met een snelheid van ongeveer 52 MB/seconde per gegevensbestand (als de gegevensbestanden zich op afzonderlijke logische stations bevinden).
De gegevens worden vervolgens gecodeerd met het door u gekozen coderingsalgoritme en vervolgens teruggeschreven naar het gegevensbestand met ongeveer 55 MB/per seconde (per gegevensbestand, als ze zich op afzonderlijke logische stations bevinden). Deze sequentiële lees- en schrijfsnelheden lijken met opzet te worden beperkt en zijn consistent in mijn tests op meerdere systemen met verschillende soorten opslag.
Het initiële TDE-coderingsproces vindt plaats op paginaniveau, onder SQL Server, dus het veroorzaakt geen vergrendeling of genereert geen transactielogboekactiviteit zoals u zou zien bij het opnieuw opbouwen van een index. U kunt een TDE-coderingsscan pauzeren door globale TF 5004 in te schakelen en de pauze ongedaan maken door TF 5004 uit te schakelen en uw ALTER DATABASE dbNAME SET ENCRYTION ON-opdracht opnieuw uit te voeren, zonder verlies van voortgang.
De CPU-impact van codering/decodering is aanzienlijk verminderd op SQL Server 2016 en nieuwer als u een processor hebt die AES-NI-hardware-instructies ondersteunt. In de serverruimte werden deze geïntroduceerd in de Intel Xeon 5600-productfamilie (Westmere-EP) voor servers met twee sockets en de Intel Xeon E7-4800/8800-productfamilie (Westmere-EX) voor servers met vier en acht sockets. Elke nieuwere Intel-productfamilie heeft ook AES-NI-ondersteuning. Als u twijfelt of uw processor AES-NI ondersteunt, kunt u zoeken naar "AES" in de uitvoer van het instructieveld van CPU-Z, zoals u ziet in afbeelding 1.
Afbeelding 1:CPU-Z-uitvoer met ondersteuning voor AES-instructies
Nadat u een database met TDE hebt versleuteld, is de runtime-impact van TDE moeilijk voorspelbaar te kwantificeren, omdat dit absoluut afhankelijk is van uw werkbelasting. Als uw werklast bijvoorbeeld volledig in de bufferpool van SQL Server past, is er in wezen geen overhead van TDE. Als uw werklast daarentegen volledig zou bestaan uit tabelscans waarbij de pagina wordt gelezen en vervolgens vrijwel onmiddellijk wordt gewist, zou dat de maximale straf opleveren. De maximale straf voor een vluchtige I/O-workload is doorgaans minder dan 5% met moderne hardware en met SQL Server 2016 of later.
Het extra werk van TDE-decodering vindt plaats wanneer u gegevens vanuit de opslag in de bufferpool leest, en het extra werk van TDE-codering vindt plaats wanneer u de gegevens terugschrijft naar de opslag. Door ervoor te zorgen dat u niet onder geheugendruk staat, door een bufferpool te hebben die groot genoeg is en door index- en query-afstemming uit te voeren, wordt de prestatie-impact van TDE duidelijk verminderd. TDE versleutelt geen FILESTREAM-gegevens en een met TDE versleutelde database gebruikt geen directe bestandsinitialisatie voor zijn gegevensbestanden.
Vóór SQL Server 2016 werkten TDE en native back-upcompressie niet goed samen. Met SQL Server 2016 en hoger kunt u TDE en systeemeigen back-upcompressie samen gebruiken, zolang u een MAXTRANSFERSIZE opgeeft die groter is dan 64 K in de back-upopdracht. Het is ook erg belangrijk dat u up-to-date bent met uw cumulatieve updates, aangezien er meerdere belangrijke TDE-gerelateerde hotfixes zijn geweest voor zowel SQL Server 2016 als SQL Server 2017. Ten slotte is TDE nog steeds en alleen voor Enterprise Edition, zelfs na SQL Server 2016 SP1 (die veel functies voor alleen Enterprise aan de Standard Edition heeft toegevoegd).
Beveiliging op rijniveau (RLS)
Row-Level Security (RLS) beperkt de leestoegang en de meeste toegang op schrijfniveau op basis van kenmerken van de gebruiker. RLS maakt gebruik van zogenaamde predicaatgebaseerde toegangscontrole. SQL Server past de toegangsbeperkingen toe in de databaselaag, en deze worden elke keer toegepast wanneer gegevenstoegang wordt geprobeerd vanuit eender welke laag.
RLS werkt door een predikaatfunctie te maken die de rijen beperkt waartoe een gebruiker toegang heeft en vervolgens een beveiligingsbeleid en beveiligingspredicaat te gebruiken om die functie op een tabel toe te passen.
Er zijn twee soorten beveiligingspredikaten, namelijk filterpredikaten en blokpredikaten. Filterpredikaten filteren stil de rijen die beschikbaar zijn voor leesbewerkingen (SELECT, UPDATE en DELETE), door in wezen een WHERE-component toe te voegen die voorkomt dat de gefilterde rijen worden weergegeven in de resultatenset. Filterpredikaten worden toegepast tijdens het lezen van de gegevens uit de basistabel, en de gebruiker of toepassing weet niet dat rijen uit de resultaten worden gefilterd. Vanuit prestatieperspectief is het belangrijk om een rijopslagindex te hebben die uw RLS-filterpredikaat dekt.
Blokpredikaten expliciet, (met een foutmelding) blokschrijfbewerkingen (NA INSERT, NA UPDATE, BEFORE UPDATE en BEFORE DELETE) die het blokpredikaat zouden schenden.
Filter- en blokpredikaten worden gemaakt als inline tabelwaardefuncties. U moet ook de CREATE SECURITY POLICY T-SQL-instructie gebruiken om de filterfunctie op de relevante basistabel toe te passen en in te schakelen
RLS is toegevoegd in SQL Server 2016 en is beschikbaar in alle edities van SQL Server 2016 en nieuwer. RLS werkt niet met Filestream-, Polybase- en geïndexeerde weergaven. RLS kan de prestaties van zoeken in volledige tekst schaden en het kan ertoe leiden dat query's op columnstore-indexen uiteindelijk de rijmodus in plaats van de batchmodus gebruiken. Dit Microsoft-blogbericht bevat meer informatie over de prestatie-impact van RLS. Een goed voorbeeld van hoe u Query Store kunt gebruiken om de RLS-prestaties af te stemmen, vindt u hier.
Dynamische gegevensmaskering (DDM)
Dynamische gegevensmaskering (DDM) kan de blootstelling aan gevoelige gegevens helpen beperken door deze te maskeren voor niet-bevoorrechte gebruikers. DDM wordt toegepast op tabelniveau, zodat alle query's worden beïnvloed door de gegevensmaskering, terwijl de feitelijke maskeringsregels worden toegepast in afzonderlijke kolommen in de tabel.
Er zijn vier soorten gegevensmaskers die u kunt gebruiken, waaronder standaard, e-mail, aangepaste tekenreeks en willekeurig. Een standaardmasker biedt volledige standaardmaskering van de gegevens, afhankelijk van het gegevenstype. Een tekenreeksgegevenstype zou bijvoorbeeld een masker van 'XXXX' krijgen in plaats van de daadwerkelijke gegevens. Een e-mailmasker retourneert de eerste letter van het daadwerkelijke e-mailadres, gevolgd door [email protected], ongeacht het daadwerkelijke domeinachtervoegsel. Een aangepast tekenreeksmasker toont de eerste en laatste letters van de tekenreeks, met een aangepaste opvulling in het midden. Ten slotte wordt een willekeurig masker gebruikt om numerieke gegevens te maskeren en een willekeurige waarde in een gedefinieerd bereik te bieden. Gegevensmaskers kunnen worden gemaakt in een CREATE TABLE-instructie of met een ALTER COLUMN-instructie.
Dynamische gegevensmaskering biedt geen maskering voor bevoorrechte gebruikers die nog steeds rechtstreeks uw tabellen kunnen opvragen en de ontmaskerde gegevens kunnen zien. Maskeringsregels kunnen niet worden gebruikt met versleutelde kolommen (Always Encrypted), berekende kolommen of met Filestream-gegevens. Als er bestaande indexen zijn voor een kolom die u wilt maskeren, moet u de index verwijderen, het masker voor de kolom maken en vervolgens de index opnieuw maken. Het is ook mogelijk om de waarden voor gemaskeerde gegevenskolommen af te leiden door query's te schrijven waarmee de gebruiker uiteindelijk een waarde voor een gemaskeerde kolom kan raden.
Dynamic Data Masking is geïntroduceerd in SQL Server 2016 en is beschikbaar in alle edities van SQL Server. DDM is niet bedoeld als een sterke beveiligingsmaatregel zoals daadwerkelijke versleuteling, maar aan de andere kant lijkt de impact op de prestaties vrij verwaarloosbaar te zijn.