Мы очень давно — более 10 лет — говорим о безопасности k8s. Это второй опенсорс-проект в мире после Linux, а в РФ только «ванильным кубом» пользуются более 53% компаний (не считая коммерческие и облачные Managed K8s), десятки best practices и подходов, а инструментов только под Security больше 100.
Казалось бы, всё должно быть хорошо.
Однако с безопасностью k8s всё ещё плохо. К примеру, судя по отчёту Red Hat «State of Kubernetes Security 2024» в 2024, 46% компаний понесли убытки из-за недостаточной безопасности Kubernetes, в 9 из 10 организаций произошел минимум один инцидент, связанный с безопасностью контейнеров или Kubernetes.
Причина проста — инструменты сами по себе не дают требуемого уровня безопасности. Поставить сканер — не значит быть защищенным. Включить политики — не значит, что они работают. Написать требования — не значит, что их будут выполнять.
Здесь нужен системный подход. Я говорю это не просто так. До того, как у нас появился системный подход, требования жили отдельно, инциденты отдельно, аудиты отдельно, и разные команды решали одну и ту же проблему совершенно по-разному. Страшно говорить, но мы даже не знали, сколько у нас кластеров, какие они и где. Это тот случай, когда незнание не освобождает от ответственности.
Собственно, я хочу рассказать, как мы строили системный подход обеспечения ИБ кластеров Kubernetes. Меня зовут Александр, я лид отдела безопасности K8S и облаков в Альфа-Банке. Моя статья об этом — как выстроить безопасность K8S как систему (функцию) в компании и масштабировать её в окружении сотен кластеров. Обсудим, какие процессы работают, какую зону ответственности должна занимать команда и как её собрать.
Сразу оговорюсь — моя статья не туториал о том, как настроить очередной инструмент или закрыть угрозу одним из десяти способов (что, безусловно, важно), она о процессах и будет интересна, в первую очередь, лидам.
Карта процессов как система
Процессы — это база. В самом начале работы с кластерами я думал, что причешу все кластеры по очереди: ревью пулл-реквестов на сетевые политики, роли и т.д. Проекты этого кластера проверю, думал я, и пойду дальше. Это не работает. Всё превращалось в день сурка. Снежный ком копился, а я не успевал.
Потом решил, что поставлю коммерческий продукт, настрою и будет счастье. Но поставить и настроить несложно, а вот процессы подключения кластеров и поддержку самого решения и его агентов, обновлений на эти сотни, обработку всех результатов никто не отменял.
Как говорил ранее, можно выбрать набор тулов из сотни инструментов и только по безопасности, прочитать и изучить десятки best practices, десятки подходов. И при этом за безопасность k8s я бы всё ещё переживал. И не потому, что нет инструментов. А потому что инструменты сами по себе не дают нужного уровня безопасности.
И проблема не в инструментах, а в отсутствии системного подхода, процессов.
Процессов может быть у кого-то больше, у кого-то меньше, но результат у всех по сути схож — удовлетворить потребности бизнеса и руководства и свести к минимуму количество рисков в проде.
Я не стал выносить все наши процессы, а сгруппировал их вокруг жизненного цикла угрозы, условно:
обнаружить,
предотвратить,
проверить,
контролировать,
реагировать.
У нас все процессы начинаются с моделирования угроз:
которые перерастают в требования;
которые, в свою очередь, необходимо доносить командам;
а после проверять их реализацию;
по некоторым из которых необходимо оценивать риски;
и вообще-то для выявления и построения всего этого необходимы те самые инструменты;
ну и, конечно же, не забываем про мониторинг рантайма и реагирование.
Ниже визуализировал процессы в некий пайплайн. Выглядит знакомо, как будто не о K8S говорим, да?
Все эти процессы полезно будет совместить с зоной ответственности. К примеру, наша команда ИБ k8s работает на стыке разных доменов ИБ. Кластер живет поверх нод, физических, виртуальных ли — не суть важно, главное, что безопасность кластера отчасти зависит от безопасности этих нод. В кластере живет вся наша бизнес-нагрузка, и её безопасность уже напрямую зависит от кластера, но справедливо также и обратное утверждение. Так что нам приходится думать обо всем.
Но самим играть в одну каску или нет – это вопрос правильно выстроенных зон ответственности. У нас применяется подход RACI, по сути — один из способов формализовать классические договоренности, где:
R – исполнитель,
A – ответственный,
C – оказывающий экспертизу (консалтинг),
I – информируемый, тот, кого необходимо проинформировать о статусе активности.
Данный подход позволяет разложить любой процесс между командами. Начнем с моделирования угроз.
1. Моделирование угроз
Источником для формирования модели угроз может быть что угодно:
коммерческие решения;
специализированные решения, предоставляющие вам сервис с информацией по угрозам;
статьи, новости, райтапы – публичные источники, описывающие тот или иной сценарий проникновения, компрометации;
другое.
Без понимания своего ландшафта и его окружения, поверхности атаки, нарушителей, их действий и возможностей, сложно выстроить что-то адекватное, а безопасность ради безопасности — нерабочий подход.
Соответственно, к модели угроз мы подвязываем наши требования, потому что они должны закрывать эти самые угрозы, и просто так их требовать смысла нет. Сами требования мапятся на модель угроз, а сценарий риска, описывающий, как тот или иной злоумышленник будет вас/нас компрометировать, реализуя ту или иную угрозу, формируются из невыполнения этих самых требований, которые привязаны к модели угроз.
Всё закольцовано, всё друг с другом взаимосвязано.
Мы, как команда безопасности кубов, полностью отвечаем за формирование как самой модели, так и за обработку источников угроз для неё, обладая экспертизой, сами описываем сценарии атак и связываем всё это добро с требованиями. Конечно, в части междоменных вопросов мы обращаемся к коллегам (за дополнительной информацией), но концептуально это на итог не влияет.
Как раз на примере матрицы RACI можно это увидеть: где-то мы являемся исполнителями, где-то ответственными за данные подпроцессы, а другие команды, состав которых может у вас отличаться, нас консультируют по некоторым вопросам. И по итогу их же мы и информируем о том, что у нас вышло.
Теперь к требованиям, с ними немного интереснее.
2. Требования
Для нас мало собрать список требований и требовать. Наш интерес в выполнении, а значит они должны быть понятны. Потому (по возможности) всем членам ИТ команд мы разрабатываем спецификации и рекомендации, в которых определяем, как выполнять то или иное требование с вариантами и т.д.:
Для архитекторов разработали паттерны на single-tenant кластер и на multi-tenant кластер, который четко описывает, как должен выглядит кластер, как сегментирован, какие компоненты должен иметь и т.п.
Вместе с DevOps пишем разные скрипты: роли раскатки кластера, плэйбуки, auditPolicy — в общем то, что позволит по возможности получить реализацию наших требований (и как цель - безопасный куб).
И, конечно же, требования не формируются в вакууме, они формируются с учетом регуляторки и здесь уже мы никак не можем обойтись без наших методологов, которые нам отлично помогают.
Собственно, распределение зон ответственности здесь уже будет выглядеть несколько иначе:
Большинство «документов» мы пишем сами, но что-то уже и не мы. В половине случаев уже ответственность не у нас, а где-то мы выступаем именно теми, кого информируют.
3. Экспертиза проектов
И вот проекты поехали в кластера и нам надо их как-то проверять. Для каждого проекта нам необходимо провести экспертизу: рассказать про требования, ответить на вопросы, провалидировать те или иные решения, ведь все они уникальны, со своими сложностями, интересными техническими решениями, проблемами, ограничениями, исключениям.
Но помимо своей части k8s мы должны знать и общие архитектурные подходы, что творится у наших коллег и соседей, ту же облачную специфику, on-prem специфику и др. И здесь сам себе не поможешь, никто не поможет.
Но нам повезло. У нас есть классные AppSec Business Partners (BP), которые полностью лидируют процессы, в том числе, и процесс экспертизы проектов, в котором мы лишь часть «кубовой» экспертизы. Проектная команда пишет свою проектную доку и запускает её на согласование в нашу внутреннюю систему для проектов. Если там встречается куб, то коллеги BP привлекают нас на доп. согласование. Но мы также пишем плэйбуки согласования для BP и пилотируем процесс согласования уже “без нас”, пишем различные F.A.Q. и помним о паттернах/спеках, чтобы команды готовились куда лучше прежнего.
И, как видим (немного упрощенно), но мы снова везде являемся и ответственными, и исполнителями в экспертизе относительно своей части внутри большого процесса.
4. Аудит
Прекрасный, сложный и комплексный процесс. В целом, аудит состоит из следующих крупных блоков:
Выявление мисконфигов: здесь мы, как команда безопасности кубов, руками, глазами и автоматизированно проверяем кластера на соответствие нашим же требованиям. Какие мисконфиги мы ищем и как — полностью наша зона ответственности, ибо кроме нас никто лучше этого сделать не сможет.
Валидация. Далее всё, что мы выявили, необходимо проверить на соответствие контексту: что-то фолзит, что-то было согласовано, что-то невалидно по другим причинам и без знания этой специфики мы сами не справимся, нам помогают как сами команды DevOps, так и упомянутые ранее BP.
Вместе с ними мы занимаемся и устранением: кто-то устраняет руками, кто-то следит за SLA, напоминает, эскалирует и т.д., а мы являемся в общем случае ответственными за подпроцесс, помогаем с мерами, придумываем варианты, работаем с исключениями.
Отдельно стоит обратить внимание на инвентаризацию. Я бы разделил её на два этапа: первый — инвентаризация самих кластеров как отдельных объектов (за это отвечает ИТ), второй — инвентаризация внутренностей кластера (обычно тоже ИТ, но мы делаем сами).
На самом деле процесс куда сложнее, чем выглядит. В целом, про каждый из показанных мною процессов можно сложить отдельную хорошую дискуссию.
Матрица зон ответственности здесь выглядит следующим образом:
5. Риски
По спорным вопросам, которые мы не можем закрыть технически, проходит процедура оценки рисков — последняя мера воздействия, так сказать. Под это у нас выделена отдельная функция и участвуют все роли в ИТ, а у нас маленький кусочек — описываем меры митигации и сценарии рисков, про которые писал выше.
Так что тут всё просто
Но не такая уж просто это всё переложить на технологические рельсы.
6. Платформа
Про платформу я расскажу чуть далее, потому тут лишь пара тезисов. У нас 4 кластера под нашу платформу и все процессы Развития/Сопровождение/Интеграции/Процессы связанные с ней — всё наше и только наше.
7. SOC
Последний по списку, но не по значению — процесс реагирования на инциденты.
У нас есть отдельная команда SOC и для неё мы прорабатываем процесс сбора логов с кластеров и политики, пишем требования и инструкции, пишем «сигнатуры» инцидентов и плэйбуки, помогаем с разбором — то есть выступаем экспертной функцией, 2/3 линией. Но реагированием (и расследованием), в первую очередь, занимаются уже наши коллеги.
Получаем следующую матрицу распределения зон ответственности.
Если посмотреть на все процессы и зоны ответственности то возникает вопрос: «Кто вообще должен всё это делать?»
Матрица компетенций и роли
В результате обзора всех процессов, призванных решить наши цели и задачи, мы получаем, что список требуемых компетенций для этого самого решения, довольно обширный:
Мы должны глубоко и широко знать домен кибербезопасности (не только k8s и контейнеров, но и (не)много вэб), много про сети, безопасность уровня ОСи (Операционных Систем).
Мы должны быть и архитекторами, потому что строить кластер для системы или десятка систем одновременно — это дело не пяти минут.
Мы должны быть и DevOps-инженерами, потому что нам нужно не только писать и скрипты, конфиги, инструкции и требования, понятные для всех, но и сопровождать свою же инфраструктуру.
Мы должны быть и разработчиками, чтобы писать и развивать свои собственные сервисы, интеграции и автоматизацию.
И одновременно менеджерами, чтобы приходить ко всем остальным и договариваться, потому что, опять же, без договоренности ничего работать не будет.
В одном человеке они находиться не могут, а значит будут распределены по разным ролям, подразделениям, командам. У меня получились вот такие роли.
№1. Архитектор ИБ k8s. Ключевая роль, отвечающая за весь фундамент. На его решениях строятся все команды, он задаёт начало всем тем самым процессам и подпроцессам, о которых говорили в начале. На карте процессов архитектор вступает здесь:
№2. Аналитик/инженер. Роль реализующая то, что сделал архитектор, и отвечающая за сопровождение выстроенных процессов на земле, оборачивающая всё это в некие технические решения и ответственная за сопровождение операционных процессов работы с кластерами. Как видно из этого примера, компетенции можно группировать и делать сборные роли: можно сделать отдельного аналитика-инженера, так и дать эту роль команде, можно перенести какие-то зоны ответственности процесса в другую роль.
По карте процесса это отлично видно: зоны ответственности далеко друг от друга, потому что это не pipeline, а взаимосвязанная система (всё есть процесс).
№3. Аудитор. Эта роль шлифует уже работающие процессы и отвечает за весь комплексный процесс аудита, когда нужно что-то выявить, провалидировать (со всеми), закрыть, проконтролировать. Аудитор также отвечает за развитие нашего инструментария аудита, взаимодействуя и с командами и с BP.
Вот её законное место на карте процессов.
№4. DevOps (Инженер платформы). Роль, без которой весь наш техстэк был бы просто чем-то неприличным — обеспечивает нам спокойствие, наблюдаемость наших тулов и работоспособность нашей платформы.
Вот её уникальное место на карте процессов относительно процессов сопровождения инфры.
Если убрать одну из ролей — выпадут и их процессы.
Данный подход нам позволяет определить наличие этих компетенций в различных подразделениях/командах нашей компании. Возможно они уже есть в других местах, в том же ИТ. Тогда часть ролей можно отдать им, распределить зоны ответственности наших процессов, как на примерах выше, уже немного по другому.
Четыре человека на 500 кластеров
Мы уже с вами определились с тем, что мы делаем, как мы делаем, где находимся и каково наше место в процессах, какие нам нужны компетенции, какие роли собрать.
Теперь бы понять, а сколько человек вообще на это все нужно?
Представим, что у нас 1-2 кластера. Потянет ли их один человек? А если больше 500 кластеров, среди которых есть кластера и по 6 нод, и по 300+ нод?
Нам их нужно не просто знать, нам нужно знать, что у них внутри, собственно, понимать эти кластера, потому что без знания всего, что происходит, мы ничего путевого не сделаем.
Масштабировать безопасность количеством людей не получится — мы не можем быть сервисной командой. На рынке труда в РФ не найдется столько специалистов по безопасности кластеров. Мы должны построить экспертную команду.
И здесь нам помогает автоматизация.
Мы построили платформу, которая позволяет максимально просто подключать к ней кластера и собирать с них данные буквально за пару кликов и получать данные со всех кластеров.
И этот массив данных и является нашей базой для процессов (не для всех, конечно, для части — аудита, например, или SOC). Также мы написали свой сканер k8s, трансформирующий наши требования со спецификациями, с рекомендациями, в код, и встроили его в нашу ASOC-платформу. В итоге все 500+ кластеров мы можем просто просканировать двумя нажатиями клавиш.
Итого мы масштабируемся не людьми, а процессами, компетенциями и зонами ответственности. Платформа нам в этом помогает. На данный момент наши 500+ кластеров мы полностью закрываем 4 сотрудниками (по 1 человеку на каждую роль).
Как посчитать людей?
Предлагаю использовать следующий подход. У нас должна появиться некая матрица, в которой уже есть наши процессы, есть наша зона ответственности, есть наши компетенции, есть роли. Вот она (мой первый артефакт по этой теме).
С её помощью мы можем оценить, что мы закрываем и на каком уровне: где-то закрываем одну область на 100%, где-то на 50%, а где-то у нас есть запас.
Также мы вводим индекс — бас-фактор. Количественно показывает, сколько людей у нас может сбить автобус (может, но не надо), чтобы мы не потеряли процесс. Если бас-фактор равен 1, то никак нельзя, чтобы ваших людей сбивали автобусы. Если равен 2, можем позволить. Но один раз. Также стоит тут же учитывать, что если бас-фактор равен 2, но это разные роли, просто компетенции перекрываются, то при потере одного вы не потеряете процесс, но просядут задачи.
Здесь же под капотом я заложил процесс оценки capacity и утилизации рабочего времени сотрудника (тут же можно поговорить об отношении Demand/Capacity, но не будет, а то ещё одна статья получится), потому что у нас уже есть все, чтобы оценить сколько в нас влезет, есть масштаб, есть объем, мы понимаем что делать, мы понимаем где мы делаем, как мы делаем, понимаем, что для этого надо и теперь, при планировании, можем оценить, влезает ли в нас задача или не влезает.
Почему это работает?
Как говорил ранее, у нас более 500 кластеров и мы все их знаем, они в разных бизнес доменах, со своими командами, проектами, но все они нам известны и на 90+% покрыты нашими процессами инструментами. Почему не 100%? Потому что эти 500+ кластеров — это кластеры всех сред: dev, test, ft, lt - разные тестовые среды - предпрод и прод и другие. Не для всех кластеров нужны все процессы, все инструменты. Поэтому пусть будет 90+.
Мы не строили абсолютно новых процессов (ну почти), мы встраиваемся/модифицируем и развиваем текущие (есть своя специфика, но всё же), сейчас все проекты, которые едут в кластера проходят через наши требования и экспертизу.
Ранее мы не знали какой инструмент, на какой кластер закинуть, ладно инструмент выбрать, про них столько докладов, но как это сделать, как собрать все результаты, как провалидировать, а как проверить то, что нет в инструментах? Сейчас подключение к платформе — 1 тикет, 1 пайплайн автоматизации формирования чарта за пару минут, пара команд от DevOps — и готово (всё за 5 минут в лучшем случае). И никаких проблем с наблюдаемостью, отчетами и тд – всё централизовано.
Раньше аудит кластера занимал 1-2 рабочих недели (запуск условного куббенча, проверка сегментации, распределение нагрузки, проверка архитектуры и т.д.). Сейчас это 4,5 часа в среднем автоматизированного скана и пара дней валидации даже на жирный кластер. Опять же, то, что мы не можем выполнить или закрыть по тем или иным причинам, мы ведем на оценку рисков. Благо у нас есть для этого уже отдельная команда.
И, возвращаясь к предыдущей схеме, мы можем оценить, где у нас узко, где у нас есть запас, собственно, и тем самым предотвращать процессные проблемы.
Безопасность — это не инструменты
А процессы, люди, компетенции. Сместив фокус с бесконечной гонки за новыми «тулами» на выстраивание сквозной карты процессов и четкое распределение ролей, мы получили контролируемую и прозрачную систему, что и позволило подключить автоматизацию и масштабировать экспертизу всего четырех человек на 500+ разнородных кластеров.
Внедрение инструментов в кластера теперь занимает 5 минут вместо недель, аудит проходит за считанные часы, а встроенные метрики (capacity-менеджмент) позволяют нам заранее видеть свои узкие места и планировать нагрузку на отдел.