| Oracle Label Security - част I |
| Понеделник, 31 Юли 2006 12:20 | |||||||||||||||||||||||||
|
Когато говорим за привилигии в термините на Oracle, обикновено имаме предвид два типа ограничаване или предоставяне на достъп - на системно ниво (например "свързване към базата") и на ниво достъп до обект (например select върху определена таблица за дадена роля). Управлението на достъпа до информацията на ниво обект на принципа "всичко или нищо" не винаги е подходящо. Как трябва да постъпим, ако искаме различни потребители да имат достъп само до определени части от данните в една таблица? Тук на помощ идва Oracle Label Security (OLS). OLS е опция към Oracle Database Enterprise Edition, чрез която на различните типове информация могат да се задават класифициращи етикети. Тези етикети показват колко "чувствителна" е информацията и според правата на потребителите може да им бъде предоставен или отказан достъп. По този начин контролът на сигурността слиза едно ниво "надолу" - от контрол на ниво обект до контрол на ниво ред в таблица. Концепция В OLS са дефинирани три вида критерии за управление на достъпа - ниво, област и група. Нивото показва чувствителността на дадена информация. Ако използваме тривиалния пример дадена информация може да бъде некласифицирана, класифицирана, секретна и строго секретна. Областите от своя страна представят отделени една от друга зони с информация, за които са валидни различни ограничения за достъп. Често чрез областите представяме функционалните групи в дадена организация (счетоводство, човешки ресурси, администрация и т.н.) Групите се използват за лимитиране на достъпа на собственикът на информацията и също могат да се използват за описване на по-сложни правила при достъпа. Те могат да се задават различни права спрямо йерархичната структура на организация (например локалният мениджър вижда само своите продажби, регионалният - тези в целия регион). Как работи Oracle Label Security Когато към дадена таблица с данни се създаде нова политика на сигурност, автоматично към таблицата се добавя нова колона. В последствие в нея записваме нивото на чувствителност на всеки отделен ред (казано по друг начин поставяме "етикет" на всеки ред). Тези "етикети" представляват комбинация от нивото на чувствителност, областта и групата. Когато потребител се опита да достъпи данните в таблицата, той първо трябва да удовлетвори политиката за достъп до обектите (с други думи, да има например SELECT върху таблицата). Идеята тук е, че DAC и OLS не се изключват взаимно, а елегантно се допълват. След като потребителят е получил достъп до таблицата, той може да изпълни някаква заявка към нея. Тогава в зависимост от самоличността на потребителя се определя и неговото ниво на достъп, което се сравнява с нивото на всеки отделен ред. Ако нивото на достъп на потребителя удовлетворява критериите за достъп до данните в реда, то всичко е наред. В противен случай, този ред се "скрива" от потребителя и той не може да получи достъп до него (фактически, той изобщо не го вижда).  Примерен сценарий - контрол на достъпа към HR данни Тъй като данните на отдел Човешки ресурси обикновено са чувствително място за всяка компания, а и примерните данни на Oracle базата съдържат такава схема, ще изградим примерният сценарий около нея. Схемата HR съдържа таблиците REGIONS, LOCATIONS, DEPARTMENTS, JOBS, COUNTRIES, JOB_HISTORY и EMPLOYEES. Тъй като собственик на тези данни е потребителят hr то той ще определя нивото на чувствителност на данните в тези таблици. В таблицата EMPLOYEES са описани всички служители на компанията - общо 107 души.  Президентът на компанията е Steven King (неговият JOB_ID е AD_PRES, който в таблицата JOBS е описан като President). Steven има двама вицепрезиденти - Neena Kochhar и Lex De Haan. Ще обърнем внимание на още един от служителите – Shanta Vollman. Хората включени в нашия демонстрационен сценарий са описани в следната таблица:
Всеки от служителите е зачислен в някой от отделите (описани в таблицата DEPARTMENTS), а всеки отдел се намира в определен град и държава (чрез таблицата LOCATIONS). По-голямата част от отделите са в САЩ, два са в UK, един в Канада и един в Германия. Служителите работещи в различните отдели можем да преброим чрез следния SELECT: SELECT COUNTRY_ID, COUNT (COUNTRY_ID) FROM EMPLOYEES EMP, DEPARTMENTS DEP, LOCATIONS LOC WHERE (EMP.DEPARTMENT_ID = DEP.DEPARTMENT_ID) AND (DEP.LOCATION_ID = LOC.LOCATION_ID) GROUP BY LOC.COUNTRY_ID; Резултатът е: COUNTRY_ID COUNT(COUNTRY_ID) ---------- ---------------------- US 68 CA 2 DE 1 UK 35 4 rows selected Идеята в нашия демонстрационен сценарий е така да защитим достъпа към данните в таблицата EMPLOYEES, че двамата вицепрезиденти да виждат единствено информацията за регионите, за които отговарят, а техният мениджър (президентът на компанията) да има достъп до данните и на двамата си подчинени.  Казано по друг начин, трябва да изградим защитен достъп до данните съгласно корпоративната йерархия. Когато приключим с имплементацията на механизма за сигурност, две еднакви заявки пуснати от двамата вицепрезиденти трябва да връщат различни резултати спрямо правата им. Преди обаче да започнем да изграждаме защитата на данните, трябва да инсталираме и конфигурираме Oracle Label Security. Описание на инсталацията и конфигурацията на OLS можем да видим в този кратък tutorial . Създаване на потребителите Преди да създадем акаунтите на потребителите, с които ще извършваме различните тестове свързани със сигурността трябва да се уверим, че акаунтът на потребителя hr е активен. Тъй като той е собственикът на данните, ще използваме неговия достъп, за да дефинираме някои части от политиката на достъп. Също така ще създадем и една роля, чрез която ще дадем права на новите потребителски акаунти. Ролята ще наречем EMPLOYEE_ROLE и ще й дадем права да вижда данните в таблицата EMPLOYEES. Потребителите които ще създадем и които ще използваме за тестове на OSL са следните:
За да свършим описаните неща ще използваме малък скрипт, наречен setup_users.sql със следното съдържание: /* * ORACLE LABEL SECURITY * * SETUP_USERS.SQL * */ connect / as sysdba; -- Unlock the HR account alter user hr identified by hr account unlock; -- Create the EMPLOYEE_ROLE and grant some privileges create role employee_role; grant select on hr.employees to employee_role; grant create session to employee_role; -- Create user accounts create user sking identified by sking; create user nkochhar identified by nkochhar; create user ldehaan identified by ldehaan; create user svollman identified by svollman; -- Grant the EMPLOYEE_ROLE to all user accounts grant employee_role to sking; grant employee_role to nkochhar; grant employee_role to ldehaan; grant employee_role to svollman; Изпълняваме скрипта през SQL*Plus и ако всичко е наред, потребителите ще бъдат създадени и ще получат нужните права: SQL> @/home/oracle/setup_users.sql Connected. User altered. Role created. Grant succeeded. Grant succeeded. User created. User created. User created. User created. Grant succeeded. Grant succeeded. Grant succeeded. Grant succeeded. SQL> Създаване на политика Първата стъпка от внедряването на Label Security е дефиницията на политика за сигурност и нейното прилагане към обектите, които искаме да защитим. Когато прилагаме политика към дадена таблица или схема, можем да зададем ограничаващи опции, които се прилагат при използването на данните. Ако не зададем ограничаващи опции, то по подразбиране се използват зададените в самата политика. За създаването на политика за сигурност можем да използваме CREATE_POLICY процедурата, която има следния синтаксис: PROCEDURE CREATE_POLICY ( policy_name IN VARCHAR2, column_name IN VARCHAR2 DEFAULT NULL, default_options IN VARCHAR2 DEFAULT NULL); Параметрите, които трябва да зададем имат следния смисъл:
Различните ограничаващи опции по подразбиране (default_options) са подробно описани в документацията на Oracle. Тези, които ще използваме при създаването на нашата политика ще бъдат
След като опциите, които ще използваме са уточнени, трябва да създадем политиката чрез администраторския акаунт на OLS. Можем да напишем и изпълним следния скрипт: /* * ORACLE LABEL SECURITY * * CREATE_POLICY.SQL * */ connect lbacsys/lbacsys; BEGIN SA_SYSDBA.CREATE_POLICY( policy_name=>'ACCESS_EMPLOYEES', column_name=>'SECURITY_LABELS', default_options=>'READ_CONTROL, LABEL_DEFAULT, HIDE' ); END; / Кръщаваме политиката ACCESS_EMPLOYEES,a името на колоната с етикетите ще бъде SECURITY_LABELS. Изпълняваме скрипта: SQL> @/home/oracle/create_policy.sql Connected. PL/SQL procedure successfully completed. SQL> При създаването на нова политика, автоматично се създава и една нова роля, която се именува по същия начин като политиката, но последвано от _DBA. В нашия случай автоматично създадената роля се нарича ACCESS_EMPLOYEES_DBA. Тази роля определя кои потребители могат да изпълняват административните процедури на политика. В примерния сценарий за управление на правата и политиката ще използваме потребителя LBACSYS. Ако обаче се наложи да предоставим такива права на друг потребител то можем да му дадем ролята ACCESS_EMPLOYEES_DBA и той ще може да извършва основните дейности около управлението на ACCESS_EMPLOYEES. Към Част II |
Коментари