infosecurity032020

Page 52

webcontrol 7/16/20 2:40 PM Page 50

ТЕХНОЛОГИИ

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

О

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

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

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

50 •

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

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

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

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


Turn static files into dynamic content formats.

Create a flipbook

Articles inside

Ньюсмейкеры

3min
pages 58-60

Новые продукты и услуги

7min
pages 56-57

ТЕХНОЛОГИИ

6min
pages 52-53

УПРАВЛЕНИЕ

10min
pages 48-51

ИЗМЕРЕНИЯ И СЕРТИФИКАЦИЯ

4min
pages 54-55

Круглый стол: диалог заказчика с производителями и интеграторами DLP

25min
pages 34-40

Колонка редактора

3min
page 41

Анна Попова

6min
pages 28-29

Вячеслав Половинко, Илья Кондратьев

5min
pages 32-33

Галина Рябова

6min
pages 26-27

Дмитрий Кандыбович

5min
pages 22-23

Степан Дешевых, Александр Клевцов

7min
pages 20-21

DLP уже не та. Как меняется функционал и формат работы с системой

4min
pages 24-25

Ксения Головко

6min
pages 18-19

ПЕРСОНЫ

10min
pages 11-13

ПРАВО И НОРМАТИВЫ

12min
pages 14-17

КИИ

6min
pages 8-10

В ФОКУСЕ

7min
pages 6-7
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.