Введение
В наше время одной из главных ценностей человеческого общества является информация. С развитием сети Интернет и постепенным увеличением доли цифровизации всего, что окружает человека, большая часть наших ежедневных действий производится через сеть. С увеличивающейся долей влияния информационных технологий на повседневную жизнь человека, меняются и внутренние процессы компаний, предоставляющих различные услуги пользователям средствами информационных технологий. IT
более не является обособленной сферой – каждая компания той или иной степени цифровизирована. Но просто предоставлять услуги клиентам через информационные технологии недостаточно – компаниям так же необходимо адаптировать свои бизнес-процессы, конечные продукты под постоянно меняющуюся конъектуру рынка. Это приводит к проблеме – как обеспечить максимально беспроблемный для компании и незаметный для конечного пользователя процесс постоянной адаптации ПО под меняющиеся едва ли не ежедневно бизнес-задачи?
Ранее ПО преимущественно разрабатывалось по каскадной модели (от английского waterfall – водопад), сутью которой являлась формализованная, поступательная, разбитая на этапы разработка с четкими критериями для прохождения каждого этапа. Но данный подход не применим к постоянно меняющейся конъектуре рынка – при каскадной модели разработка и релиз законченного продукта занимает от года. Какие опции существуют у команд разработки в таком случае?
Как ответ на озвученный выше вопрос родилась гибкая методология разработки – Agile (от английского – гибкий). Вместо четкого технического задания и долгого, выверенного процесса, разработка производится итеративно, мелкими шагами. Проект выводится в свою первую рабочую версию как можно быстрее, после чего дорабатывается под необходимые нужды в соответствии с поставленными бизнесом ценностями. Но такой
7
подход несет определенные риски – в первую очередь, риски нестабильности новых релизов ПО из-за сложности тестирования в необходимом объеме при частых обновлениях программ, а частые обновления неизбежно ведут к простоям и недоступности ПО для пользователей. Для избежание озвученных выше проблем все чаще стандартом архитектуры приложений становится микросервисная архитектура, подразумевающая декомпозицию всего бизнес-функционала ПО на множество в силу возможности автономных и небольших приложений – микросервисов, каждый из которых выполняет свою часть функционала, все множество же микросервисов сообща осуществляет конечную бизнес-логику. Микросервисная архитектура позволяет избежать длительных простоев – развернуть одновременно несколько экземпляров ПО, если они не большие, не составляет труда. Помимо этого, такой архитектурный подход упрощает тестирование – проверить маленькое приложение проще, нежели большое. Но озвученные выше плюсы такого подхода разбиваются, если микросервисное приложение имеет множество микросервисных элементов. Как обеспечить бесперебойный, быстрый, безопасный, проверенный цикл разработки, если количество микросервисов приложения стремится к десяти, двадцати, пятидесяти обособленным сервисам?
Ответом на это стало развитие DevOps (от английского Development– разработка и Operations – операционное использование) – методология сотрудничества команд разработки и команд сопровождения программного обеспечения. Благодаря этой методологии, команды развития получают обратную связь от команд сопровождения касаемо качества сборок, команды сопровождения лучше понимают продукт, ими сопровождаемый. Развитием этой методологии стало появление автоматизированных конвейеров сборок – так называемых пайплайнов (от английского pipeline – водопроводная труба)
– по этим конвейерам приложения проходит этапы CI (Continuous Integration)
– непрерывной сборки, подразумевающей автоматическую компиляцию исходного кода по последним изменениям в исходном коде приложения;
8
следом идет этап CDL (Continuous Delivery) – непрерывной доставки – этапа, отвечающего за автоматическую доставку собранного на этапе CI версии приложения до среды, где это приложение необходимо развернуть, при условии, что сборка прошла успешно. За этапом CDL следует этап CDP (Continuous Deployment) – непрерывного развертывания, подразумевающий автоматическое разворачивание собранной и доставленной в рамках этапов
CI/CDL версии приложения, и получение сообщений об
успешности/неуспешности процесса разворачивания. Из методологии DevOps появился отдельный набор практик, в совокупности выводящийся в отдельную методологию – DevSecOps (от английского Development – разработка, Security – безопасность, Operations – операционное использование). Данная методология рассматривает вопросы обеспечения безопасности на всех этапах жизненного цикла приложения – от разработки до операционного использования.
Предметом исследования данной работы является методология DevSecOps - безопасная автоматизация технических процессов в информационной системе с применением практик непрерывной интеграции, доставки и развёртывания.
Целью же данной работы является разработка и практическое внедрение комплекса мер по обеспечению информационной безопасности на всех этапах создания микросервисного приложения.
Введение
Введение................................................................................................................... 7
1. Оценка существующих подходов к анализу исходного кода
микросервисного приложения. ............................................................................
10
1.1
Микросервис как архитектурный подход к построению ПО. .............
10
1.2
Статический анализ кода. ........................................................................
12
1.3
Динамический анализ кода......................................................................
14
1.4
Вывод .........................................................................................................
15
2.
Анализтехнологийреализацииархитектуры
микросервисного
приложения с учетом потенциальных угроз безопасности ТКС. ....................
16
2.1
Жизненный цикл программного обеспечения.
......................................
16
2.2
Репозитории и системы контроля версий. .............................................
17
2.3
Инструменты виртуализации серверов. .................................................
20
2.4
Инструменты контейнеризации программного обеспечения. .............
21
2.5
Оркестрация микросервисных приложений. .........................................
22
2.6
Базы данных. Выбор реализации БД, выбор реализации СУБД. ........
25
2.7
Инструменты автоматизации процессов сборки и разворачивания
приложений.........................................................................................................
26
2.8
Архитектура микросервисного приложения для интернет-магазина. 27
2.9
Вывод .........................................................................................................
29
3.
Разработка
микросервисного
приложения
для
защищенного
взаимодействия пользователя с базой данных интернет-магазина .................
30
3.1
Метод GET /catalogue ...............................................................................
31
3.2
Метод GET /cart ........................................................................................
32
4
3.3 Метод GET /order 33
3.4 Метод POST /cart 35
3.5 Метод POST/order 36
3.6 Тестовые сценарии. 37
3.7 Вывод. 41
4. Разработка конвейера автоматизации сборки и приложения со встроенными средствами анализа кода для безопасного и постоянного цикла
обновлений микросервисного приложения. 42
4.1 Архитектурная схема конвейера автоматизации. 42
4.2 Разворачивание инфраструктуры. 44
4.3 Конфигурация Jenkins Pipeline. 44
4.4 Вывод. 46
5. Экспериментальная оценка эффективности разработанных мер по обеспечению информационной безопасности микросервисного приложения.
47
5.1
Запуск конвейера для сборки уязвимой версии приложения. .............
48
5.2
Запуск конвейера для сборки защищенной версии приложения. .......
50
5.3
Вывод .........................................................................................................
53
6. Экономическая часть......................................................................................
54
6.1
Введение ....................................................................................................
54
6.2
Оценка целесообразности выполнения разработки на основе
определения ее технической прогрессивности...............................................
54
6.3
Календарное планирование .....................................................................
57
6.4
Определение затрат, себестоимости и цены НИР.................................
59
6.5
Оценка экономической эффективности разработки .............................
61
5
6.6 Вывод 61
7. Раздел охраны труда и окружающей среды. Обеспечение благоприятных условий труда специалиста при разработке комплекса мер информационной
безопасности 63
7.1 Введение 63
7.2 Анализ вредных и опасных производственных факторов 64
7.3 Микроклимат 66
7.4 Освещение 67
7.5 Шум 72
7.6 Электробезопасность 74
7.7 Пожарная безопасность 75
7.8 Психофизиологические факторы 76
7.9 Вывод 85
Заключение 86
Список литературы 88
Приложение 1. Исходный код разработанного микросервисного приложения
90
Приложение 2. Исходный код разработанного конвейера автоматизации... 121
Приложение 3. Результат работы инструмента статического тестирования при
проверке исходного кода уязвимой версии разработанного приложения 124
Показать весь текст...
Содержание
Введение
В наше время одной из главных ценностей человеческого общества является информация. С развитием сети Интернет и постепенным увеличением доли цифровизации всего, что окружает человека, большая часть наших ежедневных действий производится через сеть. С увеличивающейся долей влияния информационных технологий на повседневную жизнь человека, меняются и внутренние процессы компаний, предоставляющих различные услуги пользователям средствами информационных технологий. IT
более не является обособленной сферой – каждая компания той или иной степени цифровизирована. Но просто предоставлять услуги клиентам через информационные технологии недостаточно – компаниям так же необходимо адаптировать свои бизнес-процессы, конечные продукты под постоянно меняющуюся конъектуру рынка. Это приводит к проблеме – как обеспечить максимально беспроблемный для компании и незаметный для конечного пользователя процесс постоянной адаптации ПО под меняющиеся едва ли не ежедневно бизнес-задачи?
Ранее ПО преимущественно разрабатывалось по каскадной модели (от английского waterfall – водопад), сутью которой являлась формализованная, поступательная, разбитая на этапы разработка с четкими критериями для прохождения каждого этапа. Но данный подход не применим к постоянно меняющейся конъектуре рынка – при каскадной модели разработка и релиз законченного продукта занимает от года. Какие опции существуют у команд разработки в таком случае?
Как ответ на озвученный выше вопрос родилась гибкая методология разработки – Agile (от английского – гибкий). Вместо четкого технического задания и долгого, выверенного процесса, разработка производится итеративно, мелкими шагами. Проект выводится в свою первую рабочую версию как можно быстрее, после чего дорабатывается под необходимые нужды в соответствии с поставленными бизнесом ценностями. Но такой
Показать весь текст...
Список литературы
7. Раздел охраны труда и окружающей среды. Обеспечение благоприятных условий труда специалиста при разработке комплекса мер информационной безопасности
7.1 Введение
В данной дипломной работе происходит разработка варианта организации защищенного процесса передачи данных. Для реализации поставленных перед проектом задач требуется установить и развернуть необходимое ПО для созданной структуры комплекса. Поэтому выполнение дипломной работы сводится к работе на ПЭВМ.
В рамках данного раздела производится проверка соответствия условий труда специалиста установленным государственным стандартам и предложение мер по улучшению организации рабочего места в случае несоблюдения безопасности труда.
Процесс выполнения работы происходит в помещении площадью 8.75 м2, показанном на рисунке 34. Работа осуществляется на протяжении 8 часов с перерывом на обед продолжительностью 1 час. Рабочим положением является положение сидя. Количество людей, находящихся в помещении - 1 человек. Размеры комнаты указаны в таблице 8.
Таблица 8 - Параметры комнаты производственного помещения.
Наименование параметра Значен Мера измерения
ие
Высота 2,55 м
Длина 3,5 м
Ширина 2,5 м
Объем помещения 22.3125 м3
Общая площадь помещения 8.75 м2
63
Рисунок 34- План комнаты специалиста
В ходе работы применялось следующее оборудование: люстра потолочная, стол, стул.
Материал пола - ламинат, стены оштукатурены и оклеены обоями. В комнате есть окно, которое представлено пластиковым стеклопакетом и находится на высоте 1 м над уровнем пола, площадь окна: 1,50 * 80 = 1,2 м2. Искусственная система освещения состоит из люстры в центре комнаты, с использованием 4 ламп мощностью по 75 Вт каждая (900 люмен), и настольной лампы мощностью 40 Вт (400 люмен).
7.2 Анализ вредных и опасных производственных факторов
64
Факторы производственной среды оказывают существенно влияние на функциональное состояние и работоспособность специалиста. Анализ опасных и вредных факторов проводится согласно ГОСТ 12.0.003-2015 ССБТ. "Опасные и вредные производственные факторы. Классификация".
Опасные и вредные факторы подразделяются на следующие группы:
• физические
• химические
• биологические
• психофизиологические
Биологические и химические факторы не встречаются в данной работе специалиста, поэтому их можно не учитывать.
Из вредных и опасных физических факторов в качестве основных можно выделить следующие:
Показать весь текст...
Отрывок из работы
1. Оценка существующих подходов к анализу исходного кода
микросервисного приложения.
В рамках данного раздела будет произведена оценка существующих подходов к анализу исходного кода микросервисного приложения. Анализ исходного кода позволяет находить уязвимые места приложения на этапе разработки, что существенно снижает стоимость исправления найденных уязвимостей. Для успешного применения инструментов анализа, необходимо понимать специфику микросервисной архитектуры, разность между различными подходами тестирования. Подробное описание этих тем находится в главах 1.1, 1.2, 1.3 текущей работы.
1.1 Микросервис как архитектурный подход к построению ПО.
Как уже было озвучено ранее, микросервисное приложение – приложение, логика функционирования которого разбита на множество небольших, слабо связанных и легко изменяемых модулей –
микросервисов[1]. Аналогом микросервисной архитектуры является более старая «монолитная» модель, подразумевающая объединение всей бизнес-логики с соответствующими техническими реализациями внутри одного компонента – экземпляра ПО. Сравнение микросервисного приложение с монолитным приложением приведено на
Рисунок 1.
Рисунок 1- Сравнение монолитных и микросервисных архитектур
10
Микросервисное приложение подразумевает деление всего функционала приложения на множество максимально независимых друг от друга компонент – микросервисов, которые, в совокупности, могут выполнять тот же функционал, что и монолитное приложение аналогичного назначения.
Плюсами данного архитектурного подхода является модульность, меньшая сложность разработки каждого отдельного сервиса, повышенная отказоустойчивость за счет реплик приложения, простота в обслуживании. Минусами данного подхода является частый цикл обновления ПО – микросервисная архитектура чаще всего используется в системах, для которых критически важно гибко реагировать на постоянно меняющиеся потребностей клиентов, соответственно возрастает частота обновлений или пересоздания микросервисов с нуля. При частых обновлениях неизбежно уменьшается качество кода в виду сложности тестирования ПО в полном объеме при
Показать весь текст...
Не смогли найти подходящую работу?
Вы можете заказать учебную работу от 100 рублей у наших авторов.
Оформите заказ и авторы начнут откликаться уже через 5 мин!
