Линтер методичка
.pdf
|
|
B |
|
TC |
обновить строку, внесенную пользователем |
видим, что сменилась |
|
|
|
|
|
C. Уровни доступа не указывать. Например: |
группа, а также |
|
|
П |
|
|
update c.tc set t=’B modif’ where t=’1-C’; |
повысился RAL строки |
|
|
ра |
|
|
(согласно RAL |
|
|
|
|
|
|
пользователя B) |
|
|
|
кт |
|
|
просмотреть полученные строки с группами |
|
|
|
|
|
|
||
|
|
ич |
|
|
и уровнями: |
|
|
|
ес |
|
|
select c.tc.*, security(*,’G’) GR, security(*,’R’) |
|
|
|
ко |
|
|
|
|
|
|
|
|
RAL, security(*,’W’) WAL from c.tc; |
|
|
|
|
B е |
|
|
|
|
|
|
|
TC |
понизить RAL обновленной строки и |
RAL строки и колонки T |
|
|
|
за |
|
|
колонки T до «ДСП» |
понизился, RAL |
|
|
ня |
|
|
||
|
|
|
|
|
колонки D остался |
|
|
|
ти |
|
|
update c.tc##"ДСП"# set T##"ДСП"# = T |
прежним |
|
|
е 7 |
|
|
where T='B modif'; |
|
|
|
Ра |
|
|
просмотреть полученные строки с уровнями |
|
|
|
зг |
|
|
|
|
|
|
|
|
RAL и WAL и уровнями RAL столбцов: |
|
|
|
|
ра |
|
|
select c.tc.*, security(*,'R') RAL, |
|
|
|
ни |
|
|
|
|
|
|
че |
|
|
security(*,'W') WAL, |
|
|
|
|
|
security(D,'R') DRAL, security(T, 'R') TRAL |
|
|
|
|
ни |
|
|
|
|
|
|
|
|
from c.tc; |
|
|
|
|
C е |
|
TC |
выборка данных (select *) |
видим только 2 строки |
|
|
до |
|
|
|
|
|
|
C |
|
TC |
выборка столбца (select T) |
видим 3 строки, т.к. |
|
|
ст |
|
|
|
RAL был понижен |
|
|
уп |
|
|
|
|
|
|
B а |
|
TC |
повысить WAL поля T в строке до |
WAL поля повысился |
|
|
в |
|
|
«СЕКРЕТНО»: |
|
|
|
С |
|
|
update c.tc##”ДСП”# set |
|
|
|
У |
|
|
|
|
|
|
|
|
T##”ДСП”#”СЕКРЕТНО” = T where T='B |
|
|
|
|
Б |
|
|
modif'; |
|
|
|
Д |
|
|
проверим: |
|
|
|
Л |
|
|
|
|
|
|
|
|
|
|
|
|
|
И |
|
|
select security(T,’W’) from c.tc where T='B |
|
|
|
Н |
|
|
modif'; |
|
|
|
CТ |
|
TC |
Попытка обновить значение поля T в этой |
Обновлено/удалено 0 |
|
|
ЕР |
|
|
строке: |
строк: уровень |
|
. |
|
|
|
ценности поля |
|
|
|
М |
|
|
update tc set T=’C modif’ where T=’B modif’; |
«СЕКРЕТНО» не |
|
|
ан |
|
|
|
позволяет |
|
|
|
|
аналогично для удаления: |
пользователю C с RAL |
|
|
|
да |
|
|
||
|
|
|
|
|
«ДСП» перезаписать/ |
|
|
|
тн |
|
|
delete from tc where T='B modif'; |
удалить данные |
|
|
Bы |
|
TC |
понизить WAL поля T и RAL поля D в строке |
строка успешно |
|
|
й |
|
|
до «ДСП»: |
обновлена |
|
|
до |
|
|
update c.tc##”ДСП”# set T##”ДСП”#”ДСП” = |
|
|
|
ст |
|
|
|
|
|
|
уп |
|
|
T, D##”ДСП”#=D where T='B modif'; |
|
|
|
C |
|
TC |
удалить запись: |
теперь удаление |
|
41! |
|
|
delete from tc where T='B modif'; |
успешно |
|
|
|
E- |
|
|
|
|
|
|
|
|
|
|
|
|
mai |
|
|
|
|
|
|
|
l: |
|
|
|
|
|
|
ma |
|
|
|
|
|
|
rke |
|
|
|
|
|
|
t@ |
|
|
|
|
|
rele |
|
|
|
|
|
|
|
x.r |
|
|
|
|
|
|
u |
|
|
|
|
!42
7.10. Ограничение доступа с сетевых станций
П |
Задача: Разрешить сетевой доступ для пользователей групп G1 и G2 только с |
|
ра |
||
|
||
конкретной сетевой станции; кроме того, уровень доступа этих пользователей должен быть |
||
нектниже «ДСП». |
||
ич |
Указания: |
|
ес |
1. Сначала отменим доступ любых пользователей с любых сетевых станций: |
|
ко |
REVOKE ACCESS ON UNLISTED STATION FROM ALL; |
|
е3. Для данной практики необходима работа с двумя компьютерами: клиентом и
за |
сервером, имеющими разные сетевые адреса. |
|
ня |
На клиентском компьютере настройте клиентскую часть (пропишите сервер в |
|
nodetab), запустите драйвер клиента. На серверной части запустите драйвер сервера. |
||
ти |
Проконтролируйте настройки: на клиентской части запустите INL и попробуйте |
|
е 7 |
||
присоединится к серверу, например под пользователем SYSTEM. Должна выдаваться |
||
Ра |
|
|
ошибка 1022 – нарушение привилегий (нет доступа с сетевых станций). Примечание. Если |
||
будутзг выдаваться другие ошибки, это означает, что неправильно настроено сетевое |
||
взаимодействие. Настройте его корректно. |
||
ра |
4. Присоединитесь к БД с консоли сервера под АБ (SYSTEM ), и создайте станцию в |
|
ни |
||
че |
соответствии с условием задачи: |
|
CREATE STATION G1_G2 PROTOCOL ‘TCPIP’ ADDRESS ‘<адрес |
||
ни |
||
е |
станции>’ LEVEL(“ДСП”,”НЕСЕКРЕТНО”); |
|
|
||
до
ст Адрес станции можно узнать, например, при помощи команды ifconfig в Unix, или
через панель управления в Windows, или зная имя компьютера и подав ping на него.
уп
а
вGRANT ACCESS ON STATION G1_G2 TO G1;
С
У
Б6. Проверим возможность доступа пользователей с сетевой станции.
Д
Л Пользователи A и C должны получить доступ. Пользователь B не получает доступ,
т.к. его RAL выше максимального разрешенного RAL для станции G1_G2. Пользователи D
И
и SYSTEM по-прежнему не имеют доступа с сетевых станций.
Н |
7.11. Ограничение доступа к внешним устройствам |
|
Т |
||
|
ЕР Задача: Разрешить использовать дополнительную директорию ~/addb для хранения
данных таблиц, если пользователи имеют уровень доступа (RAL) «СЕКРЕТНО» и выше.
.
Пусть соответствующее устройство называется ‘SY01’.
МУказания:
ан |
1. Вначале попробуем определить устройство через переменную окружения, как в |
|
да |
||
незащищенном режиме. Выполним команды ОС: |
||
тн |
mkdir ~/addb |
|
ы |
йexport SY01=~/addb
до Попробуем создать таблицу, файл данных которой должен размещаться на устройстве SY01.
уп inl –u SYSTEM/MANAGER
SQL> create table t(I int) datafiles 1(‘SY01’ 10);
Получим ошибку нарушения мандатного доступа, т.к. указанное устройство не
находится в списке разрешенных.
E-
mai 7. Создадим устройство: l:
ma rke
t@ rele x.r u
CREATE DEVICE SY01 DIRECTORY ‘~/addb’
LEVEL(“СЕКРЕТНО”,”НЕСЕКРЕТНО”);
8. Дадим доступ к устройству всем пользователям:
GRANT ACCESS ON DEVICE SY01 TO ALL;
9. Проверим возможность работы с устройством.
Будем пытаться от имени разных пользователей (с категорией не ниже RESOURCE)
размещать данные таблицы T на устройстве SY01 при помощи запроса
ко
еCREATE TABLE T(I INT) DATAFILES 1(‘SY01’ 10);
|
за |
Результаты должны соответствовать таблице: |
|
|
ня |
||
|
|
|
|
|
ти |
|
|
|
Пользователь7 |
Результат |
|
|
|
|
|
|
Ра |
|
успешно |
|
B |
|
|
|
зг |
|
неудачно: RAL пользователя недостаточен |
|
C |
|
|
|
ра |
|
|
|
Dни |
|
успешно |
|
|
|
|
|
че |
|
|
|
ни |
7.12. Аудит |
|
|
е |
|
|
|
Задача: Необходимо регистрировать все случаи успешной модификации данных |
||
|
до |
||
таблицы C.TC любого вида (т.е. вставка, удаление, обновление), а также неуспешных
ст
попыток обновления данных в этой таблице. Необходимо также протоколировать все соединенияуп и отсоединения пользователей к БД.
аУказания:
в Работа выполняется под пользователем – АБ. Сначала необходимо включить протоколированиеС :
УAUDIT START;
Б
ДЗатем необходимо настроить протоколирование требуемых событий:
ЛAUDIT ENABLE INSERT ON C.TC BY ACCESS WHEN SUCCESS;
И |
AUDIT ENABLE DELETE ON C.TC BY ACCESS WHEN SUCCESS; |
Н |
ТAUDIT ENABLE UPDATE ON C.TC BY ACCESS WHEN SUCCESS;
ЕР |
AUDIT ENABLE UPDATE ON C.TC BY ACCESS WHEN NOT SUCCESS; |
. |
|
М |
AUDIT ENABLE CONNECT WHEN SUCCESS; |
ан |
|
да |
AUDIT ENABLE DISCONNECT WHEN SUCCESS; |
тн |
После этого выполните несколько успешных/неуспешных попыток модификации |
ы |
|
таблицы из-под разных пользователей (см. предыдущие задания) и просмотрите протокол: |
|
й |
SELECT * FROM AUDIT_EVENTS; |
до |
|
ст |
Задача для самостоятельного выполнения: |
уп |
1. Необходимо также протоколировать удачные и неудачные попытки соединения |
|
под пользователем SYSTEM, и удачные и неудачные попытки вставки строк в |
43! |
таблицу TB. |
E- mai l: ma rke t@ rele x.r u
44!
Практическое занятие 8 Пример создания защищенной базы данных
Практика 2 часа (Лекция 6)
На лекции мы подробно рассмотрели пример проектирования защищенной БД для задачи автоматизации документооборота. На практическом занятии мы создадим эту БД, зададим в ней все ПРД, и проверим их функционирование на нескольких примерах запросов. В частности, мы проверим реакцию систему на выделенные нами в модели нарушителя попытки НСД.
Последовательности запросов для создания объектов БД и назначения ПРД содержатся в директории pract8. Каждый файл соответствует некоторому этапу проектирования защищенной БД. Мы будем исполнять эти файлы по порядку в утилите INL. Перед исполнением просмотрите и проанализируйте каждый файл.
Последовательность действий состоит из следующих этапов. 1. Подготовка базы данных
1.1.Создайте новую базу данных.
1.2.Запустите на ней СУБД ЛИНТЕР.
1.3.Проинициализируйте поддержку расширенного КСЗ и хранимых процедур/ триггеров (для этого прогоните файлы systab.sql и secutiry.sql (для ЛИНТЕР 5.9 еще
необходимо прогнать файл extsec.sql) из директории dict дистрибутива ЛИНТЕР). Для ЛИНТЕР 5.7 после этого необходимо остановить и снова перезапустить ядро, чтобы СУБД «увидела» соответствующие системные таблицы.
Замечание. После инициализации расширенной защиты в БД доступ к этой БД с удаленных сетевых станций будет по умолчанию запрещен. Чтобы разрешить доступ, надо либо явно прописать каждую станцию, либо явно подать запрос, разрешающий доступ со всех удаленных станций:
GRANT ACCESS ON UNLISTED STATION TO ALL;
2. Создание объектов базы данных и ПРД
2.1.Первый шаг в создании защищенной БД состоит в создании уровней защиты. Это задача администратора безопасности (АБ), т.е. пользователя SYSTEM. Прогоните файл cre_levels.sql.
2.2.Теперь АБ должен создать пользователя – администратора приложений (DOCUM) и группу «Документооборот». Соответствующие запросы приведены в файле init_doc.sql. Прогоните этот файл.
2.3.Следующим шагом разработчик создает объекты БД. Соединитесь с БД под пользователем DOCUM (можно сделать это не выходя из INL, подав команду
username DOCUM/ ). Прогоните файл doc_base.sql.
Обратите внимание, что в таблице содержимого документов мы явно подняли WAL до «ДСП», чтобы обеспечить, что содержимое документов будет всегда иметь гриф не ниже
«ДСП».
Кроме того, мы создали триггер INS_DOC_REG , которые обеспечивает, что ответственным за новый документ всегда оказывается начальник соответствующего отдела, а в поле создателя записывается логин того пользователя, который добавил запись. Также автоматически проставляются дата создания и статус документа.
2.4. Разработчик задает правила разграничения доступа: прогоните файл doc_base_access.sql.
3. Создание субъектов БД с соответствующими правами (в нашем примере выполняет разработчик приложения, создавая новых пользователей СУБД)
E-mail: market@relex.ru |
ЗАО НПП «РЕЛЭКС» |
http://www.relex.ru |
3.1. Для удобства создания нового пользователя документооборота создайте хранимую процедуру reg_docum_user: прогоните файл reg_docum_user.sql . Эта процедура также использует
процедуру генерации первичного ключа GeneratePK, так что прогоните также файл sp_seq.sql. |
||
П |
3.2. Создайте несколько пользователей системы документооборота. В файле |
|
ра |
||
|
||
test_cre_users.sql содержатся девять вызовов хранимой процедуры reg_docum_user, которые |
||
создаюткт три отдела и девять пользователей. Процедура должна возвращать значение 0 (нет
ошибок). Можно проконтролировать список добавленных пользователей СУБД, подав select * from |
||||
ич |
|
|
|
|
NEW_USERS. |
|
|||
ес |
4. Назначение групп и уровней доступа пользователям (выполняет АБ) |
|||
ко |
||||
В нашем примере пользователи СУБД только что были созданы, поэтому АБ должен |
||||
е |
||||
назначить им группы (в нашем случае «Документооборот») и уровни доступа. Войдите под АБ |
||||
за |
|
|
|
|
(можно не выходя из INL: username SYSTEM/MANAGER) и прогоните файл new_users_access.sql. |
||||
ня |
5. Инициализация подсистемы аудита (выполняет АБ) |
|||
ти |
Необходимо включить режим протоколирования и установить необходимость |
|||
протоколированияе 8 |
изменений в таблицах БД документооборота. Соответствующие запросы |
|||
приведены в файле doc_audit.sql. |
||||
П |
|
|
|
|
ри |
8.1. Работа с защищенной базой данных |
|||
ме |
Попробуем сымитировать работу с нашей защищенной базой данных на примере |
|||
жизненногор |
цикла двух документов. Сначала мы разберемся, как будет выглядеть штатная |
|||
работасо с данными (без нарушений ПРД). Затем на примере уже имеющихся данных о
документах проверим, что реализуются все требования ПРД по отношению к пресечению |
|||
зд |
|
|
|
попыток НСД перечисленных в лекции типов. |
|||
ан |
Жизненный цикл будем имитировать через последовательности запросов, |
||
ия |
|||
|
|
||
выдаваемых разными пользователями. Эти запросы можно исполнять через INL или |
|||
утилитуза |
lindesk (lindeskx), если она имеется в рассматриваемом дистрибутиве ЛИНТЕР. |
||
щЖизненный цикл первого документа:
и1. Пользователь-секретарь SEC1 создает новый документ с идентификатором 1,
щименем ‘Документ 1’, и относит его к отделу с кодом 3 (в нашем примере это
ен |
|
отдел с именем ‘Отдел 2’). Для этого соединяемся с сервером БД под именем |
|
но |
|
SEC1 и подаем запрос |
|
insert into doc_info_ins(doc_id, name, r_division) |
|||
й |
|||
ба |
values(1, 'Документ 1', 3); |
||
зы |
Результаты завершения свидетельствуют о том, что строка добавлена. Мы можем |
||
проверитьда |
это, подав select из doc_info_read: |
||
нн |
select * from doc_info_read; |
||
ы |
|||
х |
(в результате видим одну строку, причем триггер на INSERT автоматически прописал |
||
поля R_REVIEWER (‘BOSS2’), CRE_DATE и STATUS).
45!
E-
mai
l: Заметим, что запись о документе доступна пользователю BOSS 2, т.к. он является
контролером документа. ma
rke t@ rele x.r u
46!
11.Пользователь U21 добавляет содержимое документа, имеющее гриф «ДСП».
ПВходим под именем U21. Подаем контрольный запрос
ра |
select * from doc_info_read; |
кт |
|
ич |
Пользователь U21 видит запись, т.к. он назначен в качестве ответственного за |
документ. |
||
ес |
Для добавления содержимого документа подаем запрос: |
|
ко |
||
|
||
еinsert into doc_ins##"ДСП"#"ДСП" (r_doc##"ДСП"#"ДСП",
за |
comment##"ДСП"#"ДСП") values (1, 'Донесение'); |
|
|
ня |
|
||
В данном случае мы могли бы и не указывать метки доступа, т.к. у пользователя U21 |
|||
ти |
|||
RAL и WAL и так равны (“ДСП”,”ДСП”). Мы сделали это для полноты. |
|
||
е 8 |
Теперь можно проконтролировать добавленную запись, подав запрос |
|
|
П |
|
||
select * from doc_read; |
|
||
ри |
|
||
ме |
Ответственный за документ видит добавленную информацию (поле |
content типа |
|
BLOBр мы оставим в нашем примере пустым, т.к. оно не может заполняться запросами, и это уже задачасо приложения; на защиту это никак не влияет).
зд 12. Начальник отдела BOSS2 проверяет добавленное содержимое документа. Входим под
ан
ия
за
щ
и
щ
ен
но
йinsert into doc_info_ins(doc_id, name, r_division)
ба values(2, 'Документ 2', 2);
зы да Проверим:
ннselect * from doc_info_read;
ы
х Получаем только одну запись – о только что добавленном документе. Запись о первом документе пользователь SEC2 не видит, т.к. не имеет к ней отношения.
13.Начальник Отдела 1 назначает в качестве исполнителя документа своего подчиненного U11. Входим под именем BOSS1 и подаем запрос
update doc_info_write##"НЕСЕКРЕТНО"#"НЕСЕКРЕТНО"# set R_OPERATOR##"НЕСЕКРЕТНО"#"НЕСЕКРЕТНО"#='U11' where doc_id=2;
E- mai l: ma rke t@ rele x.r u
14.Начальник Отдела 1 передает свою функцию контроля документа своему подчиненному U12. Подаем запрос
update doc_info_write##"НЕСЕКРЕТНО"#"НЕСЕКРЕТНО"# set R_REVIEWER##"НЕСЕКРЕТНО"#"НЕСЕКРЕТНО"#='U12' where doc_id=2;
Проверяем результаты:
select * from doc_info_read;
Видим, что значение поля R_REVIEWER поменялось на U12. Заметим, что BOSS 1 продолжает видеть информацию о документе, т.к. является начальником отдела, к которому
приписан документ.
П
ра
кт
ич пользователь BOSS1 не увидит ни одной строки: он уже не является ни |
|
ответственнымес |
, ни контролером документа, поэтому не может модифицировать |
информацию о нем.
ко
е15. Пользователь U11 добавляет содержимое документа, имеющее гриф «ДСП». Входим под именем U 11. Для добавления содержимого документа подаем
за |
запрос: |
|
ня |
||
insert into doc_ins##"ДСП"#"ДСП" (r_doc##"ДСП"#"ДСП", |
||
ти |
||
е 8 |
comment##"ДСП"#"ДСП") values (2, 'Приказ 1'); |
|
П |
Теперь можно проконтролировать добавленную запись, подав запрос |
|
ри |
||
select * from doc_read; |
||
ме |
рВидим добавленную запись.
со |
16. Пользователь U11 добавляет обновление содержимого документа, причем на |
зд |
этот раз оно имеет гриф «СОВ.СЕКРЕТНО». Подаем запрос: |
ан |
insert into doc_ins##"СОВ.СЕКРЕТНО"# |
ия |
|
за |
(r_doc##"СОВ.СЕКРЕТНО"#, comment##"СОВ.СЕКРЕТНО"#) values |
щ(2, 'Приказ 1 – секретная часть');
и |
Проконтролируем добавленную запись, получив также информацию об уровне |
|
чтениящ |
записей: |
|
ен |
select doc_read.*, security(*,’R’) from doc_read; |
|
но |
||
й |
Видим обе записи, т.к. пользователь U11 имеет право чтения информации с грифом |
|
«СОВ.СЕКРЕТНО». Последняя колонка показывает, что вторая строка действительно добавлена |
||
ба |
|
|
с RAL равным 4 (что и соответствует «СОВ.СЕКРЕТНО»). |
||
зы |
17. Пользователь U12 (контролер документа) смотрит содержимое документа 2. |
|
да |
||
Входим под пользователем U12. Подаем запрос |
||
нн |
select * from doc_read; |
|
ы |
||
х |
Видим только первую запись, т.к. у пользователя U 12 нет прав на чтение сов. |
|
секретной информации.
!47 8.2. Проверка выполнения ПРД по модели нарушителя
Проверим, как в нашей БД реализуются необходимые ПРД.
1. Секретарь пытается получить содержимое секретного документа.
Теоретически это можно попытаться сделать одним из запросов:
select * from docum.doc_content; select * from doc_read;
select * from doc_read where r_doc = 1;
Первый запрос отвергается по нарушению доступа. Остальные два не возвращают данных, т.к. секретарю не назначен ни один документ.
E- Допустим теперь, что начальник Отдела 2 (BOSS2) назначил секретаря SEC 1 в
mai |
|
качестве ответственного за Документ 1. |
|
l: |
Для этого войдем под пользователем BOSS2, и подадим запрос |
ma |
|
rke t@ rele x.r u
48!
П |
update doc_info_write##"НЕСЕКРЕТНО"#"НЕСЕКРЕТНО"# set |
|
||
ра |
R_OPERATOR##"НЕСЕКРЕТНО"#"НЕСЕКРЕТНО"#='SEC1' where |
|
||
кт |
doc_id=1; |
|
|
|
ич |
Теперь по дискреционному принципу пользователь SEC1 должен увидеть |
|
||
содержимоеес |
документа. Но содержимое документа имеет уровень чтения «ДСП», а |
|
||
пользователь SEC1 может читать только информацию с грифом «НЕСЕКРЕТНО». |
|
|||
ко |
Снова войдем под пользователем SEC1 и подадим один из перечисленных выше |
|
||
е |
|
|||
select-запросов из doc_read. Пользователь не видит данных. |
|
|
||
за |
Проверим, что если бы SEC 1 имел доступ хотя бы к информации грифа «ДСП», он |
|||
ня |
||||
бы увидел содержимое документа. Для этого войдем под АБ и подадим запрос |
|
|||
ти |
alter user SEC1 level("ДСП","НЕСЕКРЕТНО"); |
|
|
|
е 8 |
|
|
||
П |
Теперь снова войдем под SEC1 и подадим SELECT из doc_read |
. Пользователь |
||
увридел данные. |
|
|
||
ме |
2. Секретарь пытается явно назначить ответственного за документ (минуя отдел). |
|
||
р |
Речь идет о добавлении нового документа. Войдем под пользователем SEC |
1 и |
||
попытаемся подать запрос |
|
|
||
со |
|
|
|
|
зд |
insert into doc_info_ins(doc_id, name, r_division, |
|
||
ан |
|
|||
r_reviewer) values(10, 'Документ 10', 2, ‘SEC2’); |
|
|||
ия |
|
|||
за |
Т.е. мы попытались явно задать в качестве ответственного SEC |
2. Запрос прошел |
||
удачно, но смотрим что получилось: |
|
|
||
щ |
|
|
|
|
иselect * from doc_info_read;
щ |
Поле R_REVIEWER в добавленной записи установлено в ‘BOSS1’ вместо ‘SEC 2’ – |
||
ен |
|||
|
|
||
это обеспечил триггер. |
|||
но |
3. Работник пытается получить информацию или содержимое не назначенного ему |
||
документай |
. |
||
ба |
Войдем под пользователем U 11. Ему был назначен документ с идентификатором 2. |
||
Длязы получения информации или содержимого документа с идентификатором 1 можно было
бы попытаться использовать один из запросов
да
ннselect * from doc_info_read;
ы
х select * from doc_info_read where doc_id = 1; select * from doc_read;
select * from doc_read where r_doc = 1;
Ни один из этих запросов не вернет записей о документе с идентификатором 1. Доступ же к таблицам напрямую (не через представления) вообще закрыт.
4. Секретный документ случайно назначен сотруднику, который не имеет доступа к секретным сведениям
Это требование уже два раза проверялось Один раз, когда при проверке жизненного цикла документа 2 мы вставили данные о документе с грифом «СОВ.СЕКРЕТНО», и контролер документа эту запись не увидел. Второй раз, когда мы проверяли первое ПРД.
5. Работник, имеющий доступ к секретному документу, пытается открыть эту информацию (понизить уровень секретности)
В нашем примере пользователь U11 не может понизить уровень чтения известной ему информации ниже «ДСП».
E- Первое действие могло бы быть связано с попыткой внести в таблицу содержимого документовmai что-нибудь с RAL ниже «ДСП»
l: ma rke t@ rele x.r
u
|
|
insert into doc_ins##"НЕСЕКРЕТНО"#(r_doc##"НЕСЕКРЕТНО"#) |
|
||
|
П |
values(2); |
|
|
|
|
Результатом является ошибка 1070 – нарушение мандатного доступа. Заметим, что |
||||
|
ра |
||||
WAL самой таблицы DOC_CONTENT не позволяет вносить в нее записи с RAL ниже «ДСП». |
|||||
|
кт |
Тогда представим, что пользователь U11 получает категорию DBA (дайте ему |
|
||
|
ич |
11 |
|||
|
|
|
|
||
соответствующие права при помощи АБ). Попытаемся теперь создать от имени U |
|||||
несекретную таблицу: |
|
|
|||
|
ко |
create table notsec(c char(100) |
|
|
|
|
е |
|
|
||
|
за |
level(“НЕСЕКРЕТНО”,”НЕСЕКРЕТНО”)) |
|
|
|
|
ня |
level(“НЕСЕКРЕТНО”,”НЕСЕКРЕТНО”); |
|
|
|
|
ти |
По-прежнему получаем ошибку доступа: WAL пользователя опять не позволяет |
|
||
создатье 8 |
такую таблицу. |
|
|
||
|
П |
Теперь представим, что в БД есть доступная |
U11 на запись несекретная таблица. |
|
|
Можно создать ее в INL: |
|
|
|||
|
ри |
|
|
|
|
|
ме |
usernameSYSTEM/MANAGER |
|
|
|
|
р |
|
|
||
|
createtable notsec (c char(100) |
|
|
||
|
со |
|
|
||
|
зд |
level(“НЕСЕКРЕТНО”,”НЕСЕКРЕТНО”)) |
|
|
|
|
ан |
level(“НЕСЕКРЕТНО”,”НЕСЕКРЕТНО”); |
|
|
|
|
ия |
|
|
||
|
grant all on notsec to public; |
|
|
||
|
за |
|
|
||
щПусть теперь U11 пытается вставить в эту таблицу данные с уровнем, ниже «ДСП»
и
щ insert into system.notsec##”НЕСЕКРЕТНО”# values(‘тест’);
ен Опять получаем ошибку нарушения мандатного доступа. Хотя следующий запрос проходитно нормально:
йinsert into system.notsec##”ДСП”# values(‘тест’);
ба зы Что касается попытки раскрытия секретных данных при выгрузке информации из БД,
эта проблема должна решаться на стыке со средствами защиты ОС, как говорилось в
да
лекции.
нн6. Работник, не являющийся секретарем, пытается добавить новый документ
ыПопробуем добавить информацию о документе от имени пользователя BOSS1:
х insert into doc_info_ins(doc_id, name, r_division) !49 values(20, 'Документ 20', 2);
Получаем нарушение привилегий (1022), т.к. только пользователи роли SECRETARY имеют право вставлять записи в эту таблицу.
7. Работник, не связанный с документом, пытается добавить его содержимое
Попробуем добавить запись о содержимом документа с идентификатором 1 из-под пользователя U11:
insert into doc_ins##"ДСП"#"ДСП" (r_doc##"ДСП"#"ДСП", comment##"ДСП"#"ДСП") values (1, 'Моиданные');
Ошибок не выдается, но мы получаем сообщение о том, что добавлено ноль строк (можно это и проверить при помощи SELECT). Это ПРД реализовано при помощи триггера.
E- |
8. Работник пытается удалить данные о документе или его содержимом |
mai |
Запросы DELETE просто запрещены по дискреционному принципу. Любой запрос на |
DELETEl: из таблиц DOCUM.DOC_REG или DOCUM.DOC_CONTENT возвращает 1022. ma
rke t@ rele x.r u
!50
9. Администратор безопасности (приложения) пытается получить информацию о
документахП
ра
кт
ич
ес
ко |
DOCUM не видит ни одной записи, т.к. они были сделаны пользователями другой |
|
е |
||
|
||
группы. Сменить себе группу (оказать доверие) DOCUM не может, т.к. не является АБ. |
||
за |
АБ вообще не имеет доступа к таблицам документооборота, т.к. DOCUM не назначил |
|
емуня никаких прав на них.
ти 10. Администратор безопасности (приложения) пытается модифицировать информацию оедокументах8
ПВойдем под пользователем DOCUM и попытаемся подать запросы
ри |
delete from doc_reg; |
||
ме |
|||
delete from doc_content; |
|||
р |
|||
со |
В первом случае ошибка не выдается, но ничего не удаляется, т.к. записи, |
||
сделанныезд |
пользователями другой группы, пользователю DOCUM не видны. Во втором |
||
случае выдается нарушение мандатного доступа, т.к. метки доступа DOCUM не позволяют |
||
ан |
|
|
даже в принципе модифицировать таблицу DOC_CONTENT. |
||
ия |
Аналогично можно проверить попытки с операторами UPDATE. |
|
за |
||
АБ вообще не имеет доступа к таблицам документооборота, т.к. DOCUM не назначил |
||
щ |
||
ему никаких прав на них. |
||
и |
Таким образом, все ПРД оказались выполненными. |
|
щ |
||
8.3. Протоколирование (аудит) |
||
ен |
||
Протоколирование изменений данных о документах было включено с самого начала. |
||
но |
||
Можно зайти под АБ (SYSTEM) и подать запрос |
||
й |
|
|
ба select * from audit_events; |
||
зы |
В результате будут видны все записи о сделанных модификациях, включая время, |
|
да |
||
|
||
автора модификации, тип события и т.д. |
||
нн |
|
|
ы |
|
|
х |
|
|
E- mai l: ma rke t@ rele x.r u