Разработка защищенной автоматизированной информационной системы те-стирования знаний кредитных инспекторов в коммерческом банке. Курсовая_Шевченко_БАСО-03-18. Курсовая работа по дисциплине Разработка и эксплуатация защищенных автоматизированных систем (наименование дисциплины)
 Скачать 2.54 Mb.
|
2.2 Проектирование, реализация и защита базы данных создаваемой защищенной автоматизированной системы персональных данных2.2.1 Проектирование логического уровня модели данныхВ качестве метода проектирования базы данных (БД) решено использовать метод семантического моделирования данных (сущность-связь) в нотации IDEF1X, являющейся подмножеством SADT методологии. Инструментальным средством реализации метода семантического моделирования данных выбрано CASE-средство CA ERwin Data Modeler, в котором уровни представления модели данных разделены на логический и физический. Логический уровень модели данных является универсальным и никак не связан с конкретной реализацией СУБД. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. В CA ERwin Data Modeler различают 3 подуровня логического уровня модели данных, отличающиеся по глубине представления информации о данных: 1) ER-диаграмма – диаграмма «Сущность-связь»; 2) KB-модель – модель данных, основанная на ключах; 3) FA-модель – полная атрибутивная модель. Полученные в результате исследования предметной области данные о сущностях и их определения представлены в таблице 2.1. Таблица 2.1 – Сущности и их определения
Данные о выявленных связях между сущностями, полученные в результате многоаспектного анализа предметной области, отображены в таблице 2.2. Таблица 2.2 – Связи между сущностями
На основе данных из этой таблицы была сформирована ER-диаграмма, представленная на рисунке 2.4.  Рисунок 2.4 – ER-диаграмма базы данных тестирования знаний кредитных инспекторов Для определения первичных и внешних ключей сущностей в результате анализа предметной области были выявлены следующие основные закономерности: каждый банк обладает уникальным идентификатором; каждый банк может направлять сотрудников; каждый сотрудник обладает уникальным идентификатором; каждый эксперт обладает уникальным идентификатором; каждый эксперт проводит тестирование; каждый сотрудник проходит тестирование; каждое тестирование обладает уникальным идентификатором; тестирование состоит из вопросов; каждый вопрос обладает уникальным идентификатором; вопрос может содержать варианты ответа; каждый вариант ответа обладает уникальным идентификатором; сотрудник на каждый вопрос дает ответ; каждый ответ обладает уникальным идентификатором; каждое тестирование имеет результат; каждый сотрудник имеет результат тестирования; каждый результат обладает уникальным идентификатором. Для каждой сущности были определены первичные ключи, на основе следующих требований: атрибуты первичного ключа не могут принимать неопределенных значений; атрибуты первичного ключа должны однозначно идентифицировать экземпляр сущности; количество атрибутов в первичном ключе должно быть минимальным. В результате была сформирована KB-модель, которая представлена на рисунке 2.5.  Рисунок 2.5 – КВ-модель базы данных тестирования знаний кредитных инспекторов В таблице 2.3 отображены атрибуты выявленных ранее сущностей. Основные функциональные зависимости отражены в таблице 2.4. Таблица 2.3 – Атрибуты сущностей
Окончание таблицы 2.3
Таблица 2.4 – Функциональная зависимость
В результате на логическом уровне представления данных была сформирована FA-модель предметной области, представленная на рисунке 2.6.  Рисунок 2.6 – FA-модель базы данных тестирования знаний кредитных инспекторов 2.2.2 Проектирование физического уровня модели данныхФизическая модель данных, в отличии от логической, ориентирована на конкретную СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Различают два подуровня физического уровня модели данных: Т-модель (Transformation Model) - трансформационная модель; модель DBMS (Database-Management System) – модель СУБД. Для построения трансформационной модели необходимо определить домены атрибутов сущностей, области их допустимых значений, а также типы данных. В таблице 2.5 отображены необходимые данные и примеры значений, используемые в базе данных. Домены определены в таблице 2.6. Таблица 2.5 – Домены атрибутов сущностей
Окончание таблицы 2.5
Таблица 2.6 – Поля таблиц, их описание и домены
Окончание таблицы 2.6
В результате была сформирована трансформационная модель, ориентированная на формат выбранной СУБД и включающая все сущности, атрибуты, их типы данных, ограничения контроля целостности и согласованности. Результат представлен на рисунке 2.7.  Рисунок 2.7 – Т-модель базы данных тестирования знаний кредитных инспекторов Далее была разработана DBMS-модель в виде SQL-кода, представленного в приложении А. Его реализация позволила сформировать и построить системный каталог БД MS SQL Server. 2.2.3 Реализация модели данных в СУБД (MS SQL Server)Реализация модели данных будет происходить по средству передачи (в режиме прямого проектирования) схемы автоматизированной информационной системы тестирования знаний кредитных инспекторов в СУБД MS SQL Server 2019, а также заполнением данными с помощью файла Microsoft Excel 97-2003. На основе разработанной в CA ERWin DM физической модели данных выполним автоматическую генерацию системного каталога базы данных тестирования знаний кредитных инспекторов (БДТЗКИ) на сервере SQL Server 2019. Здесь особенностью является то, что до осуществления передачи модели базы данных из CA ERWin DM на сервер там должна быть заранее создана пустая база данных. Процесс создания такой пустой базы данных с именем «База данных тестирования знаний кредитных инспекторов» показан на рисунках 2.8-2.10.  Рисунок 2.8 – Переход к созданию новой базы данных  Рисунок 2.9 – Создание БДТЗКИ  Рисунок 2.10 – Системный каталог баз данных Как видно из рисунка 2.10, созданная нами база данных отображается в системном каталоге, следовательно, можно сделать вывод, что процесс создания был выполнен успешно. Процесс генерации схемы базы данных из модели данных называется прямым проектированием (Forward Engineering). При генерации схемы ERwin Data Modeler создает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие объекты, доступные для выбранной СУБД. В результате мы получаем SQL-скрипт создания схемы. Процесс создания и генерации схемы продемонстрирован на рисунках 2.11-2.12.  Рисунок 2.11 – Переход к генерации схемы  Рисунок 2.12 – SQL-скрипт создания схемы После выполнения полученного скрипта убедимся в его корректности и проверим наличие созданных таблиц. Как видно из рисунка 2.13, в системном каталоге отображаются все таблицы, следовательно, можно сделать вывод, что скрипт выполнился успешно.  Рисунок 2.13 – Список таблиц в БДТЗКИ На основе полученных таблиц создадим диаграмму базы данных. Полученная диаграмма представлена на рисунке 2.14.  Рисунок 2.14 – Диаграмма БДТЗКИ Далее заполним базу данных путем импорта данных из файла Microsoft Excel. Для каждой таблицы был создан лист Excel, заполненный соответствующими данными. Пример такого листа для таблицы Тестирование представлен на рисунке 2.15.  Рисунок 2.15 – Данные для таблицы Тестирование Далее произведём импорт данных из файла Excel в базу данных БДТЗКИ. Процесс осуществления импорта данных представлен на рисунках 2.16-2.18.  Рисунок 2.16 – Переход к импорту данных  Рисунок 2.16 – Выбор файла для импорта данных  Рисунок 2.17 – Выбор назначения импорта данных  Рисунок 2.18 – Выбор таблиц для импорта данных После осуществления процедуры импорта данных убедимся, что все прошло успешно. Для этого выведем все данные из таблицы Тестирование. Как видно из рисунка 2.19, в таблице Сотрудник содержатся те же данные, что и в исходном Excel-файле, следовательно, можно сделать вывод, что импорт данных прошел успешно.  Рисунок 2.19 – Выборка данных из таблицы Тестирование 2.2.4 Построение системы защиты базы данныхСоздание регистрационных имен, имен пользователей и ролей в базе данных С помощью инструкции языка Transact-SQL создадим регистрационные имена main_admin и user1 с соответствующими паролями p34xkwFo и 3C78snyr в БДТЗКИ. После реализации регистрационных имен проверим их наличие с помощью системного каталога. Процесс и результат создания регистрационных имен представлены на рисунках 2.20-2.21.  Рисунок 2.20 – Создание регистрационных имен main_admin и user1  Рисунок 2.21 – Наличие созданных регистрационных имен в системном каталоге Как видно из рисунка 2.21, регистрационные имена были успешно созданы. Далее для полученных выше регистрационных имен создадим с помощью инструкций языка T-SQL соответствующие имена пользователей Admin111 и User111. После создания пользователей проверим их наличие с помощью системного каталога. Процесс и результат создания представлен на рисунках 2.22-2.23.  Рисунок 2.22 – Создание имен пользователей Admin111 и User111  Рисунок 2.23 – Наличие созданных имен пользователей в системном каталоге Как видно из рисунка 2.23, имена пользователей были успешно созданы. Теперь создадим две новые определяемые пользователем роли базы данных AdminRole и UserRole, после чего проверим их наличие с помощью системного каталога и отобразим информацию о полученных ролях и их членах. Процесс и результат создания представлен на рисунках 2.24-2.25.  Рисунок 2.24 – Создание ролей AdminRole и UserRole  Рисунок 2.25 – Наличие созданных ролей AdminRole и UserRole в системном каталоге Как видно из рисунка 2.25, роли AdminRole и UserRole были успешно созданы. Выдача разрешений Для реализации разрешений воспользуемся инструкциями языка Transact-SQL. Используя инструкцию GRANT, предоставим пользователю Admin111 разрешение на создание таблиц, а также на обновление столбцов и вставку строк в столбцы таблиц Эксперт, Тестирование, Вопрос и Вариант_ответа, а пользователю User111 – разрешение на считывание значений столбцов таблицы Результат. Код запроса для реализации разрешений представлен на рисунке 2.26.  Рисунок 2.26 – Реализация разрешений для пользователей Admin111 и User111 Обратимся к свойствам пользователей Admin111 и User111 и убедимся, что разрешения были успешно предоставлены. Разрешения, имеющиеся у пользователей Admin111 и User111 представлены на рисунках 2.27-2.31.  Рисунок 2.27 – Разрешения пользователя Admin111 для таблицы Вариант_ответа  Рисунок 2.28 – Разрешения пользователя Admin111 для таблицы Вопрос  Рисунок 2.29 – Разрешения пользователя Admin111 для таблицы Тестирование  Рисунок 2.30 – Разрешения пользователя Admin111 для таблицы Эксперт  Рисунок 2.31 – Разрешения пользователя User111 для таблицы Результат Далее с помощью инструкции DENY запретим пользователю User111 считывать значения из таблицы Вариант_ответа. Для этого выполним запрос, представленный на рисунке 2.32.  Рисунок 2.32 – Реализация запрета для пользователя User111 Обратимся к свойствам пользователя User111 и убедимся, что запрет был успешно установлен. Как видно из рисунка 2.33, пользователь User111 не может считывать значения столбцов таблицы Вариант_ответа.  Рисунок 2.33 – Запрет пользователя User111 Шифрование базы данных Одним из способов шифрования данных в SQL Server является прозрачное шифрование. Шифрование файлов базы данных выполняется на уровне страницы. Страницы в зашифрованной базе данных шифруются до записи на диск и дешифруются при чтении в память. Прозрачное шифрование данных не увеличивает размер зашифрованной базы данных. Чтобы зашифровать базу данных способом прозрачного шифрования, необходимо выполнить следующие шаги: создать главный ключ; создать сертификат, защищенный главным ключом; создать ключ шифрования БД и защитить его с помощью сертификата; включить шифрование БД. Кроме этого, при использовании прозрачного шифрования необходимо создать резервные копии сертификата и связанного с ним ключа. Они потребуются в случае, если сертификат становится недоступным или подключение базы данных происходит на другом сервере. Без сертификата и ключа получить доступ к базе данных будет невозможно. Приступим к шифрованию базы данных. Прежде всего необходимо создать главный ключ базы данных. Для этого выполним запрос, код которого представлен на рисунке 2.34.  Рисунок 2.34 – Создание главного ключа базы данных Далее создадим резервную копию главного ключа и сохраним его в файле masterkey.mk. Для этого выполним запрос, код которого представлен на рисунке 2.35.  Рисунок 2.35 – Создание резервной копии главного ключа базы данных Далее создадим сертификат, защищенный главным ключом. Для этого выполним запрос, код которого представлен на рисунке 2.36.  Рисунок 2.36 – Создание сертификата Теперь создадим резервную сертификата и сохраним его в файле credit_cert.cer. Для этого выполним запрос, код которого представлен на рисунке 2.37.  Рисунок 2.37 – Создание резервной копии сертификата Далее создадим ключ шифрования, защищенный сертификатом, и включим шифрование базы данных БЗТЗКИ. Для этого выполним запрос, код которого представлен на рисунке 2.38.  Рисунок 2.38 – Шифрование базы данных БДТЗКИ Перейдем в свойства базы данных БДТЗКИ и убедимся, что шифрование включено. Как видно из рисунка 2.39, шифрование базы данных БДТЗКИ включено.  Рисунок 2.39 – Свойства БДТЗКИ |