Сигурността е от първостепенно значение за администраторите на бази данни, които искат да защитят своите гигабайти от жизненоважни бизнес данни от любопитните очи на неоторизирани външни лица и вътрешни лица, опитващи се да надхвърлят авторитета си. Всички системи за управление на релационни бази данни осигуряват някакъв вид присъщи механизми за сигурност, предназначени да сведат до минимум тези заплахи. Те варират от простата защита с парола, предлагана от Microsoft Access до сложната структура на потребител / ролка, поддържана от съвременни релационни бази данни като Oracle и 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 Integrated Security. Съгласно тази схема потребителите се идентифицират към базата данни чрез техните потребителски акаунти в Windows NT и не се изисква да въвеждат допълнителен потребителски идентификатор и парола за достъп до базата данни. Този подход е изключително популярен сред администраторите на бази данни, тъй като прехвърля тежестта на управлението на сметките към служителите в администрацията на мрежата и осигурява лекотата на еднократно влизане в крайния потребител.
Роли
Ако сте в среда с малък брой потребители, най-вероятно ще откриете, че създаването на потребителски акаунти и задаването на разрешения директно на тях е достатъчно за вашите нужди. Въпреки това, ако имате голям брой потребители, най-вероятно ще бъдете затрупани от тежестта на поддържането на сметки и подходящите разрешения. За да се облекчи тази тежест, релационните бази данни подкрепят понятието роли. Ролите на базите данни функционират по същия начин като Windows NT групите. Потребителските акаунти се присвояват на роля (и) и след това разрешенията се присвояват на ролята като цяло, а не на индивидуалните потребителски акаунти. Например, можем да създадем ролята на DBA и след това да добавим потребителските профили на нашия административен персонал към тази роля. След като извършим това, можем да дадем конкретно разрешение на всички настоящи (и бъдещи) администратори, като просто зададем разрешението на тази роля. Още веднъж, процедурите за създаване на роли варират от платформата до платформата. Администраторите на MS SQL Server трябва да разследват съхранената процедура sp_addrole, докато Oracle DBAs трябва да използват синтаксиса CREATE ROLE.
Предоставяне на разрешения
Сега, когато добавихме потребители към нашата база данни, е време да започнем да засилваме сигурността чрез добавяне на разрешения. Първата ни стъпка ще бъде да предоставим подходящи разрешения за базата данни на нашите потребители. Ще постигнем това чрез използването на изявлението SQL GRANT.
Ето синтаксиса на израза:
GRANT <разрешения>
[ON
]
ДО <потребител / роля>
[С ОТПУСКАНЕ НА ОТПУСКАНЕ]
Сега, нека да разгледаме това изявление по ред. Първият ред GRANT <разрешения> ни позволява да определим конкретните разрешения за таблици, които предоставяме. Те могат да бъдат разрешения на ниво таблица (като SELECT, INSERT, UPDATE и DELETE) или разрешения за бази данни (като CREATE TABLE, ALTER DATABASE и GRANT). Повече от едно разрешение може да бъде дадено в един отчет на GRANT, но разрешенията на ниво таблица и разрешенията на ниво база данни може да не се комбинират в един отчет.
Вторият ред, ON
, се използва за определяне на засегнатата таблица за разрешения на ниво таблица. Този ред е пропуснат, ако предоставяме разрешения на ниво база данни. Третият ред посочва потребителя или ролята, на която се предоставят разрешения.
Накрая, четвъртият ред, с възможност за отпускане на средства, е по избор. Ако този ред е включен в изявлението, засегнатият потребител също така има право да предостави същите разрешения на други потребители. Обърнете внимание, че опцията WITH GRANT OPTION не може да бъде зададена, когато правата за достъп са определени за роля.
Примери
Да разгледаме няколко примера. В нашия първи сценарий наскоро наехме група от 42 оператори за въвеждане на данни, които ще добавят и поддържат клиентски записи. Те трябва да имат достъп до информацията в таблицата "Клиенти", да променят тази информация и да добавят нови записи в таблицата. Те не би трябвало да могат да изтрият изцяло запис от базата данни. Първо, трябва да създадем потребителски акаунти за всеки оператор и след това да ги добавим към нова роля, DataEntry. След това трябва да използваме следния SQL израз, за да му дадем съответните разрешения:
GRANT SELECT, INSERT, UPDATE
ON Клиенти
Към DataEntry
И това е всичко, което има! Сега нека разгледаме случая, при който възлагаме разрешения на ниво база данни. Искаме да позволим на членовете на DBA да добавят нови таблици към нашата база данни. Освен това искаме те да могат да дават на други потребители разрешение да направят същото. Ето SQL израза:
ТАБЛИЦА СЪЗДАВАНЕ НА ГРАНТ
ДО DBA
С ОТПУСКАНЕ НА ОТПУСКАНЕ
Забележете, че сме включили линията WITH GRANT OPTION, за да сме сигурни, че нашите DBA могат да припишат това разрешение на други потребители.
Премахване на разрешенията
След като сме издали разрешения, често се оказва необходимо да ги отменим на по-късна дата. За щастие SQL ни предоставя командата REVOKE, за да премахнем предоставените по-рано разрешения. Ето синтаксиса:
REVOKE [OPTION за GRANT] <разрешения>
ON
ОТ <потребител / роля>
Ще забележите, че синтаксиса на тази команда е подобен на командата GRANT. Единствената разлика е, че опцията GRANT OPTION е зададена в командния ред REVOKE, а не в края на командата. Като пример, нека си представим, че искаме да отменим преди разрешението на Мария да премахне записи от базата данни на клиентите. Ще използваме следната команда:
ОТВАРЯНЕ
ON Клиенти
От Мери
И това е всичко, което има! Има един допълнителен механизъм, поддържан от Microsoft SQL Server, който заслужава да бъде споменат - командата DENY. Тази команда може да се използва, за да се откаже изрично разрешение на потребител, което иначе би могло да има чрез настоящо или бъдещо членство в ролите. Ето синтаксиса:
DENY <разрешения>
ON
ДО <потребител / роля
Примери
Връщайки се към нашия предишен пример, нека си представим, че Мери също е член на ролята на мениджърите, който също има достъп до таблицата "Клиенти". Предходното изявление REVOKE не би било достатъчно, за да откаже достъп до масата. Тя ще премахне разрешението, предоставено й чрез извлечение на GRANT, насочено към потребителския си профил, но няма да повлияе на правата, придобити чрез нейното членство в ролята на мениджърите. Ако обаче използваме изявление DENY, то ще блокира наследството й. Ето командата:
Изтриване на денонощието
ON Клиенти
ДО Mary
Командата DENY по същество създава "отрицателно разрешение" в контролите за достъп до базата данни. Ако по-късно решим да дадем на Мария разрешение да премахнем редове от таблицата "Клиенти", не можем просто да използваме командата GRANT. Това командване ще бъде незабавно преодоляно от съществуващия DENY. Вместо това първо трябва да използваме командата REVOKE за премахване на отрицателното разрешение, както следва:
ОТВАРЯНЕ
ON Клиенти
От Мери
Ще забележите, че тази команда е същата като тази, използвана за премахване на положително разрешение. Не забравяйте, че командите DENY и GRANT работят по подобен начин - те създават разрешения (положителни или отрицателни) в механизма за контрол на достъпа до базата данни. Командата REVOKE премахва всички положителни и отрицателни разрешения за конкретния потребител. След като тази команда бъде издадена, Мери ще може да изтрива редове от таблицата, ако тя е член на роля, която притежава това разрешение. Друга възможност е да бъде издадена команда GRANT, за да се предостави разрешението DELETE директно на нейната сметка.
В хода на тази статия научихте много за механизмите за контрол на достъпа, поддържани от стандартен език за заявки. Това въведение трябва да ви даде добра отправна точка, но Ви препоръчвам да направите справка в документацията на DBMS, за да научите засилените мерки за сигурност, поддържани от вашата система. Ще откриете, че много бази данни поддържат по-усъвършенствани механизми за контрол на достъпа, като даване на разрешения за конкретни колони.