Дипломная (вкр): Создание защищенного приложения для ведения учета продаж и закупок, ориентированного на малый бизнес

Таблица 2 - Поставщики

Таблица 3 - Производители

Таблица 4 - Продажи

Таблица 5 - Закупки

Таблица 6 - Цены

Цена для различного подразделения (магазина) может отличаться, поэтому используем наименование подразделения.

Таблица 7 - Ставки НДС

Таблица 8 - Склады

Таблица 9 - Подразделения

Помимо объектов для ведения учета торговой деятельности предприятия нам необходимо выделить отношения для регистрации новых пользователей и реализации политики управления доступом.

Для этих целей необходимо выделить следующие сведения:

)        пароль;

)        логин;

)        роль.

Отношения, которые будут содержать вышеприведенные наборы данных, следующие:

)        пользователи; роли.

Соответственно, отношение «Пользователи» содержит в себе информацию о логине и пароле, а отношение «Роли» информацию о роли данного пользователя. Однако, поскольку связь между двумя отношениями имеет тип «Многие ко многим»: один пользователей может иметь несколько ролей, и в то же время одна роль может распространяться на несколько пользователей, то дополнительно у нас будет отношение связи между пользователями и ролями. Данное отношение так и будет называться: «Связь роли и пользователя».

Таблица 10 - Пользователи

Таблица 11 - Роли

Таблица 12 -Связь роли и пользователя

Создавая базу данных, мы будем использовать реляционную модель данных. Эта модель представляет собой набор отношений: отношений со сведениями о предметной области «Торговля» и отношений, обеспечивающих связь между отношениями.

При табличной организации данныхcтроки и столбцы могут быть просмотрены в любом порядке, поэтому высока гибкость выбора любого подмножества элементов в строках и столбцах.

Физическая реализация таблицы в базе данных представляет собой строки, которые называют записями, и столбцы, которые называют полями. На пересечении строки столбцов находятся ячейки с данными, то есть конкретные значения атрибутов.

Таблица в реляционной базе данных характеризуется следующим:

) каждый столбец имеет уникальное имя;

) порядок строк в таблице не определён;

) в таблице нет одинаковых строк;

) количество строк в таблице теоретически не ограниченно;

) все строки таблицы имеют одинаковую структуру (тип данных в ячейке, количество ячеек)[1,3].

база архитектура безопасность закупка

. ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ СИСТЕМЫ БЕЗОПАСНОСТИ ПРИЛОЖЕНИЯ БАЗЫ ДАННЫХ

Проектирование архитектуры системы безопасности будем осуществлять с учетом:

.        обеспечение целостности данных;

.        разграничение прав доступа;

.        хэширование паролей;

.        шифрование содержимого БД;

.        защита от SQL-инъекций;

.        защищенное соединение SSL;

.        резервное копирование;

.        защита от дизассемблирования.

.1 Архитектура безопасности

Каждый элемент системы безопасности, за исключением защиты от дизассемблирования и резервного копирования, взаимодействует между собой. Данные взаимодействия происходят в соответствии с представленной на рисунке 3 архитектурой системы безопасности.

Рисунок 3-Модель системы безопасности

Как видно из модели, при запуске приложения у нас происходит установка защищенного соединения по протоколу SSL. Далее, при вводе логина и пароля в окне приложения и нажатию кнопки «Вход», происходит аутентификация пользователя. Сначала введенные данные(логин и пароль) проходят обработку защиты от SQL-инъекций. Далее происходит проверка логина, вычисление хэша пароля и его проверка. При создании новых пользователей вместо пароля пользователя в базу данных заноситься только их хэш. Затем для пользователя происходит определение его роли. Каждый пользователь, в соответствии с его ролью, получает доступ к интерфейсу. При внесении информации в базу данных она проходит проверку на целостность, после чего зашифровывается и через защищенное соединение по протоколу SSLпомещается в БД на сервер.

Таким образом, мы достигаем цели реализации необходимой степени защиты информации.

Поскольку база данных создана СУБД MySql, мы используем клиент-серверное взаимодействие для работы с данными (рисунок 4).

Рисунок 4- Схема клиент-серверного взаимодействия

Как видно из рисунка, запрос пользователя отправляется на сервер СУБД, где происходит его обработка, выбираются запрашиваемые данные, которые после отправляются пользователю для его дальнейшей работы.

2.2 Система контроля доступа с использованием ролевой политики безопасности

Контроль доступа гарантирует нам, что каждый пользователь будет иметь доступ только к тем функциям, которые определены его профессией: продавец оформляет продажи, директор просматривает отчетность и так далее.

Для обеспечения подобного контроля доступа в приложении была реализована система контроля доступа с использованием ролевой политики безопасности.

Ролевое разграничение доступа является составляющей многих современных компьютерных систем. Задание ролей позволяет определить четкие и понятные для пользователей компьютерной системы правила разграничения доступа. При этом РРД наиболее эффективно используется в компьютерных системах, для пользователей которых четко определен круг их должностных полномочий и обязанностей.

Роль является совокупностью прав доступа на объекты компьютерной системы. РРД определяет порядок предоставления прав доступа пользователям в зависимости от сессии его работы и от имеющихся или отсутствующих у него ролей в каждый момент времени. Для анализа и изучения свойств систем РРД используются математические модели РРД. В основе всех математических моделей РРД лежит базовая модель РРД.

Данная модель определяет самые общие принципы построения моделей РРД.

Основными элементами базовой модели являются:

множество пользователей();

множество ролей ();

множество прав доступа на объекты компьютерной системы ();

множество сессий пользователей ();

функция, определяющая для каждой роли множество прав доступа; при этом для каждого  существует , такая что, ;

функция, определяющая для каждого пользователя множество ролейна которые он может быть авторизирован;

функция, определяющая для каждой сессии пользователя, от имени которого она активизирована;

функция, определяющая для пользователей множество ролей, на которые он авторизирован в данной сессии, при этом в каждый момент времени для каждоговыполняется условие:

. (1)

Отметим, что могут существовать роли, на которые не авторизирован ни один пользователь.

В базовой модели РРД предполагается, что множества ,, и функции, не изменяются с течением времени. Однако в нашем случае администратор может создавать произвольное число пользователей, а также различное число ролей.

.3 Защищенное соединение

С целью повышения безопасности работы приложения с базой данных, необходимым шагом является создание защищенного соединения между сервером и клиентом.

Cоздание подобного соединения будет проходить по протоколу SSL.

Криптографический протокол SSL был разработан в 1996 году компанией Netscape и вскоре стал наиболее популярным методом обеспечения защищенного обмена данными через Интернет. Этот протокол интегрирован в большинство браузеров и веб-серверов и использует ассиметричную криптосистему с открытым ключом, разработанную компанией RSA. Для осуществления SSL соединения необходимо, чтобы сервер имел инсталлированный цифровой сертификат. Цифровой сертификат - это файл, который уникальным образом идентифицирует пользователей и серверы. Протокол SSL обеспечивает защищенный обмен данных за счет двух следующих элементов [21-23]: