МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

БД	–	база данных
СУБД	–	система управления базами данных
РРД	–	ролевое разграничение доступа
ИНН	–	идентификационный номер налогоплательщика
ИП	–	индивидуальный предприниматель
КПП	–	код причины постановки
MD5	–	message digest 5 – алгоритм хэширования
SHA-1	–	secure hash algorithm 1 – алгоритм хэширования
MAC	–	message authentication code – код проверки сообщения
HMAC	–	hashed message authentication code – хэшированный код проверки сообщения
SSL	–	secure sockets layer – криптографический протокол для защищенного обмена данными
TLC	–	transport layer security – криптографические протокол, обеспечивающие защищённую передачу данных
DES	–	data encryption standard – алгоритм для симметричного шифрования
3DES	–	triple data encryption standard – симметричный блочный шифр, на основе алгоритма DES
RC2	–	rivest's cipher 2 – алгоритм блочного шифрования
AES	–	advanced encryption standard – симметричный алгоритм блочного шифрования

ВВЕДНИЕ

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

Важным аспектом в ведении предпринимательской деятельности является торговый учет. Именно благодаря ему мы можем оценить рентабельность предприятия, на основании продаж спрогнозировать дальнейшие заказы, на основании выручки и чистой прибыли сформировать ценовую политику. На основании средств, затраченных на рекламу
и клиентов, пришедших с этой рекламы, строить свои выводы
об эффективности маркетинговой компании и так далее. Таким образом, «цифры» – важнейший показатель в предпринимательской
деятельности [2, 5].

Возникает вопрос: «Каким образом лучше всего вести торговый учет? ».

Логичным ответом на него является использование специализированных программ, например 1С. И действительно, данное решение подойдет очень многим предпринимателям, однако не всем. Дело
в том, что система 1С является универсальной и многофункциональной – она ориентирована на любые виды бизнеса и торговый учет у нее может вестись в разрезе сотен измерений, что делает её достаточно неудобной для маленьких компаний, которым требуется малая часть от функционала, который предоставляет 1С. Другим достаточно важным недостатком является стоимость программы и постоянная плата за услуги мастера, который будет обновлять её.

Все это в совокупности делает подобную систему неподходящей
для начинающего предпринимателя, не имеющего большого количества продаж и не работающего с большим количество видов документов.

Другим ответом на поставленный вопрос является электронные таблицы, например, MS Excel. Данное приложение позволяет нам записывать суммы продаж и закупок и на основании их формировать представление
о рентабельности малого предприятия. Однако на этом функционал Excel можно считать завершенным. Поэтому проведение анализа затруднено.
В приложении MS Excel нет специальных функций для ведения учета
по товарам, поставщикам, производителям, складам и датам. Таким образом, MS Excel также можно считать малопригодным для ведения торгового
учета [6].

Остается третий вариант – использование бесплатной специализи-рованной программы, не имеющей громоздкого функционала, но в то же вре-мя обладающей минимальным набором нужных опций. Разработка именно такой программы является целью ВКР.

Цель работы – создание защищенного приложения «Система ведения учета продаж и закупок» для малого бизнеса.

Поставленная цель ВКР определяет следующие задачи:

1. Проектирование модели базы данных в соответствии с предметной областью «Торговля».

2. Разработка архитектуры системы безопасности приложения
по ведению базы данных.

3. Реализация приложения, обеспечивающего учет продаж и закупок предприятия, и реализация способов его защиты.

4. Тестирование приложения.

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

МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

Анализ предметной области

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

Поскольку наше приложение ориентированно на учет продаж
и закупок, будем рассматривать сферу бизнеса, связанную исключительно с продажей товара. Продажа товара может быть оптовой, розничной
и оптово-розничной. Ведение оптовой и оптово-розничной торговли
в большинстве случаев относится к средним и крупным компаниям, так как для осуществления подобной деятельности необходимы развитая логистика, большие денежные средства для закупок, наличие крупных складов, взаимодействие с другими компаниями и так далее. Помимо продаж
и закупок существует масса других факторов, которые необходимо учитывать: расхождения в заказе поставщику и присланной продукцией, порча товара в пути, контроль брака товара, возвраты от других оптовых покупателей, сроки доставки, проведение ревизий и так далее. Таким образом, очевидно, что в данной деятельности требуется сложная
и многофункциональная программа ведения торгового учета, поэтому
мы сосредоточимся исключительно на розничной торговли.

Ведение розничной торговли может рассматриваться как осуществ-ление двух основных торговых операций – закупок и продаж товара. Каждая закупка и продажа должна характеризоваться товаром, участвующим
в операции, а также его количеством.

В свою очередь товар также должен содержать в себе некую дополнительную информацию, характеризующую его: является товар весовым или штучным, в каких формах он продается (упаковки, штуки, коробки и так далее), какова цена данного товара, кто является
его поставщиком и производителем, какова ставка НДС для данного товара, какой штрихкод у товара и так далее.

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

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

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

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

Выделим предварительный набор сведений, которые должны храниться в базе данных для корректного ведения управления торговлей:

1) наименование номенклатуры;

2) единица измерения номенклатуры;

3) поставщик номенклатуры;

4) адрес поставщика (город, улица, номер дома, телефон);

5) ИНН и КПП производителя;

6) ставка НДС;

7) страна происхождения номенклатуры;

8) производитель номенклатуры;

9) адрес производителя (город, улица, номер дома, телефон);

10) штрихкод;

11) закупочная цена;

12) розничная цена;

13) операция продажи;

14) дата продажи;

15) количество проданной продукции;

16) сумма продажи;

17) операция закупки;

18) дата операции закупки;

19) количество закупленной продукции;

20) сумма закупки;

21) склад номенклатуры;

22) подразделения (магазины).

Дополнительно будем выделять такие сведения, как «Цена с учетом НДС» (для закупок и продаж).

В качестве модели представления данных будет использована модель «Сущность-Связь».

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

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

Абстрагирование – это мыслительная операция выделения существенных свойств объекта путем отвлечения в процессе познания
от несущественных свойств. Абстрагирование, иначе, – это упрощенное описание части реального мира в форме понятий.

Метод «Сущность-Связь» использует следующие понятия:

1) сущность – это понятие, данное объекту реального мира;

2)свойство сущности – это понятие, данное свойству объекта реального мира;

3) атрибут сущности – это имя свойства сущности;

4) ключ сущности – это один или несколько атрибутов сущности, значения которых не могут встречаться в двух различных экземплярах сущности;

5) экземпляр сущности – это понятие, поставленное в соответствии объекту из набора объектов реального мира, в котором у каждого объекта имеется набор одинаковых свойств, и значения наборов свойств не повторяются.

5. Связь – это понятие, данное взаимодействию объектов реального мира [4].

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

– один к одному (обозначается 1: 1). Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности
с другой ролью;

– один ко многим (обозначается 1: n). В данном случае сущности
с одной ролью может соответствовать любое число сущностей с другой ролью [7].

Из анализа предметной области мы можем выделить 7 основных сущностей:

1) номенклатура;

2) поставщики;

3) производители;

4) продажи;

5) склады;

6) подразделения;

7) закупки.

Также выделим 3 дополнительные сущности, относящихся
к пользователям и их ролям:

1) пользователь;

2) роль;

3) связи роли и пользователя.

Представим сущности с их атрибутами и связями между ними в виде модели предметной области (рисунки 1-2). Поскольку мы будем разделять хранение данных, связанных с торговлей и данных, связанных
с пользователями, ролями и паролями, будет создано две модели БД.

Рисунок 1 – Модель предметной области «Пользователи и роли»

Рисунок 2 – Модель предметной области «Главная база данных»

Благодаря средствам программы WorkBench данные модели были преобразованы в базы данных в СУБД MySql [8].

Проектирование базы данных

Проектирование базы данных будем осуществлять в соответствии
с реляционной моделью данных. Для этого, исходя из предварительной информации раздела 1.1, сформируем следующие отношения:

1) номенклатура;

2) поставщики;

3) производители;

4) продажи;

5) склады;

6) подразделения;

7) закупки.

Поскольку для торговой отчетности нам может понадобиться история по таким данным, как изменение цены товара со временем, мы выделим отношения «Цена товара». Аналогично в отдельное отношение мы выделим данные по товарам на складе.

Также мы имеем некоторые наборы фиксированных данных, такие, как ставки НДС и, для сохранения целостности БД, будет разумно создать отдельное отношение, которое будет хранить ставки.

Без использования отношения «ставки НДС» возможны ошибки при вводе с клавиатуры, что не позволит создавать корректную отчетность
по продажам, поскольку ставка НДС непосредственно влияет на итоговую цену товара.

Общий список отношений следующий: номенклатура; ставки НДС; поставщики; производители; продажи; склады; цены; подразделения; закупки.

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

Полученные отношения запишем в виде таблиц (таблица 1–12).

Таблица 1 – Номенклатура

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Наименование	Name	Текстовый (varchar)
Единица измерения	EdinitsaIzmereniya	Текстовый (varchar)
Поставщик	PostavshikiName	Текстовый (varchar)
Страна происхождения	Country	Текстовый (varchar)
Производитель	ProizvoditeliName	Текстовый (varchar)
Ставка НДС	StavkaNDSRazmerStavki	Числовой (int)
Штрихкод	Shtrihkod	Текстовый (varchar)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Наименование	Name	Текстовый (varchar)
ИНН	INN	Числовой (int)
КПП	KPP	Числовой (int)
Город	City	Текстовый (varchar)
Улица	Street	Текстовый (varchar)
Номер дома	BuildingNumber	Текстовый (varchar)
Телефон	Phone	Текстовый (varchar)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Наименование	Name	Текстовый (varchar)
ИНН	INN	Числовой (int)
КПП	KPP	Числовой (int)
Город	City	Текстовый (varchar)
Улица	Street	Текстовый (varchar)
Номер дома	BuildingNumber	Текстовый (varchar)
Телефон	Phone	Текстовый (varchar)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Код продажи	idProdazi	Числовой (int)
Подразделение	PodrazdelenieName	Текстовый (varchar)
Номенклатура	NomenklaturaName	Текстовый (varchar)
Дата	Date	Дата (data)
Количество	Kolichestvo	Числовой (int)
Розничная цена	RoznichnayaTsena	Числовой (int)
Цена с учетом НДС	TsenaSnds	Числовой (int)
Сумма	Summa	Числовой (int)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Код закупки	idZakupki	Числовой (int)
Поставщик	PostavshikiName	Текстовый (varchar)
Номенклатура	NomenklaturaName	Текстовый (varchar)
Склад	Skladi_Name	Текстовый (varchar)
Дата	Date	Дата (data)
Количество	Kolichestvo	Числовой (int)
Закупочная цена	ZakupochnayaTsena	Числовой (int)
Сумма	Summa	Числовой (int)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Номенклатура	NomenklaturaName	Текстовый (varchar)
Подразделение	Текстовый (varchar)	Текстовый (varchar)
Дата	Date	Дата (data)
Цена продажи	TsenaProd	Числовой (int)
Цена закупки	TseniZakup	Числовой (int)
Поставщик	PostavshikiName	Текстовый (varchar)

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

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Размер ставки	RazmerStavki	Числовой (int)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Наименование	Name	Текстовый (varchar)
Город	City	Текстовый (varchar)
Улица	Street	Текстовый (varchar)
Номер дома	BuildingNumber	Числовой (int)
Телефон	Phone	Текстовый (varchar)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Наименование	Name	Текстовый (varchar)

Продолжение таблицы 9 – Подразделения

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Наименование	Name	Текстовый (varchar)
Город	City	Текстовый (varchar)
Улица	Street	Текстовый (varchar)
Номер дома	BuildingNumber	Текстовый (varchar)
Телефон	Phone	Текстовый (varchar)

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

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

1) пароль;

2) логин;

3) роль.

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

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

2) роли.

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

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Имя пользователя	Name	Текстовый (varchar)
Пароль	Password	Текстовый (varchar)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Наименование	Name	Текстовый (varchar)

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

Имя поля в схеме данных	Имя поля в компьютерной БД	Тип поля
Наименование роли	Roles_Name	Текстовый (varchar)
Имя пользователя	Users_Name	Текстовый (varchar)
Пароль	Users_Password	Текстовый (varchar)
Доп. проверка	DopProverka	Текстовый (varchar)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

БД

Клиент (приложение)

Запрос

Ответ

Сервер СУБД (обработка запроса)

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

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

Безопасности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. (1)

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

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

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

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

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

Криптографический протокол SSL был разработан в 1996 году компанией Netscape и вскоре стал наиболее популярным методом обеспечения защищенного обмена данными через Интернет. Этот протокол интегрирован в большинство браузеров и веб-серверов и использует ассиметричную криптосистему с открытым ключом, разработанную компанией RSA.

Для осуществления SSL соединения необходимо, чтобы сервер имел инсталлированный цифровой сертификат. Цифровой сертификат – это файл, который уникальным образом идентифицирует пользователей и серверы.

Протокол SSL обеспечивает защищенный обмен данных за счет двух следующих элементов [21–23]:

а) аутентификация;

б) шифрование.

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

Протокол SSL предоставляет «безопасный канал», который имеет три основных свойства [24]:

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

2) канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, а клиентская делает это опционально;

3) канал надежен. Транспортировка сообщений включает в себя проверку целостности.

Работу протокол SSL можно разделить на два уровня.

Первый уровень представляет слой протокола подтверждения подключения (Handshake Protocol Layer). Он состоит из трех подпротоколов: протокол подтверждения подключения (Handshake Protocol), протокол изменения параметров шифра (Change Cipher Spec Protocol)
и предупредительный протокол (Alert protocol).

Второй уровень представляет слой протокола записи. На рисунке 5 схематично изображены уровни слоев SSL.

Рисунок 5 – уровни слоев SSL

Уровень подтверждения подключения состоит из трех подпротоколов:

а) подтверждение подключения. Этот подпротокол используется для согласования данных сессии между клиентом и сервером. В данные сессии входят:

1) идентификационный номер сессии;
2) сертификаты обеих сторон;
3) параметры алгоритма шифрования, который будет использован;
4) алгоритм сжатия информации, который будет использоваться;
5) «общий секрет», применён для создания ключей;

6) открытый ключ;

б) изменения параметров шифрования. Этот подпротокол используется для изменения данных ключа (keyingmaterial), который используется для шифрования данных между клиентом и сервером. Данные ключа – это информация, которая используется для создания ключей шифрования. Подпротокол изменения параметров шифрования состоит из одного единственного сообщения. В этом сообщении сервер говорит,
что отправитель хочет изменить набор ключей. Дальше, ключ вычисляется
из информации, которой обменялись стороны на уровне подпротокола подтверждения подключения;

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

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

Установление подлинности участников. Для определения подлинности участников обмена данных, протокол подтверждения подключения использует сертификат стандарта Х.509. Это помогает подтвердить подлинность второй стороны, которая владеет сертификатом и секретным ключом. Сертификат – это цифровой способ идентификации, который выпускает центр сертификации. В сертификате содержится иденти-фикационная информация, период действия, публичный ключ, серийный номер, и цифровые подписи эмитента.

Сертификационный центр – это третья сторона, которой по умолчанию доверяют обе стороны. При попытке установить подключение в режиме SSL сессии, сертификационный центр проверяет инициатора (обычно в этой роли выступает пользователь, компьютер клиента), а затем выдает ему сертификат. Если необходимо, сертификационный центр обновляет или конфискует сертификаты. Проверка подлинности проходит по схеме:

1) клиенту предоставлен сертификат сервера; компьютер клиента пытается сопоставить эмитента сертификата сервера со списком доверительных сертификационных центров;

2) если эмитент сертификата – доверительный сертификационный центр, то клиент связывается и этим центром и проверяет, является
ли сертификат настоящим, а не подделанным;

3) после проверки сертификата у сертификационного центра, клиент принимает сертификат как свидетельство подлинности сервера.

Шифрование данных. Существует два основных способа шифрования данных: симметричный ключ (еще называется «общий секретный ключ»)
и ассиметричный ключ (второе название «открытый ключ» или «схема открытый-секретный ключ»). Протокол SSL использует как симметричные, так и ассиметричные ключи для шифрования данных [21].

SSL-ключ – это зашифрованные данные, которые используются
для определения схемы шифрования данных во время сессии. Чем длиннее ключ, тем труднее его взломать. Как правило, алгоритмы ассиметричных ключей более стойкие, их практически невозможно взломать.

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

Шифрование симметричным ключом обычно используется для шифро-вания большого объема данных, так как это процесс проходит быстрее,
чем при ассиметричном шифровании. Обычно используются алгоритмы
DES, 3DES, RC2, и AES.

Ассиметричный ключ. Шифрование с применением ассиметричного (открытого) ключа использует пару ключей, которые оба были получены, пройдя целый комплекс математических вычислений. Один из ключей используется в качестве открытого, как правило, сертификационный центр публикует открытый ключ в самом сертификате владельца. Секретный ключ держится в тайне и никогда никому не открывается.

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

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

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

Именно это является основой для цифровых подписей. Самый распространенный алгоритм, который используется при шифровании
с ассиметричными ключами – RSA (назван в честь разработчиков Rivest, Shamir, Adleman).

Протокол SSL использует шифрование с открытым ключом для того, чтоб подтвердить клиенту подлинность сервера, и наоборот. Шифрование открытым ключом также используется для определения ключа сессии. Ключ сессии используется симметричными алгоритмами для шифровки большого объема данных.

Это объединяет ассиметричное шифрование (для проверки подлин-ности) и быстрое симметричное шифрование объемных данных (что не тре-бует больших вычислительных ресурсов и больших затрат времени).

Хэширование. Во время подтверждения подключения согласовывается также и хэш-алгоритм. Хэш-функция – это односторонняя математическая функция, которая принимает на входе сообщение произвольной длины
и вычисляет из него строку фиксированной длины.

Хэш-значение играет роль идентификационной отметки, «отпечаток сообщения». Как и отпечатки пальцев уникальны для каждого человека, хэш-значения тоже уникальны. Кроме того, как отпечатки пальцев значительно меньше, чем сам человек, так и хэш-значение намного меньше оригинального сообщения.

Хэширование используется для обеспечения целостности передачи данных. Самыми популярными хэш-алгоритмами являются MD5 и SHA-1. MD5 создает 128 битное хэш–значение, а SHA-1 создает 160 битное
хэш-значение. Есть также новые, более устойчивые алгоритмы хэширования: Whirlpool, Haval, Tiger [25].

Результатом работы хэш-алгоритма выступает значение, которое используется для проверки целостности переданных данных. Это значение создается с использованием либо MAC либо HMAC.

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

HMAC похож на MAC, но при этом используется хэш–алгоритм вместе с общим секретным ключом. Общий секретный ключ прикрепляется
к данным, которые хэшируются.

Это позволяет сделать хэширование более безопасным, так как обе стороны должны иметь одинаковые секретные ключи для подтверждения подлинности данных. HMAC используется только протоколом TLC.

12 3 4 Следующая ⇒