ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.04.2021
Просмотров: 1873
Скачиваний: 3
!
46
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
8
П
ри
ме
р
со
зд
ан
ия
за
щ
и
щ
ен
но
й
ба
зы
да
нн
ы
х
!
!
E-
mai
l:
ma
rke
t@
rele
x.r
u
11.
Пользователь
U21
добавляет
содержимое
документа
,
имеющее
гриф
«
ДСП
».
Входим
под
именем
U21.
Подаем
контрольный
запрос
select * from doc_info_read;
Пользователь
U21
видит
запись
,
т
.
к
.
он
назначен
в
качестве
ответственного
за
документ
.
Для
добавления
содержимого
документа
подаем
запрос
:
insert into doc_ins##"
ДСП
"#"
ДСП
" (r_doc##"
ДСП
"#"
ДСП
",
comment##"
ДСП
"#"
ДСП
") values (1, '
Д
онесение
');
В
данном
случае
мы
могли
бы
и
не
указывать
метки
доступа
,
т
.
к
.
у
пользователя
U21
RAL
и
WAL
и
так
равны
(“
ДСП
”,”
ДСП
”).
Мы
сделали
это
для
полноты
.
Теперь
можно
проконтролировать
добавленную
запись
,
подав
запрос
select * from doc_read;
Ответственный
за
документ
видит
добавленную
информацию
(
поле
content
типа
BLOB
мы
оставим
в
нашем
примере
пустым
,
т
.
к
.
оно
не
может
заполняться
запросами
,
и
это
уже
задача
приложения
;
на
защиту
это
никак
не
влияет
).
12.
Начальник
отдела
BOSS2
проверяет
добавленное
содержимое
документа
.
Входим
под
именем
BOSS2
и
подаем
запрос
select * from doc_read;
Начальник
отдела
также
видит
данные
документа
.
Жизненный
цикл
второго
документа
:
1.
Пользователь
-
секретарь
SEC2
создает
новый
документ
с
идентификатором
2,
именем
‘
Документ
2’,
и
относит
его
к
отделу
с
кодом
2 (
в
нашем
примере
это
отдел
с
именем
‘
Отдел
1’).
Для
этого
соединяемся
с
сервером
БД
под
именем
SEC2
и
подаем
запрос
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##"
НЕСЕКРЕТНО
"#"
НЕСЕКРЕТНО
"#='U
1
1' where
doc_id=
2
;
14.
Начальник
Отдела
1
передает
свою
функцию
контроля
документа
своему
подчиненному
U12.
Подаем
запрос
update doc_info_write##"
НЕСЕКРЕТНО
"#"
НЕСЕКРЕТНО
"# set
R_
REVIEWER
##"
НЕСЕКРЕТНО
"#"
НЕСЕКРЕТНО
"#='U
12
' where
doc_id=
2
;
Проверяем
результаты
:
select * from doc_info_read;
!
!
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
8
П
ри
ме
р
со
зд
ан
ия
за
щ
и
щ
ен
но
й
ба
зы
да
нн
ы
х
!
47
E-
mai
l:
ma
rke
t@
rele
x.r
u
Видим
,
что
значение
поля
R_REVIEWER
поменялось
на
U12.
Заметим
,
что
BOSS1
продолжает
видеть
информацию
о
документе
,
т
.
к
.
является
начальником
отдела
,
к
которому
приписан
документ
.
Однако
если
подать
запрос
select * from doc_info_write;
пользователь
BOSS1
не
увидит
ни
одной
строки
:
он
уже
не
является
ни
ответственным
,
ни
контролером
документа
,
поэтому
не
может
модифицировать
информацию
о
нем
.
15.
Пользователь
U11
добавляет
содержимое
документа
,
имеющее
гриф
«
ДСП
».
Входим
под
именем
U11.
Для
добавления
содержимого
документа
подаем
запрос
:
insert into doc_ins##"
ДСП
"#"
ДСП
" (r_doc##"
ДСП
"#"
ДСП
",
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;
Видим
только
первую
запись
,
т
.
к
.
у
пользователя
U12
нет
прав
на
чтение
сов
.
секретной
информации
.
8.2.
Проверка
выполнения
ПРД
по
модели
нарушителя
Проверим
,
как
в
нашей
БД
реализуются
необходимые
ПРД
.
1.
Секретарь
пытается
получить
содержимое
секретного
документа
.
Теоретически
это
можно
попытаться
сделать
одним
из
запросов
:
select * from docum.doc_content;
select * from doc_read;
select * from doc_read where r_doc =
1
;
Первый
запрос
отвергается
по
нарушению
доступа
.
Остальные
два
не
возвращают
данных
,
т
.
к
.
секретарю
не
назначен
ни
один
документ
.
Допустим
теперь
,
что
начальник
Отдела
2 (BOSS2)
назначил
секретаря
SEC1
в
качестве
ответственного
за
Документ
1.
Для
этого
войдем
под
пользователем
BOSS2,
и
подадим
запрос
!
48
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
8
П
ри
ме
р
со
зд
ан
ия
за
щ
и
щ
ен
но
й
ба
зы
да
нн
ы
х
!
!
E-
mai
l:
ma
rke
t@
rele
x.r
u
update doc_info_write##"
НЕСЕКРЕТНО
"#"
НЕСЕКРЕТНО
"# set
R_OPERATOR##"
НЕСЕКРЕТНО
"#"
НЕСЕКРЕТНО
"#='SEC1' where
doc_id=1;
Теперь
по
дискреционному
принципу
пользователь
SEC1
должен
увидеть
содержимое
документа
.
Но
содержимое
документа
имеет
уровень
чтения
«
ДСП
»,
а
пользователь
SEC1
может
читать
только
информацию
с
грифом
«
НЕСЕКРЕТНО
».
Снова
войдем
под
пользователем
SEC1
и
подадим
один
из
перечисленных
выше
select-
запросов
из
doc_read.
Пользователь
не
видит
данных
.
Проверим
,
что
если
бы
SEC1
имел
доступ
хотя
бы
к
информации
грифа
«
ДСП
»,
он
бы
увидел
содержимое
документа
.
Для
этого
войдем
под
АБ
и
подадим
запрос
alter user SEC1 level("
ДСП
","
НЕСЕКРЕТНО
");
Теперь
снова
войдем
под
SEC1
и
подадим
SELECT
из
doc_read.
Пользователь
увидел
данные
.
2.
Секретарь
пытается
явно
назначить
ответственного
за
документ
(
минуя
отдел
)
.
Речь
идет
о
добавлении
нового
документа
.
Войдем
под
пользователем
SEC1
и
попытаемся
подать
запрос
insert into doc_info_ins(doc_id, name, r_division,
r_reviewer) values(10, '
Документ
10', 2, ‘SEC2’);
Т
.
е
.
мы
попытались
явно
задать
в
качестве
ответственного
SEC2.
Запрос
прошел
удачно
,
но
смотрим
что
получилось
:
select * from doc_info_read;
Поле
R_REVIEWER
в
добавленной
записи
установлено
в
‘BOSS1’
вместо
‘SEC2’ –
это
обеспечил
триггер
.
3.
Работник
пытается
получить
информацию
или
содержимое
не
назначенного
ему
документа
.
Войдем
под
пользователем
U11.
Ему
был
назначен
документ
с
идентификатором
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
не
может
понизить
уровень
чтения
известной
ему
информации
ниже
«
ДСП
».
Первое
действие
могло
бы
быть
связано
с
попыткой
внести
в
таблицу
содержимого
документов
что
-
нибудь
с
RAL
ниже
«
ДСП
»
!
!
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
8
П
ри
ме
р
со
зд
ан
ия
за
щ
и
щ
ен
но
й
ба
зы
да
нн
ы
х
!
49
E-
mai
l:
ma
rke
t@
rele
x.r
u
insert into doc_ins##"
НЕСЕКРЕТНО
"#
(r_doc##"
НЕСЕКРЕТНО
"#)
values(2);
Результатом
является
ошибка
1070 –
нарушение
мандатного
доступа
.
Заметим
,
что
WAL
самой
таблицы
DOC_CONTENT
не
позволяет
вносить
в
нее
записи
с
RAL
ниже
«
ДСП
».
Тогда
представим
,
что
пользователь
U11
получает
категорию
DBA (
дайте
ему
соответствующие
права
при
помощи
АБ
).
Попытаемся
теперь
создать
от
имени
U11
несекретную
таблицу
:
create table notsec(c char(100)
level(“
НЕСЕКРЕТНО
”,”
НЕСЕКРЕТНО
”))
level(“
НЕСЕКРЕТНО
”,”
НЕСЕКРЕТНО
”);
По
-
прежнему
получаем
ошибку
доступа
: WAL
пользователя
опять
не
позволяет
создать
такую
таблицу
.
Теперь
представим
,
что
в
БД
есть
доступная
U11
на
запись
несекретная
таблица
.
Можно
создать
ее
в
INL:
username
SYSTEM/MANAGER
create
table 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)
values(20, '
Документ
20', 2);
Получаем
нарушение
привилегий
(1022),
т
.
к
.
только
пользователи
роли
SECRETARY
имеют
право
вставлять
записи
в
эту
таблицу
.
7.
Работник
,
не
связанный
с
документом
,
пытается
добавить
его
содержимое
Попробуем
добавить
запись
о
содержимом
документа
с
идентификатором
1
из
-
под
пользователя
U11:
insert into doc_ins##"
ДСП
"#"
ДСП
" (r_doc##"
ДСП
"#"
ДСП
",
comment##"
ДСП
"#"
ДСП
") values (1, '
Мои
данные
');
Ошибок
не
выдается
,
но
мы
получаем
сообщение
о
том
,
что
добавлено
ноль
строк
(
можно
это
и
проверить
при
помощи
SELECT).
Это
ПРД
реализовано
при
помощи
триггера
.
8.
Работник
пытается
удалить
данные
о
документе
или
его
содержимом
Запросы
DELETE
просто
запрещены
по
дискреционному
принципу
.
Любой
запрос
на
DELETE
из
таблиц
DOCUM.DOC_REG
или
DOCUM.DOC_CONTENT
возвращает
1022.
!
50
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
8
П
ри
ме
р
со
зд
ан
ия
за
щ
и
щ
ен
но
й
ба
зы
да
нн
ы
х
!
!
E-
mai
l:
ma
rke
t@
rele
x.r
u
9.
Администратор
безопасности
(
приложения
)
пытается
получить
информацию
о
документах
Войдем
под
пользователем
DOCUM
и
попытаемся
подать
запросы
select * from doc_reg;
select * from doc_content;
DOCUM
не
видит
ни
одной
записи
,
т
.
к
.
они
были
сделаны
пользователями
другой
группы
.
Сменить
себе
группу
(
оказать
доверие
) DOCUM
не
может
,
т
.
к
.
не
является
АБ
.
АБ
вообще
не
имеет
доступа
к
таблицам
документооборота
,
т
.
к
. DOCUM
не
назначил
ему
никаких
прав
на
них
.
10.
Администратор
безопасности
(
приложения
)
пытается
модифицировать
информацию
о
документах
Войдем
под
пользователем
DOCUM
и
попытаемся
подать
запросы
delete from doc_reg;
delete from doc_content;
В
первом
случае
ошибка
не
выдается
,
но
ничего
не
удаляется
,
т
.
к
.
записи
,
сделанные
пользователями
другой
группы
,
пользователю
DOCUM
не
видны
.
Во
втором
случае
выдается
нарушение
мандатного
доступа
,
т
.
к
.
метки
доступа
DOCUM
не
позволяют
даже
в
принципе
модифицировать
таблицу
DOC_CONTENT.
Аналогично
можно
проверить
попытки
с
операторами
UPDATE.
АБ
вообще
не
имеет
доступа
к
таблицам
документооборота
,
т
.
к
. DOCUM
не
назначил
ему
никаких
прав
на
них
.
Таким
образом
,
все
ПРД
оказались
выполненными
.
8.3.
Протоколирование
(
аудит
)
Протоколирование
изменений
данных
о
документах
было
включено
с
самого
начала
.
Можно
зайти
под
АБ
(SYSTEM)
и
подать
запрос
select * from audit_events;
В
результате
будут
видны
все
записи
о
сделанных
модификациях
,
включая
время
,
автора
модификации
,
тип
события
и
т
.
д
.