Захист інформації в інформаційних системах (стр. 1 из 2)
МІНІСТЕРСТВО НАУКИ І ОСВІТИ УКРАЇНИ
Одеський національний політехнічний університет
Кафедра комп’ютерних інтелектуальних систем та мереж
ЗАХИСТ ІНФОРМАЦІЇ В ІНФОРМАЦІЙНИХ СИСТЕМАХ
Курсова робота
АМКР.АМ035м.0909
Зміст
Вступ................................................................................................................ 3
Основна частина.............................................................................................. 4
1.Завдання................................................................................................. 4
2.Проектування БДІС............................................................................... 4
3.Реалізація елементів безпеки................................................................. 5
4.Реалізація елементів гарантованості................................................... 10
Заключення.................................................................................................... 16
Перелік літератури........................................................................................ 17
Знання критеріїв оцінки інформаційної безпеки здатне допомогти при виборі і комплектуванні апаратно-програмної конфігурації. Крім того, в своїй повсякденній роботі адміністратор безпеки вимушений хоча б до деякої міри повторювати дії сертифікуючих органів, оскільки обслуговувана система швидше за все час від часу зазнає зміни, і потрібно по-перше, оцінювати доцільність модифікацій і їх результату, а, по-друге, відповідним чином коректувати повсякденну практику користування і адміністрування. Якщо знати, на що звертають увагу при сертифікації, можна концентруватися на аналізі критично важливих, аспектів економлячи час і сили і підвищуючи якість захисту.
Спроектувати базу даних, що відповідає вимогам: політика безпеки, гарантованість, підзвітність, документація. Для варіанту дев’ять база даних призначена для зберігання інформації з предметної області «Банк», а саме
- інформація про рахунки по філіях банку (accounts): номер рахунку, назва філії, що обслуговує рахунок, баланс на рахунку;
- інформація про операції, що виконуються у філії (operations): код, дата, номер кредитного рахунку, номер дебетного рахунку, кошти переводу;
- інформація про філії (branch): назва, адреса, капітал.
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)