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

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

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

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

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

АМКР.АМ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_databasef my_database₁₅.05.2008.dump
• Шифрування дампу виконується за допомогою бібліотеки openssl алгоритмом DES:
• openssl ence -des-cbciv smart_initial_valuek very_good_long_keyin my_database₁₅.05.2008.dumpout my_database₁₅.05.2008.dump.arh
• Розшифрування архівної копії:
• openssl encd -des-cbciv smart_initial_valuek very_good_long_keyin my_database₁₅.05.2008.dump.arhout my_database₁₅.05.2008.dump
• Завантаження інформації з дампу до бази даних:
• psql < my_database₁₅.05.2008.dump
• 5. Реалізація елементів Підзвітності
• a. Забезпечення надійності з'єднання
• Для генерації сертифікатів центру сертифікації виконаємо наступну команду:
• openssl reqconfig $SSLDIR$/openssl.cnfnewx509 -nodesdays 1000 -sha1 rsa:1024 -keyout $SSLDIR$/private/ca.keyout $SSLDIR$/ca.crtsubj `/C=UA/ST=OdessaRegion/L=Odessa/O=ONPU/OU=CISN/CN=www.ae035.com.ua'
• Для генерації сертифікатів клієнтів виконаємо наступну команду:
• openssl reqnewsha1 -newkey rsa:1024 -nodeskeyout server. keyout request.pemsubj `/O=ONPU/OU=CISN/CN=www.ae035.com.ua'
• І команда підписання сертифікату:

openssl caconfig $SSLDIR$/openssl.cnfpolicy policy_anythingnoemailDNout $SSLDIR/requests/signed.peminfiles $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 с.