LINTER от 04.02.15

7.4. Создание и назначение групп пользователей

Задача: Объединить пользователей A и B в группу G1, а пользователей C и D включить в группы G2 и G3 соответственно.

Для этого сначала создадим группы G1, G2 и G3. Пример:

CREATE GROUP G1;

Теперь назначаем группы пользователям. Пример:

ALTER USER A GROUP G1;

Теперь, подав SELECT из представления USER_SECURITY, видим в столбце SGR назначенные группы.

7.5. Создание объектов БД

Задача: Создать несколько таблиц с разными уровнями доступа от имени разных пользователей:

Пример:

SQL>username D/ SQL>CREATE TABLE TD(

I INT LEVEL(“ДСП”, “ДСП”),

D DATE LEVEL(“ДСП”, “ДСП”)) LEVEL(“ДСП”, “ДСП”);

Заметим, что пользователь D не может создать таблицу с RAL ниже «ДСП» - это не позволяет сделать его WAL. Такой запрос

CREATE TABLE TD2(

I INT,

D DATE) LEVEL(“НЕСЕКРЕТНО”, “ДСП”);

вызовет ошибку нарушения привилегий.

Указание: т.к. пользователь С не имеет категории DBA, он не может явно указывать уровни при создании таблицы. Уровни его таблицы берутся по умолчанию по его собственным RAL и WAL.

Проверьте назначенные таблицам уровни, подав из-под SYSTEM запрос:

select * from table_security where tabname in ('TB','TC','TD');

Назначьте все привилегии на все созданные таблицы для всех пользователей. Это позволит лучше увидеть работу мандатного доступа, т.к. по дискреционному доступу всем пользователям будет все разрешено.

Практическое занятие 7 42 Разграничение доступа в СУБД ЛИНТЕР. Мандатный доступ

Пример:

GRANT ALL ON TB TO PUBLIC;

7.6. Добавление данных

Задача: Подать серию запросов на добавление данных в созданные таблицы из-под разных пользователей:

Пример запроса с указанием уровней:

insert into b.tb##"СЕКРЕТНО"#"ДСП" values(2,'2-A');

Примечание: Примеры всех запросов приведены в файле ins.sql

7.7. Выборка данных

Задача: Просмотреть добавленные данные под разными пользователями:

7.8. Установка доверия между группами

Задача: Установить доверие группы G2 к группе G1. Решение: АБ (SYSTEM) подает запрос

GRANT ACCESS ON G2 TO G1;

Задача: Проверить возможность доступа пользователей разных групп к объектам и данным группы G2.

7.9. Модификация/удаление данных

Задача: Выполнить несколько запросов на модификацию/удаление данных (осмыслить случаи разрешенных и запрещенных действий; проверить получающиеся после модификации метки доступа):

Практическое занятие 7 44 Разграничение доступа в СУБД ЛИНТЕР. Мандатный доступ

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 46 Разграничение доступа в СУБД ЛИНТЕР. Мандатный доступ

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. Создадим устройство:

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. Необходимо также протоколировать удачные и неудачные попытки соединения

48

Практическое занятие 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. Создание субъектов БД с соответствующими правами (в нашем примере

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, т.к. он является контролером документа.

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);

Проверим: