Всички релационни системи за управление на бази данни предоставят някакъв вид присъщи механизми за сигурност, предназначени да минимизират заплахите от загуба на данни, повреда на данните или кражба на данни. Те варират от простата защита с парола, предлагана от Microsoft Access към сложната структура потребител / роля, поддържана от усъвършенствани релационни бази данни като Oracle иMicrosoft SQL Сървър. Някои механизми за сигурност са общи за всички бази данни, които прилагатезик за структурирани заявки.
Защита на ниво потребител
Сървърно базирани бази данни поддържат a потребител концепция, подобна на тази, използвана в компютърните операционни системи. Ако сте запознати с йерархията потребител / група, намерена в Microsoft Windows NT и Windows 2000, ще откриете, че групите потребители / роли, поддържани от SQL Server и Oracle, са сходни.
Създайте индивидуални потребителски акаунти на база данни за всеки човек с достъп до вашата база данни.
Избягвайте да предоставяте общи акаунти, достъпни за няколко различни хора. Първо, тази практика елиминира индивидуалната отчетност - ако потребител направи промяна във вашата база данни (да кажем чрез като си даде повишение от $ 5000), няма да можете да го проследите до конкретно лице чрез използването на одит трупи. Второ, ако конкретен потребител напусне вашата организация и искате да премахнете достъпа му от базата данни, трябва да промените паролата, на която разчитат всички потребители.
Методите за създаване на потребителски акаунти варират от платформа до платформа и ще трябва да се консултирате със специфичната за СУБД документация за точната процедура. Потребителите на Microsoft SQL Server трябва да проучат използването на sp_adduser съхранена процедура. Администраторите на база данни на Oracle ще намерят СЪЗДАЙТЕ ПОТРЕБИТЕЛ команда полезна. Също така може да искате да проучите алтернативни схеми за удостоверяване. Например Microsoft SQL Server поддържа използването на Windows NT Integrated Security. По тази схема потребителите се идентифицират в базата данни от техните потребителски акаунти на Windows NT и не се изисква да въвеждат допълнителен потребителски идентификатор и парола за достъп до базата данни. Този подход е популярен сред администраторите на бази данни, защото прехвърля тежестта на акаунта управление на персонала на мрежовата администрация и осигурява лесното еднократно влизане в краен потребител.
Сигурност на ниво роля
Ако сте в среда с малък брой потребители, вероятно ще откриете, че създаването на потребителски акаунти и задаването на разрешения директно на тях е достатъчно за вашите нужди. Ако обаче имате голям брой потребители, ще бъдете претоварени от поддържане на акаунти и правилни разрешения. За да се облекчи тази тежест, релационните бази данни поддържат роли. Ролите на базата данни функционират подобно на Windows NT групите. Потребителските акаунти се присвояват на роля (и) и разрешенията след това се присвояват на ролята като цяло, а не на отделните потребителски акаунти. Например можете да създадете DBA роля и след това да добавите потребителските акаунти на вашия административен персонал към тази роля. След това можете да зададете конкретно разрешение на всички настоящи (и бъдещи) администратори, като просто присвоите разрешението на ролята. Още веднъж процедурите за създаване на роли варират от платформа до платформа. Администраторите на MS SQL Server трябва да проучат sp_addrole съхранена процедура, докато Oracle DBA трябва да използват СЪЗДАЙТЕ РОЛЯ синтаксис.
Предоставяне на разрешения
След като добавихме потребители към нашата база данни, е време да започнем да укрепваме сигурността чрез добавяне на разрешения. Първата ни стъпка ще бъде да предоставим подходящи разрешения за база данни на нашите потребители. Ще постигнем това чрез използването на оператора SQL GRANT.
Ето синтаксиса на изявлението:
ГРАНТ.
[НА.
ДА СЕ.
[С ОПРЕДЕЛЕНА ОПЦИЯ]
Сега, нека да разгледаме това изявление ред по ред. Първият ред, ГРАНТ , ни позволява да посочим конкретните разрешения за таблици, които предоставяме. Това могат да бъдат или разрешения на ниво таблица (като SELECT, INSERT, UPDATE и DELETE) или разрешения на база данни (като CREATE TABLE, ALTER DATABASE и GRANT). Повече от едно разрешение могат да бъдат предоставени в един оператор GRANT, но разрешения на ниво таблица и разрешения на ниво база данни не могат да се комбинират в един израз.
Вторият ред, НА
И накрая, четвъртият ред, С ГРАНТОВА ОПЦИЯ, е по избор. Ако този ред е включен в изявлението, засегнатият потребител също има право да предоставя същите разрешения на други потребители. Обърнете внимание, че WITH GRANT OPTION не може да бъде посочено, когато разрешенията са присвоени на роля.
Примерни безвъзмездни средства за база данни
Нека разгледаме няколко примера. В първия ни сценарий наскоро наехме група от 42 оператора за въвеждане на данни, които ще добавят и поддържат записи на клиенти. Те трябва да имат достъп до информация в таблицата на клиентите, да променят тази информация и да добавят нови записи към таблицата. Те не трябва да могат да изтрият изцяло запис от базата данни.
Първо, трябва да създадем потребителски акаунти за всеки оператор и след това да ги добавим към нова роля, Въвеждане на данни. След това трябва да използваме следния SQL израз, за да им предоставим подходящите разрешения:
ДАЙТЕ ИЗБЕРЕТЕ, ВМЕСТЕТЕ, АКТУАЛИЗИРАТЕ.
НА клиенти.
TO DataEntry.
Сега нека разгледаме случай, в който присвояваме разрешения на ниво база данни. Искаме да позволим на членовете на ролята на DBA да добавят нови таблици към нашата база данни. Освен това искаме те да могат да предоставят разрешение на други потребители да правят същото. Ето SQL израза:
ГРАНТ СЪЗДАЙТЕ ТАБЛИЦА.
КЪМ DBA.
С ГРАНТОВА ОПЦИЯ.
Забележете, че сме включили реда WITH GRANT OPTION, за да гарантираме, че нашите администратори на данни могат да присвоят това разрешение на други потребители.
Премахване на разрешения
SQL включва командата REVOKE за премахване на предварително предоставени разрешения. Ето синтаксиса:
ОТМЕНЕТЕ [ОПРЕДЕЛЕНО ОПЦИЯ ЗА]
НА.
ОТ.
Ще забележите, че синтаксисът на тази команда е подобен на този на командата GRANT. Единствената разлика е, че WITH GRANT OPTION е посочено в командния ред REVOKE, а не в края на командата. Като пример, нека си представим, че искаме да отнемем предварително предоставеното разрешение на Мери за премахване на записи от базата данни на клиентите. Ще използваме следната команда:
ОТМЕНЕТЕ ИЗТРИВАНЕ.
НА клиенти.
ОТ Мери.
Има един допълнителен механизъм, поддържан от Microsoft SQL Server, който си струва да се спомене - командата DENY. Тази команда може да се използва за изрично отказване на разрешение на потребител, което иначе може да има чрез текущо или бъдещо членство в роля. Ето синтаксиса:
ОТРЕЧАЙТЕ.
НА.
ДА СЕ.