Анализ механизмов защиты информации в микросервисных архитектурах

Disclaimer: Решил залить на Хабр текст своей научной статьи для ВУЗовской конференции. Сам материал мне показался довольно годным. Это обзорная статья. В ней я попытался провести исследование о механизмах защиты микросервисных архитектур. Являясь офенсив специалистом, мне также интересны вопрос построения защищенных архитектур. Как говорится, если знаешь как нападать, то знаешь как защищаться. У меня нет опыта в разработке и проектирования ПО. На архитектуру я смотрю с точки зрениях возможных рисков безопасности. Благодарю своего научного руководителя, Каменских Антона Николаевича, за помощью при написании работы. Приятного чтения.

А.Н. Каменских, К.В. Филимонов

Введение

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

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

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

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

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

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

Актуальность научного исследования

Согласно опроса O’Reilly [1] от 31 января 2020 года, в котором приняли участие 1502 читателей их почтовой рассылки, большинство респондентов (92%) считают свой опыт с микросервисной архитектурой скорее успешным, 54% успешным и 10% очень успешным.

Опрос показал, что лишь 21% респондентов выразили заинтересованность в вопросах безопасности при использовании микросервисной архитектуры. Современный подход к взаимодействую между микроcервисами может реализовываться в использовании программных интерфейсов приложений (Application Programming Language, API). В 2019 году организация Open Web Application Security Project (OWASP) обновила методологию тестирования безопасности API [2]. В методологии самыми актуальными являются проблемы аутентификации и авторизации при использовании API методов (API1:2019 Broken Object Level Authorization, API2:2019 Broken User Authentication).

Преимущества микросервисных архитектур

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

В уже ранее упомянутом отчете Oreilly читатели отметили плюсы перехода к микросервисных архитектурам (Рисунок 1). Среди плюсов фигурируют такие как: гибкость разработки, оперативная изменение технологий под бизнес требования, возможность масштабирования, повышения частоты обновлений продукта, повышение качества тестирования приложений, повышения уровня доступности и уменьшение затрат на разработку.

Важно отдельно выделить плюсы использования микросервисных архитектур с точки зрения безопасности:

• Уменьшение кодовой базы и как следствия площади атаки. Помещение бизнес-логики приложений в отдельные микросервисы снижает кодовую базу, что способствует уменьшению площади атак. Меньше кода — ниже вероятность ошибки;

• Ускорение времени статического анализа и развертывания приложения в боевую готовность. При внедрении подходов безопасной разработки ПО (Secure Software Development Life Cycle, S-SDLC) необходимо проводить статическое и динамическое автоматизированное тестирование разрабатываемых приложений (Static/Dynamic Application Security Testing, SAST/DAST). Использование микросервисного подхода ускоряет тестирование отдельных компонентов системы и снижает время ввода в эксплуатацию (Time to Market);

• Сокрытие всего функционала приложения за конкретными микросервисами. Использование архитектурного шаблона API шлюз (API Gateway) позволяет обращаться к функционалу конкретных сервисов путем указания конкретных путей (endpoints). Таким образом, существенная часть функционала может быть скрыта, а попытки эксплуатации уязвимостей микросервисов ограничены.

Существующие практики обеспечения безопасности микросервисов

В работе Overcoming Security Challenges in Microservice Architectures [3], Татьяна Ярыгина, исследовательница безопасности из Университета Берген, приводит перечень лучших практик по повышению уровня защищенности микросервисов:

• Взаимная аутентификация (mutual TLS, mTLS). Внедрение механизмов взаимной аутентификации позволяет микросервисам устаналивать доверенный канал между друг другом на основании асимметричной криптографии протокола Transport Layer Security (TLS). В статье приводятся примеры двух принципиально отличающихся подходов к реализации mTLS проектов Docker Swarm и Netflix. В обоих случаях главную роль играет удостоверяющий центр (Certificate Authority, CA), однако отличается срок выдачи самоподписанные сертификатов. В первом случае срок перевыпуска составляет 3 месяца, во втором случае сертификаты выдаются как на долгий период, так и на короткий (short-lived). Выдача короткоживущих сертификатов связано с попыткой решения проблемы отзыва сертификатов. mTLS решает проблему шифрования канала связи и аутентификации, но не решает проблему авторизации.

• Токены безопасности (JWT). Использование токенов безопасности аналогичным образом базируется на криптографических принципах. Токены создаются на стороне отдельного микросервиса после успешного прохождения процедуры аутентификации. Лучшей практикой считается внедрение счетчика деактивации токена, что позволяет избежать его повторного использования в случае кражи. Токен безопасности может быть многократно использован для разграничения доступа между различными микросервисами, так как содержит в себе сведения об аутентификации и авторизации конкретного пользователя. Среди популярных стандартов чаще всего используется JSON Web Token (JWT) или OpenID.

