Подробно за контрол на достъпа и кандидатстване контексти (част 1)
Тази статия описва два нови Oracle8i механизъм:-прецизен контрол на достъпа (Fine контрол дребнозърнест Access) и контексти на защитени приложения (Application Secure контексти). Когато се използват заедно, те предоставят нови възможности за качество, за да се гарантира сигурността на информацията от базата данни.
Различните издания на фин контрол на достъпа може да се наричат по различен начин. По-долу са синоними:
Подробно за контрол на достъпа (дребнозърнест Контрол на достъпа - техническа име)
С две думи,-прецизен контрол на достъп до Oracle8i - това е една възможност по време на работа динамично присъединят предикат (където клауза) на един и всички въпроси, издадени срещу таблица или изглед. Така, че е възможно процесуално искане изменение по време на изпълнение. Можете да разбера, който прави искането, когато искането се изпълнява, когато започва изпълнението на заявката, както и формиране на предиката, съответстващи на тези критерии. При използване на контекста Заявленията могат да бъдат безпроблемно чрез околната среда (например, чрез ролята, поверена на потребителското приложение), за да добавите допълнителна информация, както и да получите достъп до него чрез процедурата или сказуемото.
Пример за фин контрол на достъпа може да служи като политика за сигурност, който определя кои редове могат да бъдат достъпни от различни групи потребители. политика на сигурност представлява сказуемото, под формата на които зависи от потребителя, свързан с базата и групата, към която принадлежи. Подробна контрол на достъпа ви позволява да пишете ", изберете * от ЕМИ" различни потребители, за да го превърнат в следния вид:
Запитване динамично пренаписана
Контролер да видите в даден отдел. Това въвежда синтаксиса за получаване на контекстни променливи за кандидатстване - вградена SYS_CONTEXT ().
Има много причини, за да използват този механизъм. Най-често срещаните:
- Лесно се поддържа. Подробна контрол на достъпа ви позволява да имате само една маса и една съхранена процедура за управление, която ще замени използването на няколко представяния. Осигуряване на множество изображения обикновено води до пролиферация на обекти на базата данни, тъй като за всеки потребител група създаване на отделни представяне изисква. Така например, в примера описан по-горе с служители, ръководители и мениджъри в конвенционалната система трябва да създаде база данни три представяния. Ако имате нужда от още една група от потребители, трябва да се добави още един набор от идеи, които ще трябва да се управляват и поддържат. Ако (т.е. да изисква мениджъри видяха не само непосредствените им подчинени, но и на 2 по-долу), ще бъде необходимо с промяната на правилата за сигурност, за да пресъздадете оглед база данни, а след това всички обекти, които се обръщат тези възгледи, ще стане нищожен.
- Извършва се на сървъра. Като се има предвид сложността на управлението и поддържането на голям брой изображения, разработчиците многократно опитват да определят логиката на приложението в заявлението. Заявленията гледат кой е база данни, която е изискана, и да извърши съответните искането. Това предпазва данните, но само когато има връзка с тази молба. Това намалява възможността за използване на генерирането на заявката и доклад, както и други средства за обработка на данни. Също така увеличава вероятността от невярна информация, защото, за да се направи изкривяване, достатъчно, за да се свърже с базата данни чрез всякакви други средства, различни от приложенията за докладване, както и заявка на данните. Благодарение на включването в базата данни на логика безопасност, т.е. механизъм, който определя кои данни могат да бъдат видени от потребителя, - vymozhete бъдете сигурни, че данни са защитени, независимо от средствата за достъп до тях, а лечението може да се извърши с всички средства, от които възможно за достъп до данните.
- Забраната за свързването към базата данни от името на общи потребители. Благодарение на подробен контрол на достъп на всеки потребител трябва да се свърже с базата данни под името. Това гарантира пълна отчетност - можете да следите действия на ниво потребител. По-рано, много от приложенията, когато работят с различни изгледи с данни за различните потребители трябваше да се използва от потребителя база данни, съответно, избрани данни. Така например, в случая по-горе, на служител / управител / ръководител в заявлението трябва да бъдат създадени три сметки. Всеки служител трябва да използва "официалната" акаунт. Всеки мениджър трябва да използвате "Мениджър" акаунт. Всеки контролер трябва да използвате сметката "Контролер". Това прави невъзможно да се разгледа действия на ниво потребител
- Опростяват разработката на приложения. Подробно за контрол на достъпа се логиката на сигурността от логиката на приложението. За сигурността на програмист на приложение може да се съсредоточи върху себе си, а не прилагането на логиката на достъпа на ниско ниво до данните. Тъй-прецизен контрол на достъп е напълно въведена в сървъра, приложението директно наследяват тази логика. Преди това, разработчиците на приложения трябва да се вгради логиката на приложението при вземането на по-сложна, прилагането на първо място да се развива и особено трудно за проследяване му подкрепа. Ако приложението има достъп до данните, както и за едни и същи данни и приложения от множество точки, а след това просто да промените политиката на сигурност може да повлияе на десетките модули за кандидатстване. Чрез използването на фин контрол на достъпа. промени в политиката за сигурност nevliyayut на модули за кандидатстване.
- Използването на усъвършенствани инструменти за разработка на приложения. В много среди, политиките за сигурност на върха все още не е правилно определени и след известно време може да се променят. Ако има сливане или други структурни промени или се въведат правила за секретност, политиката за сигурност, която искате да промените. Тъй като контрол на достъпа се извършва на ниво, близко до данните, че е възможно да се създадат условия за развитието на приложения с минимално влияние върху него, както и на инструменти за развитие. Това е една от причините, за да отидете на автоматична използването на двата нова логика, и всички приложения и инструменти, които дават възможност за достъп до базата данни с новата вградена логика.
В Oracle8i, има два вида-прецизен контрол на достъпа:
За да се възползвате от тази възможност, разработчикът, в допълнение към стандартните роли се свържете и на ресурсите, трябва да има следните привилегии:
EXECUTE_CATALOG_ROLE. Това позволява на разработчика да извършват пакет dbms_rls. Друг вариант - може да бъде прикрепен като SYS, мине привилегията само към пакета: грант изпълнение на dbms_rls да<учетная_запись>.
НЕ ДАВАТ Контекст: Позволява на разработчиците да създават приложения контексти.
контекст на приложения за създаване на прост SQL-команди
OurApp - е името на контекст и Our_Context_Pkg - това PL / SQL-пакет, чрез който се определя от контекста ценности. Възможност за ползване на контексти кандидатстване за фин контрол на достъпа е важно по две причини:
Тя осигурява гарантиран начин за настройване на променливи в пространство от имена. За да се определи стойността на този контекст може само PL / SQL-пакет, свързан с контекста. Това ще гарантира целостта на стойностите от контекста. От контекста използвани за ограничаване или позволява достъп до контекст стойности интегритет на данните трябва да бъдат осигурени.
Ако искате ви политика позволяват на потребителя, който не е RLS_ADMIN, виждат само тези редове, на "собственика", на която той е, тогава трябва да изпълните командата: \
SQL> създаде функция my_security_function (p_schema в varchar2,
2 p_object в varchar2) връщане varchar2
5, ако (ръководство = 'RLS_ADMIN "), след това
8 връщане "собственик = USER ';
Предикати ", където собственик = USER" ще бъде динамично добавя към всички искания, посочени в таблицата, която е свързана с тази функция, която значително намалява броя на редовете, достъпни за потребителя. Предикатна NULL (празен) се връща само когато е свързан понастоящем RLS_ADMIN потребителя база данни. Върнати празен предикат изглежда като "1 = 1" или "TRUE".
С цел да се обвърже тази функция на масата, трябва да използвате PL / SQL процедурата "dbms_rls.add_policy". Например, има следната таблица:
Свързани статии