Microsoft има редица функции за сигурност в SQL Server 2017, които са полезни за различни цели, в зависимост от това какво се опитвате да защитите и от каква заплаха(и) се опитвате да защитите. Някои от тези функции за сигурност могат да имат последици за производителността, които трябва да сте наясно, когато решавате кои от тях искате да приложите. Като въведение ще покрия някои акценти на няколко от тези защитни функции.
Прозрачно криптиране на база данни (TDE)
Прозрачното криптиране на данни (TDE) е формата на криптиране на SQL Server в състояние на покой, което означава, че вашите файлове с данни, регистрационни файлове, tempdb файлове и пълните, диференциални и архивни копия на вашия SQL Server ще бъдат криптирани, когато активирате TDE в потребителска база данни . Това защитава вашите данни от това, че някой получава достъп до тези бази данни или архивни файлове на базата данни, стига този човек да няма достъп до вашите сертификати и ключове за криптиране.
Първоначалното сканиране с TDE криптиране за потребителска база данни ще използва една фонова нишка на процесора на файл с данни в базата данни (ако файловете с данни са разположени на отделни логически устройства), за бавно четене на цялото съдържание на файла с данни в паметта със скорост от около 52MB/секунда на файл с данни (ако файловете с данни са разположени на отделни логически устройства).
След това данните се криптират с избрания от вас алгоритъм за криптиране и след това се записват обратно във файла с данни с около 55 MB/с (на файл с данни, ако са на отделни логически устройства). Тези последователни скорости на четене и запис изглеждат нарочно ограничени и са последователни в моето тестване на множество системи с различни типове съхранение.
Първоначалният процес на TDE криптиране се случва на ниво страница, под SQL Server, така че не предизвиква заключване или генерира активност на регистрационния файл на транзакции, както бихте видели при повторното изграждане на индекс. Можете да поставите на пауза сканиране с TDE криптиране, като активирате глобалния TF 5004, и да го отмените, като деактивирате TF 5004 и стартирате отново вашата команда ALTER DATABASE dbNAME SET ENCRYTION ON, без загуба на напредък.
Въздействието на криптирането/декриптирането върху процесора е значително намалено при SQL Server 2016 и по-нови, ако имате процесор, който поддържа хардуерни инструкции на AES-NI. В сървърното пространство те бяха въведени в продуктовото семейство Intel Xeon 5600 (Westmere-EP) за сървъри с два сокета и продуктовото семейство Intel Xeon E7-4800/8800 (Westmere-EX) за сървъри с четири и осем гнезда. Всяко по-ново семейство продукти на Intel също ще има поддръжка на AES-NI. Ако се съмнявате дали вашият процесор поддържа AES-NI, можете да потърсите „AES“ в полето за инструкции, изведено от CPU-Z, както виждате на фигура 1.
Фигура 1:Изход на CPU-Z, показващ поддръжка на AES инструкции
След като сте криптирали база данни с TDE, въздействието на TDE по време на изпълнение е трудно да се определи количествено, защото абсолютно зависи от вашето работно натоварване. Ако например вашето работно натоварване се вписва изцяло в буферния пул на SQL Server, тогава ще има по същество нулеви допълнителни разходи от TDE. Ако, от друга страна, вашето работно натоварване се състоеше изцяло от сканиране на таблици, където страницата се чете и след това се изтрива почти веднага, това би наложило максимално наказание. Максималното наказание за променливо I/O работно натоварване обикновено е по-малко от 5% с модерен хардуер и със SQL Server 2016 или по-нова версия.
Допълнителната работа на TDE декриптирането се случва, когато четете данни в буферния пул от хранилището, а допълнителната работа на TDE криптирането се случва, когато запишете данните обратно в хранилището. Да се уверите, че не сте под напрежение в паметта, като имате достатъчно голям буферен пул и като направите настройка на индекси и заявки, очевидно ще намалите въздействието върху производителността на TDE. TDE не криптира FILESTREAM данни и TDE криптирана база данни няма да използва незабавна инициализация на файл за своите файлове с данни.
Преди SQL Server 2016 TDE и естествената компресия на архивиране не работеха добре заедно. Със SQL Server 2016 и по-нови версии можете да използвате TDE и собствена компресия на архивиране заедно, стига да посочите MAXTRANSFERSIZE, който е по-голям от 64K в командата за архивиране. Също така е много важно да сте актуални с вашите кумулативни актуализации, тъй като има множество важни актуални корекции, свързани с TDE както за SQL Server 2016, така и за SQL Server 2017. И накрая, TDE все още е функция само за Enterprise Edition, дори след SQL Server 2016 SP1 (който добави много функции само за предприятия към Standard Edition).
Сигурност на ниво ред (RLS)
Защитата на ниво ред (RLS) ограничава достъпа за четене и повечето достъп на ниво запис въз основа на атрибутите на потребителя. RLS използва това, което се нарича контрол на достъп, базиран на предикати. SQL Server прилага ограниченията за достъп в нивото на базата данни и те ще се прилагат всеки път, когато се направи опит за достъп до данни от което и да е ниво.
RLS работи, като създава предикатна функция, която ограничава редовете, до които потребителят има достъп, и след това използва политика за сигурност и предикат за сигурност, за да приложи тази функция към таблица.
Има два типа предикати за сигурност, които са предикати за филтриране и предикати за блок. Предикатите за филтриране ще филтрират безшумно редовете, налични за операции за четене (SELECT, UPDATE и DELETE), като по същество добавят клауза WHERE, която предотвратява показването на филтрираните редове в набора от резултати. Предикатите на филтъра се прилагат при четене на данните от основната таблица и потребителят или приложението няма да знаят, че редовете се филтрират от резултатите. Важно е от гледна точка на производителността да имате индекс на хранилище на редове, който покрива предиката на филтъра на RLS.
Блокирайте предикатите изрично, (със съобщение за грешка) блокирайте операции за запис (СЛЕД ВМЕСВАНЕ, СЛЕД АКТУАЛИЗИРАНЕ, ПРЕДИ АКТУАЛИЗИРАНЕ и ПРЕДИ ИЗТРИВАНЕ), които биха нарушили предиката на блока.
Предикатите на филтъра и блока се създават като вградени функции с таблично стойности. Ще трябва също да използвате оператора CREATE SECURITY POLICY T-SQL, за да приложите и активирате функцията за филтриране към съответната базова таблица
RLS беше добавен в SQL Server 2016 и е наличен във всички издания на SQL Server 2016 и по-нови. RLS няма да работи с Filestream, Polybase и индексирани изгледи. RLS може да навреди на производителността на пълнотекстово търсене и може да принуди заявките за индекси на columnstore да използват режим на ред вместо пакетен режим. Тази публикация в блога на Microsoft съдържа повече информация за въздействието върху производителността на RLS. Добър пример за това как да използвате Query Store за настройка на RLS производителността е тук.
Динамично маскиране на данни (DDM)
Динамичното маскиране на данни (DDM) може да помогне за ограничаване на излагането на чувствителни данни, като ги маскира за непривилегировани потребители. DDM се прилага на ниво таблица, така че всички заявки са засегнати от маскирането на данни, докато действителните правила за маскиране се прилагат в отделни колони в таблицата.
Има четири типа маски за данни, които можете да използвате, които включват по подразбиране, имейл, персонализиран низ и произволен. Маската по подразбиране осигурява пълно маскиране по подразбиране на данните в зависимост от типа данни. Например, низов тип данни ще получи маска от „XXXX“ вместо действителните данни. Маска за имейл ще върне първата буква от действителния имейл адрес, последвана от [email protected], независимо от действителния суфикс на домейна. Персонализирана маска на низа ще покаже първата и последната буква на низа, с персонализиран подпълване в средата. И накрая, произволна маска се използва за маскиране на цифрови данни и предоставяне на произволна стойност в определен диапазон. Маските на данни могат да бъдат създадени в израз CREATE TABLE или с оператор ALTER COLUMN.
Динамичното маскиране на данни не осигурява маскиране за привилегировани потребители, които все още могат директно да правят заявки за вашите таблици и да виждат немаскираните данни. Правилата за маскиране не могат да се използват с криптирани колони (Винаги криптирани), изчислени колони или с данни от файлов поток. Ако има съществуващи индекси в колона, която искате да маскирате, ще трябва да пуснете индекса, да създадете маската върху колоната и след това да създадете отново индекса. Възможно е също така да се изведат стойностите за маскирани колони с данни чрез писане на заявки, които позволяват на потребителя евентуално да отгатне стойност за маскирана колона.
Динамичното маскиране на данни беше въведено в SQL Server 2016 и е достъпно във всички издания на SQL Server. DDM не е предназначена да бъде силна мярка за сигурност като действителното криптиране, но от друга страна, влиянието му върху производителността изглежда е доста незначително.
