В ИТ-инфраструктуре происходит постепенное увеличение уровня абстракции, в частности, виртуальная машина — это абстракция уровня физического сервера, контейнер — абстракция уровня приложения. Не вдаваясь в историю виртуализации, можно сказать, что разработка программного обеспечения сейчас активно развивается в рамках микросервисной архитектуры и технологий контейнеризации. В этой статье мы расскажем, как мы улучшили навыки защиты микросервисных архитектур в отделе проектных решений нашего Интеграционного центра.

Суть проблемы

Использование контейнеров дает дополнительные преимущества — от этапа разработки, когда, например, вы можете писать разные службы на разных языках программирования, до этапа эксплуатации, где, например, вы можете масштабировать приложения на основе входящей нагрузки. Но в то же время использование контейнеров меняет подходы к информационной безопасности, т.к. Защита контейнерных приложений имеет несколько особенностей:

  • новые защитные элементы;

  • новые векторы реализации угроз;

  • новые уязвимости;

  • технологические характеристики (например, срок службы контейнеров может измеряться секундами);

  • характеристики/ограничения средств защиты. Например, мы не можем поставить в каждый контейнер антивирус или NSD-оверлей информационной безопасности;

  • нехватка квалифицированных специалистов.

Защита контейнерных приложений не может рассматриваться отдельно от безопасного жизненного цикла разработки (SDLC). Эти два подхода дополняют друг друга: если уменьшается количество уязвимостей в разрабатываемом ПО, уменьшается поверхность атаки при развертывании ПО в продуктивной среде.

В коммерческих проектах давно реализована разработка ПО в рамках микросервисной архитектуры и технологий контейнеризации. Государственные информационные системы также стали активно двигаться в этом направлении. Если раньше мы рассматривали использование микросервисной архитектуры и контейнеризации только в проектах развития системной инфраструктуры, то сейчас почти все создаваемые ГИС используют микросервисы.

Как вы знаете, в число наших клиентов входят многие федеральные правительственные организации с распределенными инфраструктурами и крупными центрами обработки данных, на которых размещены ГИС. И мы все чаще сталкиваемся с необходимостью обеспечения информационной безопасности, в том числе в средах контейнеризации/оркестрации.

Нормативные требования охватывают эту область поверхностно и запоздало. Из регламентов сейчас доступны только требования по защите информации к средствам контейнеризации, утвержденные Приказом ФСТЭК России от 07.04.2022 № 118, определяющим требования к классам защиты средств контейнеризации. При этом, судя по национальному реестру, сертифицированных контейнерных мощностей нет.

Все эти предпосылки привели нас к мысли, что пора углубить тему защиты контейнеризации и позаботиться о соответствующем обучении.

ЧИТАТЬ   Основатель рухнувшей криптобиржи FTX просит не сажать в тюрьму на 100 лет

Выбор подхода

Мы хотели не просто обучить пять-шесть человек из одного отдела, а массово повысить квалификацию участников в разных ролях проекта. Мы остановились на 30 аудиторах, в список вошли ведущие инженеры проекта, дизайнеры, консультанты по информационной безопасности, инженеры по внедрению и инженеры по эксплуатации.

Выбор первого источника знаний

Мы решили взять за основу Kubernetes: именно это решение мы встречаем чаще всего и видим, что разрабатываемые российские системы часто используют именно этот оркестратор.

Попытка пойти стандартным путем и найти курс по безопасности Kubernetes не удалась после дня активных поисков. Стало понятно, что нужно заказывать авторский курс. Учебные центры предлагали разные программы, но все они включали теоретический материал, который давал лектор, как правило, имевший опыт работы с Kubernetes. Рассматривая такие программы, мы поняли, что этот материал можно освоить самостоятельно, купив несколько книг и прочитав статьи на Хабре. Нужна была практика — знать, что на самом деле происходит, как на самом деле защищают, какие инструменты бесплатные и платные, что и как они используют. Причем знания по теме хотелось получить более глобальным образом — как со стороны атакующих (с учетом опыта аудитов и пентестов), так и со стороны развертывания инфраструктур для микросервисных архитектур, в том числе понимаемых в контекст организации защиты приложений и сред. В общем, нам нужно было, чтобы спикер отлично знал Kubernetes, его внутренние механизмы, интеграцию со сторонними инструментами безопасности и повседневное управление микросервисными системами и системами управления.

Мы позвонили друзьям, и через две-три недели поиски спикера привели нас к техническому директору Luntry Дмитрию Евдокимову, выступления которого на эту тему мы уже встречали на различных форумах. Да, это реклама, которая сэкономит кому-то две-три недели времени.

В результате мы вместе разработали программу и согласовали дату двухдневного курса.

На чем вы сосредоточились

