В ИТ-инфраструктуре идет постепенное повышение уровня абстракции, в частности, виртуальная машина – абстракция на уровне физического сервера, контейнер – абстракция на уровне приложения. Не вдаваясь в историю виртуализации, можно констатировать, что сейчас разработка ПО активно развивается в рамках микросервисной архитектуры и технологий контейнеризации. В этой статье расскажем, как мы подтянули компетенции по защите микросервисных архитектур в департаменте проектных решений нашего центра интеграции.
Суть проблемы
Использование контейнеров дает дополнительные преимущества – начиная от стадии разработки, во время которой можно, например, писать разные сервисы на разных языках программирования, заканчивая стадией эксплуатации, во время которой, например, можно масштабировать приложения сообразно поступающей на вход нагрузке. Но при этом использование контейнеров видоизменяет подходы к обеспечению ИБ, ибо защита контейнеризированных приложений имеет некоторые особенности:
новые объекты защиты;
новые векторы реализации угроз;
новые уязвимости;
особенности технологий (например, время жизни контейнеров может измеряться секундами);
особенности/ограничения средств защиты. Например, мы не можем поставить в каждый контейнер антивирус или наложенное СЗИ от НСД;
дефицит толковых специалистов.
Защиту контейнеризированных приложений нельзя рассматривать отдельно от организации цикла безопасной разработки (SDLC). Эти два подхода комплементарно дополняют друга: если уменьшается количество уязвимостей в разработанном ПО, сокращается поверхность атаки при развертывании ПО в продуктивной среде.
В коммерческих проектах разработка ПО в рамках микросервисной архитектуры и технологий контейнеризации реализовывается уже достаточно давно. Государственные информационные системы также начали активно двигаться в этом направлении. Если раньше использование микросервисной архитектуры и контейнеризации мы рассматривали только в системных проектах развития инфраструктуры, то сейчас уже практически каждая создаваемая ГИС использует микросервисы.
Как известно, среди наших заказчиков много государственных организаций федерального масштаба с распределенными инфраструктурами и крупными ЦОДами, в которых хостятся ГИСы. И мы все чаще сталкиваемся с потребностью обеспечивать ИБ в том числе и среды контейнеризации/оркестрации.
Требования регуляторов охватывают эту область поверхностно и с запозданием. Из нормативки сейчас в наличии только требования по безопасности информации к средствам контейнеризации, утвержденные приказом ФСТЭК России от 04.07.2022 № 118, в котором определены требования к классам защиты средств контейнеризации. При этом, судя по государственному реестру, сертифицированных средств контейнеризации нет.
Все эти предпосылки натолкнули нас на мысль, что пора глубже нырнуть в тему защиты контейнеризации и озаботиться соответствующим обучением.
Выбор подхода
Мы хотели не просто обучить пять-шесть человек от одного отдела, а массово прокачать компетенции участников разных проектных ролей. Остановились на 30 слушателях, в список вошли главные инженеры проектов, проектировщики, консультанты по ИБ, инженеры внедрения и инженеры эксплуатации.
Выбор первоисточника знаний
За основу решили взять Kubernetes: мы чаще всего сталкиваемся именно с этим решением и видим, что разрабатываемые российские системы нередко используют именно этот оркестратор.
Попытка пойти стандартным путем и найти курс «Безопасность Kubernetes» провалилась спустя день активного поиска. Стало ясно, что нужно заказывать авторский курс. Учебные центры предлагали разные программы, но все они включали теоретический материал, который давал лектор, как правило, имеющий опыт работы с Kubernetes. Рассматривая такие программы, мы поняли, что подобный материал можно освоить самостоятельно, прикупив пару книг и почитав статьи на Хабре. Нам же была нужна практика – узнать, что реально бывает, как реально защищают, какие бесплатные и платные инструменты есть, для чего и как они используются. Кроме этого, хотелось получить знания о предметной области более комплексно – как с атакующей стороны (с учетом опыта аудитов и пентестов), так и со стороны развертывания инфраструктуры для микросервисных архитектур, в том числе в контексте организации защиты приложений и сред. В общем, нам было нужно, чтобы лектор отлично знал Kubernetes, его внутренние механизмы, возможности интеграции со сторонними средствами защиты и каждый день имел дело с микросервисными системами и системами управления.
Обзвонили знакомых, и в течение двух-трех недель поиски лектора привели нас к техническому директору компании Luntry Дмитрию Евдокимову, на чьи выступления по этой теме мы ранее наталкивались на разных форумах. Да, это реклама, которая сэкономит кому-то две-три недели времени.
В итоге совместно составили программу и договорились о дате двухдневного курса.
На чем сконцентрировали внимание
Мы ориентировались на практику, поэтому требовалось, чтобы у всех слушателей было хотя бы базовое представление о контейнеризации. У кого-то с этим было все хорошо, но некоторые не в полной мере понимали отличие контейнеризации от традиционной виртуализации. Для поверхностного погружения мы подготовили программу самостоятельной подготовки, которая включала в себя:
Ознакомление с видеоматериалами, лекции 1–7;
Ознакомление с материалами и выполнение практического задания по развертыванию простейшего контейнерного приложения (обязательно – для новичков и по желанию – для тех, кому нужно вспомнить);
Выполнение лабораторной работы, заключающейся в развертывании и выполнении базовых операций с контейнерными приложениями (обязательно для части слушателей).
А вот как выглядела программа самого курса:
1-й день. Безопасность Cloud-Native-приложений
Погружение в Cloud-Native-специфику
Трансформация мышления к Cloud-Native-безопасность
Знакомство с Kubernetes
В первый день мы рассмотрели, что такое Cloud-Native-подход и безопасность. В процессе этого мы узнали, какие классы средств защиты и подходы существуют сегодня для Cloud-Native-приложений на основании классификации Cloud Native Computing Foundation (CNCF). Все это было разделено на фазы жизненного цикла приложения: Develop, Distribute, Deploy, Runtime. А последняя стадия также была разделена на части: Compute, Storage и Access. Еще пробежались по темам Threat Modeling, Threat Intelligence, Incident Response, Least Privilege и т. д. Закончили первый день небольшим знакомством с Kubernetes с прицелом на безопасность и источниками информации, полезными для работы с ним.
2-й день. Безопасность контейнеров, Kubernetes и их механизмы
Безопасность контейнеров
Безопасность Kubernetes
Механизмы Kubernetes
Во второй день мы рассмотрели, из чего состоит и что лежит в основе безопасности контейнеров и Kubernetes. Разбирали вопросы по защите, возможные действия атакующих и примеры реальных инцидентов. Среди рассмотренных тем были: Image security, Container runtime security (побеги из контейнеров), Host security, Network security, Kubernetes security (control plane), Application security. По каждой теме разбирали живые примеры с использованием инструментов с открытым исходным кодом, что было особенно полезно. Рассмотрели механизмы безопасности, которые предоставляет Kubernetes: RBAC, Network Policy, PodSecurityPolicy, Admission controllers, Service Accounts, Secrets, Audit Policy. Закончили обзором свободно доступных площадок, проектов для оттачивания мастерства по защите и атаке Kubernetes, разговорами о подходе к анализу рисков в Kubernetes и о возможных путях реализациях self-protecting и ZeroTrust.
В ходе интенсива мы рассмотрели много практических кейсов, актуальных проблем организации комплексной защиты микросервисных архитектур и способов их решения.
Что получилось
Важно отметить, что оба дня присутствовали 100% слушателей. Это как минимум говорит не только об актуальности самой темы, но и интересе к ней со стороны наших сотрудников (спасибо популярности различных комбинаций слов: sec, dev, ops). А еще теперь, когда раздается слово «контейнеризация», сразу собирается группа специалистов, чтобы совместно поискать варианты решения задачи.
Получилось живо, максимально полезно… Но, если честно, тяжело из-за высокой концентрации полезного материала по теме. Хотя мы с ней и сталкиваемся значительно чаще, чем год назад, но все же не каждый день. Больше половины слушателей в выходные повторно пересматривали материал и делали заметки для использования полученных знаний в ближайших проектах.
Наши дальнейшие планы
Этот кейс повлиял на подход к организации обучения в будущем – мы будем и дальше стараться находить именно практиков, которые каждый день на протяжении нескольких лет занимаются интересующей нас темой.
Что касается обеспечения безопасности сред контейнеризации, то пока мы решили остановиться на следующем:
построение правильной архитектуры среды контейнеризации;
максимальное использование встроенных механизмов защиты Kubernetes и операционных систем (это исключит лишние точки отказа и сохранит управляемость);
использование внешних решений для мониторинга текущего состояния и происходящих процессов (назвать удобным штатный функционал язык не поворачивается);
использование специализированных средств анализа защищенности и хорошо знакомых классических средств защиты.
В фокусе внимания будем держать:
требования ФСТЭК в части использования сертифицированных хостовых ОС;
российские средства внешнего мониторинга и управления (очень ждем, когда Luntry завершит процесс сертификации своего решения);
российские средства защиты, адаптированные под контейнеризацию;
российские системы контейнеризации/оркестрации.
В общем, на месте не сидим, учиться мы любим, если ты тоже – присоединяйся к нашей команде. Всегда рады драйвовым коллегам!
