Журнал "Information Security/ Информационная безопасность" #6, 2019

Фактически разработчик при выборе инструментария должен самостоятельно выстраивать модель угроз таким образом, чтобы, с одной стороны, обеспечи- вались требования DevOps в части оперативности внесения изменений в программный продукт и поставок обновлений, а с другой – чтобы сама Production-система отвечала требованиям защищенности. Еще одну существенную сложность вызывает выра- ботка документации. При всех недостатках ГОСТ и их аналогов грамотно выстроенный процесс раз- работки позволяет порож- дать необходимую докумен- тацию в процессе перехода от этапа к этапу. При этом в первом и втором случае требования безопасно- сти ориентированы на конкрет- ные виды инструментов разра- ботчика и тестировщика без учета особенностей конкретного программного продукта. Фак- тически, согласно букве закона, угроза безопасности программ- ному продукту появляется толь- ко после того, как он развернут в рамках программно-аппарат- ного комплекса. С чего начать? С практической точки зрения наиболее удобной "точкой входа" в массив документации, посвященной проблематике защиты информации в автома- тизированных системах, являет- ся ГОСТ Р 57628–2017 "Инфор- мационная технология (ИТ). Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности". В разделе 2 "Нормативные ссыл- ки" содержится перечень ресур- сов, позволяющих разобраться с установленной терминологи- ей, которая, в свою очередь, не вступает в явные противоречия с принятой в индустрии. Необходимо подчеркнуть, что процесс разработки профилей защиты рассматривается с точки зрения эксплуатации системы. Под "средой" в п. 9 "Специфика- ция раздела "Определение про- блемы безопасности" понима- ется именно среда функциони- рования. Фактически разработ- чик при выборе инструментария должен самостоятельно выстраивать модель угроз таким образом, чтобы, с одной сторо- ны, обеспечивались требования DevOps в части оперативности внесения изменений в про- граммный продукт и поставок обновлений, а с другой – чтобы сама Production-система отвеча- ла требованиям защищенности. Организация DevOps с точки зрения защиты информации Применение различных средств автоматизированного развертывания, таких как Ansi- ble и 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 Инфор- мационная технология (ИТ). Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности. l 40 • ТЕХНОЛОГИИ Ваше мнение и вопросы присылайте по адресу is@groteck.ru