Мы были практическими, поэтому всем студентам было необходимо иметь хотя бы базовое представление о контейнеризации. Некоторых это устраивало, но некоторые не до конца понимали разницу между контейнеризацией и традиционной виртуализацией. Для поверхностного погружения мы подготовили программу самообучения, которая включала:

  1. Ознакомление с видео материалуроки с 1 по 7;

  2. Ознакомление с материалы и выполнить практическое задание по развертыванию простейшего приложения-контейнера (обязательно для новичков и необязательно для тех, кому нужно помнить);

  3. Выполните лабораторную работу, включающую развертывание и выполнение основных операций с контейнерными приложениями (требуется для некоторых учащихся).

    И вот как это выглядело сама программа курса:

ЧИТАТЬ   Как новая политика easyJet в отношении защиты животных влияет на ваши путешествия

1-й день. Безопасность облачных приложений

  • Погрузитесь в особенности Cloud-Native

  • Думая о переходе на облачную безопасность

  • Знакомство с Kubernetes

В первый день мы рассмотрели, что такое облачный подход и безопасность. В процессе мы узнали, какие классы безопасности и подходы существуют сегодня для приложений Cloud Native на основе классификации Cloud Native Computing Foundation (CNCF). Все это разбито на этапы жизненного цикла приложения: разработка, распространение, развертывание, выполнение. И последний шаг тоже был разделен на части: вычисления, хранилище и доступ. Мы также рассмотрели такие темы, как моделирование угроз, анализ угроз, реагирование на инциденты, наименьшие привилегии и т. д. Мы закончили первый день небольшим введением в Kubernetes с прицелом на безопасность и полезные источники информации для работы.

2-й день. Безопасность контейнеров, Kubernetes и их механизмы

  • Контейнерная безопасность

  • Кубернетес Безопасность

  • Механизмы Kubernetes

На второй день мы рассмотрели, что это такое и что лежит в основе безопасности контейнеров и Kubernetes. Мы обсудили вопросы защиты, возможные действия злоумышленников и примеры реальных инцидентов. Рассматриваемые темы включали: безопасность образа, безопасность среды выполнения контейнера (побеги контейнера), безопасность хоста, безопасность сети, безопасность Kubernetes (плоскость управления), безопасность приложений. Каждая тема была освещена живыми примерами с использованием инструментов с открытым исходным кодом, что было особенно полезно. Мы учли механизмы безопасности, предоставляемые Kubernetes: RBAC, Network Policy, PodSecurityPolicy, Admission controllers, Service Accounts, Secrets, Audit Policy. Мы закончили обзором сайтов, доступных бесплатно, планами по оттачиванию навыков защиты и атак Kubernetes, рассказом о подходе к анализу рисков в Kubernetes и возможных способах реализации самозащиты и ZeroTrust.

В ходе интенсива мы рассмотрели множество практических кейсов, реальные проблемы организации комплексной защиты микросервисных архитектур и пути их решения.

ЧИТАТЬ   Суд ООН отклонил ряд возражений России на обвинения Украины в спецоперации

Что случилось

Важно отметить, что оба дня присутствовали 100% слушателей. Это как минимум говорит не только об актуальности самой темы, но и об интересе к ней наших сотрудников (благодаря популярности различных словосочетаний: sec, dev, ops). И теперь, когда звучит слово «контейнеризация», сразу же собирается группа специалистов, чтобы совместно исследовать варианты решения проблемы.

Получилось живо, максимально полезно… Но, честно говоря, сложно из-за высокой концентрации полезного материала по теме. Хотя мы с ним встречаемся гораздо чаще, чем год назад, но все же не каждый день. Более половины студентов повторно просмотрели материал на выходных и сделали заметки, чтобы использовать полученные знания в будущих проектах.

Наши будущие проекты

Этот случай повлиял на подход к организации обучения в дальнейшем – мы продолжим каждый день пытаться найти практиков, которые занимаются интересующей нас темой уже несколько лет.

Что касается защиты сред контейнеризации, мы решили пока сосредоточиться на следующем:

  • построить правильную архитектуру среды контейнеризации;

  • Максимальное использование Kubernetes и встроенных механизмов защиты операционной системы (это устранит ненужные точки отказа и сохранит управляемость);

  • использование внешних решений для мониторинга текущего состояния и запущенных процессов (штатный функционал сложно назвать удобным);

  • использование специализированных средств анализа безопасности и известных классических средств защиты.

В фокус мы сохраним:

  • Требования ФСТЭК к использованию сертифицированных операционных систем хоста;

  • Российские инструменты внешнего контроля и управления (мы с нетерпением ждем, когда Luntry завершит процесс сертификации своего решения);

  • Российское защитное оборудование, пригодное для контейнеризации;

  • Российские системы контейнеризации/организации.

В общем, мы не сидим, нам нравится учиться, если вы тоже — присоединиться в нашу команду. Всегда рад подвезти коллег!

Source

От admin