Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Базы данных. Лекции по курсу. В 4 частях. Ч.4. Учебное пособие
.pdf
SQL> grant create table to u1;
Привилегии предоставлены.
SQL> create user u2 identified by u2psw default tablespace example;
Пользователь создан.
SQL> grant connect to u2;
Привилегии предоставлены.
SQL> connect u1/u1psw
Соединено.
SQL> create table tab1(at1 int);
Таблица создана
SQL> create table u2.tab1(at1 int);
create table u2.tab1(at1 int)
*
ошибка в строке 1:
ORA-01031: привилегий недостаточно
Пример 2. Работа с системными привилегиями
Администратор предоставил пользователю u2 права на создание
таблицы и запись в нее строк, после чего пользователь u2 успешно выполнил эти операции. Пользователь u1 не может выполнить выборку
строк до тех пор, пока ему не будет предоставлена данная привилегия.
SQL> CONNECT adm/admpsw;
Соединено.
SQL> grant create table to u2;
Привилегии предоставлены.
SQL> grant insert any table to u2;
Привилегии предоставлены.
SQL> connect u2/u2psw
Соединено.
SQL> create table tab1(at1 int);
41
Таблица создана
SQL> insert into tab1 values (1);
1 строка создана.
SQL> commit;
Фиксация обновлений завершена.
SQL> connect u1/u1psw;
Соединено.
SQL> select * from u2.tab1;
select * from u2.tab1
ошибка в строке 1:
ORA-01031: привилегий недостаточно
SQL> CONNECT adm/admpsw;
Соединено.
SQL> grant select any table to u1;
Привилегии предоставлены.
SQL> connect u1/u1psw;
Соединено.
SQL> select * from u2.tab1;
At1
--------------
1
Следующий пример иллюстрирует возможность предоставления
набора привилегий одной командой. Пусть таблица Tab1 создана предложением:
CREATE TABLE Tab1(At1 Number);
Владелец таблицы, пользователь и2, предоставляет пользователю u1
привилегии по выборке, вставке и
модификации для таблицы Tab1.
Выполнение операций, привилегии для которых предоставлены,
проходит успешно, а попытка пользователя u1 выполнить удаление
строк отвергается системой.
42
Пример 3. Предоставление набора привилегий
SQL> CONNECT u2/u2PSW@EDUC;
Connected.
SQL> GRANT SELECT, INSERT, UPDATE ON Tab1 TO u1;
Grant succeeded.
SQL> CONNECT u1/u1PSW@EDUC;
Connected.
SQL> INSERT INTO u2.Tab1 VALUES (123);
1 row created.
SQL> SELECT * FROM u2.Tab1;
At1
--------------
123
SQL> UPDATE u2.Tab1 SET At1 = 345;
1 row updated.
SQL> SELECT * FROM u2.Tab1;
At1
--------------
345
SQL> DELETE FROM u2.Tab1;
DELETE FROM u2.Tab1 *
ERROR at line 1:
ORA-01031: insufficient privileges
Наконец, следующий пример 4 иллюстрирует возможность избирательного, по столбцам, предоставления набора привилегий для команд
вставки и модификации данных в таблице Таb1.
Владелец таблицы, пользователь u2, предоставляет пользователю u1
привилегии по вставке и модификации столбца At1 таблицы Таb1. Выполнение перечисленных операций проходит успешно, а попытка пользователя u1 выполнить
модификацию столбца At2 таблицы Tab1 отвер-
гается системой.
43
Пример 4. Возможность избирательного предоставления привилегий
SQL> CONNECT u2/u2PSW@EDUC;
Connected.
SQL> CREATE TABLE Tab1(At1 NUMBER, At2 NUMBER);
Table created.
SQL> GRANT SELECT ON Tab1 TO u1;
Grant succeeded.
SQL> GRANT INSERT, UPDATE (At1) ON Tab1 TO u1;
Grant succeeded.
SQL> CONNECT u1/u1PSW@EDUC;
Connected.
SQL> INSERT INTO u2.Tab1 VALUES (123, 123);
1 row created.
SQL> UPDATE u2.Tab1 SET At1 = 345;
1 row updated.
SQL> SELECT * FROM u2.Tab1;
At1 At2
---------------------
345 123
SQL> UPDATE u2.Tab1 SET At2 = 345;
UPDATE u2.Tab1 SET At2 = 345
*
ERROR at line 1:
ORA-01031: insufficient privileges
Ниже приведен пример создания роли Sat, которой предоставлена
системная привилегия осуществления выборки из любой таблицы, и
роли SUDat, которой предоставлены системные привилегии выполнения выборки, модификации и удаления строк из любой таблицы. Для
роли SUDat предусмотрена защита паролем sudat_psw.
44
SQL> connect adm/admpsw;
Соединено.
SQL> CREATE ROLE Sat;
Роль создана.
SQL> CREATE ROLE SUDat IDENTIFIED BY sudat_psw;
Роль создана.
SQL> GRANT SELECT ANY TABLE TO Sat;
Привилегии предоставлены.
SQL> GRANT SELECT ANY TABLE, UPDATE ANY TABLE, DELETE
ANY
TABLE TO SUDat;
Привилегии предоставлены.
SQL> GRANT Sat TO u2;
Привилегии предоставлены.
SQL> CONNECT u2/u2psw
Соединено.
SQL> SELECT * FROM ul.Tab1;
At1 At2
---------------------
1 abc
Отметим, что этот пример носит учебный характер. Предоставление
пользователю привилегии SELECT ANY TABLE и тем более UPDATE
или DELETE ANY TABLE в системе с повышенными требованиями
безопасности вряд ли целесообразно.
Однако и дискреционная, и ролевая защита ограничивают доступ
только к именованным объектам, а не к собственно хранящимся данным: нельзя в полном объеме ограничить
доступ только к части информации, хранящейся в таблице. Частично проблему ограничения доступа
к информации решает использование хранимых процедур, которые реализуют тот или иной набор бизнес-действий и предоставляют лишь
45
часть данных объектов (таблиц, представление и т. д.). Но часто этого
недостаточно. Избирательный доступ к хранящимся данным реализован
в мандатной модели безопасности.
4.2.4. МАНДАТНАЯ МОДЕЛЬ БЕЗОПАСНОСТИ
Мандатное управление доступом реализуется в модели многоуров-
невой защиты.
Еще раз отметим недостатки дискреционного и ролевого управления: средства дискреционного и ролевого управления доступом не могут помешать авторизованному пользователю законно получить секретную информацию и затем сделать ее доступной для пользователей
с другими полномочиями. Нетрудно понять, почему это так. Привиле
-
гии существуют отдельно от данных (в случае реляционных СУБД – отдельно от строк реляционных таблиц); получив доступ к таблице или
представлению, субъект доступа может передать их кому угодно даже
средствами самой СУБД.
Модель многоуровневой защиты (multilevel secure) – модель, обес-
печивающая разграничение доступа субъектов с различными правами
доступа к объектам различных уровней
конфиденциальности.
В модели мандатного управления анализируются условия, при которых невозможно создать информационные потоки от субъектов с более
высоким уровнем доступа к субъектам с более низким уровнем доступа.
Мандатное управление доступом строится на основе так называемой
модели Белла–ЛаПадула (Bell–LaPadula, B-L): объекты базы данных
классифицируются по уровням конфиденциальности, а каждый субъект
причисляется к одному из классов доступа объекта базы данных.
Инструментами разграничения доступа субъектов к объектам данных являются метки конфиденциальности информации, содержащейся
в объектах, и метки субъектов, разрешающие обращаться к информации
данного уровня конфиденциальности.
Основная идея мандатной модели доступа (mandatory access control)
состоит в приписывании объектам и субъектам меток. Если метки объекта и субъекта в некотором смысле совпадают, то субъект получает
право выполнять определенные действия с объектом. В роли метки,
приписываемой субъектам, выступает, например, форма доступа.
К созданию модели Дэвида Белла и Леонарда Лападула подтолкнула
система безопасности для работы с секретными документами Прави-
46
тельства США. Суть системы состоит в том, что каждому субъекту
(лицу, работающему с документами) и объекту (документам) присваи-
вается метка конфиденциальности, от самой высокой («особой важности») до самой низкой («несекретный» или «общедоступный»).
1. Субъект, которому разрешен доступ только к объектам с более
низкой меткой конфиденциальности, не может получить доступ к
объ-
екту с более высокой меткой конфиденциальности.
Например, в системе военного учреждения содержится информация
от полностью открытой до «совершенно секретно» и уровень доступа
тоже варьируется от допуска только к несекретной информации до допуска к совершенно секретным данным. Субъект, имеющий допуск
уровня «не секретно», не может получить доступ к объекту,
имеющему
метку «для служебного пользования». В то же время субъект с допуском
уровня «секретно» имеет право доступа к объекту с меткой «для служебного пользования».
2. Субъекту, которому разрешен доступ к объектам с более высокой
меткой конфиденциальности, запрещается также запись информации в
объекты с более низким уровнем безопасности (рис. 4.2).
Рис. 4.2. Правила разграничения доступа в мандатной модели безопасности
Класс доступа субъекта состоит из двух компонентов. Первый из
них – это иерархический компонент по уровням конфиденциальности.
Пользователь с более низким уровнем доступа не будет знать даже
47
о существовании объектов с более высоким уровнем конфиденциальности.
Второй компонент – группы принадлежности – представляет собой
некоторое множество неиерархических категорий, которые могут относиться к любому уровню иерархии (рис. 4.3).
Рис. 4.3. Класс доступа субъекта
Например, первый компонент (уровни конфиденциальности) может
принимать значения «совершенно секретно», «секретно», «конфиденциально», «для служебного пользования», «для ограниченного распространения», «для неограниченного распространения». Второй компонент (группы принадлежности) может принимать значения «не для субподрядчиков», «не для прессы», «только для финансовых работников»,
«только для руководства».
Мандатный принцип состоит в сопоставлении
меток доступа субъектов и объектов базы данных, возможно, вплоть до отдельных полей
записи (рис. 4.4).
48
Рис. 4.4. Метки в мандатной модели безопасности
Метка объекта включает следующую информацию:
группа субъекта, который внес данный объект;
уровень доступа на чтение – RAL (Read Access Level);
уровень доступа на запись – WAL (Write Access Level).
Метка субъекта выглядит аналогично:
группа, к которой принадлежит субъект;
RAL-уровень субъекта; пользователь может получать (читать)
информацию, RAL-уровень которой не выше его собственного уровня
доступа. В модели
B-L этот принцип известен под названием простого
свойства секретности (simple security property) – No Read Up;
WAL-уровень субъекта; пользователь может вносить информацию только в объекты такого же WAL-уровня доступа (см. рис. 4.2).
То, что запрещено выполнять запись объектов более высокого класса,
это понятно, а выполнять запись объектов более низкого класса запрещено, поскольку это
может сделать доступную субъекту информацию
менее конфиденциальной, чем указано в данном параметре. В модели
B-L это свойство известно под названием *-свойства: запрет записи
вниз – No Write Down.
49
Примером СУБД с мандатной защитой является отечественная
СУБД «Линтер», которая получила признание в силовых структурах,
как единственная СУБД, имеющая сертификат по второму классу защиты от несанкционированного доступа. Мандатный контроль доступа
к данным в этой СУБД организуется на уровне таблиц, столбцов записей и отдельных полей записей: сотрудник, имеющий доступ к
таблице
на чтение, не имеет доступа ко всем записям.
Проиллюстрируем использование мандатной модели в СУБД Oracle.
В СУБД Oracle есть компонент Oracle Label Security. Установка этого
компонента приводит к появлению нового пользователя LBACSYS,
с набором привилегий по управлению метками доступа. Ниже представлены шаги технологии работы с мандатной моделью безопасности.
Шаг 1. Создание политики доступа
SQL> connect lbacsys/newlbacpsw
Соединено
exec SA_SYSDA.CREATY_POLICY(‘OLS_P1');
Процедура PL/SQL успешно завершена
OLS_P1 – абстрактный объект: политики безопасности;
CREATY_POLICY – процедура из пакета SA_SYSDA.
Шаг 2. Создание структуры метки доступа
Содержательно метка безопасности имеет трехкомпонентную
структуру: уровень секретности (level), отделения (compartments),
группы (groups). Параметр уровня секретности является обязательным.
Теоретически возможно до 10 000 уровней секретности. Уровни секретности должны образовывать строгую иерархию. Отделения задают непересекающиеся множества.
Группы могут образовывать иерархические структуры и обычно ассоциируются с территориальным делением
некоторой структуры. Параметры отделения и группы не обязательны.
Предположим, что информация подразделяется по степени секретности на три категории: открытая, корпоративная, аналитическая. Корпоративная информация может быть двух типов: исследовательская
и производственная. К исследовательской корпоративной информации
имеют доступ только
уполномоченные сотрудники исследовательских
подразделений, к производственной корпоративной информации – сотрудники производственных подразделений.
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]