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

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 26.02.2009
Размер файла 51,1 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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 с.


Подобные документы

  • Основні поняття безпеки інформаційних технологій. Законодавчі вимоги і регулювання інформаційної безпеки в мережах. Класифікація шкідливих програм. Приклади цінності інформації. Методи шахрайства. Програмний захист від витікання інформаційних даних.

    курсовая работа [171,9 K], добавлен 08.12.2015

  • Принципи інформаційної безпеки. Статистика атак в Інтернеті. Засоби захисту інформації у системах передачі даних. Загальні поняття та визначення в галузі проектування захищених автоматизованих систем. Захист телефонної лінії від прослуховування.

    магистерская работа [1,2 M], добавлен 07.03.2011

  • Дослідження криптографічних методів захисту даних від небажаного доступу. Основи безпеки даних в комп'ютерних системах. Класифікаційні складові загроз безпеки інформації. Характеристика алгоритмів симетричного та асиметричного шифрування інформації.

    курсовая работа [245,8 K], добавлен 01.06.2014

  • Широке використання інформаційних технологій у всіх сферах життя суспільства. Інформація як об’єкт захисту. Основні види загроз безпеки інформації в комп’ютерних мережах. Несанкційований доступ до інформації і його мета. Порушники безпеки інформації.

    реферат [253,2 K], добавлен 19.12.2010

  • Вразливість інформації в автоматизованих комплексах. Концепція захисту інформації. Комплекс основних задач при розробці політики безпеки. Стратегія та архітектура захисту інформації. Політика безпеки інформації. Види забезпечення безпеки інформації.

    реферат [243,2 K], добавлен 19.12.2010

  • Забезпечення захисту інформації. Аналіз системи інформаційної безпеки ТОВ "Ясенсвіт", розробка моделі системи. Запобігання витоку, розкраданню, спотворенню, підробці інформації. Дослідження та оцінка ефективності системи інформаційної безпеки організації.

    курсовая работа [1,6 M], добавлен 27.04.2014

  • Основи безпеки даних в комп'ютерних системах. Канали проникнення та принципи побудови систем захисту. Ідентифікація і аутентифікація користувачів. Захист даних від несанкціонованого доступу. Технічні можливості зловмисника і засоби знімання інформації.

    курс лекций [555,1 K], добавлен 05.12.2010

  • Інформаційна безпека як захист інтересів суб'єктів інформаційних відносин. Інформація - данні про людей, предмети, факти, події, явища і процеси незалежно від форми їхнього представлення. Об'єктно-орієнтований підхід и складові інформаційної безпеки.

    реферат [97,7 K], добавлен 10.03.2009

  • Терміни та визначення в галузі інформаційної безпеки, напрями її забезпечення (правовий, організаційний, інженерно-технічний). Захист інформації у комп’ютерних системах. Види загроз та можливі наслідки від їх реалізації. Суб’єкти та об’єкти захисту.

    презентация [481,4 K], добавлен 21.10.2014

  • Аналіз предметної галузі, постановка задачі, проектування бази даних. UML-моделювання, побудова ER-діаграми, схеми реляційної бази даних у третій нормальній формі. Призначення і логічна структура. Опис фізичної моделі бази даних, програмної реалізації.

    курсовая работа [3,5 M], добавлен 28.11.2011

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.