[ главная ]   [ рейтинг статей ]   [ справочник радиолюбителя ]   [ новости мира ИТ ]



Ответов: 0
25-02-12 07:01







   Web - программирование
PHP


ASP






XML



CSS

SSI





   Программирование под ОС











   Web - технологии








   Базы Данных









   Графика






Данные




Базы Данных / MySQL /

Oracle: Изучаем метки доступа к строкам: задание свойств столбца доступа в таблице

Эта статья рассматривает некоторые особенности средства label security в oracle. Здесь показана возможность секретить служебный столбец с метками доступа к строкам, а также рассмотрены некоторые правила правки меток. В первую очередь статья затрагивает использование параметра table_options процедуры apply_table_policy из пакета sa_policy_admin.

Введение


 

label security есть реализация фирмой oracle меточного, или
мандатного метода доступа, известного специалистам по защите
данных. Описание label security в документации oracle имеет характерный
справочный характер, что в данном случае можно считать обоснованным, так
как самый мандатный доступ не придуман фирмой (аналогично тому, как фирма
oracle не придумала sql или, скажем, jdbc). В то же время описание
мандатного доступа, на которое ссылается фирма oracle,
href="http://niap.nist.gov/cc-scheme/cc_docs/"
target=_blank>http://niap.nist.gov/cc-scheme/cc_docs/
, весьма непросто
для восприятия специалистом по БД. Несколько более понятны тексты на
русском языке, подготовленные
href="http://www.sbcinfo.ru/articles/doc/gtc_doc/contents.htm"
target=_blank>Гостехкомиссией при Президенте РФ
, однако и они
рассчитаны в первую очередь на специалистов по безопасности.
 

Настоящая работа предназначена показать некоторые возможности label
security именно администраторам и разработчикам на oracle, а главное -
помочь им в самостоятельном изучении этой темы. Без последнего, увы, не
обойтись: даже выборочное рассмотрение меточного доступа на простых
примерах потребовало сразу серии статей !
 

Здесь будет показана возможность секретить служебный столбец с метками
доступа к строкам, а также рассмотрены некоторые возможности правки
конкретных меток. В первую очередь статья сосредотачивается на
использовании параметра table_options процедуры apply_table_policy из
пакета sa_policy_admin.
 

Подготовка к работе


 

Предполагается, что имеются структуры и объекты, а именно:
 


     
  • первоначально отсутствовавшая в схеме scott таблица phone,
    заполненная номерами телефонов для сотрудников из таблицы emp
     
  • два уровня секретности с краткими названиями 'open' и 'limited'
     
  • политика меточного доступа под названием empsec_policy и заданное в
    рамках этой политики название служебного столбца для меток доступа под
    названием empsec_label
     
  • две разные метки, построенные на базе имеющихся уровней секретности,
    и которыми в рамках политики empsec_policy помечены строки таблиц phone
    и emp схемы scott
     
  • два пользователя employee и head, отмеченные разными правами доступа
    к строкам

 

Чтобы все это построить в своей БД, достаточно шаг за шагом повторить
действия из предыдущей статьи.
 

Для удобства работы в sql*plus подготовим несколько файлов. Файл
phonepolicyoptions.sql:

connect lbacsys/lbacsys


begin sa_policy_admin.remove_table_policy ( policy_name => 'empsec_policy' , schema_name => 'scott' , table_name => 'phone' , drop_column => true ); end; /
begin sa_policy_admin.apply_table_policy ( policy_name => 'empsec_policy' , schema_name => 'scott' , table_name => 'phone' , table_options => '&1' ); end; /
update scott.phone set empsec_label = case when empno in ( select empno from scott.emp where job in ( 'manager', 'president' ) ) then char_to_label ( 'empsec_policy', 'limited' ) else char_to_label ( 'empsec_policy', 'open' ) end ;

 

В этом сценарии сначала из политики empsec_policy исключается таблица
scott.phone, причем благодаря явно указанному значению параметра
drop_column => true служебный (в рамках этой политики) столбец
empsec_label также удалится. Затем политика применяется к таблице заново,
а ее (новые, те, что нам требуется) свойства будем указывать через
параметр для sql*plus. Поскольку служебный столбец в таблице phone
воссоздается заново, его придется и заново заполнять, причем (обратите
внимание !) ради удобства всегда однаково.
 

Другой файл, phones.sql, послужит для наблюдения результата:
 

select ename, pno

from scott.emp left outer join scott.phone

using (empno)

/

 

Он взят из предыдущей статьи, но в силу своей краткости и ради ясности
повторяется здесь.
 

Создадим также файл updateallen.sql:

update scott.phone 

set 

  empsec_label

= char_to_label ( 'empsec_policy', '&1' ) 

where

  empno 

= ( select empno from scott.emp where ename = 'allen' )

/


 

Несколько прочих сценарных файлов будет создано по ходу дела.
 

Выдадим в sql*plus:

sql> set verify off


 

Можно ставить опыты.
 

Исчезающий столбец


 

В предыдущей статье оговаривалось, что служебный столбец, добавленный в
результате применения политики к таблице, можно скрыть от пользователей.
Покажем, как это сделать. Выдадим в sql*plus:

@phonepolicyoptions 'read_control, hide'

 

Проверка:

sql> column policy_name format a22

sql> column schema_name format a12

sql> column table_name format a12

sql> column table_options format a15 word

sql> select policy_name, schema_name, table_name, table_options

  2  from dba_sa_table_policies;



policy_name schema_name table_name table_options ---------------------- ------------ ------------ -------------- empsec_policy scott emp read_control, label_default empsec_policy scott phone read_control, hide
sql> save showoptions Создано file showoptions.sql sql> connect employee/employee Соединено. sql> select column_name from all_tab_columns 2 where owner = 'scott' and table_name = 'phone';
column_name ------------------------------ empno pno
sql> save showcolumns Создано file showcolumns.sql sql> connect head/head Соединено. sql> /
column_name ------------------------------ empno pno

 

Обратите внимание: столбец empsec_label стал невидим, то есть ни у
хозяина таблицы, ни у пользователей не стало причин догадываться, что им
предъявляется только часть строк ! Дополнительной скрытности добавляет то
обстоятельство, что даже sys не увидит скрытого столбца (проверьте это !)
А вот для сравнения, что будет, если свойство hide «уберем» (то есть не
укажем):

@phonepolicyoptions 'read_control'

 

Проверка:

sql> connect head/head

Соединено.

sql> @showcolumns


column_name ------------------------------ empno pno empsec_label

 

Обратите внимание на то, что когда столбец empsec_label был невидим,
это обстоятельство не помешало администратору label security (пользователю
lbacsys) обратиться к столбцу командой update scott.phone set
empsec_label = ...
в файле phonepolicyoptions.sql.
 

Кто и как может изменять метки секретности


 
Умолчательная реакция на изменение метки обычным пользователем

 

Метку секретности строки можно поменять, и администратор (пользователь
lbacsys) это уже делал. А вот что произойдет, если поменять значение метки
попробуют «обычные» пользователи:

connect / as sysdba


grant insert, update, delete on scott.phone to minimal;
Проверка:
sql> connect head/head

Соединено.

sql> @updateallen open


1 строка обновлена.
sql> @updateallen limited
1 строка обновлена.
sql> @updateallen limited
1 строка обновлена.
sql> @updateallen open
1 строка обновлена.

 

Вывод: пользователь head беспрепятственно изменяет метку строки, как
ему угодно. А пользователь employee ?

sql> connect employee/employee

Соединено.

sql> @updateallen open


1 строк обновлено.
sql> @updateallen open
1 строк обновлено.
sql> @updateallen limited
1 строк обновлено.
sql> @updateallen limited
0 строк обновлено.
sql> @updateallen open
0 строк обновлено.

 

Очевидно, как только метка становится limited, пользователь employee
теряет возможность ее изменять, а когда значение метки - open, он такую
возможность имеет. Он даже может сделать строку более секретной, но тогда
потеряет к ней доступ.
 

Запрет делать то, результат чего не увидишь

 

Ситуация напоминает выводимую таблицу, view, где обладатель права
изменять view может добавить через view в базовую таблицу строки, которые
сам через view не увидит. Воспрепятствовать этому способно специальное
ограничение целостности with check option. А можно ли здесь запретить
выводить строки из зоны собственной видимости ? Да: для этого в параметре
table_options достаточно указать специальный режим check_control
использования метки в таблице phone. Выдаем в sql*plus:

@phonepolicyoptions 'read_control, check_control'
Проверка:
 
sql> connect employee/employee

connected.

sql> @updateallen open


1 row updated.
sql> @updateallen limited update scott.phone * error at line 1: ora-28115: policy with check option violation
sql> @updateallen open
1 row updated.
В то же время пользователь head, который «видит все», нового
ограничения не заметит:
sql> connect head/head 

connected.

sql> @updateallen open


1 row updated.
sql> @updateallen limited
1 row updated.
sql> @updateallen limited
1 row updated.
sql> @updateallen open
1 row updated.

 
Жесткий запрет на изменение метки

 

Другой режим использования метки в table_options еще более
ограничителен. Он вовсе запрещает изменять значение метки, не важно в
сторону ли увеличения или понижения ее секретности. Выдадим:

@phonepolicyoptions 'read_control, label_update'

 

Проверяем:

sql> connect employee/employee

connected.

sql> @updateallen open


1 row updated.
sql> @updateallen limited update scott.phone * error at line 1: ora-12406: unauthorized sql statement for policy empsec_policy ... ... ... ...
sql> @updateallen open
1 row updated.
sql> connect head/head connected. sql> @updateallen open
1 row updated.
sql> @updateallen limited update scott.phone * error at line 1: ora-12406: unauthorized sql statement for policy empsec_policy ... ... ... ...

 

Пример пока лишь доказывает, что метку нельзя сделать более
«секретной». Но возможно, разрешено «играть на понижение» секретности ?
Проверям снова:

connect lbacsys/lbacsys

connected.

sql> @updateallen limited


1 row updated.
sql> connect head/head connected. sql> @updateallen limited
1 row updated.
sql> @updateallen open update scott.phone * error at line 1: ora-12406: unauthorized sql statement for policy empsec_policy ... ... ... ...

 

Что и требовалось доказать: режим label_update использования метки,
заданный для таблицы phone в рамках нашей политики, не позволяет обычным
пользователям изменять значение меток доступа в строках таблицы.


Владимир Пржиялковский


Комментарии

 Ваш комментарий к данному материалу будет интересен нам и нашим читателям!



Последние статьи: Базы Данных / MySQL /

Близкие контакты третьего вида с Visual Foxpro (или как написать свой провайдер для FoxPro)
12-03-2010   

Многие наверное как и я в свое время задавались интересным вопросом – “А вот как бы задействовать всю силу применяемой в моем проекте СУБД? Не только стандартные SQL запросы, а и скрытые возможности.” Тогда ведь можно будет получать результат найэффективнешими методам... подробнее

Кол. просмотров: общее - 4458 сегодня - 2

Oracle: Изучаем метки доступа к строкам: задание свойств столбца доступа в таблице
07-03-2010   

Эта статья рассматривает некоторые особенности средства label security в oracle. Здесь показана возможность секретить служебный столбец с метками доступа к строкам, а также рассмотрены некоторые правила правки меток. В первую очередь статья затрагивает использование параметра table_options процедуры apply_table_policy из пакета sa_policy_admin... подробнее

Кол. просмотров: общее - 3248 сегодня - 0

Простой журнал аудита на триггерах MySQL
07-03-2010   

Небольшая заметка об использовании триггеров в СУБД MySQL. Несмотря на достаточно приличный возраст этой СУБД, поддержка триггеров появилась только в 5-й версии и достаточно мало описана на русском языке... подробнее

Кол. просмотров: общее - 3152 сегодня - 0

Настройки mysql-server сразу после установки
07-03-2010   

Мой любимый вопрос, задаваемый DBA, которые хотят увеличить производительность MySQL: “какие параметры надо настраивать в первую очередь, сразу после установки сервера?”... подробнее

Кол. просмотров: общее - 2938 сегодня - 2

10+ способов обрушить mysql-сервер
07-03-2010   

Иногда у меня спрашивают о ошибках MySQL, (например таких), которые могут привести к обрушиванию mysql-сервера пользователем с обычными привелегиями. Потом звучит вопрос: “Что же делать в таких случаях? Как защититься от подобных ситуаций?”... подробнее

Кол. просмотров: общее - 8310 сегодня - 1



  WWW.COMPROG.RU - 2009-2012 | Designed and Powered by Zaipov Renat | Projects