О стоимости одного сканирования. Продолжая тему со сканером Яндекс Клауда. 13,2 рубля / 7,2 рубля за скан это много или мало? По сравнению с бесплатными продуктами всё что угодно будет дорого, конечно. 😏 Но вот, для сравнения, цены на API кредиты Vulners (один кредит — один вызов API для проверки одного Linux хоста или Docker-образа, если не заморачиваться оптимизациями):
Получается у Яндекса как в 2–4 раза дешевле. 🙂 Но, конечно, далеко не всё определяется ценой. Нужно смотреть на реальные возможности детекта и оценивать прежде всего качество сканирования.
Про сканер уязвимостей в Yandex Cloud. На днях были новости, что Yandex открыл доступ к своему сканеру уязвимостей. Из этих новостей было не очень понятно что за сканер, для чего сканер. Но я нашел первоисточник — блогопост на сайте Яндекс Клауда.
1. Речь о сканере для Docker-образов, интегрированный в сервис Yandex Container Registry. Это аналог Aqua Trivy, Clair, Falco, Docker scan. Ну и моего Scanvus-а. 🙂 И видимо имеется ввиду Сканер уязвимостей описанный в документации, поддерживающий Alpine, CentOS, Debian, Redhat, Ubuntu в качестве ОС, на которых могут быть собраны пользовательские Docker-образы.
2. В чем преимущество: "Чтобы использовать сканер уязвимостей Yandex Cloud, не требуется выделять дополнительную инфраструктуру, обслуживать её, заниматься разворачиванием и поддержкой продукта или глобально менять процесс выкладки кода. "
3. Описание сканера частично понятно, детект по пакетам: "по результатам сканирования образа пользователь получает отчёт об уязвимостях, обнаруженных в конкретных пакетах ОС, и о версиях этих пакетов с исправлениями, если такие имеются". А то, что понимается под "сканер уязвимостей с использованием статического анализа" — загадочно.
4. Уровни сканирования: реестра целиком и выбранных репозиториев. Сканирование отдельных образов и фильтрации по тегам пока нет, но обещают.
5. Сколько стоит: "Первые шесть первичных и шесть последующих сканирований бесплатны. Начиная с седьмого раза нужно будет платить: за каждое первичное — 13,2 рубля, а за последующее — 7,2 рубля."
Некоторые заметки по итогам митапа Яндекс‑а. Зафиксирую, чтобы не забылось. Для тех, кто не смотрел, полное видео уже доступно.
1. Прикольная тема из Яндекс Финтех про "одна команда — один Golden Image":
"У нас большой стек. У нас сервисы пишутся и на Kotlin, и на плюсах, и для разных языков мы используем разные Golden Image‑ы. Но стараемся, чтобы внутри команды, которая пишет на одном фреймворке и на одном языке сформировался какой-то единый образ, который будет использоваться внутри этой команды. У нас есть набор этих золотых образов, которые используются конкретными командами. Все контейнеры, которые получаются мы пушим в наш registry. Вопрос сколько их сложный, т.к. у нас микросервисная архитектура и у нас очень много микросервисов."
➡️ Вопрос: Используете ли вы distroless образы в Банке, да и в Яндексе в целом, к примеру Google distroless, чтобы минимизировать поверхность атаки и уменьшить размер самих образов? Ответ: нет, но очень хотим к этому прийти ➡️ Вопрос: Если не секрет, что у вас за базовый образ? Аstra Linux? 😉 Ответ: отвечу, что такой же как и во всем Яндексе )
Вполне возможно это секрет полишинеля на основе какого Linux-дистрибутива базовые образы в Яндексе делают, но я не знаю. Если кто знает — шепните в личку, любопытно. 😉
2. То, что Яндекс Финтеху комфортно в Яндекс Облаке это понятное дело. Но будет ли так же комфортно другим банкам и финтехам?
➡️Вопрос: Возвращаясь к сертификации банка в облаке по стандартам PCI DSS и ГОСТам. Я смогу запустить такой банк в я.облаке и получить содействие при прохождении аудита со стороны Команды облака или это единичный случай для «родственной» компании? Ответ: Можно это получить как отдельную услугу в Облаке. ➡️ Вопрос: прям услуга Облака или рекомендованная внешняя команда? Ответ: В Облаке есть архитекторы и premium support.
3. В Wildberries и Яндекс Финтех для организации привилегированного доступа к Linux-инфраструктуре используют Teleport. Почему именно его? Как минимум половина доклада команды Wildberries была про обоснование этого выбора. Очень подробно и убедительно. Единственное жаль, что тема в основном крутилась про то как безопасно дать доступ до нужных серверов и дать/не дать root‑а, но не про хитрое ограничение прав пользователя на хосте. А это у Wildberries есть, т.к. Teleport у них сильно допиленный:
"Команда переписала админку Teleport‑а полностью с нуля. Написала свой PAM-модуль, который учитывает роли, которые передаются телепортом при аутентификации и на основе этого настраивает sudo. Но мы сегодня про это подробно не рассказывали, потому что оно опять же не поместилось."
Про sudo тема интересная, будем ждать следующего раза. 🙂
Отличные новости по моему опенсурсному проекту Scanvus! Теперь вы можете проводить проверки на уязвимости Linux хостов и докер-образов не только с помощью API от Vulners.com, но и с помощью аналогичного API от Vulns.io. Особенно приятно, что весь код для поддержки нового API коллеги из Vulns.io написали и законтрибьютили сами. Оставалось только потестить, что все работает. За это им огромное спасибо!
Чем может быть полезна поддержка двух API детекта уязвимостей в Scanvus?
1. Нет привязки к одному вендору, выбирайте чьи условия вам нравятся больше. 2. Набор поддерживаемых ОС у Vulners.com и Vulns.io различается. Если какой-то Linux дистрибутив не поддерживается у одних, он может поддерживаться у других. 3. Реализации проверок независимые. Если при сканировании одного и того же хоста/образа результаты будут различаться, то будут наглядно видны ошибки/особенности реализации. 4. Scanvus выпускается под лицензией MIT, поэтому вы можете использовать его как пример работы с API Vulners.com и Vulns.io и использовать этот код в своих проектах.
Что дальше?
В настоящий момент поддержка API Vulners.com и Vulns.io реализована в равной степени, но она реализована независимо. Скрипты инвентаризации на bash для каждого из API различаются. Также используются 2 независимые функции репортинга. Скрипты для инвентаризации видится правильным унифицировать, чтобы эти результаты инвентаризации можно было бы проверить и с помощью Vulners.com и Vulns.io. Также напрашивается создание единого формата представления результатов детектирования, к которому можно будет приводить сырые результаты от API, и который можно будет использовать для построения отчетов и дальнейших интеграций. Кажется, что на примере работы Vulners.com и Vulns.io можно отладить схему добавления новых API в Scanvus.
