Идем в DevSecOps: чем эта роль отличается от DevOps и кому подходит

Термин DevSecOps — сокращение от английских Development, Security и Operations. Так называют подход, который сводит в одном процессе три направления: разработку, безопасность и эксплуатацию. А вырос он из той же проблемы, из которой когда-то возник DevOps: из разрыва между командами. Этот разрыв случался, когда разработка передавала готовый код команде эксплуатации, которая затем запускала и поддерживала приложение. Проблема была в том, что каждая команда видела прежде всего свой участок работы и приложение словно перебрасывали через стену. DevOps помог эту стену убрать, но осталась еще одна — между инженерами и специалистами по безопасности. .

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

Я с этим столкнулся в свой первый год в DevOps, когда поддерживал приложение, поиск в котором был построен на Elasticsearch. Наш Elasticsearch «торчал наружу», то есть был напрямую доступен из интернета. А в то время как раз гремел Log4Shell — критическая уязвимость в Log4j, библиотеке, с помощью которой огромное количество Java-приложений ведет журналы событий, записывая, что происходит во время работы. И была проблема: на уязвимом сервере Log4Shell могла позволить атакующему удаленно запускать свои команды.

Про нее тогда писали, кажется, все, и я о ней знал. Но атака всё равно до нас «доехала»: через Log4Shell зашли в наш Elasticsearch. Данные не украли, ничего не вынесли, но снесли поисковые индексы. В итоге поиск просто перестал работать в приложении. Мы починили это за пару часов, но заметили это поздно: никакой мониторинг не помог.

Больно не было, но меня озадачило другое. Между публичной уязвимостью, про которую знал весь интернет, и сервисом, который в этот интернет «смотрел», не стояло вообще ничего. Ни процесса обновлений, ни ревизии того, что «торчит наружу», ни оповещения о том, что с сервисом происходит что-то странное.

Почему проверка перед релизом становится узким местом? Ответ лежит на поверхности. Как и всё, за что берутся в последний момент, она проводится в спешке. Сначала на нее закладывают время, потом откладывают до последнего, а затем просят «посмотреть быстренько».

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

Отсюда главная мысль подхода, который называют shift left: «сдвиг влево», то есть перенос проверок ближе к началу разработки.

Под shift left часто понимают конкретное действие: «поставить сканер пораньше». Но такое понимание поверхностное, потому что смысл подхода не в инструментах. Важно, кто принимает решение и на каком этапе ошибку еще можно исправить без дорогой переделки.

Так вот, сканер может формально «стоять слева» от релиза, но если он запускается в конце конвейера, то решение к тому моменту уже принято. Его предупреждение лишь создаст конфликт.

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

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

Делает DevOps

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

Добавляет DevSecOps

Ищет возможные пути атаки. Например, проверяет, какие сервисы будут доступны из интернета и действительно ли им нужен такой доступ.

Делает DevOps

Автоматически собирает программу и запускает тесты.

Добавляет DevSecOps

Подключает SAST — сканер исходного кода. Он ищет конструкции, которые могут привести к уязвимостям, таким как утечка данных или обход авторизации.

Делает DevOps

Передает конвейеру данные, необходимые для подключения к серверам и облачным сервисам.

Добавляет DevSecOps

Следит, чтобы пароли и токены — цифровые ключи доступа — не хранились прямо в коде. Если разработчик случайно добавит такой ключ, проверка не пропустит изменение дальше.

Делает DevOps

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

Добавляет DevSecOps

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

Делает DevOps

Автоматически создает серверы, базы данных, сети и другие ресурсы.

Добавляет DevSecOps

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

Делает DevOps

Упаковывает приложение вместе с нужными ему компонентами в контейнер и отправляет этот пакет на сервер.

Добавляет DevSecOps

Проверяет не только само приложение, но и всю его «упаковку». Уязвимость может скрываться в операционной системе или системной библиотеке внутри контейнера.

Делает DevOps

Останавливает релиз, если приложение не собралось или не прошло функциональные тесты.

Добавляет DevSecOps

Вводит дополнительное условие, при котором обновление нельзя выпускать, пока в нем остается критическая уязвимость.

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

