Контакты
Подписка 2021
МЕНЮ
Контакты
Подписка

От DevOps к DevSecOps

Дарья Орешкина, 04/09/20

Однажды в кафе произошел занимательный диалог официанта и посетителя:
– Я просил не курицу, а говядину, и не полусырую, а прожаренную.
– Да, вышла небольшая ошибка, извиняемся, но у нас все свежее, так что приятного аппетита!
– Я хирург. Верно ли я понял, что когда вы ко мне попадете и я вместо аппендицита удалю что-нибудь другое, потом просто извинюсь, то это будет правильно и всех устроит результат?

Стоит ли уточнять, какое было тщательное обслуживание после этого…

Невольно задумываешься: только ли медицина или питание должны быть безопасными и давать требуемый результат? Какова ответственность DevOps за свой продукт? Является ли экономия бюджетов основанием для выпуска уязвимых программных продуктов?

Автор: Дарья Орешкина, директор по развитию бизнеса компании Web Control

Коммерческая компания или сотрудник любой организации гипотетически хотели бы добиваться восхитительных результатов, быть востребованными обществом, прикладывая к этому разумные усилия. Рассмотрим прикладную задачу, составляющую часть пути к успеху, – переход от DevOps к гармоничному DevSecOps.

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

4 ключевых ингредиента

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

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

  1. 1. Сдвиг задач комплайнса и безопасности на наиболее ранние этапы в конвейере разработки.
  2. 2. Интеграция автотестирования безопасности и комплайнса в процесс непрерывной поставки.
  3. 3. Отслеживание состояний каждого шага создания продукта.
  4. 4. Наглядное представление и оценка уязвимостей безопасности.

Эти четыре ключевых ингредиента помогут любой компании из любой отрасли гармонично перейти от DevOps к DevSecOps.

Сдвиг задач комплайнса и безопасности на наиболее ранние этапы в конвейере разработки

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

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

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

Shift Left ("сдвиг влево") для обеспечения безопасности и комплайнса с ранних этапов не означает, что решение этих вопросов перекладывается целиком на разработчиков. Наибольшая эффективность достигается, когда разработчики, службы эксплуатации и информационной безопасности работают над этим вместе.

Интеграция автотестирования безопасности и комплайнса в процесс непрерывной поставки

Автотестирование является наилучшей практикой для команд, принявших концепцию непрерывной доставки. Автоматизация тестирования комплайнса и безопасности с помощью инструментов статического анализа и композиции кода, таких как Fortify, SonarQube, WhiteSource, – весьма распространенный выбор для разработчиков и служб ИБ. Инструменты статического анализа дают возможность проверить, соответствует ли конкретный кусок кода требованиям безопасности и регуляторов. В подавляющем количестве проектов активно используется Open Source, поэтому инструменты автоматизации проверки компонентов с открытым исходным кодом и их зависимостей становятся незаменимы, в частности WhiteSource помогает выбрать качественные компоненты на этапе их выбора и включения в проект. Лучшей практикой становится объединение результатов всех тестов с другой информацией, относящейся к релизу ПО, – это позволяет видеть всю картину выпуска ПО целиком и всеми заинтересованными лицами.

Снимок экрана 2020-09-03 в 15.27.18В большинстве крупных компаний оценка безопасности и комплайнса не всегда может быть представлена в виде "соответствует/ не соответствует". Часто владелец продукта, менеджеры релиза, специалисты по безопасности и комплайнсу принимают решение о выпуске продукта на основе бизнес-целей, несмотря на выявленные проблемы. Немаловажный нюанс в том, что большинство из названных специалистов не настолько близки к процессу разработки, как разработчики, и, возможно, они никогда не видели результаты автотестов. Но для принятия решения им нужно иметь доступ к этим результатам и понимать, что они означают применительно как к отдельным функциям продукта, так и к релизу в целом.

Отслеживание состояний каждого шага создания продукта

"Сдвиг влево" и интеграция проверок безопасности и комплайнса в конвейер разработки ПО создает большой объем данных. Одним из вариантов их использования является создание цепочки учета событий каждого релиза. Она представляет собой набор подробно зафиксированных результатов всех действий в процессе разработки, в которых содержится информация о том, что произошло, когда и кто это сделал. Автоматический захват данных и учет позволяют бизнесу отслеживать процесс разработки и фиксировать результаты каждого этапа, предоставлять аудиторам нужную информацию и подтверждать выполнение всех проверок. Наличие такой цепочки учета событий дает возможность провести разбор ошибок в случае сбоя, накапливая суммарные знания компании и облегчая расследование инцидентов. Кроме того, команды получают инструмент для непрерывного управления качеством продукта, обнаруживая все недочеты на самых ранних стадиях: невыполненные действия или действия, которые регулярно не выполняются либо выполняются с ошибкой, ручные процедуры, которые можно автоматизировать.

Наглядное представление и оценка уязвимостей безопасности

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

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

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

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

Фундаментальные принципы DevSecOps

Джин Кин, консультант по стратегическим вопросам компании XebiaLabs и автор ряда книг по DevOps, сформулировал ключевые принципы DevSecOps:

  1. При проектировании необходимо учитывать самые худшие сценарии. Пользователи не всегда следуют оптимальному или ожидаемому сценарию. Нужно учитывать злонамеренные пользовательские истории и проверять возможность их реализации, моделировать ландшафт угроз и проводить симуляцию разных уровней сбоев.
  2. Тестирование безопасности на каждом этапе конвейера. Можно использовать инструменты реальной атаки типа Metasploit. Безопасность должна быть не в виде бумажного документа, а в виде кода, хранящегося в репозитории, откуда его может взять любой разработчик. В конвейер должны быть встроены SAST-, DAST-, IAST-инструменты и инструменты проверки компонентов Open Source.
  3. Тренировок AppSec недостаточно. Нет также необходимости тренировать всех разработчиков писать безопасный код. Код пишут люди, и на 10 тыс. строк кода будет определенное число ошибок, часть из них приведет к уязвимостям. Тренировками эту проблему не решить. Нужны подходящие инструменты и автоматизация.
Темы:Безопасная разработкаЖурнал "Информационная безопасность" №3, 2020

Хотите сотрудничать?

Выберите вариант!

Печатное издание
Интернет-портал
Стать автором

More...