CC BY
29ПРЕИМУЩЕСТВА
ГИБКОГО ПОДХОДА
ДЛЯ СОПРОВОЖДЕНИЯ ПРОЕКТОВ
РАЗРАБОТКИ
ПРОГРАММНОГО ПРОДУКТА
ADVANTAGES OF FLEXIBLE APPROACH FOR SOFTWARE PRODUCT DEVELOPMENT PROJECTS SUPPORT
УДК 004.056 DOI: 10.25631/PEJ.2019.4.42.51
МАЙОРОВА Елена Витальевна
доцент кафедры вычислительных систем и программирования Санкт-Петербургского государственного экономического университета, кандидат технических наук, chertok83@mail.ru
MAYOROVA, Elena Vitalievna
Associate Professor at the Department of Computer Systems and Programming, Saint Petersburg State University of Economics, Candidate of Technical Sciences, chertok83@mail.ru
СОКОЛОВСКАЯ Светлана Анатольевна
доцент кафедры вычислительных систем и программирования Санкт-Петербургского государственного экономического университета, кандидат экономических наук, доцент, ssokolovskaja@mail.ru
SOKOLOVSKAYA, Svetlana Anatolyevna
Associate Professor at the Department of Computer Systems and Programming, Saint Petersburg State University of Economics, Candidate of Economic Sciences, Associate Professor, ssokolovskaja@mail.ru
ЧЕРТОК Александр Витальевич
главный специалист отдела защиты цифровых продуктов ООО «ИТСК», avchertok@yandex.ru CHERTOK, Alexander Vitalievich
Chief Specialist of Digital Products Protection Department of LLC "ISK", avchertok@yandex.ru
Аннотация.
В статье рассмотрена целесообразность использования гибкой методологии разработки программного обеспечения. В рамках данной методологии рассмотрен гибкий подход к разработке программного продукта. Выделены этапы и подэтапы создания программного продукта. При этом описаны процессы и подпроцессы информационной безопасности и разработана схема их реализации в процессе разработки программного продукта для организации-разработчика программного обеспечения. Для оценки качества программного продукта предлагается показатель предотвращенных потерь.
© Майорова Е. В., Соколовская С. А., Черток А. В.., 2019.
Ключевые слова: информационная безопасность, информационная система, программное обеспечение, программный продукт, гибкая методология разработки программного обеспечения, гибкий подход к разработке программного продукта, система информационной безопасности, показатель предотвращенных потерь.
Abstract.
The article considers the feasibility of using a flexible methodology for software development. Within the framework of this methodology, a flexible approach to software development is considered. The stages and sub-stages of software product creation are highlighted. The processes and subprocesses of information security are described and the scheme of their implementation in the process of software development for the organization-software developer is developed. To assess the quality of the software product, an indicator of prevented losses is proposed.
Key words: information security, information system, software, software product, flexible methodology of software development, flexible approach to software product development, information security system, index of prevented losses.
В рамках принятой Доктрины информационной безопасности [1] определены перспективы развития научных исследований и порядок их проведения, осуществление опытных разработок в целях создания перспективных информационных технологий и средств обеспечения информационной безопасности (ИБ). Поэтому на всех этапах разработки программного обеспечения (ПО) обязательна процедура сопровождения средствами ИБ.
Также в Указе Президента РФ от 9 мая 2017 г. № 203 «О Стратегии развития информационного общества в Российской Федерации на 2017-2030 годы» определены цели, задачи и меры по реализации внутренней и внешней политики Российской Федерации в сфере применения информационных и коммуникационных технологий, направленные на развитие информационного общества, обеспечение национальных интересов и реализацию стратегических национальных приоритетов, предполагающие обеспечение необходимого уровня ИБ всех видов экономической деятельности [2].
Особое внимание уделяется разработке системы информационной безопасности (СИБ)
при реализации проектов по разработке компьютерного программного обеспечения, оказанию консультационных услуг в данной области [2].
В настоящее время при разработке программного обеспечения все чаще используются гибкие методологии разработки ПО, которые позволяют быстро создать качественный программный продукт (ПП) при минимальных затратах в условиях постоянно изменяющихся требований заказчика. При этом применении таких методологий эффективно решаются проблемы ИБ при разработке ПП.
Специализированная отрасль 62.1 «Разработка компьютерного программного обеспечения, консультационные услуги в данной области и другие сопутствующие услуги» представлена более чем 25, 6 тысячами организаций, являющихся разработчиками компьютерного ПО, предоставляющих консультационные услуги по сопровождению ПО для автоматизированных информационных систем [3]. В большинстве организаций разработка ПО производится силами собственных подразделений, что позволяет обе-
спечивать не только гибкость в управлении информационной системой (ИС), бесперебойность работы ИС, сопровождения ПО, но и ИБ на всех этапах разработки и реализации проекта.
В настоящее время для разработки ПО данными организациями могут использоваться такие методологии, как каскадная и гибкая.
В случае использования каскадной методологии при разработке ПО реализуется подход, ориентированный на поэтапное утверждение схемы разработки, в основу которого заложен принцип невозможности возврата к предыдущему этапу разработки или изменений после утверждения этапов.
В том случае, когда разработчиками ПО принята за основу гибкая методология разработки ПО, при создании нового ПП осуществляется гибкое взаимодействие исполнителей проекта и заказчика на всех этапах разработки ПО, что позволяет оперативно принимать решения и поэтапно минимизировать риски, возникающие в процессе разработки ПО [4; 5].
В отличие от каскадной методологии, гибкая методология разработки ПО получила наибольшее распространение в организациях-разработчиках ПО за счет возможности оперативного взаимодействия разработчиков и заказчика, что обеспечивает необходимый уровень качества разработки ПП. Данная методология вошла в основу документа, известного как «Манифест гибкой методологии разработки программного обеспечения» [4], созданного представителями международных организаций-разработчиков ПО.
Целью создания данного документа является приоритетность: осуществления взаимодействия людей в сравнении с процессами и инструментами; отлаженного функционирования системы над сопровождающей его документацией; взаимодействий с заказчиком над условиями контракта и готовности к изменениям над следованием первоначальному техническому заданию.
Принципы реализации гибкой методологии разработки ПО, согласно «Манифесту гибкой методологии разработки программного обеспечения», более подробно представлены на рисунке 1.
Преимущественно гибкие методологии направлены на уменьшение потерь методом сведения разработки ПО к серийной разработке непродолжительных итераций.
В рамках данной статьи под итерацией авторами понимается промежуточный вариант работоспособной версии ПП [4].
Обычно отдельная итерация не является гарантией выпуска окончательной версии ПП, но предполагает, что рабочая версия ПП готова к использованию в конце каждой итерации. По завершении каждой итерации необходимо проводить пересмотр приоритетов разработки ПП.
В таком случае гибкий подход к разработке ПП заключается в том, чтобы обеспечить изменение функциональных возможностей (функционала) рабочей версии ПП.
В рамках гибкого подхода к разработке ПП (DevOps, development (Dev), operations (Ops)) процесс создания ПП делится организациями-разработчиками на два этапа: разработка (Dev), поддержка, администрирование (Ops) и соответствующие им подэтапы: разработка ПП, тестирование ПП, реализация ПП, мониторинг ПП.
Для того, чтобы обеспечивать ИБ на всех этапах реализации проекта по разработке ПП, необходимо построение системы информационной безопасности. Основополагающими техниками СИБ являются процессы и соответствующие им подпроцессы ИБ.
На первом этапе разработки ПП (Dev) необходимо контролировать процесс обеспечения ИБ следующих объектов, нуждающихся в защите информации:
1) персональные компьютеры (ПК) разработчика, как программно-аппаратное средство разработки ПП;
2) локальный репозиторий на отдельных ПК разработчика, как хранилище данных для разработки ПП;
3) центральный репозиторий на выделенном сервере разработчика, внешнем или внутреннем, как хранилище данных для разработки ПП.
На втором этапе поддержки и администрирования разработки ПП (Ops) контролируются такие объекты защиты информации, как:
1
• Удовлетворенность клиента за. счёт ранней и бесперебойной поставки ПО
* Возможность гибкого изменения требований к разработке ПО на всех 2 этапах, даже в конце разработки
* Периодичность поставки версий рабочего 1111 (каждый месяц или неделю или ещё чаще)
* Тесное, ежедневное взаимодействие заказчика с разработчиками навсех 4 этапах проекта
• Мотивированность сотрудников организаций-разработчиков ПО
* Метод взаимод ействия с заказчиком - «лицом к лицу»
* Сокращение сроков разработки рабочей версии ГШ как измеритель прогресса
-\
* Поддержание постоянного темпа взаимодействий заказчика с разработчиками на всех этапах реализации проекта разработки 1111
* Постоянное улучшение технического мастерства разработчиков и удобного интерфейса для заказчика
10
* Оптимизация работ на всех этапах реализации проекта разработки ПО
11
Самоорганизация команды организации-разработчикаПО
* Гибкость адаптации рабочей версии ПО к изменяющимся условиям на всех этапах разработки ПП
Рисунок 1
Общие принципы создания ПО [4]
1) CI/CD-сервер (CI - Continuous Integration (непрерывная интеграция), CD - Continuous Deployment and Continuous Delivery (непрерывное развертывание и непрерывная доставка)), представляющий собой сервер автоматической установки новой итерации разрабатываемого ПП;
2) серверы управления инфраструктурой, представляющие собой серверы автоматического выделения ресурсов в виде виртуальных машин или контейнеров.
До начала проведения работ по этапам разработки ПП необходимо проведение следующих подготовительных работ по внедрению процессов СИБ, представленных на рисунке 2.
После проведения подготовительных работ группа безопасности сопровождает все этапы реализации проекта разработки ПП и продолжает отвечать за мониторинг, аудит готовой версии ПП, осуществляя контроль всех изменений на всех этапах разработки ПП.
На рисунке 3 предлагается перечень процессов СИБ, сопровождающих выполнение этапов разработки ПП, их состав (процессы СИБ 1-7) и содержание (подпроцессы СИБ 1.1-7.3).
Далее необходимо совмещение этапов и процессов обеспечения СИБ на всех этапах разработки ПП, с учетом того, что подэтапы разработки ПП, тестирования ПП, реализации ПП, мониторинга ПП выполняются последовательно, а процессы и подпроцессы СИБ могут выполняться как последовательно, так и параллельно в рамках определенного под-этапа.
На рисунке 4 представлена разработанная авторами схема реализации процессов СИБ (DevSecOps: Dev-development (разработка), Sec-security (защита)), Ops-operations (поддержка, администрирование)) на всех этапах и подэтапах разработки ПП для организации-разработчика ПО.
Рисунок 2
Основные подготовительные работы по внедрению СИБ при разработке ПП
Процессы СИБ при разработке и и
Подпроцессы СПБ ори разработке и и
1. Управление исходными данными (Source control)
2. Разворачивание (установка) установочного
Щ
пакета- контейнера на существующую инфраструктуру- с ерв ер (Build)
w
ГТП Контроль кода приложения (требования и рекомендации)
1.2. Контроль кода 1шфраструктуры (требования и рекомендации)
1.3. Просмотр всех изменений (code review) другим разработчиком
14 Запрет выполнения команды репозиторию исходного кода для мониторинг а изменении исходного кода (commit} из папкп с разрабатьш аемымновым ко дом (feature branch) в главную папку с исходным кодом разработанного ПО (master branche)
2.1. Просмотр и тестирование задач, запланированных процессов (Jobs) на комплектацию е master branch
2.2. Регистрация всех изменешш е коде (build jobs)
2. j. Организация достигла сервера, который аЕгоматизирует процесс устаноЕкп устаноЕочного пакета контейнера (Build - серЕера), только к разрешенным библиотекам
"О сл
~i
о
0)
0
1 О
О
5Í
-о
i
>
3. Работа с репозиторием и версиями приложений (Repository work)
4. Проверка качества (Quality Assurance, QA, например, при помощи Sonar, Fortyfy, checkmark и т. д.)
3.1. Отсутствие прямого доступа к бинарным файлам.
3.2. Сканирование репозиториев
4.1. Разрешение разворачивания (установки) устаноЕ очного паке га/ контейнера (build) на тшфраструктуре только после успешного сканирования исходного кода - SAST (Static Application Security7 Testing- сканер исходного кода)
4.2. Проверка конфигурации сканера исходного кода (SAST, Static Application Security7 Testing)
4.3. Возможность прослеживания каждого сценария тестирования функциональности (Function-теста) и наличие описания сценария на человекоподобном языке (user story)
4.4. Необходимость подтверждения сценариев тестирования владельцем продукта - лицом от заказчика (РО. Product owner)
4.5. Обязательное сохранение всех результатов тестов и обязательный их просмотр РО
4.6. Возможность Енесенпя изменешш е задачи и сценарии тестирования (test сазе)только ключевой командой разработки (core (dev) team)
4.7. Обязательное тестирование ключевых функций приложения
4.S. Обязательное утверждение тестов безопасности (Security7 test. Sec test)PO и Test team lead для тшфраструктурного кода
4.9. Обязательное утверждение Sec test РО и руков о дителем группы те стироЕаши (Test team lead) для кода приложения
4.10. Обязательное ознакомление с результатами тестов РО и руководителя проекта
Окончание рисунка
"О СП
"О ~1
о
Процессы СИБ при разработке Ч Ч
Подпроцессы СПБ ори разработке ММ
0)
0
1 О
О
I
>
5. Реализация на непродуктивный сегмент (синтетич ески е данны е (се™ ента), которые нужны для проверки разрабатываемого продукта) (Productive segment deploy)
6. Реализация на продуктивный сегмент (реальные данные (сегмента), которые нужно защищать) (Unproductive segment deploy)
7. Поддержка (Support)
■5.1. Проверка скр1лггов. кодов (code review) деплоя (реализации) и конфигурации > 5J2. Отсутствие связи с продуктивной средой >5.3. Использование непродуктивных данных
•6.1. Прохождение проверки кодов реализации (codereview) и конфигурации (плюс ручной режим опционально)
•6.2. Обязательное подтверждение' просмотр окончательной версии и результатов тестов РО •6.3. Каждая реализация должна иметь разрешение (ордер) на изменения •6.4. Автоматизированный откат
•6.5. Отсутствие связи с непродуктивным окружением
•7.1. Доступность разработок только для чтенти (read only) вереду разработки •12. Обязательное прохождение изменения кода через автоматический пайплайн (конвейер, подразумев aioimrii непр ерьшньп! пр оцесс CL'CD: pip eline)
•13. Обеспечение контроля доступа к любой из сред (например. Dev. test, prod)
"Л
У
Рисунок 3
Состав процессов СИБ при разработке ПП
Пцдзтал Подэгап
реализации мониторинга
^_
Пода гаи разработки
Пидетап
тестирования
_
Выпуск рабочей версии
ГШ (Р.е1еазе)
Этап р азр ао огки - йеу е1ор шеи 4 (Б ет) Этап подпер жки, адмшшстр ир ов згаш - ор егай ош (Ор Щ
Защш а (8 ее)
Рисунок 4
Реализация СИБ на всех этапах процесса разработки ПП (Беу8есОр8)
Преимущество разработанной схемы БеуБесОрз при разработке ПП заключается в том, что на всех этапах разработки ПП определяются объекты и средства защиты.
В качестве результирующего показателя защищенности разрабатываемого ПП для ИС авторами статьи рекомендовано использовать показатель потерь (П.) для каждого этапа (г).
Под показателем потерь будем понимать вероятность возникновения г-го инцидента ИБ с расчетом возможных экономических потерь до и после реализации внедрения гибкого подхода к разработке ПП по обеспечению ИБ:
П = П - П,
где П - показатель потерь г-го инцидента;
П - потери от реализации угроз до применения гибкого подхода; //
П - потери от реализации угроз после применения гибкого подхода.
В сущности, показатель потерь будет отражать ту часть прибыли, которая могла быть недополучена, если бы не применялись меры, повышающие уровень ИБ [6].
Следует отметить, что определить точное значение показателя предотвращенных потерь довольно сложно, так как для расчета используются статистические данные или экспертные методы оценки инцидентов ИБ. В ряде исследований [6-8] предлагается использовать сочетание этих методов, что позволяет более объективно оценивать значение показателя предотвращенных потерь на основе полученных данных при разработке ПП для ИС.
В рамках данного исследования показатель предотвращенных потерь может оцениваться как в денежном эквиваленте, так и во временных затратах.
Например, по данным годового отчета Сбербанка за 2018 г. [9], суммарное время простоев в 2018 г. по причине возникновения инцидентов ИБ было снижено до 8 часов против 58,8 часа в 2013 г. (год открытия программы «Надежность критичных автоматизированных систем банка (99,99)»). При этом было отражено 90% ББо8-атак.
Таким образом, можно отметить следующие преимущества построения СИБ при использовании гибкого подхода к разработке ПП для ИС:
1. Применение предлагаемого гибкого подхода к разработке ПП с обеспечением процессов ИБ существенно увеличит скорость выпуска ПП за счет внедрения непрерывных автоматизированных процессов как на этапе разработки ПП, так и на этапе его администрирования.
2. Тестирование разрабатываемого ПП в рамках предлагаемого гибкого подхода к его разработке с обеспечением процессов ИБ позволит обнаружить максимально возможное число угроз и обеспечить возможность их ликвидации, что приведет к минимизации потерь.
3. Экономия на простоях и грамотное распределение ресурсов на этапах ожидания ответа как от заказчика, так и от разработчика приведет к сокращению времени разработки ПП.
Вследствие этого сроки и качество разработанного ПП для ИС в рамках предлагаемого гибкого подхода с обеспечением процессов ИБ будут улучшены.
Список литературы
1. Доктрина информационной безопасности Российской Федерации от 5.12.2016 года № Пр-646. URL: http://www.consultant.ru/document/cons_doc_LAW_208191/ (дата обращения: 10.05.2019).
2. Указ Президента РФ от 9.05.2017 г. № 203 «О Стратегии развития информационного общества в Российской Федерации на 2017-2030 годы». URL: http://www.consultant. ru/document/cons_doc_LAW_216363/ (дата обращения: 16.05.2019).
3. Рейтинг организаций по выручке. Вид деятельности: 62 «Разработка компьютерного программного обеспечения, консультационные услуги в данной области и другие сопутствующие услуги». URL: http://www.testfirm.ru/rating/62/ (дата обращения: 16.09.2019).
4. Манифест гибкой методологии разработки программного обеспечения. URL: https://agilemanifesto.org/iso/ru/manifesto.html (дата обращения: 01.02.2019).
5. Agile Alliance. What is Agile Software Development? URL: https://www.agilealliance. org/agile101/ (дата обращения: 02.02.2019).
6. Шляпкин А. В. Метод оценки экономической эффективности подразделения по защите информации // Информационные системы и технологии: управление и безопасность. 2014. № 3. С. 318-324. URL: https://elibrary.ru/item.asp?id=23274910 (дата обращения: 05.04.2019).
7. Ефимов Е. Н., Лапицкая Г. М. Оценка эффективности мероприятий информационной безопасности в условиях неопределенности // Бизнес-информатика. 2015. № 1 (31). С. 51-56. URL: https://www.hse.rU/data/2015/05/28/1096865620/5.pdf (дата обращения: 20.03.2019).
8. Стельмашонок Е. В., Стельмашонок В. Л. Методические аспекты моделирования системы защиты информации в организации // Петербургский экономический журнал: научно-практический рецензируемый журнал. 2019. № 2. С. 64-70.
9. Сбербанк. Годовой отчет 2018. URL: https://www.sberbank.com/common/img/ uploaded/redirected/com/gosa2019/docs/sberbank-annual_report_2018_rus.pdf (дата обращения: 20.03.2019).
