Размещено на http://www.allbest.ru/

Аннотация

аутентификация микросервисный авторизация сервис

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

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

- проведено исследование микросервисной архитектуры приложений;

- выявлены основные требования реализации аутентификации в микросервисах;

- выявлены основные требования безопасности сквозного механизма аутентификации;

- проведено исследование существующих алгоритмов сквозной аутентификации;

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

- реализован прототип приложения со сквозной аутентификацией в микросервисах.

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

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

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

Введение

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

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

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

Для достижения поставленной цели необходимо исследовать следующие задачи:

- исследовать феномен микросервисной архитектуры приложений;

- выявить перечень требований реализации сквозной аутентификации в микросервисной архитектуре;

- выявить перечень требований безопасности сквозного механизма аутентификации;

- исследовать существующие популярные алгоритмы сквозной аутентификации;

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

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

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

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

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

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

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

1. Обзор предметной области и постановка задачи

1.1 Терминология

Идентификация [1] - процесс присвоения объектам или субъектам системы идентификационного номера или сравнение идентификационного номера с перечнем существующих идентификационных номеров.

Аутентификация [1] - процесс проверки подлинности объекта или субъекта системы посредством сравнения пользовательского пароля с паролем, хранящимся в БД и соответствующим пользовательскому имени (логину).

Авторизация [1] - процесс проверки доступа конкретного объекта или субъекта к заданному ресурсу.

1.2 Основные понятия

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

Монолитная архитектура - основной подход разработки программного обеспечения, при котором структура приложения включает в себя четыре основных блока: интерфейс пользователя (UI), уровень обработки бизнес-логики, уровень обработки данных, уровень хранения данных.



Рис. 1. Уровни монолитной архитектуры

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

У монолитной архитектуры есть свои преимущества и недостатки.

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

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

Модульность - принцип, при котором не связанные или слабо связанные между собой сервисы или функциональности разносятся на отдельные независимые модули. На практике каждый модуль микросервисной архитектуры может быть представлен как в виде директорий, так и в виде самостоятельных файлов. [2]

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

Сервис-ориентированная архитектура (SOA) - один из подходов разработки программного обеспечения, нацеленный на реализацию отдельных самостоятельных слабо зависящих друг от друга, заменяемых модулей. [3]

Каждый сервис SOA отвечает за исполнение конкретной задачи в системе. В результате в большинстве случаев комбинация этих сервисов представляет собой набор веб-служб, взаимодействующих между собой согласно протоколу SOAP (service-oriented architecture protocol).

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

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

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

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

1.3 Реализация микросервисов

1.3.1 JSON

Стандартом для передачи запросов и получения ответов в современных микросервисах выступает JavaScript Object Notation (JSON). Разработчику ничего не мешает использовать REST, но в ответ от любого сервера или сервиса чаще всего в ответ приходит в формате JSON.

Существует три основные причины, из-за которых стоит использовать JSON:

- Удобочитаемость

Формат данных для JSON прост. Данные отображаются в двух формах: пары имя/значение или список значений.

Данные, описанные в формате JSON легко читать и писать разработчикам и легко анализировать и генерировать машинам.

- Эффективность

Поскольку JSON избегает всего тегированного внешнего вида как HTML, так и XML, он, как правило, меньше, чем другие виды передачи данных.

- Распространенность

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

Прежде чем начать работать с JSON, полезно получить руководство по его использованию. JSON прост, но пример будет иметь больше смысла, если иметь представление, как работает JSON.

1.3.2 Использование микросервисов для общения с REST

Один из вариантов организации взаимодействия между сервисами - репрезентативная передача состояния (REST), которая является архитектурным стилем связи, поскольку она легче, чем протоколы, такие как протокол доступа к простым объектам (SOAP).

Приложения, использующие REST для связи, называются приложениями RESTful. [40] Использование REST для микросервисов дает следующие преимущества:

- отделяет производителей от потребителей;

- обеспечивает связь без сохранения состояния;

- позволяет использовать кэш;

- позволяет использовать многоуровневую систему;

- обеспечивает единый интерфейс.

Существует множество методов использования REST в микросервисной архитектуре. Основными или наиболее часто используемыми http-методами являются POST, GET, PUT, PATCH и DELETE. Они соответствуют операциям создания, чтения, обновления и удаления (или CRUD) соответственно. Существует также ряд других глаголов, но они используются реже.

Ниже приведена таблица, суммирующая рекомендуемые возвращаемые значения основных методов HTTP в сочетании с URIs ресурса:

Таблица 1. Основные методы RESTful архитектуры

HTTP-метод	CRUD	Ответ сервера	Исключения
POST	Create	201 (Created)	404 (Not Found) 409 (Conflict)
GET	Read	200 (OK)	404 (Not Found)
PUT	Replace	200 (Replaced)	404 (Not Found) 405 (Method not allowed)
PATCH	Update	200 (Updated)	404 (Not Found) 405 (Method not allowed)
DELETE	Delete	200 (Deleted)	404 (Not Found) 405 (Method not allowed)

1.3.3 Особенности подхода

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

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

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

Что стоит сделать вместо этого: вопросы о том, что на самом деле должно быть построено, должны быть явно рассмотрены на ранних этапах проекта, например, кто будет разрабатывать и поддерживать новые услуги? Кто является основными пользователями системы? Какие языки, платформы и технологии будут поддерживаться? Какие инструменты понадобятся разработчикам для создания и развертывания новых служб?

Архитектура микросервисов облегчает индивидуальное управление службами для достижения эксплуатационной гибкости, масштабируемости и отказоустойчивости. В этом контексте четко определенный API (application programming interface) каждого сервиса играет ряд важных ролей:

- Абстракция

API сервиса позволяет нам думать с точки зрения того, что делает сервис, в отличие от того, как он реализуется.

- Инкапсуляция

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

- Состав

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

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

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

Для микросервисов довольно часто используются простые протоколы связи, такие как http, или в некоторых случаях легкие брокеры сообщений. Обмен сообщениями может быть закодирован различными способами, от удобочитаемых форматов (JSON, YAML) до сериализованных двоичных объектов.

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

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

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

В традиционной монолитной архитектуре довольно часто создается централизованная модель домена [5], которая затем используется для реализации всех функциональных возможностей, от проверки ввода до бизнес-логики и сохранения бизнес-объектов в базе данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На основании обзора основных особенностей реализации микросервисов формируется перечень основных аспектов реализации приложений с микросервисной архитектурой:

- один сервис - одна функциональность;

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

- ручное и/или юнит-тестирование сервисов по отдельности и совместно;

- децентрализованность;

- поддержка JSON;

- наличие API.

1.4 Безопасность

1.4.1 Проблемы аутентификации в микросервисной архитектуре

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

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

Сервисы должны следовать принципу единственной ответственности.

Принцип единственной ответственности (single responsibility principle) [6] -- это принцип объектно-ориентированного программирования, который гласит, что каждый модуль должен нести ответственность за одну часть функциональности приложения. Проще говоря, один сервис обрабатывает одну часть бизнес-логики. Глобальная логика проверки подлинности и авторизации должна являться самостоятельным сервисом.

HTTP-протокол является протоколом без сохранения состояния (stateless protocol). [7] Для сервера каждый HTTP-запрос пользователя является независимым. Одним из ключевых свойств HTTP-протокола является способность сервера отправлять запросы клиента через любой узел кластера. Структура HTTP без отслеживания состояния имеет очевидные преимущества для балансировки нагрузки.

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

Традиционным способом является использование сеанса на стороне сервера для сохранения состояния пользователя. Поскольку сервер отслеживает состояние, это влияет на горизонтальное расширение сервера.

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

1.4.2 Основные практики безопасности

Предположение, что межсетевого экрана на периметре сети достаточно для защиты программного обеспечения, является большой ошибкой. Глубокая защита (defence in depth) [8] определяется как "концепция обеспечения информации, в которой несколько уровней контроля безопасности (обороны) размещаются по всей системе информационных технологий."

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

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

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

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

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

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

CoreOS, Red Hat Atomic Linux и Ubuntu Snappy Core - примеры проектов, которые пытаются реализовать описанную концепцию на уровне ОС.

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

Во избежание описанных проблем следует использовать промежуточный слой - API-шлюз - между клиентским приложением и микросервисами.

Amazon, с их API-шлюзом AWS, вероятно, сделал понятие API-шлюза более распространенным и легким для принятия, чем кто-либо другой.

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

С помощью этого метода можно защитить все микросервисы за брандмауэром, позволяя шлюзу API обрабатывать внешние запросы, а затем обращаться к микросервисам за брандмауэром.

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

- механизм аутентификации - отдельный сервис;

- использование протоколов SSH/TLS;

- автоматизация процессов жизненного цикла приложения;

- использование существующих крипто-библиотек.

2. Исследование методов аутентификации

В сфере онлайн-сервисов под идентификацией подразумевается определение учетной записи пользователя по логину или email; под аутентификацией подразумевается проверка соответствия введенного пользователем пароля и пароля, заданного для конкретной учетной записи, а под авторизацией подразумевается проверка роли пользователя в системе и правила доступа пользователя в те или иные его сервисы.

2.1 Основные подходы

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

2.1.1 Глобальная аутентификация и авторизация

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

2.1.2 Глобальная аутентификация, авторизация сервисов

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

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

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

Важное замечание: этот метод требует наличия серьезной аутентификации и авторизации между сервисами (используя системы для администрирования Istio и mTLS [10]). Необходимо убедиться, что при получении запроса на выполнение каких-либо действий в микросервисе с заданным контекстом безопасности контексту безопасности можно доверять.

2.1.3 Проверка подлинности и авторизация службы

Основная идея подхода заключается в аутентификации в каждом микросервисе приложения по отдельности.

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

2.2 Основные протоколы аутентификации

Хотя существует столько собственных методов аутентификации, сколько систем, которые их используют, они в значительной степени являются вариациями нескольких основных подходов [11]:

- обычная проверка подлинности HTTP;

- ключ API;

- многофакторная аутентификация;

- протокол OAuth.

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

2.2.1 Обычная проверка подлинности HTTP

Базовая аутентификация (Base Authentication) HTTP редко рекомендуется из-за присущих ей уязвимостей безопасности.

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

Проблема состоит в том, что, если система не использует SSL [12], аутентификация передана в открытом виде на небезопасных линиях. Это поддается атакам man-in-the-middle [13], где пользователь может просто захватить данные входа в систему и аутентифицироваться через HTTP-заголовок copy-cat, прикрепленный к вредоносному пакету.

Кроме того, даже если SSL применяется, это приводит к замедлению времени ответа. И даже игнорируя это, в своей базовой форме HTTP-запрос никоим образом не шифруется. Он кодируется в base64 и часто ошибочно объявляется зашифрованным из-за этого.

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

2.2.2 Ключ API

Ключи API (API-key) являются отраслевым стандартом, но не должны рассматриваться как целостная мера безопасности.

Ключи API были созданы как своего рода исправление для ранних проблем аутентификации HTTP Basic Authentication и других подобных систем. При таком подходе каждому первому пользователю присваивается уникальное сгенерированное значение, означающее, что пользователь известен. Когда пользователь пытается повторно войти в систему, его уникальный ключ (иногда генерируется из их аппаратной комбинации и IP-данных, а иногда случайным образом генерируется сервером, который их знает) используется, чтобы доказать, что они тот же пользователь, что и раньше.

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

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

2.2.3 Многофакторная аутентификация

Многофакторная аутентификация (Multi-factor authentication, MFA) [14] - это система безопасности, которая проверяет личность пользователя, требуя несколько учетных данных. Вместо того, чтобы просто запрашивать имя пользователя и пароль, MFA требует дополнительные учетные данные, такие как код со смартфона пользователя, ответ на секретный вопрос, отпечаток пальца или распознавание лица.

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

Примеры многофакторной аутентификации включают использование комбинации этих элементов для аутентификации:

- коды, генерируемые приложениями для смартфонов;

- бейджи, USB-устройства или другие физические устройства;

- короткие токены, сертификаты;

- отпечатки пальцев;

- коды, отправленные на адрес электронной почты;

- распознавание лица;

- сканирование сетчатки или радужки глаза;

- поведенческий анализ;

- оценка риска;

- ответы на вопросы личной безопасности.

Когда дело доходит до MFA, обычно предполагается три типа факторов аутентификации:

- то, что знает пользователь (знания): пароль или PIN-код;

- то, что есть у пользователя (владение): бейдж или смартфон;

- то, что есть у пользователя (наследование): биометрия, отпечатки пальцев или распознавание голоса.

Последние решения MFA включают дополнительные факторы, учитывая контекст и поведение при аутентификации. Например:

- местонахождение пользователя при попытке получить доступ, например в кафе или дома;

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

- какое устройство используется, например смартфон или ноутбук;

- к какой сети обращается пользователь, частной или публичной.

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

2.2.4 Протокол OAuth

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

OAuth технически является не только методом аутентификации, но и авторизации.

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

Рис. 2. Описание процесса авторизации в Oauth [38]

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

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

Имея эти предостережения в виду, OAuth можно легко настроить, и аутентификация будет работать невероятно быстро.

2.2.5 Особенности OAuth

OAuth -- это своего рода протокол протоколов или мета-протокол, что означает, что он обеспечивает полезную отправную точку для других протоколов (например, OpenID Connect, NAPS и UMA). Это аналогично тому, как WS-Trust использовался в качестве основы для WS-Federation, WS-SecureConversation и т. д., если существует такая система отсчета. [15]

Вначале работы с OAuth важно учитывать, что он решает ряд важных потребностей, которые есть у большинства поставщиков API, в том числе:

- делегированный доступ;

- снижение обмена паролями между пользователями и третьими лицами (так называемый “пароль анти-паттерн”);

- аннулирование доступа.

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

В OAuth существует четыре основных актера в OAuth:

- владелец ресурса (RO): сущность, контролирующая данные, предоставляемые API, обычно конечный пользователь,

- клиент: мобильное приложение, сайт и др. что хочет получить доступ к данным от имени владельца ресурса,

- сервер авторизации (AS): служба маркеров безопасности (STS) или, в просторечии, сервер OAuth, который выдает маркеры,

- сервер ресурсов (RS): служба, предоставляющая данные, т. е. API.

Рис. 3. Абстрактное описание протокола [38]

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

В OAuth существует два вида токенов:

- маркеры доступа: это маркеры, представленные API;

- маркеры обновления: они используются клиентом для получения нового маркера доступа от AS;

- маркер идентификатора: определяет OpenID Connect.

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

Порядок того, как система передает токены среди сервисов, безусловно, повлияет на общую безопасность. Существует два различных способа передачи токенов:

- по значению;

- по ссылке.

Они аналогичны тому, как язык программирования передает данные, идентифицированные переменными.

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

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

OpenID Connect основан на OAuth. OpenID Connect обеспечивает протокол, организуя деятельность сервисов. Этот профиль также добавляет новые конечные точки, потоки, типы маркеров, области и многое другое. OpenID Connect (который часто сокращается OIDC) был рассчитан на применение в мобильной сфере. Виды маркеров, которые он определяет, должны быть JWT, которые были также разработаны для сценариев с низкой пропускной способностью. При использовании OAuth, доступен как делегированный доступ, так и доступ к возможностям системы. Это ознаменует меньшее количество зависимостей и снижение уровня сложности.

2.2.6 OAuth 2.0

В обновленной версии OAuth 2.0 реализовано больше потоков OAuth, чтобы обеспечить лучшую поддержку приложений, не основанных на браузере. Это основная критика OAuth от клиентских приложений, которые не были основаны на браузере. Например, в OAuth 1.0 настольные приложения или приложения для мобильных телефонов должны были указать пользователю открыть браузер для нужной службы, пройти аутентификацию в службе и скопировать маркер из службы обратно в приложение. Основная критика здесь направлена против пользовательского опыта. С OAuth 2.0 теперь существуют новые способы получения авторизации пользователя в приложениях.

OAuth 2.0 больше не требует, чтобы клиентские приложения имели криптографию. Это возвращает нас к старому API аутентификации Twitter, который не требовал приложения для хэш-токенов HMAC и строк запроса. С OAuth 2.0 приложение может сделать запрос, используя только выданный маркер по HTTPS.