• Мелко-зернистое управление доступом (Fine-Grained Authorization). Управлять доступом можно на основе различных политик. Лучшими практиками считаются два подхода: групповая модель разграничения доступа (Role Based Access Conrol, RBAC) или разграничение доступа на основе аттрибутов (Attribute Based Access Control, ABAC). Первый отличается возможностью управлять крупными группами пользователей, второй необходим для более тонкой конфигурации. Предоставлять доступ к определенным API-методам можно с помощью ABAC, а разграничивать доступ до конкретных микросервисов можно с помощью передачи информации о роли пользователя в JWT-токене.

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

В публикации NIST 800-162 [4], посвященной разграничению доступа на основе аттрибутов (ABAC), приводится удобная терминология для описания взаимодействий между компонентами.

• Policy Administration Point (PAP) предоставляет пользовательский интерфейс для создания, управления, тестирования и отладки правил контроля доступа;

• Policy Decision Point (PDP) определяет решения доступа, оценивая применяемую политику контроля доступа;

• Policy Enforcement Point (PEP) применяет решения политики в ответ на запрос субъекта, запрашивающего доступ к защищаемому объекту;

• Policy Information Point (PIP) служит в качестве источника данных, необходимых для оценки политики, чтобы затем предоставить информацию, необходимую PDP для принятия решений.

В работе Authentication and authorization in microservice-based systems: survey of architecture patterns [5] (также статья на Habr) исследователи Александр Барабанов и Денис Макрушин анализируют существующие архитектурные подходы для реализации аутентификации и авторизации в микросервисных приложениях, приводят плюсы и минусы различных решений. Основное внимание уделяется обзору трем основным архитектурным шаблонам межсервисных взаимодействий:

1. Децентрализованный шаблон;

2. Централизованный шаблон с единой точкой принятия решения;

3. Централизованный шаблон со встроенной точкой принятия решения.

Каждый из шаблонов обладает своими характерными особенностями и возможностями к применению.

При использовании децентрализованного шаблона ответственность за безопасность ложится на плечи команды разработчиков конкретного сервиса. Повышается гибкость настройки конкретного микросервиса, но усложняется задача корректного взаимодействия всей системы. Любое изменение правил разграничения доступа требует полного тестирования всего функционала микросервиса, так как атрибуты доступа и политики находятся внутри исходного кода микросервиса. Следовательно, снижается скорость ввода микросервиса эксплуатацию и увеличиваются расходы на тестирование. Децентрализованный шаблон представлен на Рисунке 2.

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

Централизованный шаблон с механизмом встроенной точкой принятия решения отличается от единого тем, что хранение решений о доступе происходит внутри самих микросервисов. Это позволяет избежать наличие устаревших данных в кэше центра принятия решений из предыдущей модели. Наличие устаревших данных о предоставлении доступа может противоречить вновь внедряемым политикам ограничения доступа. Шаблон представлен на Рисунке 4.

Выводы и дальнейшая работа

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

Дальнейшая работа в этом направлении заключается в:

1. Анализе существующих решений и подходов парадигмы Zero Trust Architecture (ZTA) [6], которая заключается в нулевом доверии к компонентам системы и к переду с концепции «защиты на основе периметра/сегмента» к концепции «защиты конкретных ресурсов»;

2. Создании учебно-лабораторного стенда для реализации представленных микросервисных архитектур и проведении анализа эффективности.

Литература

1. Microservices Adoption in 2020 by Mike Loukides and Steve Swoyer // www.oreilly.com: официальный сайт издательства. URL: https://www.oreilly.com/radar/microservices-adoption-in-2020/ (дата обращения 10.5.2022)

2. OWASP API Security TOP 10 // owasp.org: официальный сайт проекта OWASP. URL: https://owasp.org/www-project-api-security/ (дата обращения 15.5.2022)

3. Yarygina T., Bagge A. H. Overcoming security challenges in microservice architectures //2018 IEEE Symposium on Service-Oriented System Engineering (SOSE). – IEEE, 2018. – С. 11-20

4. Hu V. C. et al. Attribute-based access control //Computer. – 2015. – Т. 48. – №. 2. – С. 85-88.

5. Barabanov A., Makrushin D. Authentication and authorization in microservice-based systems: survey of architecture patterns //arXiv preprint arXiv:2009.02114. – 2020.

6. Rose S. et al. Zero trust architecture. – National Institute of Standards and Technology, 2020. – №. NIST Special Publication (SP) 800-207.