Безбедноста е најважна за администраторите на бази на податоци кои сакаат да ги заштитат своите гигабајти од витални деловни податоци од љубопитните очи на неовластени аутсајдери и инсајдери кои се обидуваат да го надминат нивниот авторитет. Сите системи за управување со релациони бази на податоци обезбедуваат некој вид на внатрешни безбедносни механизми дизајнирани да ги минимизираат овие закани. Тие се движат од едноставната заштита на лозинка која ја нуди Microsoft Access до сложената структура на корисници / улоги поддржана од напредни релациони бази на податоци како Оракл и Microsoft SQL Server. Оваа статија се фокусира на безбедносните механизми кои се заеднички за сите бази на податоци кои го имплементираат структурираниот јазик за пребарување (или SQL ). Заедно, ќе одиме низ процесот на зајакнување на контролите за пристап до податоци и обезбедување на безбедноста на вашите податоци.
Корисници
Серверските бази на податоци ги поддржуваат корисничките концепти слични на оние кои се користат во компјутерските оперативни системи. Ако сте запознаени со хиерархијата на корисник / група која се наоѓа во Microsoft Windows NT и Windows 2000, ќе откриете дека групите на корисници / улоги поддржани од SQL Server и Oracle се многу слични.
Препорачливо е да креирате индивидуални кориснички сметки на база на податоци за секое лице кое ќе пристапува кон вашата база на податоци. Технички е можно да споделувате сметки помеѓу корисниците или едноставно да користите една корисничка сметка за секој тип на корисник кој треба да пристапи до вашата база на податоци, но јас силно ја обесхрабрувам оваа пракса од две причини. Прво, тоа ќе ја елиминира индивидуалната одговорност - ако корисникот направи промена во вашата база на податоци (да речеме со тоа што ќе се подигне $ 5,000 покачување), нема да можете да го пронајдете назад до одредено лице преку употреба на дневници за ревизија. Понатаму, ако одреден корисник ја напушти вашата организација и сакате да го отстраните неговиот или нејзиниот пристап од базата на податоци, ќе бидете принудени да ја промените лозинката за која се потпираат сите корисници.
Методите за креирање на кориснички сметки се разликуваат од платформа до платформа и ќе мора да ја консултирате документацијата специфична за DBMS за точната процедура. Корисниците на Microsoft SQL Server треба да ја испитаат употребата на sp_adduser чуваат процедура. Oracle администраторите на базата на податоци ќе ја најдат командата CREATE USER корисна. Исто така, можеби ќе сакате да ги испитате алтернативните шеми за проверка. На пример, Microsoft SQL Server поддржува употреба на Windows NT Интегрирана безбедност. Според оваа шема, корисниците се идентификуваат во базата на податоци од нивните кориснички сметки на Windows NT и не се потребни за внесување на дополнителен кориснички ID и лозинка за пристап до базата на податоци. Овој пристап е многу популарен помеѓу администраторите на бази на податоци, бидејќи го префрла оптоварувањето на управувањето со сметката со вработените во мрежната администрација и обезбедува леснотија на единствен најава за крајниот корисник.
Улоги
Ако сте во средина со мал број корисници, веројатно ќе најдете дека создавањето на кориснички сметки и доделувањето на дозволите директно до нив е доволно за вашите потреби. Меѓутоа, ако имате голем број на корисници, најверојатно ќе бидете преоптоварени од товарот на одржување сметки и соодветни дозволи. За да се олесни овој товар, релациони бази на податоци го поддржуваат поимот улоги. Улогите на базата на податоци функционираат слично на Windows NT групи. Корисничките сметки се доделуваат на улогите, а потоа се доделени дозволите на улогата како целина, а не на индивидуалните кориснички сметки. На пример, ние би можеле да создадеме улога на DBA и потоа да додадеме кориснички сметки на нашиот административен кадар за оваа улога. Откако ќе го сториме тоа, можеме да му доделиме посебна дозвола на сите присутни (и идни) администратори со едноставно доделување дозвола за улогата. Уште еднаш, процедурите за креирање на улоги варираат од платформа до платформа. Администраторите на MS SQL Server треба да ја испитаат sp_addrole чуваат процедура додека Oracle DBA треба да ја користат синтаксата CREATE ROLE.
Давање дозволи
Сега кога додадовме корисници во нашата база на податоци, време е да се започне со зајакнување на безбедноста со додавање на дозволи. Нашиот прв чекор ќе биде да им дадеме на нашите корисници соодветни дозволи за бази на податоци. Ние ќе го постигнеме ова преку употреба на SQL GRANT изјава.
Еве синтакт на изјавата:
Донација <дозволи>
[НА <маса>]
TO
[СО ОПЦИЈА НА ГРАНТ]
Сега, да ја разгледаме оваа изјава по ред. Првата линија, GRANT <дозволите>, ни овозможува да ги специфицираме специфичните дозволи на табелата што ги доделуваме. Овие можат да бидат или дозволи на ниво на табели (како што се SELECT, INSERT, UPDATE и DELETE) или дозволи за базата на податоци (како што се CREATE TABLE, ALTER DATABASE и GRANT). Повеќе од една дозвола може да биде доделена во една изјава за донација, но дозволите на ниво на табела и дозволите на ниво на база на податоци не може да се комбинираат во една изјава.
Втората линија, ON <маса>, се користи за да ја наведете погодената табела за дозволи на ниво на табела. Оваа линија е испуштена ако даваме дозволи на база на податоци. Третата линија го одредува корисникот или улогата за која им се даваат дозволи.
Конечно, четвртата линија, со доделување на опција, не е задолжително. Ако оваа линија е вклучена во изјавата, засегнатиот корисник исто така е дозволено да им ги додели овие истите дозволи на други корисници. Имајте на ум дека WITH GRANT OPTION не може да се специфицира кога дозволите се доделуваат на улога.
Примери
Ајде да погледнеме неколку примери. Во нашето прво сценарио, неодамна ангажиравме група од 42 оператори за внес на податоци кои ќе додадат и одржуваат записи на клиентите. Тие треба да бидат во можност да пристапат до информациите во табелата клиенти, да ги менуваат овие информации и да додаваат нови записи во табелата. Тие не треба да можат целосно да избришат запис од базата на податоци. Прво, ние треба да создадеме кориснички сметки за секој оператор и потоа да ги додадеме сите на нова улога, DataEntry. Следно, треба да ја користиме следнава изјава SQL за да им ги доделиме соодветните дозволи:
Донација Избери, Вметни, Ажурирање
ЗА клиенти
TO DataEntry
И тоа е сè што има за тоа! Сега да го испитаме случајот каде што сме доделуваме дозволи на база на податоци. Ние сакаме да им дозволиме на членовите на DBA улогата да додадат нови табели во нашата база на податоци. Понатаму, ние сакаме тие да бидат во можност да им дозволат на други корисници дозвола да го сторат истото. Еве ја изјавата SQL:
Донација КРЕАЦИЈА ТАБЕЛА
ДО DBA
СО ДОПОЛНИТЕЛНА ОПЦИЈА
Забележете дека ја вклучивме линијата WITH GRANT OPTION за да осигуриме дека нашите DBA може да ја додели оваа дозвола на други корисници.
Отстранување на дозволи
Откако дозволивме да дозволиме, честопати се докажува дека е потребно да ги отповикаат подоцна. За среќа, SQL ни дава команда REVOKE да ги отстрани претходно доделените дозволи. Еве ја синтаксата:
ОТВОРАЈ [ОДГОВОР НА ОПЦИЈА ЗА] <дозволи>
ON <маса>
ОД <корисник / улога>
Ќе забележите дека синтаксата на оваа команда е слична на онаа на командата GRANT. Единствената разлика е во тоа што СО ГРАНТНА ОПЦИЈА е назначена на командната линија REVOKE, наместо на крајот од командата. Како пример, ајде да замислиме дека сакаме да ја одземеме претходно добиената дозвола на Марија да ги отстраниме евиденциите од базата на податоци на клиентите. Ќе ја искористиме следнава команда:
Одбијте избришете
ЗА клиенти
Од Марија
И тоа е сè што има за тоа! Има еден дополнителен механизам поддржан од Microsoft SQL Server кој вреди да се спомене - командата DENY. Оваа команда може да се користи за експлицитно одбивање на дозвола за корисник што инаку би можеле да го имаат преку моментално или идно членство во улоги. Еве ја синтаксата:
DENY <дозволи>
ON <маса>
TO <корисник / улога
Примери
Враќајќи се во нашиот претходен пример, ајде да замислиме дека Марија е исто така член на Управувачката улога која исто така имаше пристап до табелата на клиенти. Претходната изјава за REVOKE нема да биде доволна за да го негира пристапот до табелата. Таа ќе ја отстрани дозволата што ѝ е доделена преку изјава за грант насочена кон нејзината корисничка сметка, но нема да влијае на дозволите стекнати преку нејзиното членство во Управувачката улога. Меѓутоа, ако користиме изјава на DENY, таа ќе го блокира нејзиното наследство од дозволата. Еве ја командата:
DENY DELETE
ЗА клиенти
ДО МАРИ
Командата DENY во суштина создава "негативна дозвола" во контролите за пристап до базата. Ако подоцна одлучиме да му дозволиме на Марија да ги отстрани редовите од табелата клиенти, не можеме едноставно да ја користиме командата GRANT. Таа команда веднаш ќе биде преоптоварена од постоечкиот ДЕНЕ. Наместо тоа, ние прво ќе ја користиме командата REVOKE за да го отстраниме записот за негативна дозвола на следниов начин:
Одбијте избришете
ЗА клиенти
Од Марија
Ќе забележите дека оваа команда е иста како онаа што се користеше за отстранување на позитивна дозвола. Запомнете дека командите DENY и GRANT и работат на сличен начин * mdash, и двете создаваат дозволи (позитивни или негативни) во механизмот за контрола на пристапот на базата на податоци. Командата REVOKE ги отстранува сите позитивни и негативни дозволи за наведениот корисник. Откако ќе биде издадена оваа команда, Марија ќе може да избрише редови од табелата доколку е членка на улога што ја поседува таа дозвола. Алтернативно, командата GRANT може да се издаде за да се овозможи дозвола за бришење директно до нејзината сметка.
Во текот на овој напис, сте научиле добра зделка за механизмите за контрола на пристап поддржани од стандардниот јазик за пребарување. Овој вовед треба да ви даде добра почетна точка, но ве охрабрувам да ја упатите документацијата за DBMS за да ги дознаете подобрените безбедносни мерки поддржани од вашиот систем. Ќе најдете дека многу бази на податоци поддржуваат понапредни механизми за контрола на пристап, како што се доделување на дозволи за одредени колони.