Сигурност је најважнија за администраторе базе података који желе заштитити своје гигабајте виталних пословних података од пратећих очију неовлашћених аутсајдера и инсајдера који покушавају да прекораче свој ауторитет. Сви системи за управљање базама података обезбеђују неку врсту унутрашњих сигурносних механизама осмишљених да минимизирају ове претње. Оне варирају од једноставне заштите лозинком коју нуди Мицрософт Аццесс до сложене структуре корисника / улоге подржане напредним релацијским базама података као што су Орацле и Мицрософт СКЛ Сервер. Овај чланак се фокусира на сигурносне механизме који су заједнички за све базе података које имплементирају Струцтуред Куери Лангуаге (или СКЛ ). Заједно ћемо проћи кроз процес јачања контрола приступа подацима и осигурања сигурности ваших података.
Корисници
Сервер базиране базе података подржавају кориснички концепт сличан ономе који се користи у рачунарским оперативним системима. Ако сте упознати са хијерархијом корисника / групе која се налази у Мицрософт Виндовс НТ и Виндовс 2000, видећете да су групе корисника / улога које подржавају СКЛ Сервер и Орацле веома сличне.
Препоручујемо вам да креирате индивидуалне кориснички базе података за сваку особу која ће приступити вашој бази података. Технички је могуће поделити рачуне између корисника или једноставно користити један кориснички налог за сваку врсту корисника који треба да приступи вашој бази, али ја снажно обесхрабрујем ову праксу из два разлога. Прво, то ће елиминисати појединачну одговорност - ако корисник направи промјену у вашој бази података (рецимо дајући себи $ 5,000 раисе), нећете моћи да га пратите назад одређеној особи користећи дневнике ревизије. Штавише, ако одређени корисник напусти вашу организацију и желите да уклоните његов или њен приступ из базе података, бићете приморани да промените лозинку на коју се сви корисници ослањају.
Методе за креирање корисничких налога варирају од платформе до платформе и морате се консултовати са вашом ДБМС специфичном документацијом за тачну процедуру. Корисници Мицрософт СКЛ Сервера би требало да истраже употребу сп_аддусер складиштеног поступка. Администратори Орацле базе података ће пронаћи корисничку наредбу ЦРЕАТЕ УСЕР. Такође бисте желели да истражите алтернативне шеме за аутентификацију. На пример, Мицрософт СКЛ Сервер подржава употребу Виндовс НТ Интегратед Сецурити. Према овој шеми, корисници се идентификују у базу података својим корисничким налозима за Виндовс НТ и од њих није потребно уносити додатни кориснички ИД и лозинку за приступ бази података. Овај приступ је изузетно популаран међу администраторима базе података јер помера терет управљања налогом запосленима у мрежној администрацији и пружа једноставност јединственог пријаве крајњем кориснику.
Улоге
Ако сте у окружењу са малим бројем корисника, вероватно ћете открити да креирање корисничких налога и додељивање дозвола директно њима довољан је за ваше потребе. Међутим, ако имате велики број корисника, највероватније ћете бити оптерећени теретом одржавања рачуна и одговарајућих дозвола. Да би олакшали овај терет, релацијске базе података подржавају појам улога. Улоге базе података функционирају слично Виндовс НТ групи. Кориснички рачуни додељују се улогама, а затим се доделе дозволе за улогу у целини, а не појединачне корисничке налоге. На пример, могли бисмо направити улогу ДБА, а затим додати корисничке налоге нашег административног особља на ову улогу. Када то урадимо, можемо доделити одређену дозволу свим садашњим (и будућим) администраторима једноставним додељивањем дозволе за улогу. Још једном, процедуре за креирање улога варирају од платформе до платформе. МС СКЛ Сервер администратори треба да истражују сп_аддроле ускладиштену процедуру док Орацле ДБАс требају користити синтаксу ЦРЕАТЕ РОЛЕ.
Давање дозвола
Сада када смо додали кориснике у нашу базу података, време је да почнемо јачати безбедност додавањем дозвола. Наш први корак ће бити додјељивање одговарајућих дозвола за базу података нашим корисницима. Ово ћемо постићи употребом СКЛ ГРАНТ израза.
Ево синтаксе изјаве:
ГРАНТ <дозволе>
[ОН <табела>]
ТО <корисник / улога>
[ВИТХ ГРАНТ ОПТИОН]
Сада, погледајте ову изјаву линију по линији. Прва линија, ГРАНТ <дозволе>, омогућава нам да наведемо специфичне дозволе таблица које додељујемо. То могу бити или дозволе на нивоу табеле (као што су СЕЛЕЦТ, ИНСЕРТ, УПДАТЕ и ДЕЛЕТЕ) или дозволе за базу података (као што су ЦРЕАТЕ ТАБЛЕ, АЛТЕР ДАТАБАСЕ и ГРАНТ). Више од једне дозволе може се доделити у једном ГРАНТ изразу, али дозволе на нивоу таблице и дозволе на нивоу базе података не могу бити комбиноване у једној изјави.
Друга линија, ОН <табела>, се користи да одреди подразумевану таблицу за дозволе на нивоу табеле. Ова линија је изостављена ако одобравамо дозволе на нивоу базе података. Трећа линија одређује корисника или улогу која се одобрава.
Коначно, четврта линија, са ГРАНТ ОПТИОНОМ, је необавезна. Ако је ова линија укључена у изјаву, корисници који су погођени такође имају дозволу да додјељују исте дозволе другим корисницима. Имајте на уму да се ВИТХ ГРАНТ ОПТИОН не може специфицирати када су дозволе додељене улоги.
Примери
Погледајмо неколико примера. У нашем првом сценарију недавно смо унајмили групу од 42 оператера за унос података која ће додавати и одржавати евиденцију купаца. Морају бити у могућности приступити информацијама у табели Купци, модифицирати ове информације и додати нове записе у табелу. Не би требали у потпуности избрисати запис из базе података. Прво, требали бисмо креирати корисничке рачуне за сваког оператора, а затим их све додати у нову улогу, ДатаЕнтри. Затим, требало би да користимо следећу СКЛ изразу да им дате одговарајуће дозволе:
ГРАНТ СЕЛЕЦТ, ИНСЕРТ, УПДАТЕ
ОН Купци
ТО ДатаЕнтри
И то је све до тога! Сада ћемо испитати случај у којем додјелујемо дозволе на нивоу базе података. Желимо да дозволимо члановима ДБА улоге да додају нове табеле у нашу базу података. Осим тога, желимо да им омогући и другим корисницима дозволу да то учине исто. Ево СКЛ израза:
ГРАНТ ЦРЕАТЕ ТАБЛЕ
ТО ДБА
СА ГРАНТОМ ОПЦИЈЕ
Обратите пажњу да смо укључили линију ВИТХ ГРАНТ ОПТИОН како бисмо осигурали да наши ДБА-ови могу доделити ову дозволу другим корисницима.
Уклањање дозвола
Када додамо дозволе, често се показује неопходним да их опозове касније. Срећом, СКЛ нам даје команду РЕВОКЕ да уклоните претходно додељене дозволе. Ево синтаксе:
РЕВОКЕ [ГРАНТ ОПТИОН ФОР] <дозволе>
ОН <табела>
ФРОМ <усер / роле>
Приметићете да је синтакса ове наредбе слична оној у команди ГРАНТ. Једина разлика је да је ВИТХ ГРАНТ ОПТИОН специфициран на командној линији РЕВОКЕ уместо на крају команде. Као пример, претпоставимо да желимо да одузмемо Мари-ову претходно одобрену дозволу за уклањање записа из базе података Купци. Користићемо следећу наредбу:
РЕВОКЕ ДЕЛЕТЕ
ОН Купци
ОД МАРИЈЕ
И то је све до тога! Постоји још један додатни механизам који подржава Мицрософт СКЛ Сервер који вреди помињати - ДЕНИ наредбу. Ова наредба се може користити да експлицитно одбије дозволу за корисника коју би иначе имали кроз тренутну или будућу чланарину улоге. Ево синтаксе:
ДЕНИ <дозволе>
ОН <табела>
ТО <корисник / улога
Примери
Враћајући се на наш претходни пример, претпоставимо да је Мари такође била члан улоге Менаџера који је имао приступ табелама купаца. Претходна наредба РЕВОКЕ не би била довољна да одбије њен приступ табелама. Она би уклонила дозволу која јој је додељена кроз изјаву ГРАНТ циљајући њен кориснички рачун, али не би утицала на дозволе стечене њеним чланством у улогу Менаџера. Међутим, ако користимо ДЕНИ изјаву она ће блокирати њено насљеђивање дозволе. Ево наредбе:
ДЕНИ ДЕЛЕТЕ
ОН Купци
ТО Мари
Команда ДЕНИ у суштини ствара "негативну дозволу" у контролама приступа бази података. Ако касније одлучимо да дозволимо Мари дозволу да уклони редове из табеле Купци, не можемо једноставно користити команду ГРАНТ. Та команда би одмах надвладала постојећи ДЕНИ. Уместо тога, прво би користили наредбу РЕВОКЕ да уклонимо унос негативне дозволе на следећи начин:
РЕВОКЕ ДЕЛЕТЕ
ОН Купци
ОД МАРИЈЕ
Приметићете да је ова команда потпуно идентична оној која се користи за уклањање позитивне дозволе. Запамтите да команде ДЕНИ и ГРАНТ оба делују на сличан начин * мдасх, оба стварају дозволе (позитивне или негативне) у механизму контроле приступа бази података. Команда РЕВОКЕ уклања све позитивне и негативне дозволе за одређеног корисника. Када је ова наредба издата, Мари ће моћи да избрише редове из табеле ако је члан улоге која поседује ту дозволу. Алтернативно, наредба ГРАНТ би се могла издати да омогући одобрење ДЕЛЕТЕ директно на њен рачун.
Током овог чланка научили сте доста о механизмима контроле приступа који подржава стандардни језик упита. Овај увод вам треба да обезбеди добру полазну тачку, али вас позивам да упућујете документацију ДБМС-а да бисте сазнали побољшане мере безбедности које подржава ваш систем. Наћи ћете да многе базе података подржавају напредније механизме контроле приступа, као што су додавање дозвола за одређене колоне.