DBA е пазител на данните и има два аспекта да бъдеш пазител. Първият е почтеността. Той включва задачи като проверка на последователността на базата данни, създаване на резервни копия и, ако се появят проблеми, разполагане на добре проектиран, изчерпателен план за възстановяване на базата данни.
Вторият аспект е сигурността. Предлага се да се уверите, че само оторизирани потребители имат достъп до данните и само до данните, от които се нуждаят.
Можете да намерите множество ресурси, посветени на сигурността в мрежата. Мисля обаче, че на някои важни неща им липсва подходящо внимание. В тази статия бих искал да се съсредоточа върху тези опции и да демонстрирам защо е важно да сте наясно с тях и да се справяте правилно с тях.
Мисия за компрометиране на SQL сървър
Нека имаме ролева игра, в която сте таен агент и вашата мисия, ако я приемете, е да откраднете много важни данни от TargetDB база данни, хоствана от SQL Server. Трябва да получите тези данни и да ги изтриете.
Възможно е да получите вход за вас, но всяко влизане на сървъра има изрични ОТКАЗВАНИ разрешения за целевата база данни и данни. Единствената информация, която нашият агент може да ви предостави, е тази, генерирана за проверка от протокола за сигурност по време на създаването на вашето влизане.
Информация за базата данни от целевия сървър.
Разрешения за сървъра:
Разрешения за база данни:
Като всеки свестен агент, нека си направим домашната работа и да проверим с какво се занимавате.
Не можете просто да влезете и да се свържете с TargetDB , тъй като всяко едно разрешение е отказано за вашето влизане и изрично картографиран потребител. Трябва да влезете от друга база данни.
Заключена врата
Действията с кръстосани бази данни не са лесни неща за правене. Считайте го като затворена врата с две брави. Тук няма да се фокусираме върху техническите подробности, но можете да се обърнете към статията Разширяване на представянето на база данни чрез използване на EXECUTE AS MSDN (горещо препоръчвам да го направите).
Първото заключване е Доверие на удостоверителя , а вторият е Доверие на базата данни .
Нека започнем с първото заключване. Доверяването на удостоверителя означава, че за достъп до друга база данни B, собственикът на база данни A трябва да получи (изрично или неявно) AUTHENTICATE разрешение в база данни B.
Чакай малко! Удостоверителят на ниво база данни е собственикът на самата база данни (Не я смесвайте с db_owner роля в базата данни!).
Проверете собствениците на база данни:
Въпреки че следват доста добра практика, като използват един акаунт на сървър, което не е SA , по този начин те любезно отвориха първата ключалка за вас.
Нека се съсредоточим върху второто заключване.
По някакъв начин трябва да създадете база данни на сървъра с ДОВЕРЕНА свойство ВКЛ. . Най-добрата практика тук е да зададете свойството на базата данни TRUSTWORTHY на ИЗКЛ. .
Това е моментът, в който трябва да кажем:ами ако вече имате такава база данни?
Това е базата данни MSDB.
Второто заключване е готово. Дори не се наложи да разбивате нито една от ключалките.
Значението на ролята на db_owner
Точно сега трябва да се справите с едно предизвикателство. По някакъв начин трябва да влезете в базата данни MSDB с db_owner роля в базата данни, тъй като има имплицитно, имитиращо разрешение.
Тъй като MSDB обикновено не е във фокуса на администраторите на бази данни, тази мисия вече не е невъзможна. Нека видим какво можете да направите само защото имате потребител с db_owner роля на база данни в базата данни MSDB:
Опитайте да се свържете с TargetDB :
Това е очаквана грешка. Запомнете протокола за защита, приложен към предоставеното вход. Да започнем.
Опитайте да се свържете с TargetDB и за да изберете целевите данни:
Работи! Нека го модифицираме и след това проверете действието.
Това е всичко.
Мисията е изпълнена.
Както видяхте, фокусирах се върху конкретна комбинация от конфигурация на база данни за сигурност. Това бяха собственикът на базата данни и ДОВЕРЕННИЯТ опция за база данни, обръщайки особено внимание на MSDB. Представеният сценарий беше само този, при който чувствителните данни могат да бъдат компрометирани по същия начин. Нека разгледаме друг възможен сценарий сега.
Собственик на базата данни + TRUSTWORTHY
Нека проверим фоновите подробности, като започнем с добре познатия проблем:собствеността на базата данни. Какви данни за вход трябва да използва собственикът на вашата база данни? Много хора казват, че SA е подходящ избор.
Направих бързо търсене в Google и намерих отговори като следните:
„Не си спомням това да ме е притеснявало някога. Освен че изглеждате досадно в отчетите или не можете да премахнете потребителя, ако притежава база данни, но не мисля, че това засяга операциите на сървъра. Можете просто да изберете sa за последователност.”
Или
„Не мисля, че притежаването на база данни от SA или който и да е друг потребител би трябвало да предизвиква загриженост. Важното е кой изпълнява „какво“ във вашата база данни. Така че е добра идея да създадете потребители с валидни привилегии. За простота можете да посочите собственика като SA.”
Сегашната ситуация е, че използването на акаунта в SA като собственик на база данни е НАЙ-ЛОШАТА практика . Аз лично смятам, че това трябва да бъде подчертано във всеки блог и във всяка документация, свързана с тази тема.
Ако създадем потребители само с валидни привилегии, това би било достатъчно, но за съжаление нещата обикновено не работят по този начин. Трябва да сте подготвени за „възможните най-лоши“ сценарии. Само помислете какво бихме могли да направим в предишните ни примери, ако собственикът на базата данни по подразбиране беше SA !
Нека продължим с втория вариант, ДОВЕРЕНИЯ опция за база данни. Ситуацията е малко по-добра, но все още има общ проблем. Както обикновено се смята, най-добрата практика тук е да Изключите свойството на базата данни „Надеждна“ . Току-що видяхме защо тази опция е лоша .
Но това не е всичко. Ако се опитате да намерите някои скриптове, за да проверите това свойство, вероятно ще намерите скрипт, подобен на този:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'sp_Blitz скрипт, който проверява здравето на SQL Server, също така проверява настройките по подразбиране на базите данни (включително TRUSTWORTHY като стойност по подразбиране 0) и отчита всяка база данни, която няма настройки по подразбиране. Скриптът обаче пропуска системните бази данни.
Освен това има статия в MS KB, която се фокусира върху тази тема. Обърнете се към указанията за използване на настройките на базата данни TRUSWORTHY в SQL Server:
В статията има примерен код, който изброява базите данни, които имат ВКЛЮЧЕН бит TRUSTWORTHY и чиито собственици на база данни принадлежат към ролята на сървър на системен администратор:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
Какво е общото в тези скриптове? Всеки скрипт изключва MSDB, но както се отбелязва в статията на MS KB, току-що го видяхте в нашата „мисия“:
Забележка :По подразбиране настройката TRUSWORTHY е зададена на ON за базата данни MSDB. Промяната на тази настройка от стойността по подразбиране може да доведе до неочаквано поведение от компонентите на SQL Server, които използват базата данни MSDB.
Бих искал да подчертая, че основният фокус на този раздел не е нито опцията за база данни TRUSWORTHY, нито самата собственост на собственика на базата данни, а комбинацията от тези две опции. Съсредоточих се предимно върху MSDB, защото настройката TRUSTWORTHY е зададена на ON за базата данни MSDB по подразбиране.
Заключение
Това е всичко за сега. Прегледахме и проверихме практическите сценарии, свързани със сигурността на SQL Server. Прегледахме и такива важни опции за база данни, като собственика на базата данни и настройката на базата данни TRUSWORTHY.
Просто исках да обърна внимание на тези опции, тъй като – тъй като те са критични, особено когато говорим за тях в комбинация.
