В тази статия ще разгледаме инструментите за сигурност на SQL Server и най-добрите практики за настройка и обезопасяване на тази СУБД..
Съдържание:
- Удостоверяване в SQL Server
- Упълномощаване в SQL Server
- Роли на приложението
- Филтриране на данни в SQL Server
- Схеми в SQL Server
- Шифроване на данни с помощта на SQL Server
- Използване на групови управлявани акаунти на услуги за SQL Server
- Оценка на уязвимостта на SQL Server чрез SSMS
- Одиторска дейност в SQL Server
- Най-добри практики за обща сигурност на SQL Server
Първо, нека си припомним основните концепции за сигурност на SQL Server. MSSQL контролира достъпа до обекти чрез заверка и упълномощаване.
- заверка - Това е процесът на влизане в SQL Server, когато потребителят предоставя своите данни на сървъра. Удостоверяването идентифицира потребителя, който е удостоверен;
- упълномощаване - това е процесът на определяне на кои защитени обекти потребителят може да получи достъп и какви операции са разрешени за тези ресурси.
Много обекти на SQL Server имат свои собствени разрешения, които могат да бъдат наследени от родителския обект. Разрешения могат да бъдат предоставени на отделен потребител, група или роля.
Удостоверяване в SQL Server
Акаунтът на SQL Server може да бъде разделен на 2 части: Име за вход и потребител.
- Име за вход - Това е глобалното влизане за целия екземпляр на SQL Server. С него преминавате през процеса на удостоверяване;
- потребител - това е член на базата данни, свързан с конкретно име за вход.
Например, може да бъде вашето влизане в сървъра домейн \ потребителско име, и потребителят в базата данни, свързана с това влизане, може да бъде извикан domain_databaseUser. Почти винаги името и потребителят за вход в базата данни съвпадат по име, но трябва да имате предвид, че те могат да се различават, да имат различни имена.
SQL Server поддържа 2 режима заверка:
- Удостоверяване на Windows (Удостоверяване на Windows) - удостоверяването се извършва чрез защита на Windows. Потребителите, които вече са удостоверени с Windows и имат права на SQL Server, не е необходимо да предоставят допълнителни идентификационни данни.
- Смесено удостоверяване (Смесено удостоверяване) - в този режим, освен автентификацията на Windows, автентичността на самия SQL Server се поддържа чрез вход и парола.
Microsoft препоръчва да се използва автентификация на Windows, ако е възможно. За удостоверяване чрез вход и парола данните (вход и парола) се предават по мрежата, макар и в криптирана форма. С удостоверяването на Windows се предават поредица от криптирани съобщения по мрежата, в която потребителската парола не е включена..
Но някои приложения, особено по-старите, не поддържат удостоверяване на Windows, така че когато задавате режима за удостоверяване, си струва да помислите кои приложения ще се свържат със сървъра.
SQL Server поддържа три типа Име за вход (имена за вход):
- Локален акаунт Потребител или акаунт за Windows домейн/ доверен домейн.
- Windows Group. Предоставяне на достъп до локална Windows група или група от AD домейн. Позволява ви да осигурите достъп на всички потребители, които са членове на групата.
- SQL Server Вход (Удостоверяване на SQL Server). SQL Server съхранява хеш на потребителско име и парола в базата данни майстор, използване на вътрешни методи за удостоверяване за проверка на вход.
SQL Server автоматично се интегрира с Active Directory. Ако искате да разпределите правата на домейн акаунт, трябва да използвате име на домейн и акаунт за вход в акаунта на NetBios. Например, за потребителско име в domain.local ще бъде „домейн \ потребителско име“.
Упълномощаване в SQL Server
За упълномощаване SQL Server използва защита на базата на роли, която ви позволява да присвоите разрешения на роля на Windows или група / домейн, вместо на отделни потребители. SQL Server има вградени роли на сървър и база данни, които имат предварително определен набор от разрешения.
Има 3 нива на сигурност в SQL Server; те могат да бъдат представени като йерархия от най-високо до най-ниско:
- Ниво на сървъра - на това ниво можете да разпространявате права върху бази данни, акаунти, роли на сървъра и групи за наличност;
- Ниво на база данни включват схеми, потребители на база данни, роли на базата данни и пълнотекстови каталози;
- Ниво на верига включват обекти като таблици, изгледи, функции и съхранени процедури.
Вградени сървърни роли
| роля | описание |
| администратор | Членът на ролята има пълни права върху всички ресурси на SQL Server. |
| ServerAdmin | Ролевите членове могат да променят настройките на конфигурация на ниво сървър и да изключат сървъра. |
| securityadmin | Участниците в ролята управляват входните данни и техните свойства. Те могат да предоставят права за достъп на GRANT, DENY и REVOKE на ниво сървър и на ниво база данни, ако имат достъп до него. securityadmin не се различава много от ролята на sysadmin, защото членовете на тази роля потенциално могат да получат достъп до всички ресурси на SQL Server. |
| processadmin | Участниците в ролята могат да прекратят процесите, работещи в SQL Server. |
| setupadmin | Членовете на ролите могат да добавят и премахват свързани сървъри, използвайки TSQL. |
| bulkadmin | Ролевите членове могат да изпълняват BULK INSERT операции. |
| diskadmin | Ролевите членове могат да управляват резервни устройства. На практика тази роля практически не се прилага.. |
| dbcreator | Членовете на ролите могат да създават, променят, изтриват и възстановяват бази данни. |
| обществен | Всяко влизане в SQL Server е в тази роля. Публичното членство не може да бъде променено. Когато потребителят няма разрешение за обекта, до който има достъп, той наследява разрешенията за обществена роля за този обект. |
Схема за роля на SQL Server:
На практика използването на сървърни роли не е особено често, защото често потребителят се нуждае от уникален набор от разрешения. Изключение може да бъде ролята на sysadmin за системните администратори и обществената роля.
Роли за вградени бази данни
| роля | описание |
| db_owner | Участниците в ролята могат да изпълнят всички стъпки за конфигуриране и поддържане на базата данни, включително изтриване. |
| db_securityadmin | Ролевите членове могат да променят членството на други роли. Членовете на тази група могат потенциално да увеличат правата си на db_owner, така че трябва да вземете предвид тази роля, еквивалентна на db_owner. |
| db_accessadmin | Членовете на ролите могат да контролират достъпа до база данни за съществуващи вход на сървъра. |
| db_backupoperator | Ролевите членове могат да архивират базата данни. |
| db_ddladmin | Членовете на ролите могат да изпълнят всяка команда DDL в базата данни. |
| db_datawriter | Членовете на ролите могат да създават / променят / изтриват данни във всички потребителски таблици в базата данни. |
| db_datareader | Ролевите членове могат да четат данни от всички потребителски таблици. |
| db_denydatawriter | |
| db_denydatareader | Членовете на ролите отказаха достъп до таблици с бази данни на потребители. |
Също така си струва отделно да се подчертаят специални роли в базата данни msdb.
| db_ssisadmin db_ssisoperator db_ssisltduser | Членовете на тези роли могат да администрират и използват SSIS (SQL Server Integration Services). |
| dc_admin dc_operator dc_proxy | Членовете на тези роли могат да администрират и използват колектора на данни.. |
| PolicyAdministratorRole | Членовете на тази роля имат пълен достъп до политиките на SQL Server. |
| ServerGroupAdministratorRole ServerGroupReaderRole | Членовете на тези роли имат пълен достъп до регистрирани групи сървъри.. |
| SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole | Членовете на тези роли имат пълен достъп до задания на SQL Server Agent. |
Схемата за вградените роли на базата данни в SQL Server:
Роли на приложението
Ролята на приложението е обект на база данни (същият като обикновената роля на базата данни), който позволява удостоверяването с парола да промени контекста на защита в базата данни. За разлика от ролите на базата данни, ролите на приложението са неактивни по подразбиране и се активират, когато приложението изпълни sp_setapprole и въведе съответната парола.
За разлика от обикновените роли, ролите за приложение почти никога не се използват. Като изключение тяхното приложение може да се намери в многослойни приложения..
Филтриране на данни в SQL Server
Филтрирането на данни в SQL Server чрез съхранени процедури / изгледи / функции може да бъде причислено към прилагането на принципа на най-малко привилегии, тъй като не предоставяте достъп до всички данни в таблицата, а само до някои от тях.
Например, можете да предоставите на потребителя само права на SELECT от изгледа и да предотвратите директен достъп до таблиците, които се използват в изгледа. По този начин ще осигурите достъп само до част от данните от таблицата, като зададете филтъра където в изгледа.
Филтриране на данни чрез Row-Level Security
Защита на нивото на редовете или Защита на ниво ред (RLS) ви позволява да филтрирате данните от таблицата за различни потребители чрез персонализиран филтър. Това става чрез ПОЛИТИКА ЗА СИГУРНОСТ в T-SQL
В тази екранна снимка политиката е конфигурирана така, че потребителят Sales1 да вижда редовете на таблицата, в които стойността на колоната Sales е потребителското име (Sales1), а мениджърът ще вижда всички редове.
Схеми в SQL Server
Някои обекти на SQL Server (таблици, процедури, изгледи, функции) имат схема. Схемите могат да се разглеждат като контейнери за различни обекти (или пространство с имена, ако сте запознати с програмирането).
Например, ако потребителят има права да избира от схема, то потребителят може също така да избира от всички обекти на тази схема. Тоест обекти, които принадлежат към схемата, наследяват нейните разрешения. Когато потребителите създават обекти в диаграма, обектите принадлежат на собственика на диаграмата, а не на потребителя. Разрешенията не се наследяват от схемата от потребителите. Т.е. потребителите със стандартна dbo схема нямат разрешения, предоставени на тази схема - те трябва да бъдат изрично посочени.
Основната разлика между схемите и ролите е, че разрешенията за схеми могат да бъдат предоставени на ролите. Например, ролята на testrole може да има разрешения за избор от schema1 и разрешения за избор / актуализация на schema2. Един обект може да принадлежи само на една схема, но няколко роли могат да имат права върху него.
Вградени схеми
SQL Server има вградени системни схеми:
- DBO
- гост
- сис
- INFORMATION_SCHEMA
Dbo схемата е схемата по подразбиране за нови бази данни, а dbo потребителят е собственик на dbo схемата. По подразбиране новите потребители в базата данни имат dbo схема като схема по подразбиране. Други вградени схеми са необходими за системни обекти на SQL Server..
Шифроване на данни с помощта на SQL Server
SQL Server може да криптира данни, процедури и връзки към сървъра. Шифроването е възможно с помощта на сертификат, асиметричен или симетричен ключ. SQL Server използва йерархичен модел на криптиране, тоест всеки йерархичен слой криптира слоя под него. Поддържат се всички добре познати и популярни алгоритми за криптиране. За внедряване на алгоритмите за криптиране се използва API за криптовалута на Windows..
Най-често срещаните видове криптиране са TDE (прозрачно шифроване на данни) и винаги шифровано.
Прозрачно криптиране на данните
Прозрачно криптиране на данните или Прозрачно криптиране на данните криптира цялата база данни. Ако бъде откраднат физически носител или .mdf / .ldf файл, нападателят няма да има достъп до информация в базата данни.
Диаграма, за да представи целия процес
Основно криптиране на базата данни чрез T-SQL:
USE master;
GO
СЪЗДАВАНЕ НА МОЩНОТО КЛЮЧНО ВКЛЮЧВАНЕ ПО ПАРОЛЕТ = 'парола';
Go
CREATE CERTIFICATE ServerCert С SUBJECT = 'DEK сертификат';
Go
ИЗПОЛЗВАЙТЕ AdventureWorks2012;
GO
СЪЗДАВАНЕ КЛЮЧЪТ ЗА БЕЗОПАСНОСТ
С АЛГОРИТМ = AES_128
ВКЛЮЧВАНЕ ОТ СЕРВЕРСКА СЕРТИФИКАТ ServerCert;
GO
СЛЕД ДАТАБАЗА AdventureWorks2012
ВКЛЮЧЕТЕ ВКЛЮЧВАНЕТО;
GO
Винаги криптиран
Тази технология ви позволява да съхранявате криптирани данни в SQL Server, без да прехвърляте ключовете за криптиране на самия SQL Server. Винаги криптиран, като TDE, криптира данни в базата данни, но не на ниво база данни, а на ниво колона.
За криптиране, Always Encrypted използва 2 ключа:
- Ключ за шифроване на колони (CEK)
- Основен ключ на колоната (CMK)
Всички процеси на криптиране и декриптиране на данни се извършват на клиента, само криптираната стойност на ключа за криптиране (CEK) се съхранява в базата данни.
Винаги криптиран също ви позволява да ограничите достъпа до данни дори за DBA, като по този начин ви дава възможност да не се притеснявате, че администраторът ще получи достъп до данни, които не трябва.
Кога да използвам шифроване на SQL Server?
Шифроването на данни е една от важните мерки за сигурност, но криптирането може да е взискателно към сървърните ресурси и понякога може да бъде излишно..
Ако потребителите имат достъп до данни чрез обществена мрежа, тогава може да се изисква криптиране, за да се гарантира сигурността, но ако данните се предават през защитена интранет или VPN, няма нужда да криптирате данни. Също така си струва да се обмисли възможността за криптиране на данни, ако има заплаха от кражба на физически носители с бази данни.
Изпълнението на криптирането трябва да бъде добре планирано: трябва да вземете предвид допълнителното натоварване на сървъра, независимо дали приложенията, които работят с вашия сървър, могат да внедрят поддръжка за този тип криптиране от тяхна страна и много други нюанси.
Използване на групови управлявани акаунти на услуги за SQL Server
Групови управлявани акаунти за услуги или gMSA - Това е специален акаунт, който се управлява автоматично от Active Directory. gMSA е еволюция на MSA технологията, тъй като MSA не беше възможно да се използва в клъстър сценарии.
gMSA елиминира необходимостта от ръчна промяна на пароли за акаунт. Когато конфигурирате gMSA, посочвате на кои сървъри ще се работи акаунтът на gMSA, колко често Active Directory ще променя паролата и кой има право да вижда паролата. На сървърите, на които ще бъде инсталирана gMSA, не е необходимо да посочвате парола, когато посочвате съответния gMSA акаунт.
Имайте предвид, че версията на Windows Server за работа с gMSA трябва да е поне 2012 г..
Оценка на уязвимостта на SQL Server чрез SSMS
SQL Server Management Studio има функция за оценка на уязвимостта за базата данни..
Изберете база данни -> Задачи -> Оценка на уязвимостта -> Сканиране за уязвимости.
Скенерът ще оцени базата данни за популярни грешки в конфигурацията на защитата и ще даде подходящи препоръки..
Определено трябва да преминете през този скенер на база данни с този скенер. Може да разкрие скрити проблеми, които не се виждат на пръв поглед..
Одиторска дейност в SQL Server
SQL Server предоставя възможност за одит на всяка потребителска дейност в сървърна инстанция.
Това е много мощен инструмент, който ви позволява да контролирате напълно действията на вашите потребители / разработчици..
Помислете за основната настройка на одита:
В SSMS в раздела Сигурност -> Одити създайте нов одит.
След това, за одит, трябва да създадете спецификация за одит, за да посочите събитията, които ще бъдат наблюдавани.
След като създадете и активирате одит, в дневника за одит можете да видите събитията, които се записват от одитната процедура..
Най-добри практики за обща сигурност на SQL Server
Винаги следвайте принципа на най-малко привилегия. Включително да конфигурирате акаунт на услуга на SQL Server с помощта на gMSA. Никога не използвайте домейн акаунт с права на администратор на домейн..
Принцип на най-малко привилегия
Когато правите нови потребители, се препоръчва да използвате принципа на LUA (Потребителски акаунт с най-малко привилегии или Сметка за най-малко права). Този принцип е важна част от сигурността на сървъра и данните..
За потребители с административни права се препоръчва да издават разрешения само за онези операции, които ще се нуждаят. Ролите на вградените сървъри трябва да се използват само когато наборът от разрешения им съвпада с задачите на потребителя..
Предоставяне на роли, а не на потребители
Когато има много потребители, управлението на техните разрешения става по-трудно и също така става по-трудно да се предотвратят грешки при предоставяне на права.
Препоръчва се да предоставите разрешения за роли и да добавяте потребители към ролите. По този начин ще постигнете по-голяма прозрачност, тъй като всички потребители на определена роля ще имат еднакви права. Добавянето или премахването на потребители от роля е по-лесно от създаването на индивидуални разрешителни набори за отделни потребители. Ролите може да са вложени, но това не се препоръчва поради по-малка прозрачност и потенциално влошаване на представянето (ако има твърде много вложени роли).
Можете да предоставите на потребителя права върху схемата. В този случай потребителите веднага ще могат да работят с новосъздадени обекти в тази схема, за разлика от ролите, когато създават нов обект, ролите ще трябва да получат права върху него.
