Отказ от ответственности: Я решил загрузить на Хабр текст своей научной статьи для университетской конференции.
Сам материал мне показался вполне подходящим.
Это обзорная статья.
В ней я попытался провести исследование механизмов безопасности микросервисных архитектур.
Будучи специалистом по аппаратному обеспечению, меня также интересует вопрос построения безопасных архитектур.
Как говорится, если умеешь нападать, то умеешь и защищаться.
У меня нет опыта разработки и дизайна программного обеспечения.
Я смотрю на архитектуру с точки зрения возможных рисков безопасности.
Благодарю своего научного руководителя Каменских Антона Николаевича за помощь в написании работы.
Наслаждайся чтением.
А.
Н.
Каменских, К.
В.
Филимонов
Введение
Современные подходы к разработке программного обеспечения отражаются как в организационных мерах, например, методология управления проектами SCRUM/AGILE, так и в технических мерах.Технические меры направлены на улучшение архитектуры разрабатываемых приложений, повышение производительности конкретных модулей приложения, улучшение качества исходного кода, масштабируемости приложения и, конечно же, безопасности.
С точки зрения улучшения архитектуры приложения разработчики выделяют микросервисный подход как способ разделения функциональных компонентов приложения на отдельные сервисы.
Вопрос контроля доступа является фундаментальной проблемой в сфере информационной безопасности.
Эта задача включает в себя такие процессы, как предоставление доступа (авторизация), приостановка доступа и отзыв доступа.
С внедрением микросервисной архитектуры компоненты, отвечающие за авторизацию, вынесены в отдельный микросервис.
Раньше при использовании монолитных архитектур процесс авторизации требовал прохождения процедуры подтверждения легальности пользователя или данных (аутентификация).
С внедрением микросервисной архитектуры компоненты, отвечающие за аутентификацию, также вынесены в отдельный микросервис.
Возникает проблема обеспечения доверенных каналов связи между сервисами.
Ключевой задачей при реализации микросервисного подхода является обеспечение безопасности как самих микросервисов, так и информации, которая передается между ними.
Возникает необходимость создания безопасной архитектуры для взаимодействия микросервисов разной степени критичности, обрабатывающих информацию разной степени конфиденциальности.
Чтобы оценить эффективность различных решений, необходимо определить критерии эффективности.
Основными параметрами будут считаться сохранение скорости обработки данных, обеспечение безопасности и относительная стоимость внедрения решения.
Актуальность научных исследований
В соответствии с О'Рейли опрос [1] По состоянию на 31 января 2020 года, опрошенные 1502 читателями их списка рассылки, большинство респондентов (92%) сочли свой опыт работы с микросервисной архитектурой несколько успешным: 54% — успешным и 10% — очень успешным.Опрос показал, что только 21% респондентов выразили интерес к вопросам безопасности при использовании микросервисной архитектуры.
Современный подход к взаимодействию микросервисов может быть реализован за счет использования интерфейсов прикладного программирования (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).
Среди преимуществ: гибкость разработки, быстрое изменение технологий под требования бизнеса, возможность масштабирования, увеличение частоты обновлений продукта, повышение качества тестирования приложений, повышение уровня доступности и снижение затрат на разработку.
Рисунок 1. Плюсы микросервисных архитектур согласно опросу Орейли Важно отдельно выделить преимущества использования микросервисных архитектур с точки зрения безопасности:
- Сокращение кодовой базы и, как следствие, поверхности атаки.
Размещение бизнес-логики приложения в отдельных микросервисах уменьшает базу кода, что помогает уменьшить поверхность атаки.Меньше кода означает меньшую вероятность ошибки;
- Ускорьте время статического анализа и развертывания приложений до эксплуатационной готовности.
При реализации безопасных подходов к разработке программного обеспечения (Secure Software Development Life Cycle, S-SDLC) необходимо проводить статическое и динамическое автоматизированное тестирование разрабатываемых приложений (Static/Dynamic Application Security Testing, SAST/DAST).Использование микросервисного подхода ускоряет тестирование отдельных компонентов системы и сокращает время ввода в эксплуатацию (Time to Market);
- Скрытие всей функциональности приложения за конкретными микросервисами .
Использование архитектурного шаблона API Gateway позволяет получить доступ к функциональности определенных сервисов, указав определенные конечные точки.
Таким образом, значительная часть функционала может быть скрыта, а попытки эксплуатации уязвимостей микросервиса ограничены.
Текущие практики обеспечения безопасности микросервисов
В ходе выполнения Преодоление проблем безопасности в микросервисных архитектурах [3] Татьяна Ярыгина, исследователь безопасности из Бергенского университета, приводит список лучших практик повышения уровня безопасности микросервисов:- Взаимная аутентификация (взаимный TLS, mTLS) .
Внедрение механизмов взаимной аутентификации позволяет микросервисам устанавливать доверенный канал между собой на основе асимметричной криптографии протокола Transport Layer Security (TLS).
В статье приведены примеры двух принципиально разных подходов к реализации mTLS проектами Docker Swarm и Netflix. В обоих случаях основную роль играет Центр сертификации (ЦС), однако срок выдачи самозаверяющих сертификатов различается.
В первом случае срок переоформления составляет 3 месяца, во втором случае сертификаты выдаются как на длительный срок, так и на краткосрочный.
Выдача краткосрочных сертификатов связана с попыткой решить проблему отзыва сертификатов.
mTLS решает проблему шифрования и аутентификации канала связи, но не решает проблему авторизации.
- Токены безопасности (JWT).
Использование токенов безопасности также основано на криптографических принципах.Токены создаются на стороне отдельного микросервиса после успешного завершения процедуры аутентификации.
Лучшей практикой является внедрение счетчика деактивации токена, что позволит избежать его повторного использования в случае кражи.
Токен безопасности можно повторно использовать для разграничения доступа между различными микросервисами, поскольку он содержит информацию об аутентификации и авторизации конкретного пользователя.
Среди популярных стандартов наиболее часто используется JSON Web Token (JWT) или OpenID.
- Детальный контроль доступа (Детальная авторизация).
Доступ можно контролировать на основе различных политик.
Передовой практикой считаются два подхода: групповая модель управления доступом (управление доступом на основе ролей, RBAC) или управление доступом на основе атрибутов (ABAC).
Первый отличается возможностью управления большими группами пользователей, второй требует более тонкой настройки.
Вы можете предоставить доступ к определенным методам API с помощью ABAC, а также можете ограничить доступ к определенным микросервисам, передав информацию о роли пользователя в токене JWT.
Подходы к реализации авторизации в микросервисной архитектуре
В Публикации НИСТ 800–162 [4] об управлении доступом на основе атрибутов (ABAC) предоставляет полезную терминологию для описания взаимодействия между компонентами.
- Точка администрирования политики (PAP) предоставляет пользовательский интерфейс для создания, управления, тестирования и отладки правил контроля доступа;
- Точка принятия политического решения (PDP) определяет решения о доступе путем оценки применяемой политики управления доступом;
- Пункт обеспечения соблюдения политики (PEP) применяет решения политики в ответ на запрос субъекта, запрашивающего доступ к защищенному объекту;
- Информационный пункт политики (PIP) служит источником данных, необходимых для оценки политики, а затем предоставляет информацию, необходимую ПРП для принятия решений.
Основное внимание уделяется рассмотрению трех основных архитектурных шаблонов межсервисного взаимодействия:
- Децентрализованный шаблон;
- Централизованный шаблон с единой точкой принятия решения;
- Централизованный шаблон со встроенной точкой принятия решений.
С использованием децентрализованный шаблон Ответственность за безопасность ложится на плечи команды разработчиков конкретного сервиса.
Гибкость настройки конкретного микросервиса возрастает, но задача корректного взаимодействия всей системы усложняется.
Любое изменение правил контроля доступа требует полного тестирования всей функциональности микросервиса, поскольку атрибуты и политики доступа находятся внутри исходного кода микросервиса.
Следовательно, снижается скорость ввода микросервиса в эксплуатацию и увеличиваются затраты на тестирование.
Децентрализованная модель показана на рисунке 2. 
Рисунок 2. Децентрализованная модель Простота использования централизованный шаблон с единой точкой принятия решения заключается в возможности централизованного управления правилами контроля доступа, оторванными от конкретных микросервисов.
Становится возможным внешнее тестирование политик контроля доступа на наличие аномалий в тестовой среде.
Недостатками шаблона являются возрастающая сетевая нагрузка на центр распространения правил; Возможное решение проблемы — кэширование.
Централизованный шаблон с единой точкой принятия решения представлено на рисунке 3. 
Рисунок 3. Централизованный шаблон с единой точкой принятия решения Централизованный шаблон со встроенным механизмом принятия решений отличается от унифицированного тем, что решения о доступе хранятся внутри самих микросервисов.
Это позволяет избежать наличия устаревших данных в кэше центра принятия решений из предыдущей модели.
Наличие устаревших данных о предоставлении доступа может конфликтовать с недавно реализованными политиками ограничения доступа.
Шаблон показан на рисунке 4. 
Централизованный шаблон со встроенным механизмом принятия решений
Выводы и будущая работа
В этом документе были рассмотрены лучшие практики обеспечения аутентификации и авторизации в микросервисных приложениях, а также представлены основные архитектурные подходы.Построение оптимальной архитектуры — важнейшая задача при проектировании любых программных продуктов.
В связи с этим фактором и факторами, упомянутыми выше, на рынке существует потребность в архитекторах безопасности, людях, обладающих компетенцией и опытом построения безопасных систем.
Переход к микросервисным архитектурам меняет подход к защите распределенных приложений.
Выбор наиболее эффективной архитектуры зависит от многих факторов и требует создания метамодели для тестирования.
Дальнейшая работа в этом направлении состоит из:
- Анализ существующих решений и парадигмальных подходов Архитектура нулевого доверия (ZTA) [6], заключающееся в нулевом доверии к компонентам системы и в переходе от концепции «защиты на основе периметра/сегмента» к концепции «защиты конкретных ресурсов»;
- Создание учебно-лабораторного стенда для реализации представленных микросервисных архитектур и проведения анализа эффективности.
Литература
- Внедрение микросервисов в 2020 году Майк Лукидес и Стив Свойер // www.oreilly.com : официальный сайт издательства.
URL-адрес: https://www.oreilly.com/radar/microservices-adoption-in-2020/ (дата обращения 10.5.2022)
- ТОП-10 безопасности API OWASP // owasp.org : официальный сайт проекта OWASP. URL-адрес: https://owasp.org/www-project-api-security/ (дата обращения 15.5.2022)
- Ярыгина Т.
, Багге А.
Х.
Преодоление проблем безопасности в микросервисных архитектурах // Симпозиум IEEE по сервис-ориентированному системному проектированию (SOSE), 2018 г.
– IEEE, 2018. – стр.
11-20.
- Hu VC et al. Управление доступом на основе атрибутов //Компьютер.
– 2015. – Т.
48. – № 2. – С.
85-88.
- Барабанов А.
, Макрушин Д.
Аутентификация и авторизация в микросервисных системах: обзор паттернов архитектуры //Препринт arXiv arXiv:2009.02114. – 2020.
- Роуз С.
и др.
Архитектура нулевого доверия.
– Национальный институт стандартов и технологий, 2020. – нет. Специальная публикация NIST (SP) 800-207.
-
Понимание Pdf-Файлов
19 Oct, 24 -
Поддержка Sage Mas 90 – Значение Этой Услуги
19 Oct, 24 -
Конференция C++ Россия 2018
19 Oct, 24 -
Лего Арт
19 Oct, 24
