ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.04.2021
Просмотров: 1857
Скачиваний: 3
!
!
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
7
Ра
зг
ра
ни
че
ни
е
до
ст
уп
а
в
С
У
Б
Д
Л
И
Н
Т
ЕР
.
М
ан
да
тн
ы
й
до
ст
уп
!
41
E-
mai
l:
ma
rke
t@
rele
x.r
u
B
TC
обновить
строку
,
внесенную
пользователем
C.
Уровни
доступа
не
указывать
.
Например
:
update c.tc set t=’B modif’ where t=’1-C’;
просмотреть
полученные
строки
с
группами
и
уровнями
:
select c.tc.*, security(*,’G’) GR, security(*,’R’)
RAL, security(*,’W’) WAL from c.tc;
видим
,
что
сменилась
группа
,
а
также
повысился
RAL
строки
(
согласно
RAL
пользователя
B)
B
TC
понизить
RAL
обновленной
строки
и
колонки
T
до
«
ДСП
»
update c.tc##"
ДСП
"# set T##"
ДСП
"# = T
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;
RAL
строки
и
колонки
T
понизился
, RAL
колонки
D
остался
прежним
C
TC
выборка
данных
(select *)
видим
только
2
строки
C
TC
выборка
столбца
(select T)
видим
3
строки
,
т
.
к
.
RAL
был
понижен
B
TC
повысить
WAL
поля
T
в
строке
до
«
СЕКРЕТНО
»:
update c.tc##”
ДСП
”# set
T##”
ДСП
”#”
СЕКРЕТНО
” = T where T='B
modif';
проверим
:
select security(T,’W’) from c.tc where T='B
modif';
WAL
поля
повысился
C
TC
Попытка
обновить
значение
поля
T
в
этой
строке
:
update tc set T=’C modif’ where T=’B modif’;
аналогично
для
удаления
:
delete from tc where T='B modif';
Обновлено
/
удалено
0
строк
:
уровень
ценности
поля
«
СЕКРЕТНО
»
не
позволяет
пользователю
C
с
RAL
«
ДСП
»
перезаписать
/
удалить
данные
B
TC
понизить
WAL
поля
T
и
RAL
поля
D
в
строке
до
«
ДСП
»:
update c.tc##”
ДСП
”# set T##”
ДСП
”#”
ДСП
” =
T, D##”
ДСП
”#=D where T='B modif';
строка
успешно
обновлена
C
TC
удалить
запись
:
delete from tc where T='B modif';
теперь
удаление
успешно
!
42
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
7
Ра
зг
ра
ни
че
ни
е
до
ст
уп
а
в
С
У
Б
Д
Л
И
Н
Т
ЕР
.
М
ан
да
тн
ы
й
до
ст
уп
!
!
E-
mai
l:
ma
rke
t@
rele
x.r
u
7.10.
Ограничение
доступа
с
сетевых
станций
Задача
:
Разрешить
сетевой
доступ
для
пользователей
групп
G1
и
G2
только
с
конкретной
сетевой
станции
;
кроме
того
,
уровень
доступа
этих
пользователей
должен
быть
не
ниже
«
ДСП
».
Указания
:
1.
Сначала
отменим
доступ
любых
пользователей
с
любых
сетевых
станций
:
REVOKE ACCESS ON UNLISTED STATION FROM ALL;
3.
Для
данной
практики
необходима
работа
с
двумя
компьютерами
:
клиентом
и
сервером
,
имеющими
разные
сетевые
адреса
.
На
клиентском
компьютере
настройте
клиентскую
часть
(
пропишите
сервер
в
nodetab),
запустите
драйвер
клиента
.
На
серверной
части
запустите
драйвер
сервера
.
Проконтролируйте
настройки
:
на
клиентской
части
запустите
INL
и
попробуйте
присоединится
к
серверу
,
например
под
пользователем
SYSTEM.
Должна
выдаваться
ошибка
1022 –
нарушение
привилегий
(
нет
доступа
с
сетевых
станций
).
Примечание
.
Если
будут
выдаваться
другие
ошибки
,
это
означает
,
что
неправильно
настроено
сетевое
взаимодействие
.
Настройте
его
корректно
.
4.
Присоединитесь
к
БД
с
консоли
сервера
под
АБ
(SYSTEM),
и
создайте
станцию
в
соответствии
с
условием
задачи
:
CREATE STATION G1_G2 PROTOCOL ‘TCPIP’ ADDRESS ‘<
адрес
станции
>’ LEVEL(“
ДСП
”,”
НЕСЕКРЕТНО
”);
Адрес
станции
можно
узнать
,
например
,
при
помощи
команды
ifconfig
в
Unix,
или
через
панель
управления
в
Windows,
или
зная
имя
компьютера
и
подав
ping
на
него
.
5.
Дайте
доступ
пользователям
групп
G1
и
G2
к
станции
G1_G2:
GRANT ACCESS ON STATION G1_G2 TO G1;
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);
Получим
ошибку
нарушения
мандатного
доступа
,
т
.
к
.
указанное
устройство
не
находится
в
списке
разрешенных
.
7.
Создадим
устройство
:
!
!
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
7
Ра
зг
ра
ни
че
ни
е
до
ст
уп
а
в
С
У
Б
Д
Л
И
Н
Т
ЕР
.
М
ан
да
тн
ы
й
до
ст
уп
!
43
E-
mai
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.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,
и
удачные
и
неудачные
попытки
вставки
строк
в
таблицу
TB.
Пользователь
Результат
B
успешно
C
неудачно
: RAL
пользователя
недостаточен
D
успешно
!
!
!
44
E-mail: market@relex.ru
ЗАО
НПП
«
РЕЛЭКС
»
http://www.relex.ru
Практическое
занятие
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.
Создание
субъектов
БД
с
соответствующими
правами
(
в
нашем
примере
выполняет
разработчик
приложения
,
создавая
новых
пользователей
СУБД
)
!
!
П
ра
кт
ич
ес
ко
е
за
ня
ти
е
8
П
ри
ме
р
со
зд
ан
ия
за
щ
и
щ
ен
но
й
ба
зы
да
нн
ы
х
!
45
E-
mai
l:
ma
rke
t@
rele
x.r
u
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.
Инициализация
подсистемы
аудита
(
выполняет
АБ
)
Необходимо
включить
режим
протоколирования
и
установить
необходимость
протоколирования
изменений
в
таблицах
БД
документооборота
.
Соответствующие
запросы
приведены
в
файле
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).
10.
Начальник
Отдела
2
назначает
в
качестве
исполнителя
документа
своего
подчиненного
U21.
Входим
под
именем
BOSS2
и
подаем
запрос
update doc_info_write##"
НЕСЕКРЕТНО
"#"
НЕСЕКРЕТНО
"# set
R_OPERATOR##"
НЕСЕКРЕТНО
"#"
НЕСЕКРЕТНО
"#='U21' where
doc_id=1;
Здесь
нам
пришлось
явно
указать
несекретные
метки
доступа
,
т
.
к
.
если
бы
мы
подали
обычный
UPDATE,
запись
о
документе
получила
бы
RAL “C
ЕКРЕТНО
”
по
RAL-
у
пользователя
BOSS2.
Подобные
ситуации
необходимо
учитывать
при
разработке
приложений
,
чтобы
пользователи
с
высоким
уровнем
доступа
случайно
не
повышали
уровень
чтения
модифицируемых
ими
данных
там
,
где
этого
не
должно
быть
.
Результат
обновления
можно
проконтролировать
при
помощи
запроса
select * from doc_info_read;
Заметим
,
что
запись
о
документе
доступна
пользователю
BOSS2,
т
.
к
.
он
является
контролером
документа
.