36
смешанная организация ИБ.
Файловая организация ИБ нам не подходит, потому что локальное разме-
щение базы на компьютере с последующим расшариванием средствами MS
Windows будет уменьшать скорость обработки запросов. Смешанная организа-
ция подразумевает распределенное хранение базы данных на нескольких серве-
рах с настроенной репликацией. Такое решение используется для работы в рас-
пределенных системах удаленных территориально офисов. Интегрированный
способ организации ИБ подойдет наилучшим образом, как лучший способ хра-
нения взаимосвязанных данных при минимальной избыточности, позволяющей
их использовать оптимальным образом в любых приложениях, обеспечивая не-
зависимость данных от программы. Для хранения данных будет использоваться
СУБД.
Модель логической структуры базы данных выбрана реляционная, как
позволяющая быстро сформировывать связи между таблицами для построения
запроса, затем разорвать их для построения другого запроса. Время выполнения
запроса в этой модели выше, чем при использовании других (сетевой или иерар-
хической).
Исходные сведения будем получать из документов:
электронное письмо от сотрудника компании с описанием неисправно-
сти на неформальном языке;
регламент работы службы технической поддержки;
заявка пользователя на неформальном языке;
письма, регламентирующие изменения ответственных по классифици-
рованным направлениям инцидентам и новым направлениям.
Результаты отображаются в отчетах. Например, отчет о заявках, посту-
пивших за предыдущий месяц, отчет об открытых заявках на текущий момент.
37
Обоснование проектных решений по программному обеспечению
Программное обеспечение вычислительной системы (ПО, software) - это
совокупность программ, описаний и инструкций по их применению, позволяю-
щая использовать вычислительную систему как универсальную систему для хра-
нения, обработки и обмена информацией.
В компании принят корпоративный стандарт – программное обеспечение
Microsoft. Операционные системы пользователей – Microsoft Windows 10. Элек-
тронная почта обрабатывается сотрудниками компании в MS Outlook разных
версий (от 2013 до 2019).
Для серверной части была выбрана операционная система Centos
7.7.1908. По следующим причинам:
длительность поддержки – 10 лет;
устранение уязвимостей в приемлемый срок;
стабильность работы;
не требовательна к ресурсам;
наличие пакетов установки OTRS.
К СУБД предъявляется очень много требований, которые не постоянны и
с течением времени и с развитием проекта меняются. Будем оценивать варианты
по этапам:
оценка на предмет пригодности на качественном уровне;
оценка технических характеристик;
оценка производительности.
Считаю, что нужно обращать внимание на дату появления продукта, как
показатель «благополучия», так же следует обратить внимание на динамику раз-
вития, объем продаж (или скачиваний для бесплатного продукта). На стоимость
в основном влияет вид программного продукта, число поддерживаемых пользо-
вателей и фирма - разработчик.
38
Оценку производительности я буду использовать полученную с ресурса
«The Open Source Database Benchmark», где расчет ведется с помощью тестов из
набора AS3AP (ANSI SQL Standard Scalable and Portable). [19]
В таблице 6 представлена сравнительная таблица самых распространен-
ных СУБД.
Таблица 6
Сравнительная таблица распространенных СУБД
Показатель
Microsoft SQL
Server
MySQL
PostgreSQL
Поддерживаемые
операционные си-
стемы
Microsoft Win-
dows, Linux, Unix,
Mac
Microsoft Win-
dows, Linux,
Unix, Mac
Условия
лицензирования
Коммерческий
продукт. Есть
бесплатная вер-
сия
Коммерческая
лицензия и GNU
Лицензия BSD
Наличие драйверов
ODBC, JDBC,
ADO.NET
Да
Да
Да
Возможность писать
хранимые функции
на
разных языках
программирования
Да, но нужно
скомпилировать
код в библиотеку
Нет (кроме C и
Да
Аутентификация
Средствами БД и
Средствами БД
Много разных
Методов, вклю-
чая средствами
БД и
Поддержка
рекурсивных запро-
сов
Да
Нет
Да
Производительность
планировщика за-
просов для сложных
запросов
Средняя
Очень хорошая
Плохая
39
В качестве СУБД будет использован PostgreSQL версии 10.11.
PostgreSQL — СУБД с открытым исходным кодом, основой которого был код,
написанный в Беркли. Она поддерживает большую часть стандарта SQL и пред-
лагает множество современных функций:
сложные запросы;
внешние ключи;
триггеры;
изменяемые представления;
транзакционная целостность;
многоверсионность.
Севере СУБД будет располагаться на одном сервере с OTRS. [7,8]
При выборе средства проектирования был выбран Perl 5.16 в связи с тем,
что исходный программный код OTRS выполнен именно на этом языке, также в
связи с наличием у администратора опыта написания скриптов на данном языке
программирования. Он довольно распространен и в дальнейшем будет не сложно
найти программиста под возникающие новые задачи. Язык имеет открытую ар-
хитектуру и активно развивается, будет легко разработать графический интер-
фейс в виде HTML страницы, чего не могут позволить такие распространенные
языки программирования, как Borland C++ или Microsoft Visual C++. [15,16]
Обоснование проектных решений по техническому обеспечению
Техническое обеспечение (ТО) информационных систем — это совокуп-
ность технических средств, обеспечивающих работу информационной системы,
соответствующей документации на эти средства и технологических процессов.
Для работы системы в рамках дорабатываемой ИС потребуются следую-
щие элементы ТО:
Единый сервер. На этом сервере находится система OTRS, почтовый и
сервер БД.
40
ПК-пользователя (рабочая станция) – это пользовательский ПК, посред-
ством которого будут создаваться заявки через отправку письма с описание про-
блемы на почтовый ящик горячей линии.
ПК-инженера (рабочая станция) – это пользовательский ПК, на котором
ведется обработка заявок и их распределение.
Средства организации ЛВС – активные (маршрутизатор, коммутатор,
шлюз и т.д.) и пассивные (сегменты ЛВС, коммутационные розетки и т.д.).
После анализа критериев по серверному оборудованию было принято ре-
шение перенести всё ПО в облако. Был выбран сервис Yandex Compute Cloud.
Параметры сервера настраиваются в зависимости от потребностей и могут быть
изменены в любой момент времени. Помимо этого, отпадает необходимость в
резервном копировании всей системы, обеспечении бесперебойного питания.
[14]
Согласно корпоративному стандарту для ПК-пользователя и ПК-инже-
нера основными критерием выбора оборудования будет утвержденный список
конфигураций:
Core i3 xxx /8Gb/480Gb SSD/Монитор 24''
INTEL Pentium Gold G5400 3.7Ghz /8Gb/240Gb SSD/Монитор 21.5"
Для средств организации ЛВС критерием выбора должны быть тип ка-
беля и пропускная способность. На данный момент по результатам анализа сете-
вого трафика сеть загружена мене чем на 20%. Ежеминутный опрос почтового
сервера, загрузка веб интерфейса OTRS не дадут существенной нагрузки на сеть,
поэтому пропускной способности имеющейся сетевой инфраструктуры хватит с
запасом. При используемых коммутаторах внутренняя сеть работает на скоро-
стях до 1Gbps. Используемых АПКШ «Континент» имеет такую же пропускную
способность.
Вывод: В первой главе дипломного проекта отражена аналитическая
часть, в ней была представлена технико-экономическая характеристика ООО
«Сфера ИТ», описан процесс регистрации и обработки заявок на техническую
поддержку клиентов, приведена характеристика комплекса задач, требующих
41
решения, обоснование необходимости автоматизации описанного процесса.
Проведен анализ существующих программных и технических решений, обосно-
вание выбора определенных решений и выбор стратегии автоматизации про-
цесса регистрации, обработки и учета заявок на техническую поддержку от кли-
ентов.
42
2. Проектная часть
2.1. Разработка проекта автоматизации
Этапы жизненного цикла проекта автоматизации
Жизненный цикл (далее – ЖЦ) проекта автоматизации регламентируется
разными моделями и стандартами. Основные из интерациональных это: MSF,
RUP, COBIT, XP.
Стандарт COBIT сразу отбрасываем, он не подходят под мои цели, так
как используется для проведения аудита и стратегического планирования ИС и
IT инфраструктуры в целом. Обобщим основные характеристики в таблицу –
таблица 7.
Таблица 7
Основные показатели стандартов ЖЦ ИС
Стандарт
Команда,
чел.
Соответ-
ствие стан-
дартам
Допустимые
технологии
и инстру-
менты
Удобство
модифика-
ции и сопро-
вождения
MSF
адаптируема
любые
Удобно
RUP
стандарты
UML и
продукты
Удобно (RUP)
XP
нет
любые
Сложно
Выбор пал на Microsoft Solutions Framework (MSF) как наиболее сбалан-
сированную технологию, наиболее гибкую и удобную.
В идеологии MSF существует 5 стадий жизненного цикла ИС, которые в
понятии MSF называют фазами. Первый из них это Фаза выработки концепции.
Целью данной фазы является выработка единого видения, через которую проис-
ходит сплочение проектной группы. Команда должно делиться на 6 участников,
у каждого своя роль в проекте. Роли, отведенные участникам – кластеры: Управ-
ление продуктом, Управление программой, Разработка, Удовлетворение потре-
бителя, Тестирование, Управление выпуском. В моём проекте задачи кластеров
43
объединены и расформированы на трех ответственных лиц. Итогом этапа явля-
ется подбор ответственных сотрудников и распределение задач.
Следующий этап – фаза планирования. Фаза включает в себя подготовку
функциональной спецификации, разработку дизайнов, подготовку рабочих пла-
нов, оценку затрат и сроков. Результаты фазы: функциональная спецификация,
Описание возможных рисков, сводный план и сводный календарный график про-
екта, развернутые среды разработки и тестирования. Программист должен вы-
брать язык программирования. Должна быть продумана вся архитектура ИС.
Далее идет фаза разработки. Проектная группа фокусируется на создании
компонент решения. Результат: исходный и исполнимый код приложений,
скрипты установки и конфигурирования, окончательное описание функционала
разрабатываемого решения, материалы поддержки решения, сценарии тестов.
Следующий этап – фаза стабилизации. Тестирование разработанного ре-
шения. Проектная группа устраняет ошибки и подготавливает решение к вы-
пуску. Результат фазы: окончательный продукт, документация выпуска, матери-
алы поддержки решения, результаты и инструментарий тестирования, исходный
и исполнимый код приложений, проектная документация.
Фаза внедрения. Решение стабилизируется и передается в работу персо-
налу. По завершении фазы проектная группа анализирует выполненную работу
и удовлетворенность заказчика. Для внедрения есть разные стратегии, мной была
выбрана параллельная стратегия. В ней одновременно работают старая система
и новая. Результаты работы сравниваются, и, если проблем не обнаружено, по-
степенно происходит переход на новую систему.
Следующий этап – этап эксплуатации. Работа программы отслеживается
каждые 2-3 часа. По результатам принимается решение о необходимости дора-
ботки программного обеспечения.
Ожидаемые риски на этапах жизненного цикла и их описание
При использовании стандарта MSF риски минимизированы, потому что
ЖЦ разделен на этапы, на каждом этапе есть роли, за которыми закреплены цели,
44
которые достигаются в каждой фазе. Но риски возникнуть могут. Сведем воз-
можные риски в таблицу (таблица 8).
Таблица 8
Риски на этапах ЖЦ
Фаза
Риски
Меры
Выработки кон-
цепции
Недальновидный
анализ сроков про-
екта и его бюджета
Нужно более детально прорабаты-
вать задачи и цели проекта, ставить
больше
контрольных точек.
Неправильно подо-
бранный проект-
ный состав испол-
нителей
Более тщательный подбор специали-
стов в проектную группу тестирова-
нием не только
профессиональных навыков, но и
личностных качеств.
Планирования
Неправильно или
не совсем кор-
ректно сформиро-
ванное архитек-
тура выбираемого
решения
Зависит от компетенции руководи-
теля проекта, на котором лежит при-
нятие решение
о выборе архитектуры разрабатыва-
емого решения
Разработки
Неправильная ин-
терпретация техни-
ческого задания и
как следствие не-
правильная про-
граммирование ар-
хитектуры и
сдвиг сроков
Более чёткое написание техниче-
ского задания, понятного программи-
сту
Отсутствие долж-
ной квалификации
у программиста в
том
языке, на котором
решено реализовы-
вать программу
Придется
использовать внешнего разработ-
чика, так называемый “аутсорсинг”
или “фриланс”
Тестирования
Риски неокончен-
ного тестирования
Решается путем повторного тестиро-
вания на следующей итерации разра-
ботки.
Внедрения
Риски неправиль-
ного принятия ре-
шения о закончен-
ности части про-
екта
Устраняется путем доработки при
следующей итерации
45
Организационно-правовые и программно-аппаратные средства обес-
печения информационной безопасности и защиты информации
В компании в зависимости от угроз безопасности информации введено в
действие несколько концепций обеспечения информационной безопасности.
Внутренние угрозы. Права пользователей информационной системы
OTRS разграничены по группам. Матрица доступа в таблице 9
Таблица 9
Матрица доступа
Группа
пользовате-
лей
Создание
заявки
Редактиро-
вание своей
заявки
Переназна-
чение за-
явки
Работа с ба-
зой знаний
Сетевая
группа
Чтение
Есть
Есть
Создание,
чтение, уда-
ление
Группа под-
держки поль-
зователей
Чтение
Есть
Нет
Создание,
чтение, уда-
ление
Горячая ли-
ния
Создание,
чтение, уда-
ление
Есть
Есть
Чтение
Пользователи системы разнесены в группы согласно обязанностям. Учет-
ные данные для входа в системы выданы каждому пользователю системы инди-
видуально. Вход на рабочие станции осуществляется по доменной авторизации.
Настроены политики парольной защиты и блокировки рабочего стола. Межсете-
вое экранирование в компании организовано с помощью сертифицированного
ФСТЭК России и ФСБ России межсетевого экрана. Возможный нарушитель
имеет низкий уровень потенциала по реализации угроз безопасности информа-
ции, поэтому принятых мер достаточно. Предполагается, что потенциальный
нарушитель не может вступить в сговор с администраторами информационной
системы.