Чек-лист: Как минимизировать риски при переходе на микросервисную архитектуру

Подготовка к переходу на микросервисную архитектуру

Планирование инфраструктуры идет на нескольких уровнях:

Аппаратный

Микросервисное ПО не предъявляет специфических требований к аппаратному уровню ИТ-инфраструктуры. Вычислительная инфраструктура создается на стандартном оборудовании x86-ой платформы. При разработке дизайна важно:

Правильно рассчитать планируемую нагрузку;

В своей практике мы видели немало примеров, когда ошибочный изначальный сайзинг платформы приводил к дефициту вычислительных ресурсов, тормозил ее развитие и препятствовал масштабированию. Юрий Семенюков, директор департамента инфраструктурных решений «Инфосистемы Джет»

учесть нагрузку служебных сервисов самой платформы управления контейнерами – служебная нагрузка может быть существенной, поскольку ее «генерит» много компонентов: внутренние компоненты оркестратора, реестр образов, мониторинг, логирование, сетевая маршрутизация и т. д.; определиться, будет ли микросервисная архитектура работать на физическом оборудовании, так называемом bare metal, или на виртуальной инфраструктуре – оба варианта могут задавать свои требования и ограничения реализации платформы. Системный

Здесь важно:

спланировать ландшафты системы
Помимо продуктивного ландшафта потребуется еще ряд сред – разработка, тестирование, контроль качества, «pre-prod» и т. п. Их число зависит от того, как выстроен общий процесс разработки и доставки кода в продуктив. Эти среды часто размещаются в выделенных контурах инфраструктуры, каждый из ландшафтов имеет свои требования к вычислительным ресурсам. Обычно ландшафты должны «уметь» обмениваться артефактами.

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

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

определить стратегию обеспечения непрерывности продуктивного сервиса
На случай аварии в ЦОДе для критичных сервисов, простой которых дорого обходится бизнесу, должен быть план восстановления. Вариантом может стать дублирование продуктивной среды в резервном ЦОДе или другие схемы аварийного восстановления (Disaster Recovery, DR).

В зависимости от стратегии аварийного восстановления соответствующим образом готовится и ИТ-инфраструктура. Если требуется хранить копии данных в резервном ЦОДе, важно продумать метод их доставки. Например, это можно сделать путем репликации или дублирования артефактов средствами доставки приложений. При переключении пользователей между разными ЦОД на точке «входа» трафика нужно обеспечить балансировку запросов, направляющую их на доступный ЦОД, в котором функционирует работоспособный экземпляр приложения, – комментирует Юрий Семенюков.

согласовать схемы сопряжения с экспертами ИБ

Многим микросервисным решениям нужен доступ к интернету уже на этапе инсталляции, а находятся они в продуктивном сегменте, который прямого выхода в интернет не имеет, так как это противоречит требованиям ИБ. Свои требования также предъявляют аспекты шифрования трафика. Нужно выбирать правильный SDN, так как не все плагины поддерживают данную функциональность, обращает внимание Юрий Семенюков.

Риски ИБ, возникающие при переходе на микросервисы

Технические

Сами риски остаются те же, что и для «классических» приложений, ведь все крутится вокруг триады «конфиденциальность-целостность-доступность». Меняются только технологии, их уязвимости и особенности средств защиты. При этом использование контейнерных сред ставит задачу защищать не только образы, но и сами контейнеры, run-time, а также все окружение, задействованное в разработке приложений (реестры, CI/CD-инструменты, git и т. д.).

Вот лишь неполный список ИБ-рисков, характерных для сред контейнеризации:

ошибки или уязвимости в образах контейнеров,

реализация escape-атак из контейнера на уровень хоста с повышенными привилегиями,

отсутствие контроля запускаемых процессов в контейнерах и сетевых соединений,

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

Организационные

Эти риски связаны с потребностью в изменении подхода к обеспечению ИБ. Если его не «адаптировать» вовремя, информационная безопасность может просто «исчезнуть» из разработки, т.к. будет лишь мешать достижению целей по увеличению скорости выпуска приложений (time-to-market).

Организационная адаптация требует:

Изменения взаимодействия с командами разработки и эксплуатации
Можно сказать, что задача ИБ – подготовить и предоставить командам разработки и эксплуатации удобные сервисы, которые им придется использовать. Процесс согласования изменений должен быть быстрым.

Четкого распределения ответственности
Иначе можно столкнуться с ситуацией, когда никто ничего не делает, т. к. ИБ-специалисты будут думать, что те или иные действия входят в задачи ИТ-специалистов, и наоборот.

Перед запуском микросервисов

С точки зрения ИБ стоит сделать как минимум две ключевые вещи:

Определиться с тем, какие механизмы нужно использовать для защиты кластера

Полезным будет «взгляд сверху», который поможет понять, на какие аспекты стоит обращать внимание, как можно реализовать ту или иную задачу. В качестве примера приведем используемый в проектах «Инфосистемы Джет» Jet Container Security Framework, описывающий значимые аспекты безопасности среды контейнеризации:

Access and key management: управление доступом на всех логических уровнях – от Cluster до Containers;

Security monitoring and audit: управление событиями ИБ, идентификация инцидентов, проведение проверок корректности настроек;

Cluster Security: управление уязвимостями нод кластера, контроль сетевого взаимодействия и использование встроенных возможностей ОС для ограничения ее функций (hardening). Также домен включает в себя вопросы обеспечения ИБ Container Engine (например, Docker или CRI-O);

Orchestrator Security: управление взаимодействием под/пространство имен (pod/namespace) – от аспектов сетевой ИБ до управления нодами кластера, на которых могут подниматься поды и контейнеры;

Image Security: обеспечение безопасности образа на всех этапах жизненного цикла путем управления уязвимостями и отсечения всего лишнего, что не используется в разработке;

