Файл: Курсовая работа по дисциплине Разработка и эксплуатация защищенных автоматизированных систем (наименование дисциплины).docx

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 30.11.2023

Просмотров: 3177

Скачиваний: 10

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Введение

1 Исследование предметной области и разработка требований к создаваемой защищенной автоматизированной информационной системе персональных данных

1.1 Исследование области функционирования создаваемого объекта защищенной информатизации

1.1.4 Построение и анализ модели защиты информации в ходе функционирования объекта защищенной автоматизации

1.2 Оценка угроз безопасности информации, создаваемой информационной системы

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

1.4 Разработка требований к создаваемой защищенной автоматизированной системе

Выводы по первой главе

2 Проектирование, разработка и защита создаваемой защищенной автоматизированной системы персональных данных

2.1 Построение и анализ усовершенствованной модели защиты информации в ходе функционирования объекта защищенной автоматизации

2.2 Проектирование, реализация и защита базы данных создаваемой защищенной автоматизированной системы персональных данных

2.3 Логическая схема сети с подключенными программными (программно-аппаратными) средствами защиты информации создаваемой системы

Выводы по второй главе

Заключение

Список литературы

Приложения

Приложение А





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 – Связи между сущностями

Родительская сущность

Дочерняя сущность

Имя связи

Тип связи

Семантика связи от родительской сущности к дочерней

Банк

Сотрудник

БАНК-СОТР

НИД 1:М

Направляет

Эксперт

Тестирование

ЭКСП-ТЕСТ

1:М

Проводит

Тестирование

Вопрос

ТЕСТ-ВОПР

НИД 1:М

Состоит из

Вопрос

Вариант ответа

ВОПР-ВАР_ОТВ

1:М

Содержит

Сотрудник

Ответ

сотрудника

СОТР-ОТВ_СОТР

1:М

Дает

Вопрос

Ответ

сотрудника

ВОПР-ОТВ_СОТР

1:М

Принимает

Тестирование

Результат

ТЕСТ-РЕЗ

1:М

Имеет

Сотрудник

Результат

СОТР_РЕЗ

НИД 1:М

Получает


На основе данных из этой таблицы была сформирована ER-диаграмма, представленная на рисунке 2.4.

Рисунок 2.4 – ER-диаграмма базы данных тестирования

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

  1. каждый банк обладает уникальным идентификатором;

  2. каждый банк может направлять сотрудников;

  3. каждый сотрудник обладает уникальным идентификатором;

  4. каждый эксперт обладает уникальным идентификатором;

  5. каждый эксперт проводит тестирование;

  6. каждый сотрудник проходит тестирование;

  7. каждое тестирование обладает уникальным идентификатором;

  8. тестирование состоит из вопросов;

  9. каждый вопрос обладает уникальным идентификатором;

  10. вопрос может содержать варианты ответа;

  11. каждый вариант ответа обладает уникальным идентификатором;

  12. сотрудник на каждый вопрос дает ответ;

  13. каждый ответ обладает уникальным идентификатором;

  14. каждое тестирование имеет результат;

  15. каждый сотрудник имеет результат тестирования;

  16. каждый результат обладает уникальным идентификатором.



Для каждой сущности были определены первичные ключи, на основе следующих требований:

  1. атрибуты первичного ключа не могут принимать неопределенных значений;

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

  3. количество атрибутов в первичном ключе должно быть минимальным.

В результате была сформирована KB-модель, которая представлена на рисунке 2.5.

Рисунок 2.5 – КВ-модель базы данных тестирования

знаний кредитных инспекторов
В таблице 2.3 отображены атрибуты выявленных ранее сущностей. Основные функциональные зависимости отражены в таблице 2.4.
Таблица 2.3 – Атрибуты сущностей

Имя сущности

Наименование атрибута

Ключ

Банк

id_банка

PK

Название_банка




Сотрудник

id_сотрудника

PK

Фамилия_сотрудника




Имя_сотрудника




Отчество_сотрудника




Пол_сотрудника




Телефон_сотрудника




Email_сотрудника




Дата_рождения_сотрудника




Должность_сотрудника




id_банка

FK



Окончание таблицы 2.3

Имя сущности

Наименование атрибута

Ключ

Эксперт

id_эксперта

PK

Фамилия_эксперта




Имя_эксперта




Отчество_эксперта




Телефон_эксперта




Email_эксперта




Тестирование

id_тестирования

PK

Название_тестирования




Количество_вопросов




Количество_попыток




Минут_на_тест




id_эксперта

FK

Вопрос

id_вопроса

PK

Текст_вопроса




Открытый_тип




id_тестирования

FK

Вариант ответа

id_варианта_ответа

PK

id_вопроса

FK

Текст_ответа




Правильность_ответа




Ответ сотрудника

id_ответа

PK

id_сотрудника

FK

id_вопроса

FK

Текст_ответа




Результат

id_результата

PK

id_сотрудника

FK

id_тестирования

FK

Текст_результата




Дата_результата




Номер_сертификата






Таблица 2.4 – Функциональная зависимость

Детерминанта

Функциональная часть

id_банка

Название_банка

id_сотрудника

Фамилия_сотрудника, Имя_сотрудника, Отчество_сотрудника, Пол_сотрудника, Телефон_сотрудника, Email_сотрудника, Дата_рождения_сотрудника, Должность_сотрудника

id_тестирования

Название_тестирования, Количество_вопросов, Количество_попыток, Минут_на_тест

id_вопроса

Текст_вопроса, Открытый_тип

id_ответа

Текст_ответа

id_варианта_ответа

Текст_ответа, Правильность_ответа

id_результата

Текст_результата, Дата_результата, Номер_сертификата


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

Рисунок 2.6 – FA-модель базы данных тестирования

знаний кредитных инспекторов

2.2.2 Проектирование физического уровня модели данных


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

Различают два подуровня физического уровня модели данных:

  • Т-модель (Transformation Model) - трансформационная модель;

  • модель DBMS (Database-Management System) – модель СУБД.

Для построения трансформационной модели необходимо определить домены атрибутов сущностей, области их допустимых значений, а также типы данных. В таблице 2.5 отображены необходимые данные и примеры значений, используемые в базе данных. Домены определены в таблице 2.6.
Таблица 2.5 – Домены атрибутов сущностей

Шифр домена

Наименование

домена

Определение домена

Тип данных

Пример

значения

D1

Порядковый номер

Целое число, принимает уникальные значения

int

10

D2

Дата

ГГГГ-ММ-ДД, где ГГГГ – четыре цифры, год (от 0001 до 9999), ММ – две цифры, месяц (от 01 до 12), ДД – две цифры, число (от 01 до 31)

date

1970-01-01

D3

Дата

ГГГГ-ММ-ДД чч:мм:сс, где ГГГГ – четыре цифры, год (от 0001 до 9999), ММ – две цифры, месяц (от 01 до 12), ДД – две цифры, число (от 01 до 31), чч – две цифры, час (от 00 до 23), мм – две

datetime

1970-01-01 00:00:00