41
конечного) результата и делят создание проекта на короткие циклы. Именно
методология MSF была выбрана для данного проекта.
В состав ЖЦ проекта автоматизации включены следующие стадии:
1. выработка концепции
2. планирование
3. разработка
4. тестирование (стабилизация)
5. внедрение
6. эксплуатация и сопровождение
Выработка концепции (создание общей картины). Данная фаза
закладывает фундамент будущего проекта.
Основная цель - создание проектной группы и выработки единого
видения будущего проекта.
Ключевые участники - специалисты отдела СПО, которые в дальнейшем
будут эксплуатировать ИС. Отдел телекоммуникаций и отдел интернет-
ресурсов.
Результат – общее видение проекта, согласованная функциональность и
временные рамки выполнения
Планирование. На этом этапе проектная группа подготавливает
спецификацию функциональности, разрабатывает концепцию дизайна.
Основная цель – переход от абстрактных концепций к техническим
деталям.
Ключевые участники - специалисты отдела СПО
Результат – функциональная спецификация, план управления рисками,
сводный план и план-график проекта
Разработка. На этой стадии основное внимание проектной группы
фокусируется на создании программных модулей, обеспечивающих
функционирование ИС. Параллельно с разработкой составляется документация.
Некоторая часть разработки и составления документации может быть продолжена
на стадии тестирования.
Основная цель – разработка технической части ИС для дальнейшего
тестирования и подготовка документации
42
Ключевые участники – специалисты отдела СПО, отдел интернет-
ресурсов
Результат – исходный код приложения на языке Python, описание
установки и конфигурирования, спецификация функционала, сценарии
тестирования.
Тестирование (стабилизация). Фаза стабилизации представляет собой
тестирование разработанного продукта, выявление и устранение ошибок
Основная цель – проверка продукта в реалистичной модели
производственной среды, исправление выявленных ошибок.
Ключевые участники - специалисты отдела СПО, отделы
телекоммуникаций и отдел интернет-ресурсов.
Результат – окончательный продукт с документацией, готовый к
внедрению.
В методологии MSF фаза стабилизации включает в себя промежуточную
веху «Пилотное внедрение», которое подразумевает внедрение только части
функционала, либо для части пользователей. Так как разрабатываемая система
представляет интерфейс для управления серверами, развертывание только части ее
функций не имеет смысла. Было принято решение выполнить пилотное внедрение
полнофункциональной версии ИС. В связи с тем, что у всех информационных
систем, поддерживаемых отделом СПО, есть свои тестовые серверы, данный
подход позволит использовать ИС в уже существующей тестовой среде и
максимально приблизить результаты тестирования к реальным. Рассмотрим
процесс пилотного внедрения более детально:
Шаг 1 – Выделение серверов.
Отдел телекоммуникаций разворачивает виртуальные машины с
операционной системой CentOS 7.6 для будущей ИС, присваивает им IP-адреса и
передаёт созданные серверы в управление отделу СПО.
Во время создания также проверяется наличие необходимых сетевых правил. В
случае их отсутствия необходимо открыть на сетевом оборудовании правила
прохождения траффика, согласно таблице 8.
43
Таблица 8.
Разрешающие сетевые правила для функционирования проекта
Источник
Назначение
порт
Сеть отдела СПО
Web-сервер приложения
http
ssh
Сервер базы данных приложения
5432/tcp
ssh
Web-сервер приложения
Серверы, управляемые разрабатываемой
ИС
ssh
Шаг 2 – Настройка сервера базы данных.
Первоначальная настройка ОС производится специалистами отдела
телекоммуникаций на стадии развёртывания виртуальных машин. В момент
передачи серверов в управление в ОС уже существует пользователь с
повышенными привилегиями и установлены все доступные обновления системного
ПО, так что после получения доступа можно переходить непосредственно к
установке необходимого ПО.
Для простоты установки и настройки СУБД был написан SH скрипт,
который настраивает репозитории, устанавливает PostgresPro, производит
дополнительные настройки доступа по сети, создает базу данных и пользователя.
Содержимое скрипта установки СУБД приведено в приложении 1.
В результате выполнения будет создана база данных «spo», пользователь
«django» c паролем «django» и доступ к базе будет открыт только для одного IP –
192.168.0.13. Для тестирования приложения вполне допустимо использование не
сложных паролей. В дальнейшем, при внедрении в промышленную эксплуатацию,
пароль будет изменен.
Шаг 3 – Настройка сервера приложений
Одним из несомненных плюсов разработки на Python является уже
встроенное в комплект поставки так называемое «виртуальное окружение».
Виртуальное окружение позволяет создавать отдельный контейнер со своими
библиотеками для каждого приложения, не затрагивая при этом глобальные
настройки интерпретатора на уровне ОС. Благодаря этому, при развёртывании
44
приложения на другом сервере нет необходимости устанавливать заново все
библиотеки, используемые в проекте. Достаточно скопировать папки, содержащие
код приложения, виртуальное окружение и произвести некоторые настройки
системы.
Действия на рабочей станции с разрабатываемым приложением:
1. Копируем папку проекта на сервер приложений. Для этого удобнее
использовать утилиту rsync:
# rsync -avz -e 'ssh' /opt/admin_spo kornilovas@192.168.0.13:/opt
Действия на сервере приложений:
1. Редактируем файл «conf.py» в папке приложения - он содержит
конфигурацию подключения к базе данных. Указываем следующие
значения:
• dbhost = ‘192.168.0.12’
• dbport = ’5432’
• dbname = ‘spo’
• dbuser = ‘django’
• dbpass = ‘django’
2. Редактируем файл «install.sh» в котором необходимо указать учетные
данные администратора приложения.
• admin=kornilovas
• passwd=kornilovas
• email=kornilov.it@gmail.com
3. Запускаем скрипт «install.sh», который закончит настройку приложения.
Содержимое скрипта «install.sh» приведено в приложении 1.
Далее, начинается этап тестирования функциональности приложения. В этом
процессе участвуют несколько отделов.
Отдел телекоммуникаций, со своей стороны, производит мониторинг сетевой
активности приложения на предмет выявления аномалий и подозрительного
траффика.
Отдел СПО тестирует основные эксплуатационные функции, такие как:
Правильность исполнения команд на серверах с различными версиями
операционных систем
45
Проверка поведения приложения при проблемах со связью
Проверка выполнения команд с отсутствующими на это правами, как у
пользователя приложения, так и у пользователя на удаленном сервере
Выявленные ошибки устраняются и процесс тестирования повторяется.
Внедрение. Во время этой фазы производится установка решения и всех
компонентов окружения, необходимых для его работы.
Основная цель – ввод системы в промышленную эксплуатацию.
Ключевые участники - специалисты отдела СПО, которые в дальнейшем
будут эксплуатировать ИС.
Результат – ИС находится в эксплуатации. Оформлены окончательные
версии всех проектных документов, подготовлено описание
последующих шагов.
Как уже описывалось ранее, модель MSF предполагает пилотное внедрение
продукта на фазе стабилизации. Приложение было развёрнуто в своей
полнофункциональной версии на стадии стабилизации и тестировалось на
реальных тестовых серверах существующих ИС. Переход от стадии стабилизации к
внедрению сводится к минимуму действий:
Сменить пароль пользователя «django» в СУБД
Указать новый пароль базы данных в файле «conf.py»
Сменить пароль администратора «kornilovas» в приложении
При необходимости удалить из вэб-интерфейса тестовые серверы и
скрипты
Эксплуатация. На этапе эксплуатации разработанное приложение
используется специалистами отдела СПО в реальной инфраструктуре для
управления серверами различных ИС. Основные виды работ этапа эксплуатации по
ролям участников:
Администратор приложения
Регистрация, активация и блокировка пользователей
Настройка привилегий в зависимости от полномочий пользователя
Мониторинг активности пользователей
Выявление попыток несанкционированных действий со стороны
пользователя
46
Устранение ошибок и сбоев в работе приложения
Разработка и тестирование универсальных скриптов, для последующего
добавления в раздел «Команды», который содержит наиболее часто
применяемые действия.
Формирование предложений по дальнейшему развитию системы
Консультация пользователей
Пользователь приложения:
Создание проекта
Добавление серверов проекта в приложение
Редактирование и удаление серверов из проекта
Выполнение стандартных, заранее запрограммированных команд из
раздела «Команды»
Добавление в приложение собственных SH и Python скриптов в случае,
если требуемое действие не содержится в разделе «Команды»
Редактирование и удаление скриптов из проекта
Выполнение скриптов на серверах проекта
Просмотр результатов выполнения
Просмотр истории взаимодействия с серверами проекта
Формирование предложений администратору по дальнейшему развитию
системы
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
В основном, высокому риску подвергаются первые стадии проекта, потому
как допущенные погрешности и не предусмотренные заранее угрозы, несомненно,
обретут проявление в дальнейших стадиях. Результаты могут быть самыми
серьезными и могут послужить причиной к восстановлению работ на ранних
стадиях.
Существенная проблема может быть связана с подготовкой неправильного
задания или с постановкой неправильной задачи со стороны заказчика. Причиной
могут являться кадровые проблемы, такие как нехватка квалифицированного
персонала, который сможет подготовить задание на проектирование. При
47
осуществлении проектов в сфере разработки ПО проблема подготовки ошибочной
спецификации программного обеспечения проявляется часто.
Согласование всех нюансов технической спецификации необходимо для полной
уверенности в том, что клиент и заказчик одинаково понимают суть и функции
будущего приложения.
По мнению многих разработчиков, риски получить от заказчика некорректное
техническое задание очень часто невозможно просчитать заранее. Всё это может
привести к нарушению сроков выполнения задания.
Также, часто встречается и другая ситуация, когда не смотря на отлично
подготовленное и согласованное техническое задание, в процессе разработки у
заказчика появляются новые идеи по расширению функций приложения. Всё это
также крайне негативно влияет на возможность выполнить задание в срок.
К сожалению, подобные ситуации могут возникнуть на любой из стадий
проекта, вплоть до стадии внедрения и начала эксплуатации. В некоторых случаях,
когда изменения не столь существенны, и не требуют сильного увеличения как
временных, так и финансовых затрат, можно пойти на встречу заказчику и внести
изменения в продукт на поздних стадиях. Лучше постараться добиться
максимально подробного описания всех пожеланий еще на этапе выработки
концепции.
Помимо трудностей, возникающих по вине заказчика, стоит особое
внимание уделить стадии разработки, ведь кроме правильного выбора технических
решений важно, чтобы все разработчики владели опытом и знаниями в данной
области.
На этапе выбора технических решений также скрываются угрозы, потому
как ошибки в выборе ресурсов и ПО для разработки, на дальнейших этапах станут
проявлять негативное воздействие. К примеру, программист на языке C++,
насколько бы он не был опытен, не сможет мгновенно переключиться на другой
язык, например Python или Java. То же самое касается и администраторов баз
данных – администратор Microsoft SQL server далеко не сразу вникнет во все
тонкости работы PostgresPro или Oracle. Всё это может привести как к затягиванию
сроков, так и к полной неработоспособности продукта со временем.
48
Риски на этапах тестирования и внедрения чаще всего встречаются из-за
непредусмотренных проблем на более ранних этапах. Например, в результате
тестирования может выясниться, что разработанное приложение некорректно
работает в инфраструктуре заказчика. Это свидетельствует о том, что не все
технические нюансы были учтены на стадиях планирования и разработки.
В процессе разработки проекта автоматизации в рамках данной ВКР, также
были допущены ошибки на различных стадиях, которые в настоящее время
устранены.
На стадиях выработки концепции и планирования в приложение была
заложена функциональность, которую не удалось обеспечить в установленные
сроки.
Пример:
Раздел «Команды» должен был динамически генерировать меню, в
зависимости от активированных серверов. Список сервисов и действий, доступных
на каждом сервере также планировалось сделать динамическим, получаемым в
результате выполнения фоновых скриптов без взаимодействия с пользователем.
Основной причиной отсутствия данной функциональности в конечном
варианте приложения явилось отсутствие необходимого опыта использования
Django и Javascript. В результате, потратив незапланированное время на поиски
вариантов решения этой задачи, пришлось отложить реализацию данной функции
до более глубокого изучения.
В процессе разработки также не удалось избежать ошибок, которые были
заложены на этапе планирования.
Пример:
ГКУ «Ресурсы Ямала» - государственная организация, которая постепенно
переходит на использование программных продуктов из «Единого реестра»
разрешенного ПО. В связи с этим, данный проект планировалось разработать на
RED OS Murom 7.1[11].
Еще на стадиях установки необходимого ПО начали возникать различного
рода проблемы:
Не удалось корректно установить пакет «python-pip» - внутренний
установщик языка «Python» для управления библиотеками.
49
Пакет «python-virtualenv» не мог запустить уже существующее
виртуальное окружение, ссылаясь на отсутствие зависимостей,
которые на самом деле в системе были установлены.
При установке PostgresPro операционная система возвращала
некорректные данные о своей версии (7.3 вместо необходимой 7.1), в
результате чего формировалась несуществующая ссылка на
скачивание. Это довольно странно, так как в самой ОС переменные
окружения возвращают правильный результат.
Все эти проблемы, конечно же, можно решить, но факт их наличия повлиял
на восприятие данной ОС. Вероятность постепенного обнаружения еще большего
количества проблем побудила принять решение сменить систему на CentOS 7.6.
Кроме проблем с ОС, на начальных этапах разработки возникли проблемы с
выбранными версиями языка Python и Django. На самых актуальных из них
некорректно работала библиотека «guardian», расширяющая возможности
управления правами пользователей. После решения использовать не самые
последние версии данных продуктов, в процессе тестирования выяснилось, что в
рамках разрабатываемого приложения библиотека «guardian» избыточна и для
решения поставленных задач более чем достаточно возможностей, встроенных в
Django.
Исходя из этого, можно сделать вывод о том, что команда разработчиков
должна в необходимой мере владеть программными продуктами, на которых будет
вестись разработка, а также планировать время решения поставленных задач,
исходя из реального опыта разработки. Не стоит слепо полагаться на то, что новые
версии продуктов будут работать лучше старых и проверенных. Также, процесс
развертывания приложений должен быть максимально автоматизирован, ведь
большинство задач администрирования по-прежнему решается путем написания
сценариев[3].
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В основе обеспечения физической и информационной безопасности лежат
различные программные, аппаратные и программно-аппаратные комплексы,
50
которые были подробно описаны ранее, в разделе 1.2.4. Для полноценной защиты
разрабатываемого приложения достаточно обеспечить правильное распределение
прав доступа для пользователей.
В данный момент в приложении реализован перечень назначаемых прав,
перечисленных в приложении 2.
Не смотря на широкие возможности разделения прав пользователей, следует
заострить внимание на том, что данное приложение разрабатывается для нужд IT-
администраторов. Все администраторы изначально имеют полный контроль над
серверами своих проектов, поэтому по умолчанию у всех активированных
пользователей появляется полный доступ к проектам, которые они в дальнейшем
создадут.
Возможность более тонкого разграничения прав реализована для
возможности открыть пользователю частичный либо полный доступ к проектам
других пользователей. По умолчанию такого доступа нет ни у кого.
В приложении реализована возможность регистрации пользователей, но все
же доступ в интерфейс не будет открыт до тех пор, пока администратор не
активирует нового пользователя.
Доступ к серверу и вэб-интерфейсу изначально отсутствует у всех. Для его
получения необходимо создать официальную заявку на получение сетевого
доступа. Сетевые инженеры не имеют права открывать доступ к какой-либо
системе без официального согласования с администраторами данной системы.
Остальную часть обеспечения безопасности берут на себя встроенные
механизмы Django. Например, даже зная структуру запроса к вэб-серверу для
выполнения команды, его невозможно выполнить, не авторизовавшись, так как
для каждой сессии создаётся уникальный тег «csrf token
14
»[1стр.54]
предназначенный для защиты от подделки межсайтовых запросов.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель – это набор правил и операций, необходимых для
14
Тег {% csrf_token %} представляет собой скрытое поле с автоматически сгенерированным токеном для
защиты от подделки межсайтовых запросов (Сross Site Request Forgery – CSRF-атак).