ТЕХНОЛОГИИ

От DevOps к DevSecOps

Дарья Орешкина,

директор по развитию бизнеса компании Web Control

О

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ваше мнение и вопросы присылайте по адресу is@groteck.ru