Проблемы реализации концепции DevSecOps в действующем нормативно-правовом поле

В данной статье приводится анализ актуального среза законодательно-правовых актов в сфере защиты информации с точки зрения обеспечения безопасности процесса непрерывной разработки и интеграции программных продуктов в рамках реализации концепции DevOps. В ней также рассмотрены актуальные законные акты, проведена оценка их практический реализуемости и определен ряд критических вопросов, подлежащих дальнейшему анализу.

Александр Буравцов
Руководитель службы информационной безопасности компании “Новые Облачные Технологии”

Александр Мелихов
Системный инженер службы информационной безопасности компании “Новые Облачные Технологии” 

Основным фактором бурного развития информационных систем является оперативное обновление программного обеспечения. В свою очередь, повышение оперативности потребовало коренных изменений в технологической цепочке производства программных продуктов: темпы разработки ускорились, уровень технической осведомленности пользователя за последние 20 лет существенно вырос, потребители стали более ответственно выбирать решения. При этом важным конкурентным преимуществом является наличие технической поддержки и возможности устранять ошибки и расширять функциональность программных систем в режиме непрерывного обновления. Возникли такие понятия, как CI (Continuous Integration – постоянная интеграция, оперативное расширение функциональности) и CD (Continuous Delivery – постоянная поставка, в значении "дистрибуция"), а также обобщенное понятие CI/CD. Концепция организации технологического процесса, в которой реализуется CI/CD, получила название DevOps (Development Operations).

В основе DevOps лежит методология гибкой разработки программных продуктов. Гибкость предполагает жесткое разделение полномочий между участниками процесса при высокой степени автоматизации процессов сборки, тестирования и развертывания. Применение данного подхода позволяет создавать масштабные программные продукты, делегируя задачи производства и контроля качества сравнительно небольшим командам специалистов, наращивая по мере увеличения числа программных модулей количество команд и перераспределяя их полномочия.

Основной (и на данный момент неразрешенной) проблемой гибкой разработки является обеспечение безопасности производственного процесса. Локус внимания экспертов по безопасности DevOps направлен на то, чтобы не дать потенциальному злоумышленнику внести в работающую систему изменения, которые приведут к изменениям в логике обработки информации – повышению привилегий доступа с последующим изменением, удалением и/или разглашением хранящихся в системе сведений об объектах реального или виртуального мира. Однако сама среда предприятия, в рамках которой производится разработка программных продуктов, также может стать объектом исследования, а затем и атаки.

По мере того как данное явление стало массовым, назрела необходимость включить в список объектов защиты среду не только функционирования, но и разработки. Так зародилась концепция DevSecOps, которая основана на поддержке безопасности системы с момента создания среды для ее разработки.

В настоящий момент DevSecOps стала трендом, набирающим все большую популярность – проводятся семинары, конференции. Но полноценная реализация данной концепции невозможна при противоречиях с действующим законодательством.

Актуальные законодательно-правовые акты в части защиты информации

Прежде чем перейти к анализу текущего правового поля, следует сделать одно важное замечание. Несмотря на внешнюю новизну тренда DevSecOps, схожие требования к процессу разработки, отладки и развертывания программных продуктов применялись и ранее, однако в основе мотивации к их практической реализации была ненадежность аппаратного и алгоритмического обеспечения. Например, контроль четности создавался как механизм обеспечения гарантированной передачи данных по каналам связи, а логические ошибки в программном коде могли быть результатом не злого умысла, но недоработкой конкретного языка программирования (пример – создание языка ADA, в основе дизайна которого лежит недопущение подобного рода ошибок).

Законодательство, помимо основной своей функции, заключающейся в регулировании общественных отношений, представляет собой репрезентативный показатель зрелости того или иного явления в обществе. В Российской Федерации законодательство в сфере защиты информации стало интенсивно развиваться с середины 2000-х гг., когда многим явлениям в данной сфере были даны определения, на основе которых стало возможным вести регуляторную деятельность.

Перечень основных статей

На данный момент актуальными и наиболее ярко обсуждаемыми стали дополнения о безопасности критической информационной инфраструктуры Российской Федерации, фактически определяющие направление по обеспечению безопасности государства в сфере, связанной с созданием, хранением, передачей и преобразованием информации:

• Федеральный закон от 26 июля 2017 г. № 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации";
•  приказ ФСТЭК России от 25 декабря 2017 г. N 239 "Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации" (в ред. приказа ФСТЭК России от 26 марта 2019 г. № 60).

Стоит отметить, что деятельность регулятора в данном контексте не ограничивается – в Кодексе об административных правонарушениях (КоАП РФ) предусмотрен перечень общественно опасных деяний, связанных с разглашением либо сокрытием информации:

• ст. 5.39. "Отказ в предоставлении информации";
• ст.13.11. "Нарушение законодательства Российской Федерации в области персональных данных";
• ст. 13.11.1. "Распространение информации о свободных рабочих местах или вакантных должностях, содержащей ограничения дискриминационного характера";
• ст. 13.12. "Нарушение правил защиты информации";
• ст.13.13. "Незаконная деятельность в области защиты информации";
• ст. 13.14. "Разглашение информации с ограниченным доступом".

Виды нарушений, касающиеся самой информации и средств ее обработки, представлены в следующих статьях УК РФ: l ст. 272. "Неправомерный доступ к компьютерной информации"; l ст. 273. "Создание, использование и распространение вредоносных компьютерных программ"; l ст. 274. "Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей"; l ст. 274.1. "Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации".

Основные выводы

С содержанием указанных статей (в актуальном состоянии) читателю предлагается ознакомиться самостоятельно. Для краткости перечислим основные выводы:

