Защитата на сървъра зависи главно от това колко правилно можете да конфигурирате разрешенията за достъп до обекти. Предоставянето на потребител с прекомерни разрешения може да причини много проблеми. Не, потребителят няма да използва вашите грешки. Вместо това всеки хакер или аз ще направим това. В този случай можете да забравите за вашите таблици с данни или за цялата база данни.
По някаква причина сигурността на базата данни е защита отвън, като например хакер. Това обаче се случва много рядко. Аз съм програмист в голяма компания и администратор дори не мисли за защита на сървърните портове, където всичко е отворено. Има куп бази данни, програми и дори FTP сървър на един сървър и никога не е бил хакнат през последните 5 години. За щастие убедих администратора да разположи WEB сървъра на отделен хардуер. В противен случай, ако някой знаеше IP адреса на нашия основен сървър, всеки безделник би могъл да го хакне. Нито базата данни, нито Windows са пачканени от няколко години.
Вътрешни проблеми обаче възникват всеки ден поради неправилна политика за сигурност. Всички потребители влизат с администраторски права и могат да създават всичко, което искат. Това е истински проблем, защото прекомерните разрешения позволяват на мързеливците да покажат пълната си неграмотност. Затова ще вземем предвид сигурността, независимо от това откъде идва заплахата – от хакер или от потребител.
В тази статия ще разгледаме всички необходими основи на защитата от хакери и потребители. Избрах MS SQL Server като пример, защото съдържа всичко налично в други бази данни (Oracle, MySQL и др.) и има допълнителни възможности за управление на сигурността. Някой може да си помисли, че това прави MS по-стръмна. Понякога обаче допълнителните функции могат да бъдат прекомерни, причинявайки проблеми.
Роли на сървъра
В Windows и други операционни системи има групи и потребители за управление на разрешенията. Можем да комбинираме потребители в група и да дадем права на всички наведнъж, което е много по-лесно, отколкото да присвояваме права на всеки потребител поотделно. За тези цели в базите данни има понятието „роля“.
Да приемем, че 100 потребители трябва да имат разрешения да четат данни от конкретна таблица. Да предоставите на всеки потребител това разрешение е проблем. Много по-лесно е да създадете роля, която е разрешена за четене, и след това да добавите всички необходими потребители към нея. Резултатът е подобен на групирането.
В SQL Server има два типа роли:сървър и база данни. Сървърните роли са предварително дефинирани и не могат да се променят.
Отворете клона на ролята за сигурност/сървър в Enterprise Manager, за да можете да видите списък с налични роли в дясната част на прозореца. Описанието определя какво може да прави потребителят със съответната роля.
Роли на сървъра в MS SQL Server и прозореца на мениджъра на роли
За да добавите съществуващ потребител към роля, щракнете двукратно върху реда с роля. В прозореца, който се показва, можете да добавите потребители към ролята или да ги изтриете. Разделът Разрешения описва подробно какво може да прави всеки потребител.
Потребители
За да управлявате потребители, отворете клона Защита/Вход в Enterprise Manager. В дясната част ще видите списък с всички потребители на сървъра. По подразбиране достъпът се предоставя на администратори на домейни и вградени акаунти за влизане, като sa.
За да добавите нов потребител, щракнете с десния бутон навсякъде в празната дясна част на прозореца и изберете Ново влизане в менюто, което се показва. В горната част на прозореца изберете потребителско име. Ако трябва да изберете съществуващ потребител на домейн или компютър, щракнете върху бутона (...) вдясно от полето за въвеждане и ще видите полето за търсене на потребител в домейна.
Добавяне на нов потребител
По-долу можете да изберете вида на удостоверяване – Windows или SQL Server. Ако изберете Windows, не е необходимо да задавате парола, защото сървърът ще я извлече от системата. Можете обаче да превключите или Предоставяне на достъп (разрешаване на достъп) или Отказване на достъп (забрана). В последния случай потребителят ще бъде регистриран в базата данни, но няма да може да се свърже – това е забранено.
Ако изберете удостоверяване на SQL Server, ще трябва да зададете парола, защото в този случай тя ще се съхранява в системните таблици на сървъра на базата данни. Моля, имайте предвид, че дори ако в настройките на сървъра е указано само удостоверяване на Windows, можете да създавате записи на SQL сървър, но няма да можете да влезете в системата с тези записи.
В раздела Роли на сървъра можете да посочите каква роля на сървъра ще бъде предоставена на потребител. Следователно, дори на етапа на създаване, можете да добавяте потребители към необходимите роли.
Потребителски достъп до бази данни
В раздела Достъп до база данни посочете базите данни, с които потребителят може да работи. Тук прозорецът е разделен на две части:в горната половина можете да изберете базата данни, до която е разрешен достъпът, а в долния списък можете да изберете ролята на базата данни. Тази роля в базата данни ще дефинира потребителските разрешения. На един потребител могат да бъдат предоставени няколко роли.
Създайте акаунт qq, който ще има достъп до базата данни на Northwind. Това е стандартна тестова база данни, създадена при разгръщане на сървъра.
Запазете промените.
Сега отворете клон Databases/Northwind/Users и вижте списъка с потребители, на които е разрешен достъп до избраната база данни. Моля, имайте предвид, че тук има акаунт qq. Няма акаунт в други бази данни, защото достъпът до тях за нашия нов потребител е забранен.
Роли в базата данни
Всяка база данни може да има свои собствени роли, които определят разрешенията за достъп до обекти. Много администратори не обичат да се занимават с тези разрешения. По този начин те инсталират вградената публика по подразбиране, която позволява почти всичко. Ако липсват разрешения за публичната роля, просто добавете потребител към сървърната роля на системен администратор. В този случай базата данни става уязвима.
Всеки потребител трябва да получи свои собствени и необходими разрешения. Това, което не е позволено, трябва да бъде забранено. Роли, които вече съществуват на сървъра, не трябва да се използват, защото техните разрешения са отворени за всички. Препоръчително е дори да ги изтриете всички, особено публичния.
Създаване на роля
За да създадете нова роля в базата данни, щракнете с десния бутон върху клона Бази данни/Име на база данни/Роли. В менюто, което се показва, изберете Нова роля в базата данни. Отваря се прозорецът Свойства на ролята на базата данни – Нова роля. В горната част на прозореца въведете името на ролята.
Например искаме да създадем роля за счетоводители. За да направите това, въведете Buh в полето Име.
Създаване на роля на база данни
По-долу изберете тип роля, например стандартна по подразбиране. В центъра на прозореца има списък с потребители, които ще бъдат добавени към ролята. Засега списъкът е празен. Въпреки това, ако щракнем върху Добавяне, ще добавим потребители, например, към акаунта qq, създаден по-рано. Няма какво друго да се направи на етапа на създаване на роля. Запазете промените, като щракнете върху OK.
Разрешения за достъп
Сега ще видим как можем да зададем разрешения. Щракнете двукратно върху създадената роля на Buh, за да отворите прозореца за редактиране. Моля, имайте предвид, че бутонът за разрешение е наличен сега. Само когато ролята е регистрирана в базата данни, можем да променим правата й. Щракнете върху този бутон, за да отворите прозореца със свойства на ролята на базата данни.
Задаване на разрешения за достъп за роли
В горната част на прозореца има списък с роли в базата данни, така че можете бързо да превключвате между тях. Сега ролята на Бух е избрана. В центъра на прозореца има голяма решетка със следните колони:
- Обект – имена на обекти;
- Собственик – собственик на обект;
- SELECT – разрешение за преглед на данни или изпълнение на оператора SELECT. Предлага се само за таблици и изгледи;
- INSERT – разрешение за добавяне на данни или изпълнение на оператора INSERT. Предлага се само за таблици и изгледи;
- UPDATE – разрешение за промяна на данни или изпълнение на оператора UPDATE. Предлага се само за таблици и изгледи;
- Разрешение DELETE за изтриване на данни или изпълнение на оператора DELETE. Предлага се само за таблици и изгледи;
- EXEC – разрешение за изпълнение на съхранени процедури и функции. Предлага се само за съхранени процедури и функции;
- DRI (декларативна референтна цялост). Предлага се само за таблици, изгледи и функции.
Няма разрешения за новата роля. За да можете да видите таблица, например Категории, поставете отметка в квадратчето в пресечната точка на реда Категории и колоната SELECT. Ще видите зелена отметка в полето, което означава разрешение. Второто щракване променя отметката на червения кръст и означава забрана. Това може да е необходимо, ако предоставите разрешение на потребителя и го добавите към друга роля, където достъпът до избраното действие е разрешен. Третото щракване премахва всички разрешения за действието и оставя полето празно. Това означава, че няма достъп; обаче може да се делегира, ако потребителят е добавен към друга роля с разрешенията за обекта или разрешенията са изрично посочени.
Ако изберете ред с обекта на таблицата или изгледа, бутонът Колони става достъпен в долната част на прозореца. Да приемем, че сте избрали таблицата и сте щракнали върху този бутон. Отваря се прозорецът, в който можете да зададете разрешения за отделни колони на таблицата.
Задаване на разрешения за колони
Това наистина е чудесна възможност, защото някои колони, отговорни за целостта на базата данни, не трябва да се променят от потребители или хакери. По-добре е да забраните операциите UPDATE или SELECT (ако е възможно) за тези колони.
Индивидуализъм
Ролите са удобни за използване, когато е необходимо да се комбинират подобни потребители. Например, много счетоводители трябва да получат достъп до финансови таблици. Даването на разрешения на всеки счетоводител отнема време. Много по-лесно е да създадете роля за счетоводителя, да й предоставите разрешения и след това да добавите всички счетоводни акаунти към тази роля.
Има обаче случаи, когато разрешенията трябва да са уникални за даден потребител или в допълнение към разрешенията, предоставени от ролята, е необходимо да се предоставят допълнителни разрешения. Например, един от счетоводителите трябва да има достъп до таблици на отдела по човешки ресурси. В този случай е по-добре да добавите разрешения директно към счетоводителя, отколкото да създавате нова роля.
Първо проучихме ролите, за да свикнем с тях. В повечето случаи има отделен акаунт за счетоводители, отделен акаунт за икономисти и т.н. В този случай повечето хора се свързват със сървъра чрез един акаунт. Така да се контролира кой какво прави е невъзможно. По-добре е да използвате индивидуални разрешения, където е необходимо, докато всеки потребител трябва да има собствен акаунт.
Разрешения за таблици
Нека видим как можем да дадем разрешения на определени обекти, например на таблици.
Изберете клон Databases/Northwind/Tables в дървото на обектите. В дясната част се отваря списък с всички таблици. Щракнете с десния бутон върху която и да е таблица и изберете Всички задачи/Управление на разрешенията. Отваря се прозорецът Свойства на разрешенията, който е подобен на прозореца Свойства на ролята на базата данни със списък с потребители вместо списък с обекти. Обектът е таблица, върху която щракнахме и името му ще бъде посочено в падащото меню на прозореца. Сега трябва да зададем разрешения за този обект за различни потребители.
Задаване на разрешения за таблица
Списъкът с разрешения е както следва:преглед, актуализиране, добавяне, изтриване, изпълнение и управление. Ако щракнете върху бутона Колони, се отваря прозорецът за задаване на разрешения за обекта на нивото на полетата на таблицата за конкретен потребител.
Прегледи
Имаме две маси. Една от тях съхранява списъка на служителите, а друга таблица съдържа информация за броя на отработените часове на месец и получените заплати (служебни и скрити заплати).
Да предположим, че данъчен служител идва при вас и иска да покаже заплатите на работниците. Освен това те питат дали сте платили всички данъци. Какви действия трябва да извършите от ваша страна?
Първото предложение дойде от третия ред – да се създаде нов потребител, на когото е разрешено да чете таблици, включващи списък на служителите и заплатите. Освен това не бива да забравяте да затворите колоната със скритата заплата. Всъщност решението е правилно, но абсолютно неефективно.
Най-добрият вариант е да създадете изглед, SQL заявка, която избира данни. В базата данни изглежда като таблица. Можете да избирате SQL данни с помощта на заявки и предоставяне на разрешения. Оказва се, че заявката ще бъде изпълнена срещу заявката.
За да създадете изглед, изпълнете следната заявка:
CREATE VIEW salary AS SELECT fields for a tax official FROM Employees, Wages WHERE joins
Сега има нов обект Wage в клон Databases/Northwind/Views. Ако щракнете с десния бутон върху него и изберете Всички задачи/Управление на разрешенията, ще се отвори прозорецът за предоставяне на разрешения. Задайте разрешение за данъчния служител и го запазете. За да прегледате съдържанието на изгледа, изпълнете заявката:
SELECT * FROM salary
Както можете да видите, има достъп като до обикновена маса. Данъчният служител също ще си помисли, че вижда действителни данни. Всъщност обаче тази заявка ще съдържа само данните, от които се нуждаем.
В реалния живот данъчните не могат да бъдат измамени толкова лесно, защото не са глупаци. Този пример обаче показва, че изгледът може да бъде перфектен метод за сигурност. Можем да показваме данните, от които потребителите се нуждаят, и нищо друго. В същото време имаме всички инструменти за управление на разрешенията за изгледа, без да засягаме разрешенията за достъп на таблиците.
По този начин различните изгледи към едни и същи таблици могат да показват различни данни. Ако искате да покажете допълнителна колона, добавете изгледите към заявката. В този случай няма нужда от промяна на разрешенията.
Системни изгледи
Във всяка база данни може да има системни изгледи, създадени от сървъра автоматично. Не препоръчвам да им давате разрешение, защото те могат да покажат допълнителна информация, която може да помогне на хакер да зададе разрешения или просто да унищожи данни. Системните изгледи започват с префикса sys и Системата е посочена в колоната Тип на списъка.
Процедури и функции
Съвременните сървъри на бази данни поддържат съхранени процедури и функции. Това е PL/SQL или Transact-SQL код в зависимост от базата данни, която се изпълнява на сървъра на базата данни. Използвайки тези процедури, можем да извършваме всякакви операции на сървъра или просто да избираме данни, както в изгледа. Можем да зададем разрешения за всяка процедура.
Когато преглеждаме ролите, вече видяхме процедурите в списъка с обекти, за които можете да зададете разрешения и само колоната EXEC е налична в тези редове, тъй като процедурите могат да се изпълняват само.
Съхранените процедури и функции се съхраняват в определена база данни. За да видите процедурите на базата данни Northwind, изберете клон Databases/Northwind/Stored Procedures. Има много системни процедури, чиито имена започват с префикса dt_ и Системата е посочена в колоната Тип. Препоръчително е да не се предоставя достъп до тези процедури, ако е възможно. Можете да видите функции в клона Databases/Northwind/Defined от потребителя.
За да промените разрешенията за процедури и функции, щракнете с десния бутон върху името му и изберете Всички задачи/Управление на разрешенията в менюто. В прозореца, който се показва, можете да промените само колоната EXEC за процедури и колоните EXEC и DRI за функции.
Правила за разрешения
Някои администратори задават разрешения въз основа на съществуващата роля, например публична. Това не е вярно, защото в тази роля може да има разрешения, от които потребителите не се нуждаят. Затова опитайте да зададете чисто ново разрешение.
Що се отнася до мен, винаги създавам нова роля и давам минимален набор от разрешения. Ако потребителите поискат повече разрешения и те всъщност са необходими, добавям още разрешения. Ако разрешите всичко по подразбиране, няма гаранция, че в бъдеще ненужните и опасни права ще бъдат изтрити.
Друг проблем за задаване на по-малко разрешения е навик. Потребителите могат да свикнат с факта, че им се предоставят много разрешения и тогава забраната ще предизвика сериозен скандал. Никой не обича, когато правата му се нарушават.
Таблици/бази данни
Базите данни съхраняват своите настройки и скрити свойства в системни таблици и бази данни. Те не се различават от другите обекти на базата данни и за тях могат да се задават разрешения. В никакъв случай не позволявайте на потребителите да имат достъп до тези таблици без специална нужда.
В SQL Server важните системни данни се съхраняват в главната и msdb бази данни. Следователно тези бази данни трябва да бъдат защитени. В Oracle всяка база данни съществува като отделен обект и системните таблици се съхраняват заедно с потребителските.
Почти всички сървъри на бази данни предлагат инсталиране на тестови бази данни, които могат да се използват за обучение или тестване на системата. Ако ги имате, изтрийте – защото е зададен публичен достъп до тези бази данни. Ако хакерът знае имена или свойства на който и да е съществуващ обект в системата, това значително ще опрости задачата им.
Когато се свързвате с тестова база данни, можете да изпълните някои команди на сървъра и да повредите ОС или работеща база данни. Не трябва да има допълнителни неща в системата. Освен това такива таблици/бази данни имат доста високи разрешения дори за гост.
Резюме
Въпреки факта, че използвахме MS SQL Server като пример, концепциите за разрешения, роли и удостоверяване съществуват във всички бази данни.
Познавайки всички правила, които разгледахме, единственото, от което се нуждаете, е да проучите особеностите на използването им във вашата база данни.
