Облачные SaaS-решения, как и большинство других решений, нуждаются в многопользовательской среде. Давайте быстро рассмотрим, что такое мультитенантность, что мы можем получить от нее и как легко реализовать ее с помощью двух простых уровней.
Что такое мультитенантность
По своей сути мультитенантность позволяет каждой части сервиса (т.е. каждому микросервису) обслуживать несколько клиентов без развертывания отдельных экземпляров для каждого из них.
Для того чтобы SaaS-решение могло доступно масштабироваться, удовлетворять потребности клиентов и быть при этом эластичным (т.е. экономичным в использовании облачных ресурсов), оно должно поддерживать многопользовательский режим.
Многопользовательская архитектура предоставляет множество отличных и часто необходимых функций:
-
Позволяет приложению обслуживать сразу несколько клиентов, при этом совместно используя базовую инфраструктуру и сервисы.
-
Безопасное и совместимое разделение доступа
-
балансировка нагрузки и масштабирование
Два уровня многопользовательской архитектуры
В конце концов, многопользовательская поддержка проста, если вы ее понимаете, и в основном она требует только двух вещей: контроль доступа на уровне приложений и управление схемами данных.
Давайте разделим это на две плоскости:
- Плоскость данных — это все о том, как вы передаете, храните **и управляете **разделенными данными (т.е. как базовая инфраструктура избегает смешивания данных разных арендаторов). Мультиарендаторство для плоскости данных часто реализуется как разделение на уровнях данных — например, отдельные разделы, таблицы, столбцы, идентификаторы и/или метки в схеме хранения данных (как вы сохраняете их в базе данных) и темы (например, темы Kafka), теги, домены, сокеты и/или порты для данных при передаче.
Пример таблиц БД с простым разделением арендаторов на основе столбцов
- Плоскость приложения — это то, как вы разделяете контекст и доступ в пределах логического уровня, т.е. чтобы один и тот же код работал для разных арендаторов. Авторизация — это компонент в плоскости приложения, реализующий многопользовательский доступ.
Пример маршрута приложения, обеспечивающего многопользовательский доступ с помощью SDK Permit.io (проверьте его на Github).
Реализация многопользовательской авторизации
Уровень авторизации — это самый быстрый и надежный способ безопасно перейти от однопользовательского приложения к многопользовательскому. Кроме того, уровень авторизации может реализовать разделение, не требуя изменений в самих службах, путем применения политики ко всем соответствующим службам.
Выбор правильной модели политики может упростить этот переход еще больше, с классическими моделями, такими как RBAC + Tenancy, ReBAC + Hierarchy (арендаторы становятся отношениями корневого уровня) или простым *ABAC * (с арендой в качестве атрибута).
Замечательно то, что нам не нужно самостоятельно реализовывать авторизацию с несколькими арендаторами, вместо этого мы можем воспользоваться готовыми инструментами и сервисами с открытым исходным кодом.
Реализация многопользовательской авторизации с помощью OPA + OPAL (с открытым исходным кодом)
Открытый исходный код — это отличный вариант для начала реализации уровня авторизации для многопользовательской сети. Хотя существует множество вариантов, Open Policy Agent (OPA) является одним из наиболее перспективных.
OPA действует как микросервис авторизации, который мы можем добавить в наше приложение и использовать для обеспечения доступа с помощью правил, написанных на собственном языке Rego.
Объединение OPA с OPAL (Open Policy Administration Layer) позволяет нам управлять уровнем авторизации в масштабе, используя темы Pub/Sub для поддержания агентов в актуальном состоянии с политикой (код Rego) и данными (документы JSON). Темы, например, могут быть именами или идентификаторами арендаторов, что позволяет синхронизировать агентов с изменениями для каждого арендатора.
Реализация многопользовательской аренды с Permit.io (сервис)
Решения для авторизации приложений (такие как Permit.io 😇 ) решают аспект приложений из коробки и легко накладываются на плоскость данных путем предоставления (или соотнесения в соответствии с) уникальных идентификаторов, которые могут быть использованы для разделения плоскости данных.
Permit строится поверх OPA и OPAL, добавляя интерфейсы управления, включая список арендаторов, управление ресурсами арендаторов и управление пользователями для каждого арендатора.
Переключение между арендаторами в приборной панели Permit.io
Подводя итог.
Мультиарендность позволяет нашему приложению обслуживать множество клиентов без развертывания отдельных экземпляров для каждого из них. Обеспечение многопользовательского доступа в gist состоит из двух плоскостей: данных и приложений. Один из лучших способов достижения многопользовательской эксплуатации — создание уровня авторизации, который может реализовать разделение, не требуя изменений в самих сервисах. Хотя вы можете создать свой собственный уровень авторизации, существуют также варианты с открытым исходным кодом (например, OPA + OPAL) и *сервисы* (например, Permit.io), которые позволяют реализовать его в вашем приложении, что делает критический переход к многопользовательской среде более доступным.
Рассматриваете возможность многопользовательского использования для своего приложения? Есть вопросы? Присоединяйтесь к нашему сообществу Slack и общайтесь с коллегами-разработчиками, создающими авторизацию!