1. Информационная система и содержащаяся в ней информация – различные сущности.
2. Перечень нарушений, связанных с информацией, не зависит от вида ее материального носителя, защите подлежит именно семантическая составляющая.
3. Государственная и коммерческая тайна как объект защиты ассоциируются в первую очередь с организацией (государством или частной компанией), при этом нарушителем может стать как организация, так и частное лицо.
4. Частное лицо получило возможность отстаивать свои права на доступ к информации, а также на защиту персональных данных, т.е. фактически гражданин получил возможность быть не только защищающейся стороной в случае конфликтов.
5. Помимо транспортной, энергетической и др., государство признает существование информационной инфраструктуры, т.е. защищаются не только физические каналы хранения и передачи данных, но и семантическое их наполнение, даже в случаях, когда оно не является объектом государственной тайны.

Приведенные ранее законные акты представляют собой достаточно общие по семантическому наполнению документы, из которых, однако, становится очевидной их ориентация на "водопадную" модель разработки программного обеспечения. При этом можно условно выделить три группы сред, в которых существует программное изделие:

1. среда разработки (создание, компиляция);
2. среда тестирования (тестирование и QA);
3. среда функционирования (в которой продукт выполняет непосредственные функции).

При этом в первом и втором случае требования безопасности ориентированы на конкретные виды инструментов разработчика и тестировщика без учета особенностей конкретного программного продукта. Фактически, согласно букве закона, угроза безопасности программному продукту появляется только после того, как он развернут в рамках программно-аппаратного комплекса.

С чего начать?

С практической точки зрения наиболее удобной "точкой входа" в массив документации, посвященной проблематике защиты информации в автоматизированных системах, является ГОСТ Р 57628–2017 "Информационная технология (ИТ).

Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности". В разделе 2 "Нормативные ссылки" содержится перечень ресурсов, позволяющих разобраться с установленной терминологией, которая, в свою очередь, не вступает в явные противоречия с принятой в индустрии.

Необходимо подчеркнуть, что процесс разработки профилей защиты рассматривается с точки зрения эксплуатации системы. Под "средой" в п. 9 "Спецификация раздела "Определение проблемы безопасности" понимается именно среда функционирования.

Фактически разработчик при выборе инструментария должен самостоятельно выстраивать модель угроз таким образом, чтобы, с одной стороны, обеспечивались требования DevOps в части оперативности внесения изменений в программный продукт и поставок обновлений, а с другой – чтобы сама Production-система отвечала требованиям защищенности.

Организация DevOps с точки зрения защиты информации

Применение различных средств автоматизированного развертывания, таких как Ansible и Puppet, позволяет с достаточной степенью точности фиксировать, а затем многократно тиражировать состояние программно-аппаратной системы, что в теории должно давать 100%-ную гарантию работоспособности продукта. Предполагается также, что за счет оперативной массовой и централизованной конфигурации будет решена проблема ухода компонентов системы в закритические режимы работы и, как следствие, исключено ложное срабатывание СЗИ. Однако практика существенно отличается от теории. На деле, если разработка ведется разрозненными группами, возникает насущная проблема консолидации результатов их деятельности.

Еще одну существенную сложность вызывает выработка документации. При всех недостатках ГОСТ и их аналогов грамотно выстроенный процесс разработки позволяет порождать необходимую документацию в процессе перехода от этапа к этапу.

Причем для инженера, который только начинает знакомиться с системой, сложность возрастает линейно по мере погружения в предмет исследования – от общих проблем к более частным. К сожалению (и это подтверждается в том числе и личным опытом), в случае с DevOps отсутствие формальных и жестких требований к оформлению документации приводит к тому, что инженер получает несколько ссылок на репозиторий проекта, базы знаний от разработчиков, тестировщиков, QA, техподдержки и маркетинга, а также трекеры задач и ошибок, объемы печатного текста в которых легко превышают Большую Российскую энциклопедию. При первом приближении кажется, что достижение максимальной полноты информации о производственном процессе должно способствовать разностороннему пониманию технологического процесса, однако на деле консолидация специалистов в схожих по сути, но в то же время различных по подходам предметных областях (например, тестирование и QA) требует привлечения экспертов по формализации знаний. А это существенно повышает стоимость процесса разработки и, что самое важное, негативно влияет на производительность труда.

Заключение

В рамках статьи рассмотрены ключевые проблемы внедрения методологии DevSecOps в условиях российского законодательства, при несовершенстве нормативно-правовой базы и отсутствии большого числа прецедентов, не позволяющем провести полный системный анализ данного вида деятельности.

В процессе подготовки данного материала была выявлена явная необходимость в изучении подходов к созданию конкретных программных продуктов с целью разработки типовых моделей угроз с учетом их характерных особенностей.

При этом анализ динамики развития индустрии позволяет с уверенностью сказать, что по мере роста числа сотрудников, занятых решением практических задач обеспечения безопасности разработки и внедрения программных продуктов, а также их общей компетенции указанные проблемы будут разрешены.

Список литературы

1. Вехен Дж. Безопасный DevOps. Эффективная эксплуатация систем. СПб.: Питер, 2020. – 432 с.
2. What is DevSecOps? https://www.redhat.com/en/top-ics/devops/what-is-devsecops.
3. Выписка из Примерного перечня измерительных приборов, испытательного оборудования, программных (программно-аппаратных) средств, необходимых для выполнения работ в соответствующей области аккредитации в отношении средств защиты информации от несанкционированного доступа и средств обеспечения безопасности информационных технологий, утвержденного ФСТЭК России 10 февраля 2016 г. https://fstec.ru/compo-nent/attachments/download/889.
4. ГОСТ Р 57628–2017 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности.