Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Телекоммуникаций и радиотехники

Направление (специальность) Информационная безопасность телекоммуникационных систем

Кафедра Мультисервисных сетей и информационной безопасности

Выпускная квалификационная работа (дипломная работа)

Реализация механизма аутентификации для систем автоматизации предприятия

Руководитель доцент к.т.н А.С. Раков

Н. контролер доцент к.т.н Н.М. Бельская

Разработал ИБТС-11 Е.Ю. Апаликова

Самара 2017



Введение

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

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

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

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

Для достижения поставленной цели необходимо выполнить следующие задачи:

1. изучить архитектуру клиент-сервер;

2. изучить БД MySQL, технологию ODBC;

3. рассмотреть и провести анализ основных уязвимостей сервера MySQL;

4. реализовать механизм аутентификации пользователей на языке C# для сервера MySQL.

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

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

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

Во введении обосновывается актуальность работы, цель, задачи, объект и предмет исследования. В первой главе рассматриваются архитектура клиент-сервер и её виды. Во второй главе описываются БД MySQL, технология ODBC, уязвимости MySQL и практическая реализация механизма аутентификации на языке C#. В третьей главе описывается реализация механизма аутентификации с использованием SSL - сертификатов, проводится тестирование системы на уязвимости. В заключении сделаны основные выводы и результаты по проделанной работе.

1. Архитектура клиент-сервер

аутентификация сервер уязвимость сканер

1.1 Появление клиент-серверных баз данных

Активно эволюционирующие с начала 1980-х годов открытые системы, способствовали появлению клиент-серверных баз данных.

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

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

2. прикладные функции, присущие данной предметной области;

3. основные функции хранения и управления ресурсами (файловой системой, базами данных и т.д.)

Рис. 1.1 - Компоненты сетевого приложения

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

1. компонент представления данных отвечает за пользовательский интерфейс;

2. компонент прикладная логика реализует алгоритм решения конкретной задачи;

3. компонент доступ к информационным ресурсам

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

Рис. 1.2 - Принцип работы клиент-серверных систем

В настоящее время существует большое количество СУБД, имеющие архитектуру клиент-сервер. В России наибольшим спросом пользуются: Oracle, Microsoft SQL Server, Postgre, MySQL, Informix Universal Server, InterBase фирмы Embarcadero Technologies, NetWare SQL фирмы Novell и т. д.

Доминирование клиент-серверного построения БД на сегодняшний день обусловлено несколькими причинами:

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

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

3. Основные правила поддержки целостности и непротиворечивости данных описываются на одном сервере СУБД, клиентские приложения не в состоянии обойти эти правила.

4. Экономное расходование пропускной способности компьютерных сетей.

5. Благодаря централизованному хранению данных сравнительно просто поддерживать единые для всех правила безопасности БД.

6. Наличие стандарта на основной язык общения SQL обеспечивает широкие возможности доступа к серверу БД из программного обеспечения различных производителей.

7. Упрощены вопросы обслуживания и администрирования БД.

1.2 Виды архитектуры клиент-сервер

В настоящее время в сетях, основанных на современных сетевых технологиях, имеются компоненты клиент-серверной архитектуры. Достаточно часто встречается двухзвенная архитектура (рис.1.3). Двухзвенная архитектура - это архитектура, которая имеет две составляющие: клиент и сервер [5].



Рис. 1.3 - Двухзвенная архитектура клиент-сервер

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

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

1. модель доступа к удаленным данным -- распределенное представление данных;

2. файл-сервер -- доступ к удаленной базе данных и файловым ресурсам;

3. сервер БД -- удаленное представление данных;

4. сервер приложений -- удаленное приложение.

Модель файл-сервер появилась раньше остальных. Это базовая модель для локальных сетей. Один компьютер в сети является сервером, который предоставляет доступ для других ПК к файлам (рис. 1.4). На клиентских ПК размещены 2 компонента: прикладной и представления [5].

Рис. 1.4 - Модель файл-сервер

Данная модель неэффективна так как, что при передаче большого количества информации возникает большая нагрузка на сеть.

Модель доступа к удаленным данным отличается от предыдущей модели. Компонент представления и прикладной компонент соединены на клиентском ПК. Запросы к БД осуществляются посредством языка SQL (рис. 1.5). Таким образом был унифицирован интерфейс клиент-сервер [5].

Рис. 1.5 - Модель доступа к удаленным данным

Следующая модель - модель сервера БД (рис. 1.6). Организовать данную модель стало возможным с появлением реляционных СУБД. Реализация модели сервера БД привела к уменьшению нагрузки на сеть, поскольку ядро СУБД расположено и функционирует на сервере, а прикладное ПО на клиенте. Протокол взаимодействия -- соответствующий диалект языка SQL.



Рис. 1.6 - Модель сервер БД

Заключительная модель - сервер приложений (рис.1.7). Прикладной компонент здесь был перенесён на отдельный сервер. Модель сервер приложений представляет трехзвенную архитектуру. Стоит отметить, что сетевое приложение может быть разделено на несколько частей, которые могут выполняться на разных ПК. Эти части приложения должны взаимодействовать между собой в строго определенном формате.

Рис. 1.7 - Модель сервер приложений

Соответственно, компоненты трехзвенной архитектуры распределены следующим образом:

1. Представление данных -- на стороне клиента.

2. Прикладной компонент -- выделенный сервер приложений.

3. Управление ресурсами -- на сервере БД, который и представляет запрашиваемые данные.

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



Рис. 1.8 - Многозвенная архитектура клиент-сервер

1.3 Сетевые сервисы на базе клиент-сервер

Клиент-серверная архитектура применяется в многочисленных сетевых технологиях, используемых для доступа к различным сетевым сервисам. Кратко рассмотрим некоторые типы таких сервисов (и серверов):

