Как построить защищенную среду для разработки ПО

Здоровое недоверие — хорошая основа для совместной работы.

Иосиф Виссарионович Сталин

В условиях роста киберугроз и ужесточения регуляторных требований (например, ФЗ-152, приказы ФСТЭК) компаниям необходимо выстраивать безопасный процесс разработки ПО. Особенно это важно для крупных организаций, работающих с персональными данными, госсектором или критической инфраструктурой.

Безопасная среда разработки требует комплексного подхода: от выбора защищенных российских инструментов до внедрения процессов проверки кода и обучения команды. Крупным вендорам стоит ориентироваться не только на функциональность, но и на соответствие актуальным ИБ-стандартам.

В этой статье разберем ключевые аспекты защиты среды разработки.

Что такое среда разработки ПО?

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

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

Как разработчик пишет код?

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

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

Можно ли утверждать, что ПО создано без уязвимостей, стабильно в эксплуатации и его не взломают?

Готов ли разработчик ручаться, что детали конструкции надежны и выдержат любую атаку?

Нулевое доверие

Конечно, если разработка ведется по свободным лекалам без учета и проверки применяемых компонентов, говорить о надежности и неуязвимости не приходится. Сгустим краски. Не доверять никому из участников команды, применять только проверенные компоненты и зависимости, проводить проверки безопасности при каждом изменении в проекте, блокировать релиз при подозрении на уязвимость. Звучит строго? Да, но так ли страшен черт, как его малюют?

Защищенная интегрированная среда разработки

Предоставим разработчику комфортные условия, сохранив три основных инструмента: компьютер, ОС и IDE, а еще подключим дополнения IDE для проверки кода на уязвимости во время разработки.

Обнесем нашу стройплощадку разработки забором – создадим изолированное виртуальное локальное или удаленное окружение на базе защищенной операционной системы.

Задача разработчика на этой площадке –пилить и строгать (зачеркнуто) писать код, а установка компонентов ОС и рантайтама компиляции или запуска приложения – ответственность инженера инфраструктуры, который обеспечит установку компонентов платформы только из доверенных источников.

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

Итог наших действий – общая для всех участников проекта защищенная среда разработки. Тем из них, кому мы по-прежнему не доверяем даже после изоляции и проверки уязвимостей в коде – на лету. Но кому мы можем доверять?

Единое место доверия

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

Криптографическая целостность

Каждое сохранение изменений в репозитории – commit – имеет уникальный хэш с содержимым файлов, метаданными и ссылками на «родителей». Любое изменение ломает цепочку хэшей.

Распределенная архитектура

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

Верификация цифровой подписи

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

Git hooks

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

Ролевая модель

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

Защищенные ветки, теги, окружения

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

Git hooks на уровне сервера

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

Git – точка притяжения и единое «место истины» для команды разработки. Конечно, это не просто про хранение кода, пусть и надежное, и децентрализованное. Git – основа DevSecOps – конвейера безопасной разработки.

Конвейер безопасной разработки

Классический процесс, показывающий конвейер разработки, состоит из следующих пунктов, хитро закрученных в знак бесконечности: Plan – Develop – Build – Test – Release – Deliver – Deploy – Operate – Monitoring – Feedback.

DevSecOps-конвейер обогащает процесс проверкой безопасности, контролируя создание ПО на каждом из этапов. Его цель – реализовать принцип shift-left security — выявления и устранения уязвимостей на ранних стадиях с возможностью заблокировать всю цепочку в критических случаях. Внедрение DevSecOps сокращает затраты: дешевле устранить проблему до того, как она появится в релизе и подвергнет ПО потенциальному риску утечки данных или не выдержит кибератак.

Если два первых этапа, Plan и Develop, выполняются в большей степени локально, а Git служит доверенным хранилищем, то Build, Test, Release, Deliver, Deploy уже входят в понятие CI/CD-конвейера.

Так почему же Git –это основа DevSecOps-конвейера? Ранее в статье было упоминание современных систем контроля версий исходного кода. Их логичнее назвать платформами для работы с кодом: их функционал довольно сильно выходит за рамки стандартных возможностей Git.

Наиболее эффективная функция таких платформ – возможность построить конвейер непрерывной интеграции и доставки. Этапы Build, Test, Release, Deliver и Deploy полностью входят в эту парадигму. Построение конвейера происходит декларативно: сценарии этапов описывают в yaml-файле, который хранится в проекте вместе с исходным кодом. На каждом из этапов подключается или внешний многоцелевой сервис проверки, работающий по API, или специализированная утилита, работающая в режиме командной строки и внедренная на уровне конфигурации этапа конвейера. Платформа инициирует запуск проверок, в случае критических срабатываний останавливает конвейер и выводит результирующие данные в информационных дашбордах.

Другая, не менее важная, функция платформы – это хранилище артефактов: пакетов, зависимостей, релизов и докер-образов, любых двоичных файлов, которые требуются для сборки и эксплуатации приложения. Загружаемый в хранилище контент проверяется сервисами безопасности и блокируется в случае обнаружения критических угроз.

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

Несколько слов в заключение

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

Роман Байталов, архитектор системных решений GitFlic, «Группа Астра».