Захист інформації в інформаційних системах

МІНІСТЕРСТВО НАУКИ І ОСВІТИ УКРАЇНИ

Одеський національний політехнічний університет

Кафедра комп’ютерних інтелектуальних систем та мереж

ЗАХИСТ ІНФОРМАЦІЇ В ІНФОРМАЦІЙНИХ СИСТЕМАХ

Курсова робота

АМКР. АМ035м.0909

Зміст

Вступ…………………………………………………………………………………………………. 3

Основна частина…………………………………………………………………………………. 4

1.Завдання……………………………………………………………………………………. 4

2.Проектування БДІС……………………………………………………………………. 4

3.Реалізація елементів безпеки……………………………………………………….. 5

4.Реалізація елементів гарантованості…………………………………………… 10

Заключення………………………………………………………………………………………. 16

Перелік літератури……………………………………………………………………………. 17

Вступ

Знання критеріїв оцінки інформаційної безпеки здатне допомогти при виборі і комплектуванні апаратно-програмної конфігурації. Крім того, в своїй повсякденній роботі адміністратор безпеки вимушений хоча б до деякої міри повторювати дії сертифікуючих органів, оскільки обслуговувана система швидше за все час від часу зазнає зміни, і потрібно по-перше, оцінювати доцільність модифікацій і їх результату, а, по-друге, відповідним чином коректувати повсякденну практику користування і адміністрування. Якщо знати, на що звертають увагу при сертифікації, можна концентруватися на аналізі критично важливих, аспектів економлячи час і сили і підвищуючи якість захисту.

Основна частина

1. Завдання

Спроектувати базу даних, що відповідає вимогам: політика безпеки, гарантованість, підзвітність, документація. Для варіанту дев’ять база даних призначена для зберігання інформації з предметної області “Банк”, а саме

– інформація про рахунки по філіях банку (accounts): номер рахунку, назва філії, що обслуговує рахунок, баланс на рахунку;

– інформація про операції, що виконуються у філії (operations): код, дата, номер кредитного рахунку, номер дебетного рахунку, кошти переводу;

– інформація про філії (branch): назва, адреса, капітал.

2. Проектування БДІС

ER-діаграма бази даних зображена на рис. 1. Сутність Філія (Branch) містить багато Операцій(Operation) і Рахунків(Account).

Рис. 1.

Відповідна схема реляційної моделі зображена на рис. 2.

Рис. 2.

Зв’язок “багато-до-одного” у реляційній моделі виконують проміжні таблиці Рахунки(Accounts) і Операції(Operations).

Приведена реляційна модель реалізується наступними виразами мови SQL:

CREATE TABLE Account (num INT PRIMARY KEY, balance INT NOT NULL, CHECK(balance>=0)).

CREATE TABLE Operation (code INT PRIMARY KEY, dat DATE, credit_num INT, debet_num INT, change INT NOT NULL).

CREATE TABLE Branch (num INT PRIMARY KEY, name VARCHAR(50) NOT NULL UNIQUE, adress VARCHAR(50), capital INT NOT NULL, CHECK(capital>=0)).

CREATE TABLE Operations (branch INT REFERENCES Branch, operation INT REFERENCES Operation).

CREATE TABLE Accounts (branch INT REFERENCES Branch, account INT REFERENCES Account).

3. Реалізація елементів б езпеки

Однією з важливих складових безпеки є розподілення прав доступу між користувачами.

Створимо двох користувачів та одну групу. Для кожного користувача також створимо схему.

CREATE ROLE user1;

CREATE ROLE user2;

CREATE ROLE users NOLOGIN;

GRANT users TO user2;

CREATE SCHEMA schema1;

ALTER SCHEMA schema1 OWNER TO user1;

ALTER SCHEMA schema2 OWNER TO user2;

Надамо деякі права новим користувачам.

GRANT INSERT ON Accounts TO user2;

GRANT SELECT ON Accounts TO users;

GRANT UPDATE ON Operations TO user2.

Більш гнучкішим засобом контролю за доступом до таблиць БД є віртуальна таблиця(view). Нижче приведені SQL-запити для створення віртуальних таблиць для вибору щоденних операцій, рахунків одеської філії банку та операцій з переводами коштів до філії:

CREATE VIEW Today_Operations AS

SELECT * FROM Operation WHERE dat = CURRENT_DATE

CREATE VIEW Odessa_Branch_Accounts AS

SELECT * FROM Account WHERE num IN (SELECT account FROM Accounts WHERE branch IN (SELECT num FROM Branch WHERE name = ‘Odessa’))

CREATE VIEW Income_Operations AS

SELECT * FROM Operation WHERE change > 0.

У СКБД “Postgres” для віртуальних таблиць можлива заміна запитів UPDATE, INSERT, DELETEдо цих таблиць на запити користувача.

CREATE RULE Income_Operations_INSERT AS ON INSERT TO schema1.Income_Operations

DO INSTEAD INSERT INTO Income_Operations

SELECT NEW. code, NEW. dat, NEW. credit_num, NEW. debet_num

WHERE NEW. change >0;

CREATE RULE Income_Operations_UPDATE AS ON UPDATE TO schema1.Income_Operations

DO INSTEAD UPDATE Income_Operations SET

Code=NEW. code, dat=NEW. dat, credit_num=NEW. credit_num, debet_num=NEW. debet_num

WHERE NEW. change >0;

CREATE RULE Income_Operations_DELETE AS ON DELETE TO schema1.Income_Operations

DO INSTEAD DELETE FROM Income_Operations WHERE NEW. change >0;

CREATE RULE Today_Operations_INSERT AS ON INSERT TO schema1.Today_Operations

DO INSTEAD INSERT INTO Today_Operations

SELECT NEW. code, NEW. dat, NEW. credit_num, NEW. debet_num

WHERE NEW. dat = CURRENT_DATE;

CREATE RULE Today_Operations_UPDATE AS ON UPDATE TO schema1.Today_Operations

DO INSTEAD UPDATE Income_Operations SET

Code=NEW. code, dat=NEW. dat, credit_num=NEW. credit_num, debet_num=NEW. debet_num

WHERE NEW. dat = CURRENT_DATE;

CREATE RULE Today_Operations_DELETE AS ON DELETE TO schema1.Today_Operations

DO INSTEAD DELETE FROM Income_Operations WHERE NEW. dat = CURRENT_DATE;

CREATE RULE Odessa_Branch_Accounts_UPDATE AS ON UPDATE TO schema1.Odessa_Branch_Accounts

DO INSTEAD UPDATE Account SET

Balance=NEW. balance WHERE NEW. num IN (SELECT account FROM Accounts WHERE branch IN (SELECT num FROM Branch WHERE name = ‘Odessa’))

CREATE RULE Odessa_Branch_Accounts_DELETE AS ON DELETE TO schema1.Odessa_Branch_Accounts

DO INSTEAD DELETE FROM Account WHERE NEW. num IN (SELECT account FROM Accounts WHERE branch IN (SELECT num FROM Branch WHERE name = ‘Odessa’))

Для організації більш складної системи розмежування прав та введення рівнів секретності треба створити окремі структури даних з цією інформацією та ввести додаткові правила перевірки відповідності рівня користувача запиту рівню доступу до даної таблиці. Таблиця PERSONS містить список усіх користувачів, таблиця ACCESS_LEVELS – рівні доступу, GROUPS_ACCESS_LEVEL – призначені рівні доступу групам користувачів.

CREATE SEQUENCE PERSON_ID;

CREATE TABLE PERSONS (

PERSON_ID INTEGER NOT NULL PRIMARY KEY DEFAULT NEXTVAL(‘PERSON_ID’)

NAME VARCHAR(30)

SEX CHAR(1)

BIRTHDAY DATE

CONSTRAINT VALID_SEX CHECK (SEX IN (‘M’,’W’)));

CREATE TABLE ACCESS_LEVELS (

ACCESS_LEVEL_ID INTEGER PRIMARY KEY

ACCESS_LEVELVARCHAR UNIQUE);

INSERT INTO ACCESS_LEVELS VALUES (1,’public’);

INSERT INTO ACCESS_LEVELS VALUES (2,’private’);

INSERT INTO ACCESS_LEVELS VALUES (3,’secret’);

INSERT INTO ACCESS_LEVELS VALUES (4,’top secret’);

CREATE TABLE GROUPS_ACCESS_LEVEL (

GROUP_NAME VARCHAR PRIMARY KEY

ACCESS_LEVEL INTEGER REFERENCES

ACCESS_LEVELS(ACCESS_LEVEL_ID));

REVOKE ALL ON GROUPS_ACCESS_LEVEL FROM GROUP USERS;

GRANT SELECT ON GROUPS_ACCESS_LEVEL TO GROUP USERS;

INSERT INTO GROUPS_ACCESS_LEVEL VALUES (‘users’,2);

ALTER TABLE PERSONS

ADD COLUMN SPOT_CONF INTEGER DEFAULT 1

REFERENCES ACCESS_LEVELS(ACCESS_LEVEL_ID);

CREATE OR REPLACE VIEW PERSONS_LIST AS

SELECT PERSON_ID, NAME, SEX, BIRTHDAY

FROM PG_GROUP G, PG_USER U, PERSONS P

GROUPS_ACCESS_LEVEL L

WHERE

USENAME = CURRENT_USER AND

U. USESYSID = ANY (G. GROLIST) AND

L. GROUP_NAME = G. GRONAME AND

P. SPOT_CONF <= L. ACCESS_LEVEL;

REVOKE ALL ON PERSONS FROM GROUP USERS;

GRANT SELECT ON PERSONS_LIST TO GROUP USERS;

INSERT INTO PERSONS_LIST VALUES (1,’Tkachuk’,’M’,’23-02-1986′);

UPDATE PERSONS SET SPOT_CONF = 4 WHERE PERSON_ID = 1;

INSERT INTO PERSONS_LIST VALUES (1,’Ivanov’,’M’,’15-03-1987′);

UPDATE PERSONS SET SPOT_CONF = 1 WHERE PERSON_ID = 2;

DROP RULE PERSONS_LIST_INSERT ON PERSONS_LIST;

CREATE RULE PERSONS_LIST_INSERT AS ON INSERT TO PERSONS_LIST DO INSTEAD

INSERT INTO PERSONS

SELECT CASE WHEN NEW. PERSON_ID IS NULL THEN NEXTVAL(‘PERSON_ID’) ELSE NEW. PERSON_ID END

NEW. NAME, NEW. SEX, NEW. BIRTHDAY, L. ACCESS_LEVEL

FROM PG_GROUP G, PG_USER U, GROUPS_ACCESS_LEVEL L

WHERE

U. USENAME = CURRENT_USER AND

U. USESYSID = ANY (G. GROLIST) AND

L. GROUP_NAME = G. GRONAME;

GRANT INSERT ON PERSONS_LIST TO GROUP USERS;

GRANT SELECT, UPDATE ON PERSON_ID TO GROUP USERS;

DROP RULE PERSONS_LIST_UPDATE ON PERSONS_LIST;

CREATE RULE PERSONS_LIST_UPDATE AS ON UPDATE TO PERSONS_LIST

DO INSTEAD

UPDATE PERSONS SET PERSON_ID = NEW. PERSON_ID

NAME = NEW. NAME, SEX = NEW. SEX, BIRTHDAY = NEW. BIRTHDAY

SPOT_CONF = L. ACCESS_LEVEL

FROM PG_GROUP G, PG_USER U, GROUPS_ACCESS_LEVEL L

WHERE

PERSON_ID = OLD. PERSON_ID AND

SPOT_CONF = L. ACCESS_LEVEL AND

U. USENAME = CURRENT_USER AND

U. USESYSID = ANY (G. GROLIST) AND

L. GROUP_NAME = G. GRONAME;

GRANT UPDATE ON PERSONS_LIST TO GROUP USERS.

4. Реалізація елементів гарантованості

Для створення резервної копії бази даних СКБД Postgres слід виконати команду:

Pg_dump my_database -f my_database_15.05.2008.dump

Шифрування дампу виконується за допомогою бібліотеки openssl алгоритмом DES:

Openssl enc -e -des-cbc -iv smart_initial_value -k very_good_long_key -in my_database_15.05.2008.dump -out my_database_15.05.2008.dump. arh

Розшифрування архівної копії:

Openssl enc -d -des-cbc -iv smart_initial_value -k very_good_long_key -in my_database_15.05.2008.dump. arh -out my_database_15.05.2008.dump

Завантаження інформації з дампу до бази даних:

Psql < my_database_15.05.2008.dump

5. Реалізація елементів Підзвітності

A. Забезпечення надійності з’єднання

Для генерації сертифікатів центру сертифікації виконаємо наступну команду:

Openssl req -config $SSLDIR$/openssl. cnf -new -x509 -nodes -days 1000 -sha1 rsa:1024 -keyout $SSLDIR$/private/ca. key -out $SSLDIR$/ca. crt -subj ‘/C=UA/ST=OdessaRegion/L=Odessa/O=ONPU/OU=CISN/CN=www. ae035.com. ua’

Для генерації сертифікатів клієнтів виконаємо наступну команду:

Openssl req -new -sha1 -newkey rsa:1024 -nodes -keyout server. key -out request. pem -subj ‘/O=ONPU/OU=CISN/CN=www. ae035.com. ua’

І команда підписання сертифікату:

Openssl ca -config $SSLDIR$/openssl. cnf -policy policy_anything – noemailDN – out $SSLDIR/requests/signed. pem – infiles $SSLDIR/requests/request. pem

B. Забезпечення журналювання змін

Для забезпечення журналювання змін інформації в таблицях для кожної з них створюється таблиця-журнал та правила для операцій зміни:

CREATE TABLE Account_logs (

USERNAME VARCHAR DEFAULT CURRENT_USER,

OPER_TYPECHAR(1) CHECK (OPER_TYPE IN (‘I’,’U’,’D’)),

OPER_TIMETIMESTAMP DEFAULT NOW(),

Num_new INTEGER,

Num_old INTEGER,

Balance_new INTEGER,

Balance_old INTEGER);

CREATE TABLE Operation_logs (

USERNAME VARCHAR DEFAULT CURRENT_USER,

OPER_TYPECHAR(1) CHECK (OPER_TYPE IN (‘I’,’U’,’D’)),

OPER_TIMETIMESTAMP DEFAULT NOW(),

Code_new INTEGER,

Code_old INTEGER,

Dat_new DATE,

Dat_old DATE

Credit_num_new INTEGER,

Credit_num _old INTEGER

Debet_num _new INTEGER,

Debet_num _old INTEGER

Change_new INTEGER,

Change _old INTEGER);

CREATE TABLE Branch_logs (

USERNAME VARCHAR DEFAULT CURRENT_USER,

OPER_TYPECHAR(1) CHECK (OPER_TYPE IN (‘I’,’U’,’D’)),

OPER_TIMETIMESTAMP DEFAULT NOW(),

Num_new INTEGER,

Num_old INTEGER,

Name_new VARCHAR(50),

Name_old VARCHAR(50),

Address_new VARCHAR(50),

Address_old VARCHAR(50),

Capital_new INTEGER,

Capital_old INTEGER);

DROP RULE Account_logs _INSERT ON Account;

CREATE RULE Account_logs _INSERT AS ON INSERT TO Account

DO

INSERT INTO Account_logs

(OPER_TYPE, num_new, balance_new )

VALUES (‘I’, NEW. num, NEW. balance);

DROP RULE Account_logs _UPDATE ON Account;

CREATE RULE Account_logs _ UPDATE AS ON UPDATE TO Account

DO

INSERT INTO Account_logs

(OPER_TYPE, num_new, balance_new, num_old, balance_old )

VALUES (‘U’, NEW. num, NEW. balance, OLD. num, OLD. balance);

DROP RULE Account_logs _DELETE ON Account ;

CREATE RULE Account_logs _DELETE AS ON DELETE TO Account

DO

INSERT INTO Account_logs

(OPER_TYPE, num_old, balance _old,)

VALUES (‘D’, OLD. num, OLD. balance);

DROP RULE Operation_logs _INSERT ON Operation ;

CREATE RULE Operation_logs _INSERT AS ON INSERT TO Operation

DO

INSERT INTO Operation_logs

(OPER_TYPE, code_new, dat_new, credit_num_new, debet_num_new, change_new )

VALUES (‘I’, NEW. code, NEW. dat, NEW. credit-num, NEW. debet_num, NEW. change);

DROP RULE Operation_logs _UPDATE ON Operation ;

CREATE RULE Account_logs _ UPDATE AS ON UPDATE TO Operation

DO

INSERT INTO Operation_logs

(OPER_TYPE, code_new, dat_new, credit_num_new, debet_num_new, change_new,

Code_old, dat_old, credit_num_old, debet_num_old, change_old)

VALUES (‘U’, NEW. code, NEW. dat, NEW. credit_num, NEW. debet_num, NEW. change,

OLD. code, OLD. dat, OLD. credit_num, OLD. debet_num, OLD. change);

DROP RULE Operation_logs _DELETE ON Operation ;

CREATE RULE Operation_logs _DELETE AS ON DELETE TO Operation

DO

INSERT INTO Operation_logs

(OPER_TYPE, code_old, dat_old, credit_num_old, debet_num_old, change_old )

VALUES (‘D’, OLD. code, OLD. dat, OLD. credit_num, OLD. debet_num, OLD. change);

DROP RULE Branch_logs _INSERT ON Branch ;

CREATE RULE Account_logs _INSERT AS ON INSERT TO Branch

DO

INSERT INTO Branch_logs

(OPER_TYPE, num_new, name_new, address_new, capital_new )

VALUES (‘I’, NEW. num, NEW. name, NEW. address, NEW. capital );

DROP RULE Branch_logs _UPDATE ON Branch ;

CREATE RULE Account_logs _ UPDATE AS ON UPDATE TO Branch

DO

INSERT INTO Branch_logs

(OPER_TYPE, num_new, name_new, address_new, capital_new,

num_old, name_ old, address_ old, capital_ old )

VALUES (‘U’, NEW. num, NEW. name, NEW. address, NEW. capital,

OLD. num, OLD. name, OLD. address, OLD. capital );

DROP RULE Branch_logs _DELETE ON Branch;

CREATE RULE Branch_logs _DELETE AS ON DELETE TO Branch

DO

INSERT INTO Branch_logs

(OPER_TYPE, num_old, name_old, address_old, capital_old )

VALUES (‘D’, OLD. num, OLD. name, OLD. address, OLD. capital);

Заключення

В даній роботі проведено проектування та реалізація БД у СКБД Postgres. Реалізовані наступні елементи безпеки ІС:

– цілісність даних на рівні таблиць, перевірка їх коректності;

– облік користувачів, груп користувачів та їх прав, рівні секретності, контроль доступу до таблиць;

– організація захищеного з’єднання з СКБД за допомогою протоколу SSL;

– організація журналювання змін таблиць засобами самої СКБД.

Перелік літератури

1. Грабер М. SQL. – М: Лори, 2003. – 642 с.

2. Дейт К. Дж. Введение в системы баз данных. – К: Диалектика, 1998. – 784 с.


Захист інформації в інформаційних системах