В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
Основным фактором бурного развития информационных систем является оперативное обновление программного обеспечения. В свою очередь, повышение оперативности потребовало коренных изменений в технологической цепочке производства программных продуктов: темпы разработки ускорились, уровень технической осведомленности пользователя за последние 20 лет существенно вырос, потребители стали более ответственно выбирать решения. При этом важным конкурентным преимуществом является наличие технической поддержки и возможности устранять ошибки и расширять функциональность программных систем в режиме непрерывного обновления. Возникли такие понятия, как CI (Continuous Integration – постоянная интеграция, оперативное расширение функциональности) и CD (Continuous Delivery – постоянная поставка, в значении "дистрибуция"), а также обобщенное понятие CI/CD. Концепция организации технологического процесса, в которой реализуется CI/CD, получила название DevOps (Development Operations).
В основе DevOps лежит методология гибкой разработки программных продуктов. Гибкость предполагает жесткое разделение полномочий между участниками процесса при высокой степени автоматизации процессов сборки, тестирования и развертывания. Применение данного подхода позволяет создавать масштабные программные продукты, делегируя задачи производства и контроля качества сравнительно небольшим командам специалистов, наращивая по мере увеличения числа программных модулей количество команд и перераспределяя их полномочия.
Основной (и на данный момент неразрешенной) проблемой гибкой разработки является обеспечение безопасности производственного процесса. Локус внимания экспертов по безопасности DevOps направлен на то, чтобы не дать потенциальному злоумышленнику внести в работающую систему изменения, которые приведут к изменениям в логике обработки информации – повышению привилегий доступа с последующим изменением, удалением и/или разглашением хранящихся в системе сведений об объектах реального или виртуального мира. Однако сама среда предприятия, в рамках которой производится разработка программных продуктов, также может стать объектом исследования, а затем и атаки.
По мере того как данное явление стало массовым, назрела необходимость включить в список объектов защиты среду не только функционирования, но и разработки. Так зародилась концепция DevSecOps, которая основана на поддержке безопасности системы с момента создания среды для ее разработки.
В настоящий момент DevSecOps стала трендом, набирающим все большую популярность – проводятся семинары, конференции. Но полноценная реализация данной концепции невозможна при противоречиях с действующим законодательством.
Прежде чем перейти к анализу текущего правового поля, следует сделать одно важное замечание. Несмотря на внешнюю новизну тренда DevSecOps, схожие требования к процессу разработки, отладки и развертывания программных продуктов применялись и ранее, однако в основе мотивации к их практической реализации была ненадежность аппаратного и алгоритмического обеспечения. Например, контроль четности создавался как механизм обеспечения гарантированной передачи данных по каналам связи, а логические ошибки в программном коде могли быть результатом не злого умысла, но недоработкой конкретного языка программирования (пример – создание языка ADA, в основе дизайна которого лежит недопущение подобного рода ошибок).
Законодательство, помимо основной своей функции, заключающейся в регулировании общественных отношений, представляет собой репрезентативный показатель зрелости того или иного явления в обществе. В Российской Федерации законодательство в сфере защиты информации стало интенсивно развиваться с середины 2000-х гг., когда многим явлениям в данной сфере были даны определения, на основе которых стало возможным вести регуляторную деятельность.
На данный момент актуальными и наиболее ярко обсуждаемыми стали дополнения о безопасности критической информационной инфраструктуры Российской Федерации, фактически определяющие направление по обеспечению безопасности государства в сфере, связанной с созданием, хранением, передачей и преобразованием информации:
Стоит отметить, что деятельность регулятора в данном контексте не ограничивается – в Кодексе об административных правонарушениях (КоАП РФ) предусмотрен перечень общественно опасных деяний, связанных с разглашением либо сокрытием информации:
Виды нарушений, касающиеся самой информации и средств ее обработки, представлены в следующих статьях УК РФ: l ст. 272. "Неправомерный доступ к компьютерной информации"; l ст. 273. "Создание, использование и распространение вредоносных компьютерных программ"; l ст. 274. "Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей"; l ст. 274.1. "Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации".
С содержанием указанных статей (в актуальном состоянии) читателю предлагается ознакомиться самостоятельно. Для краткости перечислим основные выводы:
Приведенные ранее законные акты представляют собой достаточно общие по семантическому наполнению документы, из которых, однако, становится очевидной их ориентация на "водопадную" модель разработки программного обеспечения. При этом можно условно выделить три группы сред, в которых существует программное изделие:
При этом в первом и втором случае требования безопасности ориентированы на конкретные виды инструментов разработчика и тестировщика без учета особенностей конкретного программного продукта. Фактически, согласно букве закона, угроза безопасности программному продукту появляется только после того, как он развернут в рамках программно-аппаратного комплекса.
С практической точки зрения наиболее удобной "точкой входа" в массив документации, посвященной проблематике защиты информации в автоматизированных системах, является ГОСТ Р 57628–2017 "Информационная технология (ИТ). Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности". В разделе 2 "Нормативные ссылки" содержится перечень ресурсов, позволяющих разобраться с установленной терминологией, которая, в свою очередь, не вступает в явные противоречия с принятой в индустрии.
Необходимо подчеркнуть, что процесс разработки профилей защиты рассматривается с точки зрения эксплуатации системы. Под "средой" в п. 9 "Спецификация раздела "Определение проблемы безопасности" понимается именно среда функционирования. Фактически разработчик при выборе инструментария должен самостоятельно выстраивать модель угроз таким образом, чтобы, с одной стороны, обеспечивались требования DevOps в части оперативности внесения изменений в программный продукт и поставок обновлений, а с другой – чтобы сама Production-система отвечала требованиям защищенности.
Применение различных средств автоматизированного развертывания, таких как Ansible и Puppet, позволяет с достаточной степенью точности фиксировать, а затем многократно тиражировать состояние программно-аппаратной системы, что в теории должно давать 100%-ную гарантию работоспособности продукта. Предполагается также, что за счет оперативной массовой и централизованной конфигурации будет решена проблема ухода компонентов системы в закритические режимы работы и, как следствие, исключено ложное срабатывание СЗИ. Однако практика существенно отличается от теории. На деле, если разработка ведется разрозненными группами, возникает насущная проблема консолидации результатов их деятельности.
Еще одну существенную сложность вызывает выработка документации. При всех недостатках ГОСТ и их аналогов грамотно выстроенный процесс разработки позволяет порождать необходимую документацию в процессе перехода от этапа к этапу. Причем для инженера, который только начинает знакомиться с системой, сложность возрастает линейно по мере погружения в предмет исследования – от общих проблем к более частным. К сожалению (и это подтверждается в том числе и личным опытом), в случае с DevOps отсутствие формальных и жестких требований к оформлению документации приводит к тому, что инженер получает несколько ссылок на репозиторий проекта, базы знаний от разработчиков, тестировщиков, QA, техподдержки и маркетинга, а также трекеры задач и ошибок, объемы печатного текста в которых легко превышают Большую Российскую энциклопедию. При первом приближении кажется, что достижение максимальной полноты информации о производственном процессе должно способствовать разностороннему пониманию технологического процесса, однако на деле консолидация специалистов в схожих по сути, но в то же время различных по подходам предметных областях (например, тестирование и QA) требует привлечения экспертов по формализации знаний. А это существенно повышает стоимость процесса разработки и, что самое важное, негативно влияет на производительность труда.
В рамках статьи рассмотрены ключевые проблемы внедрения методологии DevSecOps в условиях российского законодательства, при несовершенстве нормативно-правовой базы и отсутствии большого числа прецедентов, не позволяющем провести полный системный анализ данного вида деятельности.
В процессе подготовки данного материала была выявлена явная необходимость в изучении подходов к созданию конкретных программных продуктов с целью разработки типовых моделей угроз с учетом их характерных особенностей.
При этом анализ динамики развития индустрии позволяет с уверенностью сказать, что по мере роста числа сотрудников, занятых решением практических задач обеспечения безопасности разработки и внедрения программных продуктов, а также их общей компетенции указанные проблемы будут разрешены.
Список литературы:
Опубликовано: Журнал "Information Security/ Информационная безопасность" #6, 2019