64
пользователями. Этот риск можно устранить при помощи дополнительной
доработки экранных форм.
На подэтапе «Подготовка к созданию ПО» основная угроза заключается в
неправильной формализации расчётов показателей. Риск можно устранить
посредством тестирования программных модулей на стадии введения.
На подэтапе «Создание ПО» основная угроза состоит в неправильной
разработке программы. Данный риск можно устранить применением для
программирования языка PHP визуальной оболочки PHPEditor, которая при
программировании показывает неправильности различных компонентов
создаваемого программного средства. Следует учесть, что тестирование
программных модулей будет выполняться на стадии введения.
Угроза на стадии «Введение» заключается в неправильном тестировании
технического обеспечения программных модулей. Данный риск можно
предотвратить применением лицензионного стендового оборудования, а
устранить можно при помощи двойного тестирования. На стадии
«Сопровождение» основные угрозы заключаются в поломке оборудования,
моральном устаревание ПС и ПО. Первый риск можно предотвратить при помощи
гибкости созданной ИС и при помощи оперативной доработки программной
архитектуры. Второй риск можно предотвратить при помощи постоянного
мониторинга состояния оборудования.
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Нормативная правовая основа заключает в себе группы документации,
учтенные при соблюдении информационной безопасности:
I. Международное правовое обеспечение, составленное нормативными
актами, утвержденными Российской Федерацией и международные договора,
инициированные РФ.
II. Международное нормативное техническое обеспечение, куда входят
Регламенты, Рекомендации, Стандарты в области информации и в сфере ИБ.
III. Федеральное юридическое обеспечение, куда входят нормативные акты
Российской Федерации (Конституция России, Указы Президента РФ,
65
Государственные законы), подзаконные акты (Указы и Постановления
российского Правительства, нормативные акты уполномоченных
государственных органов власти), подзаконные и предусмотренные законом акты
субъектов Российской Федерации.
IV. Федеральное нормативное техническое обеспечение, куда входят
действующие в Российской Федерации технические стандарты, инструкции
(отраслевые, государственные), директивные документы, подзаконные акты
исполнительных федеральных органов власти преимущественно носящие
нормативно-технический характер.
Документация, которая относится к первой группе (международное
юридическое обеспечение) обладает преимущественным правом при обеспечении
безопасности данных в сетях связи третьего поколения, если иное не
предусмотрено законодательством Российской Федерации. К данной группе
относятся:
a. Европейская Конвенция о защите гражданских прав и главных свобод
(1996 г.);
b. Всеобщая декларация гражданских прав, утвержденная и
провозглашенная Генеральной Ассамблеей ООН (1948 г.);
c. Пакт о политических и общегражданских правах (1976 г.);
d. Европейская Конвенция от 28 января 1981 года об охране частного
лица по отношению к автоматизированной обработке персональной информации;
e. Распоряжение Европейского Парламента и Совета ЕС 95/46/ЕС об
обработке персональной информации;
f. Распоряжение Европейского Парламента и Совета ЕС 97/66/ЕС об
обработке персональной информации;
А также некоторые иные международные договорённости, которые
признаны Российской Федерацией.
Данные документы затрагивают определенные значимые и характерные
для национального законодательства Российской Федерации вопросы, такие как:
требования к системе защиты;
единые цели безопасности;
требования к управлению безопасностью.
66
требования, которые относятся к управлению доступом;
оценка рисков, сопряженных с любой угрозой;
аутентификация положения и привлечённых сторон;
определение механизмов по выявлению и противодействию вероятным
угрозам, а также восстановлению корректной работы ИС;
механизмы анонимности: транзитные идентификаторы с симметричным
ключом; засекреченность подлинности с использованием асимметрического
ключа; анонимный доступ;
механизмы идентификации: с асимметричным и симметричным ключом,
с "нулевым знанием";
механизмы конфиденциальности: шифрование потока, шифрование
блока;
механизмы по гарантии целостности: кодирование с добавкой
избыточности, асимметричный и симметричный ключ;
не криптографические механизмы защиты: пользовательская
регистрация, пользовательская верификация, подсчёт вызовов;
механизмы управления безопасностью: администрирование версий,
распределение ключей;
механизмы безотказности: цифровая подпись;
множественные иные вопросы.
В главные организационные меры входит: усовершенствование политик
защиты, создание документов, конкретизирующий меры соблюдения
безопасности данных по определенным вопросам и угрозам. [7]
Документированная политика информационной безопасности должна
заявлять о приверженности руководства и определять метод управления ИБ на
предприятии.
Политику информационной безопасности необходимо донести до сведения
в актуальной, ясной и доступной форме читателям, для которых она
предназначена [12].
Политика информационной безопасности должна быть составляющей
единой документированной политики.
Следовательно, главная организационная мера должна состоять в создании
67
политики информационной безопасности, ознакомлении с ее положениями
абсолютно всеми сотрудниками и в строжайшем их соблюдении.
Таким образом, опираясь на требуемые меры по информационной
безопасности в рассматриваемом предприятии, следует определить состав
разрабатываемой политики безопасности [12].
Основываясь на данные подсистем были разработаны ключевые
требования, которые касаются обеспечения информационной безопасности на
предприятии и охватывают следующие частные документы:
1. Правила защиты паролей;
2. Регламент использования системы учета документов отделом
документооборота;
3. Правила защиты от зловредного программного обеспечения и вирусов.
Кроме того, чтобы установить правила для персонала при приёме на работу
и увольнении, при возникновении внештатных ситуаций, разработана инструкция
по работе с сотрудниками, куда вошли:
1. Инструкция приема на работу и допуска к ней новых сотрудников в АС
и возложению на них полномочий, необходимых для доступа к системным
ресурсам.
2. Инструкция по увольнению персонала и лишения их полномочий
системного доступа.
3. Инструкция по действиям различных категорий персонала, включая
сотрудников отдела информационной безопасности, по устранению последствий
чрезвычайных (внештатных либо аварийных) ситуаций, во время их
возникновения.
На предприятии, которое рассматривается уже используются средства по
инженерной технической защите, к примеру, система охранной сигнализации. В
том числе, к инженерно-техническим мерам относится система по контролю и
управлению доступом. Та как активы информации главным образом
представлены на бумажных документах и файлах на магнитных дисках, то
рациональным является внедрение системы безопасного электронного
документооборота [7].
В итоге выполнения сравнения существующих систем, предоставлена
68
возможность организации защищенного обмена документами изнутри
предприятия избран программно-аппаратный продукт ViPNet с целью защиты
системы учета документов отделом документооборота предприятия.
ViPNet CUSTOM ориентирован для организации безопасного
взаимодействия клиент-клиент, тогда наибольшей частью VPN -решений иных
производителей обеспечивается только соединение уровня сервер-клиент или
сервер-сервер. Это дает возможность осуществления любой требуемой политики
разграничения доступа в границах всей безопасной сети и сокращения нагрузки
на VPN -серверы, т. к. в ходе взаимодействия клиент-клиент VPN -сервер не
применяется в процессах по кодированию трафика между такими пользователями
[22].
Методика ViPNet реализует функции брандмауэра для безопасных и
открытых соединений, IM-клиента, почтовых сервисов, назначений виртуальных
адресов видимости и систем выявления вторжений (IDS).
Чтобы создать сеть ViPNet следует установить на рабочие машины
программное обеспечене ViPNet. При этом не нужно приобретать
дополнительное оборудование и изменять существующую сетевую топологию.
Протокол, используемый в методике ViPNet, может обеспечить безопасную
передачу информации посредством любых связных каналов, при помощи любых
устройств NAT/PAT — даже, тогда, когда Интернет-провайдер создает помехи
для установления соединения с помощью запрета VoIP или авторизующих
соединений IPSec.
Применяя ViPNetCUSTOM, администратор сети располагает всеми
требуемыми средствами для решения задачи по организации безопасной сети.
Неограниченная масштабируемость решения дает возможность обеспечения
безопасной и быстрой защиты и локальной сети малого предприятия, которая
использует выход в глобальную сеть или модемный пул для присоединения
удалённых пользователей, и распределённых корпоративных сетей больших
коммерческих и государственных предприятий, не меняя при этом привычного
алгоритма использования установленных раньше в сети приложений.
Поставляется ViPNetCUSTOM в наборе с крипто-ядром Домен К и
сертифицированным ФАПСИ.
69
Сервером IP-адресов является координатор, от которого пункт абонента
получает данные о параметрах доступа, IP-адресах и состоянии узлов сети, с
которыми сопряжен данный абонентский пункт.
Как и сервер IP-адресов по умолчанию внедряется координатор, на котором
этот пункт абонента зарегистрирован в программе ViPNetManager либо
ViPNetAdministrator, то есть, в сервер-маршрутизатор абонентского пункта.
Рекомендуется использовать сервер IP-адресов по умолчанию, тем не менее, при
потребности как сервер IP-адресов можно избрать свободный координатор своей
сети, с которым сопряжен этот абонентский пункт.
Если же как межсетевой экран пользователем используется координатор,
тогда шифрованный трафик меж этим клиентом и узлами, который напрямую
недоступен по их адресам, будет перенаправляться при помощи координатора. В
этом случае координатор исполняет функции крипто-шлюза, т. е. маршрутизатора
для кодированных пакетов с функцией транслирования адресов (выполняется
изменение MAC - и IP -адресов).
Реализация автоматической маршрутизации кодированных пакетов
клиента при помощи координатора выполняется, без изменения настроек
протокола TCP/IP в операционной системе. Не меняются настройки шлюза сети,
который используется по умолчанию, после установки программного
обеспечения ViPNet. Соответственно, также не меняется маршрутизация не
кодированных пакетов, и работу в сети можно продолжать сразу после установки
ПО ViPNet. Новые маршруты создаются исключительно для кодированного IP-
трафика.
Как межсетевой экран возможно избрать координатор, который не является
для этого пункта абонента сервером IP-адресов.
Данная возможность является целесообразной для мобильного
пользователя ViPNet, находящегося в чужой локальной сети. Для того, чтобы
мобильному пользователю работать в обычном режиме в сети ViPNet будет
достаточно, как межсетевой экран выбрать координатор, который доступен в этой
локальной сети (если с координатором существует связь).
Кроме этого, обеспечивается в некоторой степени резервирование крипто-
шлюзов в сети. При недоступности установленного координатора, в перечне
70
можно выбрать иной приемлемый координатор и продолжить работу.
В таблице 6 представлена таблица разграничения прав пользователя.
Таблица 6
Разграничение прав пользователей
Группы
пользова-
телей
Общая
папка
«ПО»
Общая папка
«Пользовате
ли»
Модуль
«ТЗ»
Модуль
«Проект»
Доступ в
Internet
Менеджер
проектов
Чтение/со
здание
Полный
Полный
Полный
Не
ограниче
н
Менеджер
по
продажам
Чтение/со
здание/уд
аление
Чтение
Чтение
Полный
Ограниче
н
Дизайнер
Чтение
Чтение/созда
ние
Полный
Нет
Нет
Верстальщ
ик
Чтение
Чтение/созда
ние/
удаление
Полный
Чтение
Ограниче
н
Программи
ст
Чтение/со
здание/уд
аление
Чтение/созда
ние/
удаление
Полный
Полный
Не
ограниче
н
2.2. Управление проектом автоматизации
2.2.1 Описание системы принятия управленческих решений
Рассмотрим основные методологии управления проектами и выберем
необхогдлимую для нашего проекта.
Традиционная методология для управления проектами применяется во всех
сферах, но чаще всего в строительстве. Вследствие того, что последовательность
фаз модели подобна потоку, ее также называют водопадной или каскадной. В ней
выделено 7 логических этапов в сфере проектного управления [20]: определение
требований; проектирование; реализация; внедрение; отладка и тестирование;
установка; эксплуатация и сопровождение.
Одной из самых распространенных методологий управления проектами в
Великобритании, как в государственных, так и в бизнес сферах, является
PRINCE2 (Projects in Controlled Environments). Она ориентирована на процессы
верхнего уровня (управление, контроль, организация), и не применима для
процессов низшего уровня (разработка графиков, декомпозиция работ). В
PRINCE2 заложено по 7 типов принципов, тем и процессов. Принципы лежат в
основе методологии: при невыполнении одного из них, проект нельзя считать
71
выполненным согласно PRINCE2 [20].
Быстрая разработка приложений (RAD) – представляет собой проектную
методологию, чаще всего применяемая в проектах по созданию ПО, главной
целью которых считается качественная и быстрая разработка приложения. Такая
методология по управлению проектами предусматривает 4 этапа проекта [20]:
планирование; пользовательское проектирование; быстрое конструирование;
переключение.
Гибкое администрирование проекта - итеративная и последовательная
методология. Главная особенность заключается в том, что на начальном этапе
разработки неизвестны жизненный цикл и конечные параметры продукта.
Производится разделение итеративных фаз, именуемых «спринтами». Каждый
спринт включает в себя множество задач, имея при этом свой конечный продукт
и результаты. Agile позволяет руководителям после каждой итерации
производить улучшение конечного продукта при помощи получения обратной
связи.
Преимущество Agile заключается в гибкости: можно элементарно изменить
параметры проекта. Наиболее часто применяется для проектов, ориентированных
на сервис (разработка ПО, графический дизайн, пр.). Однако Agile не подходит
для выполнения проектов со строгими требованиями и параметрами [20].
В результате для разработки системы электронного документооборота
выбрана гибкая методология, так как с ее помощью к планированию привязаны
меньше и предусматривают совсем другой жизненный цикл – итерации.
Подобный подход обеспечивает более эффективную работу в условиях
стремительно изменяющейся бизнес-среды. Основное отличие – мнения по
поводу изменений на разных этапах проекта. При обычном подходе изменения на
конечных этапах считаются нежелательными и связаны со значительными
расходами. Гибкие методологии – одобряют изменения на всех стадиях. Этот факт
делает их наиболее конкурентоспособными в сегодняшних реалиях.
В настоящее время гибкие методологии являются хорошей альтернативой
традиционному подходу и обширно используются в разнообразных
высокотехнологичных отраслях, в особенности в области ИТ. Причиной
считается тот факт, что традиционным подходом испытываются значительные
72
затруднения, в случаях, если требования к проекту изменяются почти на любом
этапе, поскольку необходимо реагировать на быстро изменяющуюся среду.
Наиболее сложная ситуация – конечный результат продукта не совсем понятен,
другими словами следует разрабатывать, до конца не зная, что получится. В таких
случаях гибкие методологии становятся более предпочтительными.
Поэтому в текущей работе выбрана именно гибкая методология Agile.
Сопоставление фактических и запланированных сроков реализации
проекта при выполнении работ изображено в таблице 7.
Таблица 7
Сравнение фактических и запланированных сроков проекта по разработке
приложения
Задачи
Базово
е
начало
Базовое
окончани
е
Начал
о
Окончани
е
Базовая
длительност
ь,
день
Длительност
ь,
дней
Проектировани
е
14.07.
2019
08.08.
2019
14.07.
2019
29.08.
2019
20
33
Дизайн
11.08.
2019
22.08.
2019
01.09.
2019
18.09.
2019
10
14
Написание тех.
задания
заказчиком
11.08.
2019
15.08.
2019
01.09.
2019
19.09.
2019
5
15
Разработка API
заказчиком
14.07.
2019
08.08.
2019
14.07.
2019
20.10.
2019
20
92
Разработка МП
18.08.
2019
10.10.
2019
23.09.
2019
05.11.
2019
40
54
ИТОГО:
95
208
Все 5 задач обладали существенными отклонениями по
продолжительности, что привело к задержке срока сдачи проекта и увеличению
стоимости проекта. При помощи наблюдения за выполнением проекта были
обнаружены и систематизированы факторы запозданий задач проекта.
Задача «Проектирование приложения». Базовая продолжительность
планировалась 20 дней, фактическая - 33 дня.
Продолжительное составление требований, стремление минимизировать
риски путем глубокой аналитики вероятных расхождений в будущем повлекло
задержку времени согласования окончательного прообраза и начала следующего
этапа. Длительное время потрачено на добавления и корректировки прототипа,
73
следовательно, к запросам к приложению. Продолжительная неопределенность
заказчика в процессе предоставления своих запросов менеджеру проекта по
предполагаемым функциям приложения [9].
Задача «Дизайн приложения». Базовая продолжительность планировалась
10 дней, фактическая - 14 дней.
На предыдущем этапе руководитель предприятия заказчика не принимал
участие в формировании запросов к приложению, но на данном этапе он принял
решение о внесении собственных пожеланий. На этом этапе был внесены
многочисленные исправления по пожеланию заказчика, визуализировалось
приложение, что привело к задержке сроков.
Задача «Подготовка технического задания заказчиком». Базовая
продолжительность планировалась 5 дней, фактическая - 15 дней. На этом этапе
была спровоцирована задержка из-за неопределенности заказчика в своих
запросах к конечному продукту.
Задача «Разработка API заказчиком». Базовая продолжительность
планировалась 20 дней, фактическая - 92 дня.
На этом этапе заказчик обязан был предоставить API (интерфейс
взаимодействия между мобильным приложением и сервером заказчика). Однако
из-за повышенной загрузки ответственных специалистов на остальных проектах
и неопределенности функционала приложения на этом этапе случилась задержка.
В связи с тем, что заказчик задержал предоставление работоспособного API,
менеджеру проекта пришлось направить программиста на реализацию другого
проекта на срок в 27 суток.
Задача «Разработка приложения». Базовая продолжительность
планировалась 40 дней, фактическая - 54 дня.
На этом этапе была спровоцирована задержка не подготовленностью API, а
также разной интерпретацией технического задания (ТЗ) заказчиком и
исполнителем. Исполнитель полагал, что конфликтные задачи по разработке
были выполнены правильно, к тому же предмет спора не описывался в ТЗ, а
заказчик предположил, что такой бесспорный пункт не стоит даже детально
описывать. Другую задержку на этом этапе спровоцировали очевидные
изменения бизнес - запросов ПО, которые вызваны исправлениями отдела