Компьютерные науки : Курсовая работа: Политика безопасности баз данных
Курсовая работа: Политика безопасности баз данных
Аннотация
Целью данного курсового проекта
является закрепление, систематизация, углубление и развитие теоретических и
практических знаний, полученных студентами в процессе изучения дисциплины
"Надёжность и безопасность программного обеспечения". Курсовая работа
посвященна проблемам политики безопастности баз данных, гарантированности и
средств подотчётности. Основная цель курсового проектирования состоит в
изучении и анализе вопросов, связанных со специальными аспектами надёжности и
безопасности программного обеспечения.
Содержание
Введение
Индивидуальное задание
1. Проектирование таблиц
2. Управление родями
2.1 Регистрация субъектов безопасности
2.1.1 Регистрация субъектов
2.1.2 Наследование ролей
2.2 Избирательное управление доступом
2.2.1 Описание привилегий доступа для клиентов
2.2.2 Описание привилегий доступа для директоров
2.2.3 Описание привилегий доступа
для операционистов
2.2.4 Описание привилегий доступа для работников филиала
2.3 Создание представления субъекта об объекте
2.3.1 Создание схемы для директоров
2.3.2 Создание схемы для клиентов
2.3.3 Создание схемы для операционистов
2.3.4 Создание схемы для работников филиала
3. Реализация требований стандарта по критерию
"Политика безопасности"
3.1 Создания механизма по управлению метками в СУБД.
3.1.1 Таблица с информацией о клиентах
3.1.2 Таблица с информацией о директорах.
3.1.3 Таблица с информацией об операционистах
3.1.4 Таблица с информацией о работниках филиала
3.2 Реализация принудительного управления доступом в СУБД
3.2.1 Реализация принудительного управления доступом в
таблице "КЛИЕНТЫ"
3.2.2 Реализация принудительного управления доступом в
таблице "ОПЕРАЦИОНИСТЫ"
4. Реализация требований
стандарта по критерию "подотчётность"
4.1 Обеспечение идентификации и аутентификации
4.2 Построим таблицу для пользователей нашей БД
4.3 Обеспечение надежного пути
4.3.1 Способы обеспечения надежного пути
4.3.2 Общие подходы использования сертификатов в
web-технологиях
4.3.3 Создание сертификата,
подписанного доверенным центром сертификации
4.3.4 Создание самоподписанного сертификата (сертификата
местного центра сертификации)
4.3.5 Подписание сертификатов с
использованием сертификата центра сертификации
4.3.6 Аннулирование сертификатов
4.3.7 Создание клиентского сертификата
Список литературы
Знание критериев оценки
информационной безопасности способно помочь при выборе и комплектовании
аппаратно-программной конфигурации. Кроме того, в своей повседневной работе
администратор безопасности вынужден хотя бы до некоторой степени повторять
действия сертифицирующих органов, поскольку обслуживаемая система, скорее
всего, время от времени претерпевает изменения и нужно, во-первых, оценивать
целесообразность модификаций и их последствия, а, во-вторых, соответствующим
образом корректировать повседневную практику пользования и администрирования. Если
знать, на что обращают внимание при сертификации, можно сконцентрироваться на
анализе критически важных аспектов, экономя время и силы и повышая качество
защиты.
Одним из первых стандартов
сертификации систем защиты стал стандарт Национального комитета компьютерной
безопасности (National Committee of Computer Security, NСSC)"Критерии
оценки доверенных компьютерных систем" (Trusted Computer System Evaliation
Criteria, TCSEC) или "Orange Book" ("Оранжевая книга").
По стандарту "Оранжевая
книга" критериями оценки надежной компьютерной системы являются:
политика безопасности;
гарантированность;
подотчетность (протоколирование);
документация.
Политика безопасности должна
включать в себя по крайней мере следующие элементы:
произвольное управление доступом;
безопасность повторного
использования объектов;
метки безопасности;
принудительное управление
доступом.
Гарантированность:
операционная;
технологическая.
Средства подотчетности делятся
на три категории:
идентификация и аутентификация;
предоставление надежного пути;
анализ регистрационной
информации.
Документация
руководство пользователя по
средствам безопасности;
руководство администратора по
средствам безопасности;
тестовая документация;
описание архитектуры.
Цель работы - научиться включать
элементы безопасности в информационные системы (ИС) на основе существующих
стандартов проверки качества системы безопасности. Из национального стандарта
США "Оранжевая книга" выбраны критерии оценки качества создания
надежности, которые реализуются средствами системы управления базами данных на
примере СУБД PostgreSQL.
Банк.
Інформаційна система банку.
Скорочений опис концептуально
схеми БД.
13. Інформація про операц
філій, що не пройшли контроль (prohibitions):
порядковий номер заборони, назва
філії, номер операції перекладу платежів для даної філії, код заборони,
повідомлення про причину відхилення
14. Довідник з інформацією про
об'єкти контролю (control_objects): тип об`єкту контролю. Типи об'єктів
контролю: сума платежу операції, сума залишку по рахунках, сума обороту по рахунках.
15. Довідник з інформацією про
час дії контролю (control_time): час дії. Типи часу дії контролю: постійний,
щомісячний, тимчасовий.
Таблица 1. Prohibitions.
Информация про операции филиала,
которые не прошли контроль.
| Порядковый номер запрета |
Целое |
| Название филиала |
Строка |
| Номер операции перевода платежей для даного филиала |
Целое |
| Код запрета |
Целое |
| Сообщение о причине отказа |
Строка |
Create table “Prohibitions”
(“Порядковый номер запрета"
integer,
“Название филиала", char (50)“Номер
операции перевода платежей для даного филиала" integer,
“Код запрета" integer,
“Сообщение о причине отказа” char
(100));
Таблица 2. Control_objects.
Справочник с информацией про
обьекты контроля.
| Сумма платежа |
Денежный |
| Сумма остатка на счету |
Денежный |
| Сумма оборота на счету |
Денежный |
Create table “Control_objects"
(“ Сумма платежа ” double,
"Сумма остатка на счету
double,
"Сумма оборота на счету
double);
Таблица 2. Control_time.
Справочник с информацией о
времени действия контроля.
| Постоянный |
Boolean |
| Ежемесячный |
Boolean |
| Временный |
Boolean |
Create table “Control_time”
( “ Постоянный ” Boolean,
“ Ежемесячный ” Boolean,
“ Временный ” Boolean );
В версиях СУБД PostgreSQL
меньших 8.1 при управлении субъектами использовались понятия "пользователь"
и "группа" и соответствующие команды создания CREATE USER, CREATE
GROUP. Для изменения параметров пользователя или группы ипользовались команды
ALER USER и ALTER GROUP, соответственно. В версиях СУБД PostgreSQL начиная с 8.1
появился более гибкий механизм - роли.
Информационная система банка.
Групповые субъекты: клиенты,
операционисты, директор филиала, работники филиала.
Индивидуальные субъекты: клиент
"ABC", клиент “IBM”, клиент Иванов А.А., клиент Петров П.П., клиент
Сидоров В. Г, операционист Джавров В.Г., операционист Салмин Ю.Л., операционист
Киричук А.Г., директор Корниенко В.А., работник Манько А.А., работник Яновский
Г.Х.
Регистрация индивидуальных
субъектов:
Alter Role ABC
login;
Alter Role IBM
login;
Alter Role
Ivanov login;
Alter Role
Petrov login;
Alter Role
Sidorov login;
Alter Role
Djavr login;
Alter Role
Salmin login;
Alter Role
Kirich login;
Alter Role
Kornienko login;
Alter Role
Manko login;
Alter Role Yanovskiy login;
Регистрация групповых субъектов:
Alter Role
Klient nologin;
Alter Role
Director_Filii nologin;
Alter Role
Worker_Filii nologin;
Alter Role Oper
nologin;
Группировка индивидуальных
субъектов безопасности.
Grant Klient To ABC;
Grant Klient To
IBM;
Grant Klient To
Ivanov;
Grant Klient To
Petrov;
Grant Klient To
Sidorov;
Grant
Director_Filii To Kornienko;
Grant Oper To
Djavr;
Grant Oper To
Salmin;
Grant Oper To
Kirich;
Grant
Worker_Filii To Manko;
Grant
Worker_Filii To Yanovskiy;
Механизм представлений языка SQL
позволяет различными способами разделить базу данных на части таким образом,
чтобы очень важная информация была скрыта от несанкционированных пользователей.
Create Table Klients
(Klient_ID, - -идентификатор
клиента
Name_Klient, - -имя клиента
Data_BD - -дата рождения клиента)
Without oids;
Alter table
Klients owner to Klient;
Comment on
table Klient IS ’Информация о клиентах
Comment on
column Klient. Klient_ID IS ‘Идентификатор клиента
Comment on
column Klient. Name IS ‘Имя клиента
Comment on
column Klient. Data_BD IS ‘Дата рождения клиента
Для установки привиллегий
доступа используется команда:
GRANT список_привиллегий ON
таблица TO роль
Grant select,
insert ON Klients TO Klient
Create Table Dirs
(Dir_ID, - -идентификатор
Name_Dir, - -имя
Data_BD - -дата
рождения) Without oids;
Alter table
Dirs owner to Director_Filii;
Comment on
table Dirs IS ’Информация о директорах
Comment on
column Dirs. Dir_ID IS ‘Идентификатор
Comment on
column Dirs. Name_Dir IS ‘Имя
Comment on
column Dirs. Data_BD IS ‘Дата рождения
Для установки привиллегий
доступа используется команда:
GRANT список_привиллегий ON
таблица TO роль
Grant select,
insert, update, delete ON Dirs TO Director_Filii
Create Table Opers
(Oper_ID, - -идентификатор
Name_Oper, - -имя
Data_BD - -дата
рождения) Without oids;
Alter table
Opers owner to Oper;
Comment on
table Opers IS ’Информация о операционистах
Comment on
column Opers. Oper_ID IS ‘Идентификатор
Comment on
column Opers. Name_Oper IS ‘Имя
Comment on
column Opers. Data_BD IS ‘Дата рождения
Для установки привиллегий
доступа используется команда:
GRANT список_привиллегий ON
таблица TO роль
Grant select,
insert, update, ON Opers TO Oper
Create Table
Workers
(Worker_ID, - -идентификатор
Name_Worker, - -имя
Data_BD - -дата
рождения) Without oids;
Alter table
Workers owner to Worker_Filii;
Comment on
table Workers IS ’Информация о работниках филии
Comment on
column Workers. Worker_ID IS ‘Идентификатор
Comment on
column Workers. Name_Worker IS ‘Имя
Comment on
column Workers. Data_BD IS ‘Дата рождения
Для установки привиллегий
доступа используется команда:
GRANT список_привиллегий ON
таблица TO роль
Grant select ON
Workers TO Worker_Filii
В действующем стандарте языка
SQL предусматривается поддержка только избирательного управления доступом. Она
основана на двух более или менее независимых частях SQL. Одна из них называется
механизмом представлений, который может быть использован для скрытия очень
важных данных от несанкционированных пользователей. Другая называется
подсистемой полномочий и наделяет одних пользователей правом избирательно и
динамично задавать различные полномочия другим пользователям, а также отбирать
такие полномочия в случае необходимости.
CREATE SCHEMA DIRECTOR;
‘Для включения пользователя в
схему используется команда:
ALTER SCHEMA
DIRECTOR OWNER TO KORNIENKO;
‘выполнении запросов к схеме:
SELECT FROM DIRECTOR. KORNIENKO;
‘установления порядка доступа к
схемe
SET
SEARCH_PATH TO public;
SET
SEARCH_PATH TO director, public;
CREATE SCHEMA KLIENT;
‘Для включения пользователя в
схему используется команда:
ALTER SCHEMA
KLIENT OWNER TO ABC;
ALTER SCHEMA
KLIENT OWNER TO IBM;
ALTER SCHEMA
KLIENT OWNER TO IVANOV;
ALTER SCHEMA
KLIENT OWNER TO PETROV;
ALTER SCHEMA
KLIENT OWNER TO SIDOROV;
‘выполнении запросов к схеме:
SELECT FROM KLIENT. ABC;
SELECT FROM
KLIENT. IBM;
SELECT FROM
KLIENT. IVANOV;
SELECT FROM
KLIENT. PETROV;
SELECT FROM
KLIENT. SIDOROV;
‘установления
порядка доступа к схемe
SET
SEARCH_PATH TO public;
SET
SEARCH_PATH TO klient, public;
CREATE SCHEMA OPER;
‘Для включения пользователя в
схему используется команда:
ALTER SCHEMA
OPER OWNER TO SALMIN;
ALTER SCHEMA
OPER OWNER TO DJAVR;
ALTER SCHEMA
OPER OWNER TO KIRICH;
‘выполнении запросов к схеме:
SELECT FROM OPER. SALMIN;
SELECT FROM
OPER. DJAVR;
SELECT FROM OPER. KIRICH;
‘установления порядка доступа к
схемe
SET
SEARCH_PATH TO public;
SET
SEARCH_PATH TO oper, public;
CREATE SCHEMA WORKER;
‘Для включения пользователя в
схему используется команда:
ALTER SCHEMA
WORKER OWNER TO MANKO;
ALTER SCHEMA
WORKER OWNER TOYANOVSKIY;
‘выполнении запросов к схеме:
SELECT FROM WORKER. MANKO;
SELECT FROM
WORKER. YANOVSKIY;
‘установления
порядка доступа к схемe
SET
SEARCH_PATH TO public;
SET
SEARCH_PATH TO worker, public;
Политика безопасности - набор
законов, правил и норм поведения, определяющих, как организация обрабатывает,
защищает и распространяет информацию.
Политика безопасности должна
включать в себя по крайней мере следующие элементы: произвольное управление
доступом, безопасность повторного использования объектов, метки безопасности,
принудительное управление доступом.
С точки зрения работы СУБД
рассмотрим три элемента:
произвольное управление доступом;
метки безопасности;
принудительное управление
доступом.
Описание концепции использования
меток безопасности
Полномочное (принудительное) управление
доступом в промышленных СУБД не реализовано на уровне ядра управления. Но в
СУБД присутствуют программные средства для программирования такого управления.
Для реализации полномочного
управления доступом с субъектами и объектами ассоциируются метки безопасности. Метка
субъекта описывает его благонадежность, метка объекта - степень закрытости
содержащейся в нем информации.
Метки безопасности состоят из
двух частей - уровня секретности и списка категорий. Уровни секретности,
поддерживаемые системой, образуют упорядоченное множество, которое может
выглядеть, например, так: совершенно секретно, секретно, конфиденциально,
несекретно.
Категории образуют
неупорядоченный набор. Их назначение - описать предметную область, к которой
относятся данные. В военном окружении каждая категория может соответствовать,
например, определенному виду вооружений.
Главная проблема, которую
необходимо решать в связи с метками, это обеспечение их целостности:
не должно быть непомеченных
субъектов и объектов, иначе в меточной безопасности появятся легко используемые
бреши;
при любых операциях с данными
метки должны оставаться правильными.
Управление метками безопасности
в СУБД
Для реализации полномочного
управления доступом необходимо разрабатывать
дополнительный механизм,
включающий:
дополнительные структуры данных,
хранящие значение меток конфиденциальности обьектов БД (записей таблиц или их
отдельных атрибутов);
дополнительные структуры данных,
хранящие значение уровней доступа субьектов БД (пользователей или их групп);
В СУБД PostgreSQL вышеописанные
пункты механизма можно создать через:
добавление поля таблицы,
содержащего значения метки конфиденциальности
создание таблицы уровней доступа
с двумя полями: имя группы или пользователя, уровень доступа.
CREATE SEQUENCE KLIENTS_ID;
CREATE TABLE
KLIENTS (KLIENTS_ID INTEGER NOT NULL PRIMARY KEY DEFAULT NEXTVAL ('KLIENTS_ID'),
NAME VARCHAR (30),
SEX CHAR (1),
BIRTHDAY DATE,
CONSTRAINT
VALID_SEX CHECK (SEX IN ('Ж','М',’ФИРМА’)));
COMMENT ON
TABLE PERSONS IS
'ТАБЛИЦА
ИНФОРМАЦИИ О КЛИЕНТАХ;
Для создания механизма
управления метками при доступе пользователей и групп пользователей к таблице
persons выполним следующую последовательность шагов.
Шаг 1. Создать справочник
уровней доступа с помощью команды, пример которой представлен ниже.
CREATE TABLE
ACCESS_LEVELS (ACCESS_LEVEL_ID INTEGER PRIMARY KEY,
ACCESS_LEVELVARCHAR
UNIQUE) ;
INSERT INTO
ACCESS_LEVELS VALUES (1,'для общего доступа');
INSERT INTO
ACCESS_LEVELS VALUES (2,'для внутреннего использования');
INSERT INTO
ACCESS_LEVELS VALUES (3,'секретно');
INSERT INTO
ACCESS_LEVELS VALUES (4,'совершенно секретно');
Шаг 2. Создать таблицу,
содержащую матрицу уровней доступа групп пользователей, пример которой
представлен ниже.
DROP TABLE
GROUPS_ACCESS_LEVEL;
CREATE TABLE
GROUPS_ACCESS_LEVEL (GROUP_NAME | 
