|
Захист інформації в інформаційних системах
Захист інформації в інформаційних системах
2 МІНІСТЕРСТВО НАУКИ І ОСВІТИ УКРАЇНИ Одеський національний політехнічний університет Кафедра комп'ютерних інтелектуальних систем та мереж ЗАХИСТ ІНФОРМАЦІЇ В ІНФОРМАЦІЙНИХ СИСТЕМАХКурсова роботаАМКР.АМ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 с.
|
|