Run-Time Security: защита контейнеров («запущенного» образа) – контроль системных вызовов, процессов, файлов, команд и реализация поведенческой аналитики.

Jet Container Security Framework

Задача ИБ – создать свою собственную «раскраску», понять, что важно именно сейчас. После этого можно разбираться с вопросом, как это можно реализовать. Результатом этих активностей станет план работ, который позволит реализовать надлежащий уровень обеспечения ИБ-среды контейнеризации в рассматриваемой перспективе. Антон Гаврилов, руководитель направления DevSecOps Центра информационной безопасности компании «Инфосистемы Джет»

Разграничить зоны ответственности

При этом важно помнить, что распределение ответственности может меняться в зависимости от среды – Dev/Test/Prod. Для этого можно использовать аналогичный первому пункту подход: создаем набор задач, собираем вместе Dev, Sec, Ops и начинаем проговаривать потенциальные задачи. Результатом может стать RACI-матрица (матрица распределения ответственности сторон, где R – Responsible, выполняет задачу; A – Accountable, несет ответственность за результат; C – Consulted, оказывает консультации; I – Informed, получает уведомления), которую можно использовать в дальнейшем.

Возможное распределение возможностей в PROD (Dev)

Возможное распределение возможностей в PROD (Sec)

Возможное распределение возможностей в PROD (Ops)

Применение подхода на периодической основе позволит иметь перед глазами актуальный расклад сил, ведь «скорость» и постоянные изменения характерны не только для разработки, но и для безопасности и инфраструктуры, которые задействованы в создании микросервисных приложений.

Что важно не забыть при переходе на микросервисы

Идентифицировать потенциальные дефекты ИБ на ранних стадиях

Если вы используете Continuous Integration/Continuous Delivery, сделайте безопасность частью вашего пайплайна – например, можно встраивать проверки статическим анализатором, делать анализ компонентов open source, сканировать образы контейнеров на наличие уязвимостей. Так вы сможете сократить время и ресурсы на их устранение. Эти подходы можно применять и без использования CI/CD, однако потребуется адаптировать процессы и затратить большее количество времени и ресурсов ИБ-специалистов и разработчиков.

Оценить риски при формировании функциональных и нефункциональных требований, предъявляемых к разрабатываемому микросервису

Дублировать кодовую базу и вести четкую документацию по каждому микросервису

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

При этом даже незначительный промах в любом из аспектов может стать фатальным. Например, заказчик выбрал решение, которое поддерживало подключение к внешнему хранилищу по протоколу NFS. Тестирование прошло гладко. Платформу запустили в продуктив, и все сервисы «легли», потому что NFS не поддерживает квоты на ресурсы и при продуктивной нагрузке один сервис «занял» все хранилище. Очевидно, если бы изначально было выбрано верное решение и проведено достаточное нагрузочное тестирование, такого печального финала не было бы, – рассказывает Юрий Семенюков.

План по переводу монолита на микросервисы

Формулировка задач

Каждый микросервис должен быть ограничен узкой бизнес-задачей, определенной, в свою очередь, конкретной потребностью пользователя.

Сначала надо сформулировать существующие проблемы и бизнес-задачу по каждому процессу. Потом определить, какими средствами лучше решать каждую из них. Настоящий Agile — когда вы можете выбирать лучший инструментарий для каждой конкретной задачи. Александр Садыков, руководитель отдела тестирования «Инфосистемы Джет»

Создание команды

Оно строится на трех принципах:

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

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

Благодаря распределенной кодовой базе команда концентрируется на разработке своего сервиса. Плюс этого подхода — регрессионное тестирование происходит быстро и больше не является проблемой, о которой нужно беспокоиться: как правило, в каждой команде есть свой тестировщик. Разработкой подхода к распределению зон ответственности занимается главный конструктор. В каждой команде есть координатор, который контролирует сроки доставки сервисов в продуктив и другие организационные моменты, – поясняет Александр Садыков.

Доверие
Команда разработчиков должна отвечать за весь жизненный путь своего продукта, поэтому выбор языков, методологий развертывания и интерфейсов должен быть внутренним решением команды.

Создание инструмента для взаимодействия микросервисов

Экосистема должна получить среду для коммуникации — для этого создается оптимизированный для REST вызовов клиент с возможностью использовать все языки, применяемые во всех микросервисах. Еще вам понадобится локализованная под каждый микросервис и постоянно обновляемая конфигурация, с помощью которой микросервисы смогут «понимать», как общаться друг с другом.

Разработка новых правил согласования этапов процесса

Если работа не усложняется длительными бюрократическими нагромождениями, разработка микросервиса с тестированием в среднем займет две-три недели работы команды.

Не стоит тиражировать монолитные схемы в новую среду, иначе можете не ощутить все преимущества микросервисов. Например, разработка микросервисов более эффективна в итеративной модели, чем в водопадной, – рекомендует Александр Садыков.

Ускорение разработки с помощью методологии DevOps

Как сама идея микросервисной архитектуры, так и процессы кодирования, сборки, развертывания и управления ею полностью соответствуют принципам DevOps по автоматизации процессов разработки ПО и налаживания коммуникаций между смежными командами. Общая цель этих подходов — ускорение выпуска релизов. Поэтому DevOps как нельзя лучше вписывается парадигму микросервисов.

Готовый микросервис стоит представлять как минипродукт, который помещается в контейнер. Далее он проходит этапы автоматизированного и нагрузочного тестирования. Если установленные Quality Gate (критерии качества) пройдены, стартует процесс интеграционного тестирования микросервисов на пре-продуктивных стендах. Управление контейнерами при этом производится с помощью оркестратора (например, Kubernetes, Red Hat OpenShift, Docker Compose).