Делает DevOps

Убеждается, что сервис открывается, отвечает на запросы и выдерживает нагрузку.

Добавляет DevSecOps

Запускает DAST — проверку приложения снаружи, как если бы к нему обращался злоумышленник. Так можно обнаружить, например, административную страницу без защиты.

Делает DevOps

Следит за скоростью, ошибками и доступностью сервиса. При сбое перезапускает его или откатывает обновление.

Добавляет DevSecOps

Отслеживает еще и признаки атаки: множество неудачных входов, необычный трафик или неожиданные действия учетной записи.

Делает DevOps

Восстанавливает работу системы и выясняет причину сбоя.

Добавляет DevSecOps

Закрывает путь атаки: отзывает украденные ключи, обновляет уязвимый компонент и добавляет в конвейер проверку, которая не даст проблеме повториться.

Теперь о том, во что этот подход превращается на практике. Моя обычная неделя складывается из четырех вещей:

• триаж уязвимостей,
• аудиты,
• автоматизация,
• работа с конвейерами.

Триажом называют разбор того, что нашли сканеры. Инструмент выдает список находок, где всё вперемешку: реальные угрозы, уязвимости, которые невозможно использовать в вашей конфигурации, и просто ложные срабатывания. Задача инженера состоит в том, чтобы понять, что чинить сегодня, что отложить до следующей недели, а что можно закрыть с обоснованием.

Для каждой находки вопросы одни и те же:

• используется ли уязвимый участок кода?
• можно ли добраться до него снаружи, например из интернета или другой системы?
• что произойдет, если это всё-таки удастся?

Это, пожалуй, самая недооцененная часть работы, но она необходима: без триажа сканер производит шум.

Аудиты показывают, как сервисы и доступы устроены на самом деле, потому что документация нередко рассказывает совсем другую историю. А автоматизация и конвейеры в практике DevSecOps’а остаются той же работой, которой занимается DevOps-инженер. Просто внутрь добавляются проверки безопасности.

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

Со стороны такая зона ответственности выглядит вспомогательной, ведь продукт создают другие команды, а мы «только следим» за средой и инструментами. Но достаточно посмотреть, что через эту инфраструктуру проходит. Это весь код, который пишет компания, и все зависимости, которые она к себе тянет. Все сборки, которые отправляются дальше.

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

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

Это и мой путь, так что знаю о нем не понаслышке. Что дает опыт работы в DevOps? У вас уже есть конвейер, инфраструктура и рабочие отношения с разработчиками. Остается добрать понимание угроз и основных классов уязвимостей.

В этом случае ваша сильная сторона в том, что вы хорошо знаете код и понимаете, как в нем появляются ошибки. Зато инфраструктуру, эксплуатацию и сети придется осваивать почти с нуля.

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

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

Допустим, вы из DevOps. Если так, то у вас уже есть нужная база: вы умеете собирать конвейер, читать чужие конфигурации, разбираться в незнакомой инфраструктуре и договариваться с людьми. Всё это — основной инструментарий. Не хватает только привычки спрашивать «что здесь может пойти не так?» раньше, чем это сделает кто-то другой.

Если вы из «разрабов» или «инфобеза», то будет немного сложнее. Но всем, вне зависимости от точка входа, рекомендую начать работу на новом месте в DevSecOps со следующих шагов.

Выпишите, какие системы доступны из интернета и когда они в последний раз обновлялись. Это самая скучная часть работы, которая при этом чаще всего и находит проблему. Мой Elasticsearch был бы виден за пять минут такой проверки. Затем пройдите по автоматическим задачам конвейера и проверьте, какие данные передаются через переменные окружения и что попало в репозиторий вместе с кодом. Упражнение на полчаса, которое почти всегда что-нибудь находит.

Отдельно проверьте всю историю репозитория, а не только его текущее состояние. Токен, удаленный следующим коммитом, остается в истории.

Пока «наружу смотрит» то, что не должно, проверка кода не решает главную проблему. Сначала разберитесь с доступами и ограничьте системы, которые видны из интернета. Только потом ставьте первый сканер.

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

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

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

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

Разработчику проще начать со своего репозитория. Инфраструктура вам, скорее всего, недоступна, а код виден полностью. Начните с третьего шага. Выберите одну проверку. Вы лучше других поймете, какая находка настоящая, потому что знаете, вызывается ли уязвимая функция. И осваивайте параллельно инфраструктуру: без нее дальше не уехать.

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

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

Я пришел в DevSecOps не напрямую. Начинал системным администратором, затем занимался информационной безопасностью, аудитами и комплаенсом, а позже перешел в DevOps. В компании, которая разрабатывала MES-систему для тяжелой промышленности, мне поручили встраивать инструменты безопасности в пайплайны. Так две линии моего опыта начали работать вместе: автоматизация соединилась с ИБ.

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

Но DevSecOps — это не только про набор технических навыков. Скорее про особый взгляд на систему. Разработчик обычно думает, что произойдет, если пользователь случайно нажмет не ту кнопку или введет неверные данные. Специалист по безопасности задает другие вопросы: а что, если намеренно использовать систему не так, как задумано? Что произойдет дальше?

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

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

Со временем такой образ мыслей превращается в профдеформацию. Даже в обычной жизни я начинаю автоматически перебирать возможные риски.

Я начинал работать по специальности в информационной безопасности. Поначалу занимался автоматизацией в подразделении, связанном с аттестацией по инфобезу. Позднее подключился к команде своего бывшего преподавателя, а затем мы все вместе вошли в YADRO. Там задачи стали гораздо ближе к DevSecOps: мы работаем с пайплайнами, настраиваем проверки, занимаемся харденингом и другими вещами на стыке эксплуатации и защиты.

Назвать момент, когда я ощутил себя именно DevSecOps-инженером, не могу. Эта специализация как-то сама вошла в мою жизнь. Думаю, так выглядит нормальное профессиональное развитие: ты берешь одну задачу, другую, постепенно расширяешь инструментарий, а спустя время понимаешь, что работаешь уже в другой части инженерного поля.

Главный вызов для новичка в DevSecOps — прийти к принципу нулевого доверия. Это особый тип мышления — критический взгляд на всё. Нельзя считать технологию безопасной лишь потому, что она привычна, находится внутри корпоративного контура или раньше не создавала проблем. Любое такое доверие должно на чем-то основываться и регулярно подтверждаться.

В какой-то момент начинаешь постоянно спрашивать себя: почему я этим пользуюсь, почему считаю этот компонент надежным, как он работает внутри и что произойдет, если исходное предположение неверно?

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

В YADRO я не только практикующий специалист. Мне важно делится своими знаниями с другими и делать это в том числе вне своего рабочего места. К примеру, здесь, с аудиторией «Истового инженера», или в Школе DevOps, где я веду блоки по DevSecOps.

Это бесплатный курс YADRO для студентов второго курса и старше. Курсы запускают дважды в год, осенью и весной. Обучение длится 8−10 недель, занятия проходят раз в неделю. Осенний поток идет с октября по декабрь, весенний с марта по май. Участвовать можно онлайн или очно в офисах YADRO в Москве, Санкт-Петербурге и Нижнем Новгороде.

Моя часть курса состоит из дополнительных блоков. В этом году их было три:

• «Безопасность Docker»
• «SSDLC и безопасный CI»
• «Безопасность Kubernetes».

Насколько глубоко студенты в это «закапываются», хорошо показывает случай с прошлого потока, когда два моих слушателя выявили проблему в работе Kubernets, исследовали ее причины и написали об этом на Хабре.

Хотя так глубоко копают не все: студенты разные.

Многие приходят с представлением, с которым и я начинал: безопасность это технический инструмент, поставил сканер и закрыл вопрос. Моя задача — чтобы ушли они с пониманием: даже если они не собираются ею заниматься, она всё равно будет присутствовать в их жизни. Без спроса.

Я рассказываю студентам за три занятия то, до чего сам доходил через сломанные индексы, месяцы лишних сканеров и объяснения руководству. Так что если после этого текста захочется «попробовать в DevSecOps» не в одиночку, приходите. Набор объявляют на странице практических курсов YADRO.