Microsoft má v SQL Server 2017 řadu funkcí zabezpečení, které jsou užitečné pro různé účely v závislosti na tom, co se snažíte chránit a před jakými hrozbami se snažíte chránit. Některé z těchto funkcí zabezpečení mohou mít dopad na výkon, kterého byste si měli být vědomi, když se rozhodujete, které z nich chcete implementovat. V úvodu uvedu některé hlavní body několika z těchto funkcí zabezpečení.
Transparentní šifrování databáze (TDE)
Transparent Data Encryption (TDE) je forma šifrování SQL Serveru v klidu, což znamená, že vaše datové soubory, soubor protokolu, soubory tempdb a úplné, rozdílové a protokolové zálohy vašeho serveru SQL Server budou šifrovány, když povolíte TDE v uživatelské databázi. . To ochrání vaše data před tím, aby někdo získal přístup k těmto databázím nebo souborům zálohy databáze, pokud tato osoba nebude mít také přístup k vašim šifrovacím certifikátům a klíčům.
Počáteční skenování šifrování TDE pro uživatelskou databázi použije jedno vlákno CPU na pozadí na datový soubor v databázi (pokud jsou datové soubory umístěny na samostatných logických jednotkách), aby se celý obsah datového souboru pomalu načetl do paměti rychlostí přibližně 52 MB/s na datový soubor (pokud jsou datové soubory umístěny na samostatných logických jednotkách).
Data jsou poté zašifrována vámi zvoleným šifrovacím algoritmem a poté zapsána zpět do datového souboru rychlostí přibližně 55 MB/s (na datový soubor, pokud jsou na samostatných logických jednotkách). Tyto sekvenční rychlosti čtení a zápisu se zdají být záměrně omezeny a jsou konzistentní při mém testování na více systémech s různými typy úložiště.
Počáteční proces šifrování TDE probíhá na úrovni stránky, pod SQL Serverem, takže nezpůsobuje zamykání ani negeneruje aktivitu protokolu transakcí, jako byste viděli při opětovném sestavení indexu. Skenování šifrování TDE můžete pozastavit povolením globálního TF 5004 a jeho pozastavení zrušit vypnutím TF 5004 a opětovným spuštěním příkazu ALTER DATABASE dbNAME SET ENCRYTION ON bez ztráty průběhu.
Vliv šifrování/dešifrování na CPU je výrazně snížen na SQL Server 2016 a novější, pokud máte procesor, který podporuje hardwarové instrukce AES-NI. V oblasti serverů byly představeny v produktové řadě Intel Xeon 5600 (Westmere-EP) pro servery se dvěma paticemi a v rodině produktů Intel Xeon E7-4800/8800 (Westmere-EX) pro servery se čtyřmi a osmi paticemi. Všechny novější produkty řady Intel budou mít také podporu AES-NI. Pokud máte pochybnosti o tom, zda váš procesor podporuje AES-NI, můžete hledat „AES“ ve výstupu pole instrukcí z CPU-Z, jak vidíte na obrázku 1.
Obrázek 1:Výstup CPU-Z s podporou instrukcí AES
Poté, co jste zašifrovali databázi pomocí TDE, je obtížné předvídatelně kvantifikovat dopad TDE za běhu, protože absolutně závisí na vaší pracovní zátěži. Pokud se například vaše pracovní zatížení zcela vejde do oblasti vyrovnávacích pamětí serveru SQL Server, bude v podstatě nulová režie z TDE. Pokud by na druhou stranu vaše pracovní zátěž sestávala výhradně z prohledávání tabulek, kde je stránka načtena a poté téměř okamžitě vyprázdněna, znamenalo by to maximální trest. Maximální penalizace za nestabilní I/O zátěž je obvykle méně než 5 % s moderním hardwarem a SQL Serverem 2016 nebo novějším.
K práci navíc při dešifrování TDE dochází, když čtete data do zásobníku vyrovnávacích pamětí z úložiště, a k práci navíc při šifrování TDE dochází, když data zapisujete zpět do úložiště. Ujištění se, že nejste pod tlakem paměti, tím, že budete mít dostatečně velký fond vyrovnávací paměti a provedete ladění indexů a dotazů, samozřejmě sníží dopad TDE na výkon. TDE nešifruje data FILESTREAM a databáze šifrovaná TDE nebude používat okamžitou inicializaci souborů pro své datové soubory.
Před SQL Serverem 2016 nefungovaly TDE a nativní komprese zálohy společně. Se serverem SQL Server 2016 a novějším můžete používat TDE a nativní kompresi záloh společně, pokud v příkazu backup zadáte MAXTRANSFERSIZE větší než 64 kB. Je také velmi důležité, abyste měli aktuální informace o svých kumulativních aktualizacích, protože existuje několik důležitých oprav hotfix souvisejících s TDE pro SQL Server 2016 i SQL Server 2017. Konečně, TDE je stále a pouze funkce Enterprise Edition, a to i po SQL Server 2016. SP1 (který přidal do Standard Edition mnoho funkcí pouze pro podniky).
Row-Level Security (RLS)
Row-Level Security (RLS) omezuje přístup pro čtení a většinu přístupu na úrovni zápisu na základě atributů uživatele. RLS používá to, co se nazývá řízení přístupu na základě predikátu. SQL Server aplikuje omezení přístupu v databázové vrstvě a budou použita při každém pokusu o přístup k datům z jakékoli vrstvy.
RLS funguje tak, že vytvoří predikátovou funkci, která omezuje řádky, ke kterým má uživatel přístup, a poté pomocí bezpečnostní zásady a predikátu zabezpečení použije tuto funkci na tabulku.
Existují dva typy predikátů zabezpečení, kterými jsou predikáty filtru a predikáty bloků. Predikáty filtru budou tiše filtrovat řádky dostupné pro operace čtení (SELECT, UPDATE a DELETE) v podstatě přidáním klauzule WHERE, která zabrání zobrazení filtrovaných řádků ve výsledkové sadě. Predikáty filtru se aplikují při čtení dat ze základní tabulky a uživatel nebo aplikace nepozná, že jsou z výsledků filtrovány řádky. Z hlediska výkonu je důležité mít index úložiště řádků, který pokrývá váš predikát filtru RLS.
Blokové predikáty explicitně (s chybovou zprávou) blokové operace zápisu (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE a BEFORE DELETE), které by porušily predikát bloku.
Predikáty filtrů a bloků se vytvářejí jako funkce s inline tabulkou. Budete také muset použít příkaz CREATE SECURITY POLICY T-SQL k použití a povolení funkce filtrování na příslušnou základní tabulku
RLS byl přidán do SQL Server 2016 a je k dispozici ve všech edicích SQL Server 2016 a novějších. RLS nebude fungovat s Filestream, Polybase a indexovanými pohledy. RLS může zhoršit výkon fulltextového vyhledávání a může přinutit, aby dotazy na indexy columnstore skončily v režimu řádků místo dávkového režimu. Tento příspěvek na blogu společnosti Microsoft obsahuje další informace o dopadu RLS na výkon. Dobrý příklad toho, jak používat Query Store k vyladění výkonu RLS, je zde.
Dynamické maskování dat (DDM)
Dynamické maskování dat (DDM) může pomoci omezit vystavení citlivým datům jejich maskováním pro neprivilegované uživatele. DDM se aplikuje na úrovni tabulky, takže maskování dat ovlivňuje všechny dotazy, zatímco skutečná pravidla maskování se aplikují v jednotlivých sloupcích tabulky.
Můžete použít čtyři typy datových masek, které zahrnují výchozí, e-mail, vlastní řetězec a náhodné. Výchozí maska poskytuje úplné výchozí maskování dat v závislosti na typu dat. Například datový typ řetězce získá masku „XXXX“ namísto skutečných dat. E-mailová maska vrátí první písmeno skutečné e-mailové adresy následované [email protected], bez ohledu na skutečnou příponu domény. Vlastní maska řetězce zobrazí první a poslední písmena řetězce s vlastní výplní uprostřed. Nakonec se náhodná maska používá k maskování číselných dat a poskytování náhodné hodnoty v definovaném rozsahu. Datové masky lze vytvořit pomocí příkazu CREATE TABLE nebo pomocí příkazu ALTER COLUMN.
Dynamické maskování dat neposkytuje žádné maskování pro privilegované uživatele, kteří mohou stále přímo dotazovat vaše tabulky a vidět odmaskovaná data. Pravidla maskování nelze použít se zašifrovanými sloupci (Always Encrypted), vypočítanými sloupci nebo s daty Filestream. Pokud ve sloupci, který chcete maskovat, existují indexy, budete muset index zrušit, vytvořit masku na sloupci a poté index znovu vytvořit. Je také možné odvodit hodnoty pro maskované sloupce dat napsáním dotazů, které uživateli umožní nakonec uhodnout hodnotu pro maskovaný sloupec.
Dynamické maskování dat bylo představeno v SQL Server 2016 a je k dispozici ve všech edicích SQL Server. DDM není zamýšleno jako silné bezpečnostní opatření jako skutečné šifrování, ale na druhou stranu se jeho dopad na výkon zdá být zcela zanedbatelný.