В марте IT-сообщество возмутили новости о том, что в некоторых OpenSource-продуктах обнаружили вредоносы. Многие задумались, как защититься от опасного ПО. Рекомендации по безопасности дают Павел Селиванов, архитектор в Yandex.Cloud, и Дмитрий Евдокимов, Founder и CTO компании Luntry.
Материал написан по вебинару Слёрма «Обеспечение безопасности в текущих условиях: что делать с OpenSource», который прошёл 25 марта 2022 года.
Проблема с OpenSource-компонентами была всегда
Вероятность, что в OpenSource-коде окажется малварь или что OpenSource-продукт станет недоступным, была всегда. Более того, известны случаи, когда создатели сами удаляли свою разработку или добавляли в неё вредоносы, что наносило ущерб пользователям. Текущая ситуация ярко подсветила эту проблему, но она не новая.
Некоторые компании уже давно задумались о независимости от OpenSource и обезопасили свои системы от подобных ситуаций. Они руководствуются принципом «даже если весь интернет упадёт, наш CI/CD должен работать» и переносят чужой код в свои репозитории, ревьюят его, их сборка не зависит от коннекта в интернет. Однако для большинства бизнесов думать о безопасности OpenSource-компонентов — всё-таки новая практика.
Теперь многие компании будут проверять и перепроверять свой код, сторонние библиотеки и плагины, которыми пользуются. Более того, придётся своими силами или с привлечением третьей стороны проводить аудит кода, который отдаётся на аутсорс. Известны случаи, когда в код на аутсорсинге добавлялась вредоносная функциональность. Из-за этого разработка станет дороже.
Как обнаружить вредоносы
Обнаружить вредоносы в OpenSource-коде сложно, потому что добавить малварь в проект можно миллионом способов: одним коммитом или серией, через обновление или динамически. Например, у вирусописателей была такая практика. Они покупали популярное android-приложение и добавляли малварь в обновление. Пользователи обновляли программу и цепляли вирус.
Кроме того, любой код содержит уязвимости, бэкдоры и т. д. Сложность в обнаружении вредоносов состоит ещё и том, что не всегда понятно: разработчик допустил уязвимость специально или по ошибке.
По этим причинам нет серебряной пули, которая могла бы найти весь опасный код в OpenSource-компонентах. Однако обезопасить свою систему от вредоноса помогут рекомендации ниже.
Как защититься от вредоноса
Разберём действия, которые помогут защититься от зловредного кода в OpenSource-составляющих.
Во-первых, следует строить системы, которые соответствуют концепции «нулевого доверия» (Zero Trust). В частности, стоит обратить внимание на микросегментацию и принцип минимальных привилегий.
Микросегментация — это разделение корпоративной сети или других ресурсов на небольшие узлы со своими политиками безопасности и правами доступа. На практике одно из таких решений — микросервисная архитектура: если в контейнер попадёт вредоносный код, его можно быстро убить и предотвратить распространение по всей инфраструктуре.
Кроме того, стоит задействовать дополнительные подходы безопасности. Например, в Kubernetes есть поддержка AppArmor profile. Она позволяет указать конкретный процесс, который должен запускаться в контейнере. Если злоумышленник попытается запустить в там что-то ещё, у него ничего не получится.
Суть принципа минимальных привилегий: каждому пользователю даётся столько прав, сколько необходимо для выполнения его обязанностей. Таким образом, даже если аккаунт отдельного пользователя взломают, будет скомпрометирована только часть ресурсов, а не вся инфраструктура.
Во-вторых, использовать OpenSource-компоненты с большим комьюнити. Чем больше и популярнее проект, библиотека, плагин, тем меньше вероятность, что в него добавят вредонос. В тот же Kubernetes сложно внедрить малварь — за K8s огромное сообщество, которое смотрит каждый коммит и обсуждает в Kubernetes Enhancement Proposals.
Другой вопрос с библиотекой от noname-разработчика, которую используют один-два человека. В неё добавить вредонос не составит труда. Так что выбирая OpenSource-составляющие, обращайте внимание на популярность проекта и наличие комьюнити.
В-третьих, проверять код в закрытых окружениях для тестирования. Например, такая практика есть в Яндексе: весь чужой код проверяется на наличие зависимостей. Его собирают и деплоят в закрытое окружение. Если сборка не проходит, значит, есть внешние зависимости, от которых нужно избавиться.
Как автоматизировать поиск вредоносного кода? Пока такой возможности нет по причинам, которые мы озвучили выше. Придётся ревьюить код вручную. Статистические анализаторы можно использовать для перестраховки, но особо надеяться на них не стоит. Они способны находить только совсем простые вещи — если попадётся что-то посложнее, статистические анализаторы не распознают угрозы.
В-четвёртых, делать зеркала важных OpenSource-компонентов или завести прокси с кэшированием используемых библиотек. К примеру, Nexus может быть проксирующим кэшем для сторонних репозиториев, в том числе для NPM, RPM, Docker Registry и т. д. Если ремоуты станут недоступными, библиотеки удастся получить из кэша Nexus. Это не идеальный вариант, но он даст время, чтобы определить дальнейший план действий.
Безопасность в Kubernetes
Может ли вредонос попасть в кластер Kubernetes? Как мы уже говорили выше, такое вряд ли произойдёт: у K8s большое комьюнити, которое зорко следит за каждым релизом.
Кроме того, Kubernetes — де-факто стандарт оркестрации, который использует весь мир. В Google идут к тому, чтобы максимально обезопасить процесс разработки K8s и сделать его доверенным в основных компонентах.
С версии 1.15 Kubernetes полностью ушёл на Distroless. В первую очередь это обусловлено безопасностью — теперь в контейнерах нельзя породить шеллы, там только бинари, которые нужны для запуска. При этом уход на Distroless значительно уменьшил количество сторонних зависимостей от операционной системы и т. д.
Кроме этого, с версии 1.23 Kubernetes начал соответствовать первому уровню Supply-chain Levels for Software Artifacts (SLSA). SLSA предназначен для защиты от supply chain-атак — попыток внедрения вредоносного кода в процессе разработки ПО. Он состоит из четырёх уровней защиты: первый — самый низкий, четвёртый — самый высокий.
Первый уровень означает, что для основных контейнеров Kubernetes генерируются software bills of materials (SBOM-ы) — списки компонентов, которые в них входят. Теперь можно скачать SBOM на все исполняемые контейнеры и быстро узнать, из каких сторонних зависимостей они состоят. Больше не нужно самим насканивать эти зависимости сканерами уязвимостей.
Google планирует, что с версии 1.24 Kubernetes будет соответствовать уровню 2. В этом случае SBOM уже не просто генерируется, но и перепроверяется при переходе системы на следующий уровень SLSA.
Managed-решения: да или нет
Второй момент, который сейчас ярко подсветился — по разным причинам могут быть удалены или заблокированы managed-решения, на которых работает часть инфраструктуры, кода, бизнес-логики.
Поэтому важно помнить: передавая что-либо на аутсорс, нельзя передавать мозги — ответственность за архитектуру сервиса в любом случае лежит на его владельце. Managed-решения упрощают разработку и сопровождение, но также несут много рисков. Тем, кто использует зарубежные сервисы, возможно, следует присмотреться к местным managed-решениям (по крайней мере в качестве резервных вариантов).
Резюме
Нет серебряной пули, которая позволила бы найти все вредоносы в OpenSource-компонентах. Обезопасить свою инфраструктуру помогут следующие действия:
Строить системы, которые соответствуют концепции «нулевого доверия» (Zero Trust). В частности, микросегментация и принцип наименьших привилегий.
Использовать OpenSource-компоненты с большим комьюнити.
Вручную проверять и перепроверять код в закрытых окружениях.
Делать зеркала важных OpenSource-компонентов или завести прокси с возможностью кэширования.
Также важно понимать, от каких managed-решений зависит сборка, и иметь запасные варианты на случай их недоступности или выхода из строя.
От редакции: больше знаешь о Kubernetes — крепче спишь ;)
Приглашаем на курс «Kubernetes: Мега-поток», который стартует 12 апреля. Во время обучения мы заглянем под капот Kubernetes, а также узнаем больше о безопасности и отказоустойчивости.
Тема №5 курса посвящена инструментам Kubernetes, которые позволяют сделать работу в Kubernetes более безопасной, а приложение более отказоустойчивым. В современных реалиях — это очень актуально.
Интересные статьи
Интересные статьи
