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

Коммерческая компания или сотрудник любой организации гипотетически хотели бы добиваться восхитительных резуль- татов, быть востребованными обществом, прикладывая к этому разумные усилия. Рассмотрим прикладную задачу, состав- ляющую часть пути к успеху, – переход от DevOps к гармоничному DevSecOps. DevOps предполагает совместную работу разработчиков и служб эксплуа- тации для ускорения релиза. В случае DevSecOps при разработке ПО учиты- ваются также цели создания безопасного продукта. Какие шаги предпринять, чтобы наиболее рационально встроить средства обеспечения комплайнс и без- опасности в существующий DevOps-про- цесс? 4 ключевых ингредиента Можно сказать, смягчая аналогию из диалога выше, что разработка ПО отча- сти похожа на выпечку хлеба, где четыре основных ингредиента (мука, дрожжи, вода и соль), соединенные вместе, обра- зуют крепкую, но пластичную структуру. Для разработки ПО нужна хорошая осно- ва, которая обеспечит нужный вкус и тре- буемый результат продукции на выходе из печи. А качественная основа – это не только "красота" релиза, это еще и без- опасность. Торговля, финансы, здравоохранение, государственный сектор – требования к безопасности ПО в этих отраслях очень высоки. Однако количество разработчи- ков обычно в сотни раз превышает число специалистов по информационной без- опасности и аудиторов, поэтому проверка безопасности и комплайнса становится "узким горлышком" процесса разработки. Чтобы избавиться от этого, необходимо автоматизировать процессы обеспечения безопасности и встроить их в конвейер разработки и поставки ПО, для чего тре- буются четыре ингредиента: 1. Сдвиг задач комплайнса и безопас- ности на наиболее ранние этапы в кон- вейере разработки. 2. Интеграция автотестирования без- опасности и комплайнса в процесс непрерывной поставки. 3. Отслеживание состояний каждого шага создания продукта. 4. Наглядное представление и оценка уязвимостей безопасности. Эти четыре ключевых ингредиента помогут любой компании из любой отрасли гармонично перейти от DevOps к DevSecOps. Сдвиг задач комплайнса и безопасности на наиболее ранние этапы в конвейере разработки Как правило, разработчики создают код и отдают его на тестирование. Результатом тестирования на уязвимо- сти становится многостраничный отчет, выполнение бесчисленных рекоменда- ций из которого часто означает срыв сроков релиза. Концепция DevSecOps предполагает включение процессов идентификации, исправления и предотвращения проблем безопасности и нарушений комплайнса на наиболее ранних этапах жизненного цикла разработки. Разработчик уже при написании кода может получать реко- мендации по обеспечению его безопас- ности. В этом случае у команды есть возможность в штатном режиме исправ- лять недочеты. В идеале данные задачи должны быть автоматизированы и встроены в конвейер разработки, а перед встраиванием целесообразно провести ревизию средств тестирования безопас- ности продукта. Вполне возможно, что некоторые решения 10- или 15-летней давности можно заменить другими инструментами мониторинга безопасно- сти приложений и статического анализа кода и сделать процесс проверки на безопасность более простым и точным. Интеграция автоматических проверок безопасности, которые начинаются на этапе разработки и продолжаются вплоть до эксплуатации, позволяет гарантиро- вать безопасный код с первого коммита до окончания поддержки релиза. Shift Left ("сдвиг влево") для обес- печения безопасности и комплайнса с ранних этапов не означает, что решение этих вопросов перекладывается целиком на разработчиков. Наибольшая эффек- тивность достигается, когда разработ- чики, службы эксплуатации и информа- ционной безопасности работают над этим вместе. Интеграция автотестирования безопасности и комплайнса в процесс непрерывной поставки Автотестирование является наилучшей практикой для команд, принявших кон- цепцию непрерывной доставки. Автома- тизация тестирования комплайнса и без- опасности с помощью инструментов ста- тического анализа и композиции кода, таких как Fortify, SonarQube, White- Source, – весьма распространенный выбор для разработчиков и служб ИБ. Инстру- менты статического анализа дают воз- можность проверить, соответствует ли конкретный кусок кода требованиям без- опасности и регуляторов. В подавляющем количестве проектов активно использу- ется Open Source, поэтому инструменты автоматизации проверки компонентов с открытым исходным кодом и их зависи- мостей становятся незаменимы, в част- ности WhiteSource помогает выбрать каче- ственные компоненты на этапе их выбора и включения в проект. Лучшей практикой становится объединение результатов всех тестов с другой информацией, относя- щейся к релизу ПО, – это позволяет видеть всю картину выпуска ПО целиком и всеми заинтересованными лицами. В большинстве крупных компаний оцен- ка безопасности и комплайнса не всегда может быть представлена в виде "соот- ветствует/не соответствует". Часто вла- делец продукта, менеджеры релиза, спе- циалисты по безопасности и комплайнсу принимают решение о выпуске продукта на основе бизнес-целей, несмотря на выявленные проблемы. Немаловажный нюанс в том, что большинство из назван- ных специалистов не настолько близки к процессу разработки, как разработчики, и, возможно, они никогда не видели результаты автотестов. Но для принятия решения им нужно иметь доступ к этим результатам и понимать, что они означают применительно как к отдельным функ- циям продукта, так и к релизу в целом. 50 • ТЕХНОЛОГИИ От DevOps к DevSecOps днажды в кафе произошел занимательный диалог официанта и посетителя: – Я просил не курицу, а говядину, и не полусырую, а прожаренную. – Да, вышла небольшая ошибка, извиняемся, но у нас все свежее, так что приятного аппетита! – Я хирург. Верно ли я понял, что когда вы ко мне попадете и я вместо аппендицита удалю что-нибудь другое, потом просто извинюсь, то это будет правильно и всех устроит результат? Стоит ли уточнять, какое было тщательное обслуживание после этого… Невольно задумываешься: только ли медицина или питание должны быть безопасными и давать требуемый результат? Какова ответственность DevOps за свой продукт? Является ли экономия бюджетов основанием для выпуска уязвимых программных продуктов? О Дарья Орешкина, директор по развитию бизнеса компании Web Control