Почему мечта о сдвиге влево превратилась в кошмар для специалистов по безопасности и разработчиков
Автор: Иван Миленкович, вице-президент по технологиям управления рисками в регионе EMEA, Qualys
Большую часть последнего десятилетия мы пребывали в иллюзии, что безопасность и развитие идут рука об руку. Если бы мы только могли «сдвинуться влево» и заставить разработчиков взять на себя хоть немного больше ответственности за безопасность наряду с написанием кода, тестированием и развертыванием инфраструктуры, цифровой мир стал бы более безопасным, быстрым и дешевым. Но вместо этого фундаментальный конфликт между скоростью и безопасностью только усугубился.
Почему это не сработало? Разработчики находятся под колоссальным давлением. Классический треугольник управления проектами — быстро, качественно, дешево; выберите два пункта — разбит вдребезги.
Бизнес требует, чтобы все было быстро, качественно, дешево и безопасно. Когда прижмет, всегда побеждает «быстро». В то же время мы взвалили слишком большую когнитивную нагрузку на разработчиков, которые и так были перегружены.
Когда разработчики решают использовать общедоступные образы контейнеров для ускорения разработки, они пытаются достичь своих целей, но при этом подвергают себя потенциальному риску. Как же понять, в чем заключается реальная проблема, и решить ее?
Требования бизнеса важнее рекомендаций по обеспечению безопасности
В индустрии безопасности распространено мнение, что разработчики ленивы или беспечны. Это совершенно не так. Разработчики не ленивы, они перегружены работой и являются прагматичными профессионалами, реагирующими на стимулы, которые перед ними ставят. Если их премия зависит от того, будут ли функции готовы к пятнице, а проверка безопасности занимает четыре часа и блокирует сборку, они найдут способ обойти проверку.
Компании требуют все более быстрых результатов, из-за чего протоколы безопасности стали восприниматься как препятствие для продуктивности, а не как неотъемлемая часть разработки. Если инструменты безопасности создают много шума, работают медленно и не интегрированы в рабочий процесс, они становятся препятствием.
Однако в результате организации потеряли контроль над тем, что на самом деле происходит в их средах. У нас есть конвейеры, которые автоматически развертывают код, инфраструктура, которая масштабируется без участия человека, и агенты с искусственным интеллектом, которые теперь могут писать и выполнять собственные скрипты.
В этом стремительном автоматизированном хаосе мы относимся к публичным реестрам как к тщательно отобранным библиотекам, полагая, что раз образ находится в Docker Hub, то он безопасен. Однако выбор контейнера из публичного реестра, такого как Docker Hub, — это вопрос доверия.
Такие компании, как Docker, Amazon, Google и Microsoft, используют общедоступные реестры контейнеров, поэтому вполне естественно предположить, что они безопасны.
Такое доверие неоправданно. К тому времени, когда образ контейнера попадает в конвейер развертывания, он уже является доверенным артефактом, интегрированным в приложение.
Проверка реальности 34 000 образов
Подразделение Qualys по исследованию киберугроз (Qualys Threat Research Unit, TRU) недавно провело исчерпывающий анализ более 34 000 образов контейнеров, взятых из общедоступных репозиториев, чтобы выяснить, что на самом деле скрывается за манифестом.
Из них около 2500 образов — примерно 7,3 % выборки — оказались вредоносными. 70 % вредоносных образов содержали программное обеспечение для криптомайнинга.
Кроме того, в 42 % изображений было обнаружено более пяти секретных данных, которые можно было использовать для получения доступа к другим ресурсам или учетным записям. К таким данным относятся ценные сведения, например ключи доступа AWS, токены GitHub API и учетные данные для доступа к базам данных, встроенные непосредственно в слои изображений.
Qualys Research — подборка вредоносных образов на основе анализа более 2500 подтвержденных вредоносных контейнеров, обнаруженных на DockerHub
Согласно нашему анализу, самые распространенные проблемы, связанные с вредоносными контейнерами, по-прежнему очень просты. Типосквоттинг — один из самых распространенных способов, с помощью которых злоумышленники добиваются загрузки вредоносных контейнеров. Стандартный совет «проверять орфографию» важен, но это слишком простой ответ на проблему, от которой зависит многое.
Совет разработчику «быть осторожнее» — это не стратегия обеспечения безопасности. Несмотря на то, что публичные реестры удобны для ускорения работы, мы не должны позволять разработчикам обращаться к ним.
В зрелой среде каждый внешний образ должен проходить проксирование через внутренний репозиторий артефактов, который выступает в роли карантинной зоны. Однако потребность в скорости никуда не денется. Поэтому нам нужно работать над тем, как помочь разработчикам работать быстрее, не снижая уровень безопасности.
Это действительно означает, что команде, отвечающей за инфраструктуру, придется работать больше, но эта работа позволит разработчикам двигаться вперед быстрее и с меньшими рисками.
Сдвиг вниз
Логика такова: дешевле исправить ошибку на этапе проектирования или написания кода, чем в процессе эксплуатации. Таким образом, если обеспечить безопасность на ранних этапах жизненного цикла разработки программного обеспечения (SDLC), это снизит риски в дальнейшем. Теоретически это имеет смысл, но разработчикам придется самостоятельно сканировать свой код, проверять зависимости и управлять собственной инфраструктурой.
На самом деле мы просто переложили ответственность на других. Разработчикам приходится устранять уязвимости, укреплять конфигурацию, выявлять секретные данные, проводить аудит на соответствие требованиям и так далее. При этом их оценивают в первую очередь по скорости разработки функций.
Идея «сдвига влево» заключалась в том, чтобы сделать безопасность совместной работой. Но вместо этого проблема просто переместилась в среду разработки каждого разработчика. Чтобы решить эту проблему, мы должны сделать безопасность частью инфраструктуры по умолчанию, а не по замыслу.
Это предполагает тесное сотрудничество между разработчиками и специалистами по информационной безопасности. Разработчики должны понимать, чего они хотят добиться и какие требования предъявляются к создаваемому ими продукту, а специалисты по информационной безопасности должны учитывать эти требования, чтобы обеспечить безопасность продукта. Ответственность лежит на обеих командах, но обе они должны работать с той скоростью, которая необходима бизнесу.
На практике мы можем создать для разработчиков «золотой путь». Если они используют стандартные шаблоны, предварительно одобренные базовые образы и официальные конвейеры непрерывной интеграции, то безопасность обеспечивается автоматически. Если же они хотят пойти «своим путем» и создать что-то на заказ, то им придется дополнительно проверять безопасность и настраивать все вручную.
Об этом также следует с самого начала сообщить руководству, чтобы служба безопасности и отдел разработки выступали единым фронтом в вопросе стоимости.
Такой подход стимулирует безопасное развертывание, поскольку он является наименее затратным. Ответственность смещается на уровень инфраструктуры, которым управляет специализированная команда разработчиков платформы. А если потребуется что-то другое, эту работу можно будет выполнить совместно, чтобы с первого раза все сделать правильно, а не столкнуться с новыми проблемами, которые придется устранять.
Например, вместо того чтобы просить разработчика включить управление версиями для конкретного хранилища S3, команда платформы пишет политику с использованием модулей Terraform, композиций Crossplane или Open Policy Agent, которая просто не позволяет хранить данные в хранилище без управления версиями. Разработчик буквально не может совершить ошибку.
Платформа автоматически исправляет ошибку или отклоняет запрос. Точно так же разработчикам не нужно помнить о сканировании контейнеров в своих рабочих процессах — конвейер непрерывной интеграции должен делать это автоматически. Контроллер доступа должен отклонять неподходящие образы еще до того, как они попадут в кластер. Разработчику не нужно знать, как работает сканирование, — достаточно того, что если он попытается развернуть образ с критической уязвимостью, доступ будет заблокирован.
«Сдвиг вниз» также подразумевает автоматизацию исправления. Например, если в базовом образе обнаружена уязвимость, платформа должна автоматически сгенерировать запрос на включение изменений для его обновления. Если инструмент безопасности среды выполнения обнаруживает некорректное поведение контейнера (например, запуск оболочки для сохранения данных), он должен не просто отправить предупреждение. Он должен автоматически завершить работу модуля и изолировать узел.
Вместо того чтобы придерживаться существующих подходов к обеспечению безопасности и разработке, мы должны реагировать на происходящее. Это может означать, что нам придется в корне изменить принципы взаимодействия между командами.
Если мы и дальше будем придерживаться подхода «сдвиг влево», взваливая всю когнитивную нагрузку на разработчиков, мы потерпим неудачу. Мы их выгоним, и они будут обходить наши ограничения, чтобы просто сделать то, что нужно для бизнеса.
Вместо этого служба безопасности должна проактивно подходить к внедрению и поддержке подходящих для бизнеса платформ, чтобы обеспечить их автоматическую защиту.
Редактор: AndreyEx