Web-серверы. Изначально представляли доступ к гипертекстовым документам по протоколу HTTP (Huper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в частности работу с бинарными файлами (изображения, мультимедиа и т.п.) [5].

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

Серверы баз данных. Серверы баз данных используются для обработки пользовательских запросов на языке SQL. При этом СУБД находится на сервере, к которому и подключаются клиентские приложения.

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

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

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

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

Почтовые серверы. Представляют услуги по отправке и получению электронных почтовых сообщений.

Серверы удаленного доступа (RAS). Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с помощью обычного модема [5].

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

1.4 Классы приложений клиент-сервер

В рамках общей структуры приложений клиент-сервер выполняемая работа может быть разделена между клиентом и сервером по-разному. Точная доля исполняемых операций и объем передаваемых по сети данных зависят от природы информации, содержащейся в базе данных, поддерживаемых типов приложений, доступности оборудования, которое может работать совместно, а также от характера использования данных в организации. В простейшем случае работает модель тонкий клиент (thin client) (рис.1.9 а). Это вариант, когда клиентское ПО максимально упрощено и представляет собой только интерфейсную часть, состоящую из форм ввода и просмотра данных. Тонкий клиент фактически отвечает только за презентацию данных, поэтому можно сказать, что он не умеет думать, и вся программная логика сосредоточена на стороне сервера. Есть и обратное решение -- толстый клиент (fat client) (рис.1.9 б). В противовес своему тонкому собрату, толстый клиент старается максимально облегчить работу сервера, например, реализует дополнительные бизнес-правила, сортирует полученные данные на клиентской стороне, выполняет вспомогательные расчеты, проверяет синтаксис инструкций SQL и т. п.

Рис. 1.9 - Классы приложений клиент-сервер

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

В последнее время все чаще используется еще один термин: «rich»-client. «Rich«-клиент своего рода компромисс между «толстым» и «тонким» клиентом. Как и «тонкий» клиент, «rich»-клиент также представляет графический интерфейс, описываемый уже средствами XML и включающий некоторую функциональность толстых клиентов (например интерфейс drag-and-drop, вкладки, множественные окна, выпадающие меню и т.п.)

Прикладная логика «rich»-клиента также реализована на сервере. Данные отправляются в стандартном формате обмена, на основе того же XML (протоколы SOAP, XML-RPC) и интерпретируются клиентом.

Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:

1. XAML (eXtensible Application Markup Language) -- разработан Microsoft, используется в приложениях на платформе .NET;

2. XUL (XML User Interface Language) -- стандарт, разработанный в рамках проекта Mozilla, используется, например, в почтовом клиенте Mozilla Thunderbird или браузере Mozilla Firefox;

3. Flex -- мультимедийная технология на основе XML, разработанная Macromedia/Adobe.

1.5 Предпосылки для появления архитектуры клиент-сервер на предприятии

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

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

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

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

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

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

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



2. Практическая реализация аутентификации приложения клиента на сервере MySQL

2.1 Достоинства MySQL

На сегодняшний день MySQL является одной из самых популярных СУБД, поскольку распространяется по лицензии GPL и является открытой. Немаловажным роль при выборе СУБД MySQL является простота развертывания и обслуживания. MySQL - кроссплатформенная СУБД, следовательно она может работать как на *nix подобных системах, так и на платформе Windows. MySQL может быть установлена как на серверной платформе Windows Server, так и на клиентских ОС.

Поскольку реализовывать механизм аутентификации пользователей предстоит для СУБД MySQL , то приведём некоторые её достоинства:

1. Масштабируемость и гибкость. Сервер баз данных MySQL обеспечивает максимальную масштабируемость, использует только 1 Мб памяти для запуска огромных хранилищ данных, содержащих терабайты информации. СУБД MySQL разработана с использованием языков C/C++ и оттестирована более чем на 23 платформах, среди которых Windows, Linux, FreeBSD, HP-UX, Mac OS X, OS/2, Solaris и др.Открытый код, который доступен для просмотра и модернизации всем желающим. Лицензия GPL («General Public License», общедоступная лицензия) позволяет постоянно улучшать программный продукт и быстро находить и устранять уязвимые места. Особенностью лицензии GPL является тот факт, что любой код, скомпилированный с GPL-кодом, попадает под GPL-лицензию, т.е. может свободно распространяться, и условием его распространения является предоставление исходных кодов [6, с. 21].

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

3. СУБД MySQL поддерживает API (Application Programming Interface) для C, C++, Eiffel, Java, Perl, PHP, Python, Ruby и Tcl. MySQL можно успешно применять как для построения Web-страниц с использованием Java, Perl, PHP, так и для работы прикладной программы, созданной с использованием Builder C++ или платформы .NET [6, с. 21].

4. Наличие встроенного сервера. СУБД MySQL может быть использована как с внешним сервером, поддерживающим соединение с локальной машиной и с удалённым хостом, так и в качестве встроенного сервера. Достаточно скомпилировать программу с библиотекой встроенного сервера, и приложение будет содержать в себе полноценную СУБД MySQL с возможностью создания баз данных, таблиц и осуществления запросов к ним.

5. Широкий выбор типов таблиц, в том числе и сторонних разработчиков, что позволяет реализовать оптимальную для решаемой задачи производительность и функциональность [6, с. 21].

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

7. Поддержка SQL - является ещё одной важной «чертой» системы. Это обеспечивает высокий уровень кроссплатформенности данных и кода, созданных с помощью MySQL. Благодаря чему вы можете спокойно перенести БД в любую другую современную СУБД, также поддерживающую язык структурированных запросов. А весь сохраненный код (хранимые процедуры, триггеры и запросы) можно применять на любой из этих платформ.

8. Надежная защита данных. Поскольку защита данных в компаниях стоит на первом месте, MySQL предлагает исключительные функции безопасности, которые обеспечивают абсолютную защиту данных. С точки зрения проверки подлинности базы данных MySQL предоставляет мощные механизмы для обеспечения доступа к серверу базы данных только авторизованным пользователям с возможностью блокировать пользователей вплоть до уровня клиентского компьютера. Также предоставляется поддержка SSH и SSL для обеспечения безопасного и надежного соединения. Функции шифрования и дешифрования данных гарантируют, что конфиденциальные данные защищены от несанкционированного просмотра. Наконец, утилиты резервного копирования и восстановления, предоставленные MySQL и поставщиками внешнего программного обеспечения, допускают полное логическое и физическое резервное копирование, а также полное восстановление и восстановление в определённый момент времени.

2.2 Технология ODBC

Наиболее универсальная на настоящий момент технология, посредством которой можно получить доступ к базам данных - ODBC -- Open Database Connectivity (Открытый интерфейс для подключения к базам данных). ODBC является одной из самых старых технологий для работы с базами данных, которые выпустила фирма Microsoft. Одной из основных причин разработки ODBC была необходимость предоставления программистам простого способа доступа к содержимому баз данных с минимальной ориентацией на какой-либо конкретный язык.

Основные принципы ODBC стандартны для Windows -- для выполнения работы используются соответствующие драйверы, содержащиеся в DLL (Dynamic Link Library, Библиотека динамической компоновки). Драйверы, которые могут оказаться необходимыми для работы, можно получить непосредственно от поставщика базы данных -- чаще всего прямо в пакете программ.

ODBC стандартизирует доступ к базе данных используя 2 метода:

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

2. Прикладные программы должны быть способны обратиться ко многим СУБД одновременно (через разные драйверы).

ODBC успешно решает эти проблемы следующим способом.

ODBC является интерфейсом уровня вызовов:

Чтобы решить проблему с тем, как прикладные программы обращаются ко многим СУБД, используя один и тот же исходный текст, существует стандарт CLI. ODBC содержит все функции в спецификации CLI и обеспечивает дополнительные функции, обычно требуемые прикладными программами.

ODBC определяет стандартный синтаксис SQL:

В дополнение к стандартному интерфейсу уровня обращения (вызова), ODBC определяет стандартный синтаксис SQL. Он базируется на спецификации X/Open SQL CAE. Если используемый ODBC синтаксис отличается от того, который применяет конкретная СУБД, производится преобразование на лету. Однако, такие преобразования редки потому, что большинство СУБД уже используют стандартный синтаксис языка SQL.

ODBC предоставляет Driver Manager для управления одновременным доступом к многим СУБД:

Хотя использование драйверов решает проблему одновременного доступа ко многим базам данных, код, необходимый, чтобы сделать это, может быть сложен. Прикладные программы которые разработаны, чтобы работать со всеми драйверами, не могут быть статически связаны с любыми драйверами. Вместо этого они должны загрузить драйверы во время выполнения и вызывать функции в них через таблицу указателей функций. Ситуация становится более сложной, если прикладная программа использует много драйверов сразу. Чтобы избавить программу от проблем с этим, ODBC предоставляет Driver Manager. Администратор драйверов (Driver Manager) осуществляет все функции ODBC и статически связан с прикладной программой или загружен ей во время выполнения. Таким образом, вызовы из прикладной программы функций ODBC по именам обрабатываются в Driver Manager вместо того, чтобы обращаться по указателю к каждому драйверу. ODBC предоставляет много возможностей СУБД, но не требует, чтобы каждый драйвер поддерживал их все.

Архитектура ODBC базируется на пяти компонентах (рис.2.1).

Рис. 2.1 - Архитектура ODBC

Рассмотрим компоненты архитектуры ODBC более подробно.

Приложение: приложение пользователя для подключении к базе данных MySQL использует ODBC API , который в свою очередь, связывается с диспетчером драйверов. Приложению пользователя всё равно, где хранятся данные, как они хранятся, и даже, как система настроена для доступа к данным. Он должен знать только Имя источника данных (DSN).

Ряд задач является общим для всех программ, независимо от того, как они используют ODBC. Эти задачи:

1. Выбор сервера (MySQL) и подключение к нему.

2. Передача SQL запроса.

3. Получение результатов (если они есть).

4. Обработка ошибок.

5. Обработка транзакции или её откат.

6. Отключение от сервера.

Самыми главными тут являются передача на рассмотрение инструкции SQL для выполнения и получение результатов запроса (если они есть).

Driver manager: driver Manager представляет собой библиотеку для подключения, которая управляет связью между прикладной программой и драйвером или драйверами [13]. Он делает:

1. Обработку Data Source Names (DSN).

2. Загрузку и выгрузку драйверов.

3. Обработку ODBC-обращения к функции или передачу вызова драйверу.

Драйвер ODBC: драйвер ODBC представляет собой библиотеку, которая реализует функции, поддерживаемые в ODBC API. Он обрабатывает вызовы функций ODBC, подает запросы SQL на сервер MySQL и возвращает результаты обратно в приложение пользователя. В случае необходимости, драйвер изменяет запрос пользовательского приложения таким образом, чтобы запрос соответствовал синтаксису MySQL [13].

DSN Configuration: файл конфигурации ODBC хранит драйвер и информацию о базе данных, необходимые для подключения к серверу. Он использует Driver Manager, чтобы определить, какой драйвер должен быть загружен в соответствии с DSN. Драйвер использует эту возможность для считывания параметров подключения на основе указанного источника данных.

MySQL Server: эта база данных используется в качестве источника данных (во время обработки запросов) и получателя данных (во время вставки и обновления).

2.3 Установка и настройка сервера MySQL

Установка и настройка портативного варианта базы данных MySQL 5.7.17 Community Server на Windows из zip архива [12].

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

Основные преимущества такого варианта инсталляции MySQL сервера могут быть в следующем:

1. портативность установки, т.е. вы сможете переносить и использовать MySQL сервер на других PC с Windows. Так же инсталляция не будет связана с системой и не будет прописываться в реестре. Однако, если вам не нужна именно портативная установка, то тогда, наверное, технически будет проще выполнить обычную для Windows установку при помощи MySQL Installer for Windows, который можно скачать на странице загрузки.

2. возможность иметь последую актуальную версию MySQL сервера. Так на момент написания диплома MySQL имеет версию 5.7.17, которая имеет существенные преимущества перед версией 5.6 по производительности и дополнительному функционалу.

3. независимая настройка базы данных MySQL под свои нужды и возможность использования дополнений и плагинов, входящих в полный дистрибутив MySQL 5.7.17 Community Server.

4. полезный опыт по ручной настройке базы данных MySQL, который даст вам неоспоримые преимущества при самостоятельном развертывании MySQL, т.к. по своей сути все настройки MySQL будут одинаковы как для Windows, так и для Linux OS.

Загрузить zip архив с дистрибутивом MySQL Community Server 5.7.17 (mysql-5.7.17-winx32-debug-test.zip) для выполнения portable установки можно с официального сайта, где в низу страницы представлены разные варианты дистрибутивов, в том числе и в формате zip архива. Так же для работы MySQL 5.7 в Windows необходимо, что бы в системы были установлены следующие библиотеки:

1. Microsoft .NET Framework 4 Client Profile

2. Visual C++ Redistributable for Visual Studio 2013

Загруженный zip архив с дистрибутивом MySQL сервера нужно распаковать в выбранную папку.

В дополнении к уже имеющимся каталогам нужно создать дополнительно в домашней директории MySQL сервера следующие каталоги:

1. data - каталог для файлов баз данных;

2. files - каталог для файлов, с которыми может работать MySQL сервер;

3. logs - каталог для логов сервера;

4. temp - каталог для временных файлов.

Эти директории были созданы самостоятельно вручную, т.к. MySQL сервер сам не создает директории. Позднее, пути к этим папкам будут указываться в конфигурационном файле my.ini.

Перед инициализацией MySQL сервера необходимо создать в корне его домашней директории конфигурационный файл my.ini и записать в него необходимые директивы. Файл my.ini является главным конфигурационным файлом MySQL сервера в Windows. Создать файл my.ini удобно путем копирования файла заготовки my-default.ini. Ниже приводиться содержимое файла my.ini с необходимыми настройками, которых достаточно для инициализации MySQL. Для более детальной настройки необходимо обращаться к документации MySQL сервера.

Пути в файле my.ini заданы исходя из того, что домашний каталог MySQL задан как "D:\m\mysql " директория.

[mysqld]

#кодировки сервера

character-set-server=utf8

collation-server=utf8_general_ci

#Временная зона

default-time-zone='+00:00'

#Выделение памяти под буфер innodb

#Для разработческого сервера достаточно 10% от RAM

innodb_buffer_pool_size = 512M

# Путь к домашней директории сервера

basedir = D:/m/mysql

#Путь к директории для файлов баз данных

datadir = D:/m/mysql/data

#Порт

port = 3306

#IP адрес который будет слушать сервер

bind-address=127.0.0.1

#Путь к директории для экспорта и импорта файлов сервером

secure-file-priv=D:/m/mysql/files

#LOG

#Отключить запись в системный лог

log_syslog=0

#Путь к файлу ошибок. Этот файл будет создан сервером

log_error=D:/m/mysql/logs/mysql-error.log

slow-query-log-file=D:/m/mysql/logs/mysql-slow.log

log_timestamps = UTC

# Блок выделения памяти для SQL запросов

join_buffer_size = 128M

sort_buffer_size = 2M

read_rnd_buffer_size = 2M

[mysqld-5.7]

sql_mode=TRADITIONAL

Когда все каталоги и файл my.ini созданы в домашней директории MySQL сервера, сделаем инициализацию MySQL. В результате инициализации MySQL сервера будут созданы все необходимые для его работы файлы, базы данных. Для инициализации MySQL необходимо запустить файл mysqld.exe передав ему параметр initialize. Затем в командной строке вводим команду:

>mysqld -initialize -console

Результатом вышеописанной команды будет инициализация MySQL сервера и создание пользователя root с первичным паролем. В MySQL 5.7 пользователю root присваивается пароль при инициализации, раньше в предыдущих версиях пароль был пустой. В командной строке видим все сообщения, выданные MySQL сервером в процессе его инициализации, которые будут выглядеть примерно следующим образом (рис. 2.2).

Рис. 2.2 - Инициализация сервера MySQL

В MySQL 5.7 пользователю root присваивается пароль при инициализации, раньше в предыдущих версиях пароль был пустой.

После инициализации выполняем запуск MySQL сервера, для этого набираем в командой строке:

>mysqld -console

В результате выполнения этой команды MySQL сервер будет запущен и в консоли будут выведены следующие сообщения от mysqld (рис. 2.3). В диспетчере задач Windows видим работающий процесс mysqld.exe, который и является MySQL сервером.



Рис. 2.3 - Запуск сервера MySQL

2.4 Установка и настройка Connector/ODBC

Для установки MySQL драйвера ODBC необходимо запустить mysql-connector-odbc-5.3.7-win32.msi.

После установки драйвера следует создать источник данных ODBC. Для этого запускаем: “Панель управления / Администрирование / Источники данных ODBC”. Переходим на закладку «Пользовательский DSN». Добавляем новый источник данных: в открывшемся окне находим MySQL ODBC 5.3 ANSI Driver и выбираем его. На рис. 2.4 показан интерфейс Connector/ODBC. Название источника данных (Data Source Name) указываем по своему усмотрению. Далее указываем данные необходимые для подключения к БД в нашем случае это: TCP/IP Server - localhost, port - 3306, имя пользователя - user и пароль - 1Rfk3byrF7VfKbyRf87. Нажав на кнопку Test проверяем наличие соединения с сервером.

Рис. 2.4 - Интерфейс Connector/ODBC

2.5 Основные уязвимости БД MySQL

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

1. Слабая аутентификация

2. Злоупотребление чрезмерными привилегиями доступа (Excessive Privilege Abuse)

3. Злоупотребление легитимными привилегиями доступа (Legitimate Privilege Abuse)

4. Превышение привилегий доступа (Privilege Elevation)

5. Слабый аудит (Weak Audit Trail)

6. Незащищенность резервных копий (Backup Data Exposure)

1. Злоупотребление чрезмерными привилегиями доступа (Excessive Privilege Abuse).

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

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

Наилучшим решением данной проблемы для снижения вероятности злоупотребления пользователями расширенными правами является ограничение до минимально возможных прав на выполнение SQL-запросов и операций с данными. Данная мера позволит отследить пользователей, которые пытались совершить действия не предусмотренные разрешёнными им привилегиями.

2.Злоупотребление легитимными привилегиями доступа.

Эта уязвимость относится к пользователям, которым обоснованно предоставлены расширенные привилегии, тем не менее данные пользователи используют свои права для несанкционированных действий. Как правило расширенные привилегии требуются пользователям, работающим с персональными данными. Если пользователь, имеющий расширенный список привилегий, становится жертвой какой-либо вредоносной программы, злоумышленник достаточно легко сможет получить доступ к защищённым данным [9].

3.Превышение привилегий доступа.

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

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

4. Слабый аудит.

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

5. Незащищенность резервных копий.

Достаточно часто в компаниях забывают о важности резервных копий. Компаниям следует предпринимать определенные действия по защите резервных копий, т.к. в базе данных может хранится конфиденциальная информация. Наибольшее распространение имеет оставление незащищенными и уязвимыми к краже носителей резервных копий. Если злоумышленник получит доступ к резервным копиям, компания рискует потерять не только конфиденциальные данные и интеллектуальную собственность, но и полностью прекратить свое существование [9].

6. Слабая аутентификация / Подбор пароля.

В большом числе компаний очень часто реализуются надёжные и эффективные методы защиты среды вокруг БД, но при этом не уделяется достаточно внимания механизму аутентификации пользователей. Если пароль является единственным элементом, защищающим данные, то степень безопасности зависит лишь от одного фактора, а именно от длины пароля. В компаниях нередки случаи, когда пользователям присваиваются слабые пароли [9].

Имеется несколько наиболее распространенных способов получения пользовательских паролей. Злоумышленник может произвести брутфорс, рассчитывая на подбор часто встречающихся комбинаций. При этом злоумышленник может использовать средства и методы для ускорения подбора пароля, например, радужные таблицы. Большой проблемой является, то, что пользователи халатно относятся к хранению своих учетных данных, а именно, сотрудники могут оставлять свои логины и пароли в легко доступных местах для третьих лиц, что позволит злоумышленнику получить логин и пароль без применения каких-либо усилий. Ещё одна достаточно распространенная проблема - хранение паролей в файлах с недостаточным уровнем защиты. Часто для упрощения работы администраторы создают скрипты, чтобы автоматизировать рутинные задачи. Эти скрипты могут содержать пароли или конфигурационные файлы, которые могут быть выявлены во время запуска скрипта. В последнее время злоумышленники стали использовать в своих целях социальную инженерию - технику, направленную на получение пароля пользователя, например, по средствам звонка злоумышленник просит сообщить учетные данные пользователя для устранения какой-либо неисправности. Данные атаки кажутся очень простыми, но тем не менее, они являются очень эффективными. И конечно, имеют место случаи, когда от поставщика остаются стандартные ученые данные, либо учетные записи с пустыми паролями. При оставлении стандартной учетной записи от поставщика и при использовании слабого механизма аутентификации злоумышленник практически без проблем может выполнить подключение к БД и завладеть ей.

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

2.6 Добавление пользователей и назначение привилегий

В MySQL для работы с данными БД необходимо создать пользователей и указать для них логин, пароль. После чего нужно назначить, созданным пользователям, соответствующие привилегии пользования данными БД. Правильное управление доступом пользователей к данным в БД является одним из важнейших факторов, влияющих на информационную безопасность. После того, как пользователь установил соединение, для каждого поступающего запроса, сервер проверяет достаточно ли у пользователя прав для его выполнения, основываясь на типе операции, требуемой для выполнения [7]. Имеется несколько моделей управления доступом:

1. MAC (Mandatory access control) - мандатное управление доступом, назначение прав доступа осуществляется посредством использования меток. Изменять данные метки может только администратор, обладающий определенными полномочиями.

2. DAC (Discretionary access control) - метод дискреционного контроля доступа, основан на списках управления доступа. Владелец объекта решает кто и с какими привилегиями имеет доступ к данным БД [11].

3. RBAC (Role-based access control) - ролевое управление доступом. Роль - набор прав доступа. Соответственно, пользователи получают доступ через назначенные им роли.

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

Привилегии (права) в MySQL делятся на три группы:

1. управление и изменение записей в таблицах базы данных;

2. управление структурой базы данных;

3. администрирование.

Рассмотрим более подробно каждую группу привилегий.

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

1. SELECT - осуществляет выборку записей из таблиц БД.

2. INSERT - добавляет новые записи в существующие таблицы.

3. UPDATE - обновление данных в таблицах.

4. DELETE - удаление данных из таблиц.

5. FILE - выборка, считывание и запись данных в файлах.

Управление структурой базы данных.

1. CREATE - создание новых БД и таблиц в БД.

2. ALTER - удаление и добавление полей из таблиц, редактирование существующих полей.

3. INDEX - разрешает по определённому условию удалять существующие поля.

4. DROP - удаление таблиц или БД.

5. CREAT - TEMPORARY TABLES - возможность создавать временные таблицы, которые хранятся во время сессии, а по завершению сессии они автоматически удаляются.

Привилегии, связанные с администрированием БД.

1. GRANT - создание новых пользователей и изменение прав у существующих.

2. SUPER - разрешает использовать команду "kill", то есть отключить другого пользователя от соединения с БД.

3. PROCESS - выполнение команды "processlist", которая показывает список всех соединений других пользователей с БД.

4. RELOAD - открытие и закрытие файлов журналов, считывание прав пользователей.

5. SHUTDOWN - прекращение работы сервера.

6. SHOW DATABASES - просмотр всех существующих БД.

7. LOCK TABLES - блокирование таблицы при соединении определённого пользователя.

8. EXECUTE - запуск хранимых процедур.

9. REPLICATION CLIENT - даёт право отследить местонахождение главного (master) и ведомых (slaves) серверов.

10. REPLICATION SLAVE - позволяет читать ведомым журнала ведущего сервера.

Например, добавление нового пользователя осуществляется следующим образом:

mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY '1Rfk3byrF7VfKbyRf87';

Таким образом был создан пользователь «user» с паролем «1Rfk3byrF7VfKbyRf87».

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

Далее произведём назначение привилегий для созданного пользователя «user».

mysql> GRANT SELECT,INSERT,ALTER,CREATE,INDEX ON mydb.* to `user'@'localhost';

После выполнения данной команды пользователю `user' были назначены соответствующие привилегии.

2.7 Плагины безопасности и аутентификации в MySQL

MySQL включает в себя несколько плагинов, которые реализуют функции безопасности.

1. Плагины для проверки подлинности попыток аутентификации клиентов при подключении к MySQL серверу. Плагины доступны для нескольких протоколов аутентификации.

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

3. Плагин «Keyring», обеспечивающий безопасное хранение конфиденциальной информации.

4. MySQL Enterprise Audit - применяет открытый аудит MySQL API, для того, чтобы производить мониторинг на основе политик и вести журнал подключения и запросов, выполняемых на серверах MySQL.

5. MySQL Enterprise Firewall - брандмауэр прикладного уровня, который позволяет администраторам баз данных разрешать или запрещать выполнение SQL -запросов на основе сопоставления со списком разрешённых SQL -запросов.

В MySQL доступны несколько плагинов аутентификации. Приведем некоторые из них:

1. Встроенный (native) механизм аутентификации через плагин mysql_native_password, который проверяет имя пользователя и его пароль в таблице mysql.user.

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

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

1. PAM Authentication Plugin (authentication_pam) -PAM-модуль, который позволяет пользователям проходить аутентификацию на сервере MySQL. PAM Unix и LDAP позволяет использовать стандартный интерфейс для доступа к БД, применяя различные методы аутентификации.

2. Windows Native Authentication Plugin - данный плагин аутентификации выполняет подлинности клиентских соединений, используя собственные службы Windows. Пользователи, которые вошли в Windows, могут подключиться к БД без указания дополнительного пароля. По умолчанию, для аутентификации используется протокол Kerberos, если kerberos недоступен, то применяется протокол NTML.

2.8 Реализация механизма аутентификации пользователя на сервере MySQL

При подключении приложения к базе данных можно использовать технологии ADO или ADO.Net [4, с. 59]. Уровни ПО для подключения к данным (рис. 2.5).

Рис. 2.5 - Уровни ПО для подключения к данным

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

Например: провайдеру нужен адрес сервера (или путь к файлу данных) для подключения. Этот параметр часто называют "сервер" ("Server") или "Источник данных"("Data Source") [15]. Значение, указанное для этого параметра в строке подключения передается провайдеру, и, следовательно, провайдер знает теперь к чему необходимо подключиться. Есть несколько основных правил, применяемых для написания строки подключения, т.е., то каким образом будут сконфигурированы значения в строке подключения. При создании строки подключения используется строковый тип данных. Итак, основные принципы:

1. строка подключения состоит из ряда ключевых слов - пар значений, разделенных точкой с запятой (;)[15].;

2. знак равенства (=) соединяет каждое ключевое слово и его значение, например: Key1 = Значение1; Key2 = значение2; Key3 = Value3

На рис. 2.6 приведем блок-схему для программы подключения пользователя к БД.

Рис. 2.6 - Блок-схема программы для подключения пользователя к БД

Для подключения и работы с сервером MySQL была написана программа на языке C#. Данная программа написана с использованием Microsoft Visual Studio 2012.

Перейдём к строке подключения, представленной в дипломной работе.

Для начала подключили необходимое пространство имен - System.Data.Odbc [14]. Данное пространство имен является поставщиком данных для ODBC.

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

string MyConString = "DRIVER={MySQL ODBC 5.3 ANSI Driver};" +

"SERVER=localhost;" +

"DATABASE=" + bd + ";" +

"UID=" + us + ";" +

"PASSWORD=" + passw + ";" +

"OPTION=3";

В таблице 2.1 представлены параметры, используемые для подключения и значения, соответствующие им:

Таблица 2.1 Параметры строки подключения

Ниже в таблице 2.2 приведены значения для параметра OPTION.

Если требуется несколько опций, то можно сложить перечисленные параметры. Например, OPTION=12(4+8) делает отладку без ограничений пакетов.



Таблица 2.2 Значения для параметра OPTION



Далее нужно объявить класс подключения к БД OdbcConnection. Именно через этот класс в дальнейшем и будет происходить вся работа с БД.

OdbcConnection MyConnection = new OdbcConnection(MyConString);

MyConString для класса OdbcConnection будет являться входящим параметром.

MyConnection.Open() - устанавливает соединение с БД, при успешном соединении появляется сообщение об успешном подключении к БД, при возникновении какой-либо ошибки, появляется окно, сообщающее об этой ошибке.

MyConnection.Close() - закрывает соединение.Если пользователь указал верные данные для подключения, то можно увидеть сообщение - !!!SUCCESS, connected successfully!!!, а также видим параметры, с которыми произошло подключение, а именно: строку подключения, базу данных, время ожидания ответа сервера, драйвер, используемый для подключения и версию версию сервера MySQL (рис. 2.7).



Рис. 2.7 - Успешное подключение пользователя к БД

В случае, если пользователь указал неверные данные, то видим сообщение об ошибке, которое указывает нам на то, что невозможно подключиться пользователю `User' (рис. 2.8).

Рис. 2.8 - Неудачное подключение пользователя к БД



2.9 Применение разработанного модуля в программах автоматизации предприятия

Разработанный модуль на языке C# необходимо интегрировать в существующие программы автоматизации предприятия (рис.2.9, 2.10).

Для дальнейшей компиляции приложение на C# представляется в виде DLL - файла, что позволит использовать разработанный нами модуль аутентификации в различных средах разработки. Далее необходимо создать COM-объект, который позволит работать нашему модулю в программах автоматизации, написанных на Delphi.

...