|
Возможно вас заинтересует
|
|
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 /
| |
| | |
|
Многие наверное как и я в свое время задавались интересным вопросом – “А вот как бы задействовать всю силу применяемой в моем проекте СУБД? Не только стандартные SQL запросы, а и скрытые возможности.” Тогда ведь можно будет получать результат найэффективнешими методам... подробнее
|
|
Кол. просмотров: общее - 6241 сегодня - 1
|
|
|
Эта статья рассматривает некоторые особенности средства label security в oracle. Здесь показана возможность секретить служебный столбец с метками доступа к строкам, а также рассмотрены некоторые правила правки меток. В первую очередь статья затрагивает использование параметра table_options процедуры apply_table_policy из пакета sa_policy_admin... подробнее
|
|
Кол. просмотров: общее - 4571 сегодня - 0
|
|
|
Небольшая заметка об использовании триггеров в СУБД MySQL. Несмотря на достаточно приличный возраст этой СУБД, поддержка триггеров появилась только в 5-й версии и достаточно мало описана на русском языке... подробнее
|
|
Кол. просмотров: общее - 4493 сегодня - 0
|
|
|
Мой любимый вопрос, задаваемый DBA, которые хотят увеличить производительность MySQL: “какие параметры надо настраивать в первую очередь, сразу после установки сервера?”... подробнее
|
|
Кол. просмотров: общее - 4360 сегодня - 0
|
|
|
Иногда у меня спрашивают о ошибках MySQL, (например таких), которые могут привести к обрушиванию mysql-сервера пользователем с обычными привелегиями. Потом звучит вопрос: “Что же делать в таких случаях? Как защититься от подобных ситуаций?”... подробнее
|
|
Кол. просмотров: общее - 9702 сегодня - 0
|
|
| 
