Не е тайна, че информацията кара света да се върти в момента. Ако едно предприятие се грижи за своята интелектуална собственост и всеки служител може лесно да получи необходимата информация, предприятието може да се надява на растеж. Ако има хаос в данните, предприятието ще се провали въпреки екипния дух.
В тази статия ще разгледаме основите на сигурността на базата данни и примерите за защита на информацията в Oracle. Всъщност теоретичните основи за защита на информацията в базата данни, които ще разгледаме в тази статия, ще бъдат полезни и за хората, работещи с други бази данни.
Разрешения за достъп
В повечето компании, в които работех, всички администратори и разработчици имаха пълен достъп до бази данни, както и един служител на ИТ отдела беше бог и можеше да прави каквото си поиска. Защо се случва? Има две причини за това:
- Докато работят в един отдел, служителите могат да се срещат по 8 часа всеки ден и да стават приятели. Как не могат да предоставят достъп? Приятелството е едно, но бизнесът е бизнес.
- Предоставянето на някои права за достъп или промяната на някаква конфигурация може да изисква някои привилегии. Понякога администраторите смятат, че програмистите конфигурират настройките по-добре. По този начин те предоставят на програмистите ненужни права за достъп. Вместо това програмистите не трябва да участват в администрацията и не трябва да имат никакви права за това.
Според моя опит вторият проблем е много често срещан, затова ще го анализираме подробно.
Когато разработват програми за бази данни, програмистите знаят парола на суперпотребител или просто имат администраторски права на база данни. Това е ненужно и абсолютно несигурно. Само администраторът на базата данни трябва да има пълни права. Дори ръководителят на отдела, директорът и най-добрите приятели могат да имат по-малко привилегии.
Например, когато разработвате програми, е достатъчно да имате правата на собственик на схемата в базата данни на Oracle, която съхранява работни таблици. Тези права са достатъчни за създаване на нови таблици, пакети, индекси и други обекти, както и за предоставяне на права за достъп до обекти на схема на други потребители. Не са ви необходими системните права за работа на пълен работен ден.
Ако няма администратор на база данни на пълен работен ден, това е много лошо. По-добре е, когато има някой, който отговаря за производителността на базата данни, оптимизацията и сигурността. Най-малкото трябва да назначите един програмист, който ще отговаря за това и ще има изключителни права.
Според статистиката служителите на компанията най-често причиняват загуба на данни. И все пак, въпреки този факт, повечето компании продължават да игнорират тази тема и различни бази данни, съхранявани на дискове със свободен достъп, се продават дори в метрото.
Потребители и роли
Има два типа обекти за предоставяне на права за достъп в бази данни:потребители и роли. Ролите са някои групи, които комбинират потребители, които трябва да имат подобни права. Например, всички счетоводители може да изискват достъп до финансови документи. За да предотвратим предоставянето на права на всеки счетоводител, можем да ги комбинираме в роля с необходимия достъп.
Както можете да видите, принципът на ролите е подобен на групите в операционната система Windows. Все пак има някои разлики. Не без причина и трите типа обекти като потребители, групи и роли могат да бъдат внедрени в базата данни. В повечето бази данни обаче са внедрени само потребители и роли. Необходимо е да се управляват и наблюдават всички тези обекти, така че всеки потребител, който получава правата, предоставени от ролите, да има достъп до данните, които всъщност са необходими за решаване на задачи. Необходимо е да се използват правата за достъп като правила за защитна стена. Използвайки тези права, можете да разрешите същия проблем – да позволите на потребителя да изпълнява само определени задачи и да предотврати евентуална загуба или повреда.
С помощта на роли е доста удобно да контролирате достъпа, да предоставяте разрешения или да блокирате цялата група потребители. Една роля може да бъде включена в другата, като по този начин се наследяват правата за достъп. Следователно можем да създадем йерархична структура на правата.
Всички служители с права за достъп до корпоративна база данни могат да бъдат включени в една роля с минимални права. Сега, ако имате нужда от допълнителни привилегии, достъп до определени таблици, ще трябва да добавите потребител към други роли (ако групата изисква същия достъп) или да предоставите конкретен акаунт с правата.
В програмата, за да контролирате достъпа до таблиците, е възможно да проверите резултата за грешки след всеки опит за отваряне на набора от данни. Ако възникне грешка при достъпа, достъпът до посочената таблица се блокира за потребител. По този начин не е необходимо да се прилагат правата за достъп до клиентското приложение. Въпреки това, ако искате да приложите това, няма да има вреда. Поне аз не виждам нищо критично в това; изглежда има обратен ефект.
Одит на сигурността
Ако всеки потребител работи със собствен акаунт във вашата база данни, можете да извикате потребителската променлива, за да определите текущия потребител, например:
SELECT user from dual
Тази заявка ще върне потребителско име, под което се отваря връзката със сървъра. Ако няколко души могат да влязат с едно име, тази заявка ще върне едно и също име и за двете и би било безполезно за одита. Особено, ако контролът върху блокирането се осъществява на ниво сървър.
Ако няколко потребители могат да влязат с едно и също потребителско име, е сложно, но все пак възможно да се идентифицира кой е влязъл в акаунта. Следната заявка позволява получаване на подробна информация за сесията:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Както можете да видите, заявката върна потребителското име, свързано с базата данни, име в операционната система, потребителско име на терминал и програма.
Тук можете да получите достъп до изгледа v_$session от системната схема на sys. Този изглед връща информация за връзките към сървъра. В клаузата WHERE ограничаваме изхода само до текущия потребител. В резултат на това заявката връща потребителския идентификатор, име, име в операционната система, терминала и програмата, от която е установена връзката.
Когато знаете потребителско име и име на терминал, можете със сигурност да идентифицирате потребител. За да разберете към кои роли е добавен текущият потребител, можете да изпълните следната заявка:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Сигурност на акаунта
Няма да кажем, че не трябва да има пароли по подразбиране. Някои бази данни, например, MySQL правят погрешно, когато създават проста и добре позната системна парола след инсталирането. Също така няма да кажем, че паролата трябва да е сложна. Това правило важи за всички ИТ области и трябва да е известно дори на начинаещ потребител. Ще говорим за проблеми с базата данни.
Според моя опит, когато разработват корпоративни програми, разработчиците използват един и същ акаунт за достъп до база данни. Параметрите на този акаунт се регистрират директно в програмата, а достъпът до отделни модули, включително счетоводство, склад, отдел персонал и др., се осъществява по програмен начин. От една страна, този метод е удобен, тъй като програмата може да се свърже с базата данни с администраторски права и няма да се налага да се грижи за ролите и правата за достъп до таблиците. От друга страна, този метод далеч не е сигурен. Нивото на потребителите расте и приятелите на служителите на вашата компания могат да бъдат образовани в областта на сигурността и хакерството. След като знае името и паролата, под които програмата се свързва с базата данни, обикновен потребител може да получи повече възможности, отколкото желаете.
Езикът SQL не е таен и сложен език. Има много програми, с които можете лесно да преглеждате всякакви данни в базата данни. С потребителското име и паролата всеки може да открадне всичките ви данни. По този начин той ще се продава във всеки щанд, който продава дискове.
Потребителско име и парола никога не трябва да се съхраняват в програмата. Достъпът до програмата също трябва да бъде ограничен и невъзможен за трети страни. Съвсем логично е да комбинирате и двата входа в едно. Необходимо е да се създаде отделен акаунт на сървъра на базата данни с минимално необходими права за всеки потребител в организацията. Тези имена и пароли трябва да се използват при влизане в програмата. Можете да използвате обща и много ефективна логика – ако можете да влезете в базата данни с въведените данни, достъпът е разрешен; ако не, трябва да прекратите програмата. Този процес е прост и ефективен, защото използвахме упълномощаване на база данни.
За да проверите дали потребителите не работят едновременно от два различни компютъра под едно и също име, можете да изпълните следната заявка:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
Всъщност той не трябва да връща никакъв запис.
Прегледи
Изгледите са много удобен начин за изключване от структурата на данните и същевременно изграждане на допълнително ниво на защита. Вярно е, че възгледите имат отрицателно въздействие върху производителността, но имат положително въздействие върху сигурността. Можем да им предоставим собствени права за достъп, докато таблиците, от които се извличат данните, могат да останат недостъпни за този акаунт.
Кога е по-добре да използвате изгледи? Първо, нека да определим какви са техните недостатъци. Изгледът е оператор SELECT за извличане на данни. Има достъп както до една, така и до няколко таблици. Ако просто изберете данните от изгледа, няма да има загуба на производителност. Въпреки това, ние можем да използваме изгледи в други заявки, за да изберем данни и да се отнасяме към тях като към таблиците. Например:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
В този случай заявката извлича данни от изгледа и две таблици. Освен това можем да видим връзка между всички обекти и може да се зададе допълнително условие.
Сега нека разгледаме заявката, както я вижда оптимизаторът на базата данни:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
В този случай замених изгледа с абстрактен оператор SELECT в скоби, от който се състои изгледът. Оказва се, че сървърът вижда заявка с подзаявка. Ако подзаявката върне динамични данни, а не статична стойност, този избор на данни ще работи по-бавно, отколкото ако написахме същата заявка без подзаявката.
Сигурност на данните
Никога не трябва да предоставяте пълен достъп до обекти без специална нужда. Винаги започвам да предоставям права само за разрешаване на избора на данни с оператора SELECT. Ако потребителят наистина трябва да вмъкне нови записи и не може да изпълни задачите, които са му възложени, в този случай добавете разрешението към оператора INSERT на посочената таблица.
Най-опасните операции за данните са промяна и изтриване, а именно UPDATE и DELETE, съответно. Трябва внимателно да предоставите тези права. Уверете се, че данните могат да бъдат променени или изтрити. Само в този случай изберете подходящите права. Някои таблици са разширени само по природа.
Необходимо е да сте сигурни, че данните ще бъдат засегнати често. Например таблицата на служителите може да бъде разширявана и модифицирана, но нито един запис никога не трябва да се изтрива. Премахването може да повлияе на фона на работата на служителите, отчитането и целостта на данните. Случаят, когато служител по човешки ресурси случайно добави допълнителен запис и иска да го изтрие, все още е възможен. Такива случаи обаче са редки и грешката може да бъде отстранена от администратора на базата данни. Разбираме, че никой не иска да се претоварва и е по-лесно да се даде разрешение, но сигурността е по-ценна.
Предоставянето на права се извършва с помощта на оператора GRANT. Като цяло изглежда така:
ПРЕДОСТАВЯ какво да даде права на ON обекти НА потребители или роли
Например следната заявка предоставя правото за вмъкване и преглед на таблицата TestTable на User1:
GRANT Select, Insert ON TestTable TO User1
Външни ключове
Много потребители се страхуват от външни ключове, защото обикновено не позволяват изтриване на данни, когато има външно присъединяване. Проблемът може лесно да бъде решен, ако се установи каскадно изтриване. Повечето специалисти обаче не харесват тази възможност. Едно нелепо действие може да повреди много важни данни без никакви искания за потвърждение. Свързаните данни трябва да бъдат изтрити изрично и само ако потребителят съзнателно е потвърдил, че данните могат да бъдат изтрити.
Не се страхувайте от външни ключове. Те ни предоставят удобен начин да контролираме целостта на данните от сървъра на базата данни, като по този начин това е сигурност, която никога не вреди. Фактът, че може да има проблеми с изтриването, е само предимство. По-добре е да не изтривате данните, отколкото да ги загубите завинаги. Външният ключ заедно с индекса не намалява производителността. Това е само малка проверка при изтриване на данните или промяна на ключовото поле, към което са свързани данните в различни таблици.
Резервно копие
Архивирането също е един от факторите за сигурност, които игнорираме преди първата загуба на данни. Лично аз обаче бих го включил в основните. Загубата на данни може да бъде причинена не само от хакери и неспособни потребители, но и поради неизправност на оборудването. Неизправности в оборудването могат да доведат до загуба на база данни, чието възстановяване може да отнеме часове или дори дни.
Необходимо е предварително да се разработи най-ефективната политика за архивиране. Какво се има предвид под това? Времето за престой, причинено от загуба на данни и до момента на възстановяване на работоспособността, трябва да бъде минимално. Загубата на данни също трябва да бъде минимална, а архивирането не трябва да засяга работата на потребителя. Ако има пари и възможности, по-добре е да използвате такива системи като RAID, клъстер или дори репликация на данни.
Архивирането и възстановяването са отделна и интересна тема. Не бихме могли да го засегнем тук, но няма да го разглеждаме подробно.
Резюме
Разгледахме основите на сигурността, по-специално за Oracle. Не забравяйте, че защитата, осигурена от базата данни, е само едно ниво, докато защитата трябва да бъде многостепенна. За да спите малко с бистър ум, е необходимо да внедрите всички защитни функции в мрежата, сървърите и всички компютри, включително антивируси, антишпионски софтуер, VPN, IDS и т.н. Колкото повече нива на защита има, толкова повече трудно ще бъде да ги преодолеем.
Трябва да има ясна политика за сигурност и контрол. Ако служител напусне, акаунтът му се изтрива. Ако имате потребители, работещи със същата парола или използващи групова парола за изпълнение на някакви задачи, всички тези пароли трябва да бъдат променени. Например, ако администратор напусне и всички администратори използват един и същ акаунт, трябва да промените паролата.
Сигурността е необходима. Трябва да се предпазите не само от хакери, но и от „начинаещи“ потребители, които могат да повредят данните поради своята неопитност. Добрата политика за сигурност помага за предотвратяване на подобни случаи и тази възможност не може да бъде изключена. По-добре е предварително да осигурите възможност за защита на данните от неопитност, отколкото да губите много време за възстановяване на данни и да получавате ненужни престой.
Прочетете също:
Задаване на разрешения за достъп до база данни