Подписи OAuth 2.0 гораздо менее сложны. Нет больше специального разбора, сортировки или кодирования.

Токены доступа OAuth 2.0 являются "недолговечными". Как правило, токены доступа OAuth 1.0 могут храниться в течение года или более (Twitter никогда не позволяет им истекать). В протоколе OAuth 2.0 помимо токенов доступа предусмотрены токены обновления. Предполагается, что токены доступа могут быть недолговечными (т. е. основанными на сеансе), а токены обновления могут быть "временем жизни". Пользователь может использовать маркер обновления для получения нового маркера доступа, а не для повторною авторизацию в приложении.

Наконец, OAuth 2.0 должен иметь четкое разделение ролей между сервером, ответственным за обработку запросов OAuth, и сервером, обрабатывающим авторизацию пользователя. [15]

2.2.7 OpenID Connect

OpenID Connect - OpenID Connect 1.0 -- это простой уровень идентификации поверх протокола OAuth 2.0. Это позволяет клиентам проверять личность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя совместимым и REST-подобным образом.

OpenID Connect позволяет клиентам всех типов, включая веб-, мобильные и JavaScript-клиенты, запрашивать и получать информацию об аутентифицированных сеансах и конечных пользователях. Набор спецификаций является расширяемым, позволяя участникам использовать дополнительные функции, такие как шифрование идентификационных данных, обнаружение поставщиков OpenID и управление сеансами, когда это имеет смысл для них. [16]

OpenID Connect определяет токены ID. Они предназначены для клиента. В отличие от маркеров доступа и маркеров обновления, непрозрачных для клиента, маркеры идентификаторов позволяют клиенту знать, среди прочего:

- как пользователь прошел проверку подлинности (т. е. какой тип учетных данных был использован);

- когда пользователь прошел проверку подлинности;

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

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

2.2.8 Сравнительный анализ механизмов аутентификации

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

Основные критерии для сравнения методов аутентификации:

- способ ввода;

- необходимость дополнительных устройств, например, сканера отпечатков пальцев;

- надежность при попытках взлома;

- срок жизни аутентифицирующей информации;

- сложность внедрения/поддержки;

- сложность эксплуатации для пользователя;

- наличие нормативной документации, регламента использования;

- популярность использования разработчиками.

Таблица 2.Сравнительный анализ методов аутентификации

Критерий оценки	Обычная проверка подлинности	Ключ API	Многофакторная аутентификация	OAuth	OAuth 2.0
Способ ввода	Клавиатур	Автоматич	Клавиатур	Автоматич	Автоматичй
Дополни-тельные устройства	Не требуются	Не требуются	Требуются	Не требуются	Не требуются
Надежность	Низкая	Средняя	Высокая	Высокая	Высокая
Срок жизни аутентифицирующих данных	Длительный (выбирается пользователем)	Длительный	Равен длительности сеанса	До года	Сутки
Сложность внедрения	Низкая	Средняя	Высокая	Средняя	Средняя
Сложность использования пользователем	Низкая	Низкая	Высокая	Низкая	Низкая
Документация	Не требуется	Присутствует	Присутствует	Присутствует	Присутствует
Популярность	Низкая	Средняя	Высокая	Высокая	Высокая

Итак, какой из пяти подходов является лучшим? На этот вопрос трудно ответить, и сам ответ во многом зависит от ситуации. В то время как явным победителем является OAuth, есть некоторые варианты использования, в которых могут быть уместны ключи API или обычная проверка подлинности HTTP.

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

3. Реализация прототипа

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

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

3.1 Техническая составляющая

Прототип приложения разработан на языке Python версии 3.6.6.

Python -- это высокоуровневый, интерпретируемый и динамический язык программирования, который фокусируется на читабельность кода. Синтаксис Python помогает программистам писать код за меньшее количество шагов по сравнению с Java или C++. Язык основан в 1991 году разработчиком Guido Van Rossum с целью сделать программирование быстрым и доступным. Python широко используется в крупных организациях из-за его многочисленных парадигм программирования. Они обычно включают императивное и объектно-ориентированное функциональное программирование. Python имеет всестороннюю и большую стандартную библиотеку, которая имеет автоматическое управление памятью и динамические особенности.

...