Многоуровневая мультиарендность (multi-tier multi-tenant).
Программный комплекс MFASOFT SAS был разработан с учетом требований крупных корпоративных заказчиков и сервис-провайдеров, и отличается уникальной на российском рынке многоуровневой мультиарендной (multi-tier multi-tenant) архитектурой. Ниже описаны основные принципы и возможности заложенной в продукт мультиарендности.
Что такое мультиарендность?
Это архитектурный принцип, который позволяет создавать на одном установленном экземпляре программного обеспечения несколько независимо управляемых разделов. Такая возможность предназначена прежде всего для поставщиков программного обеспечения по сервисной модели (Software-as-a-Service, SaaS), которые устанавливают и поддерживают программное обеспечение, а вот администрируют его их клиенты (абоненты, подписчики). Фактически каждый такой клиент получает в свое распоряжение отдельный логический (виртуальный) сервер, которым он может управлять автономно. Получается, что клиенты делят между собой ресурсы приложения подобно тому, как земельный участок или дом делят несколько арендаторов. Поэтому такие разделы часто называют тенантами (от английского tenant - арендатор), а саму архитектуру — мультиарендной (multi-tenant).
Другой сценарий использования мультиарендности — корпоративные заказчики, где много пользователей, и где доступ и ответственность должны быть строго разграничены. В этом случае ИТ-подразделение головной компании (или вообще отдельная компания-инсорсер) запускает и обслуживает решение, а для дочерних компаний (филиалов, подразделений) создаются тенанты, администрированием которых занимаются локальные ИТ-отделы.
Альтернативы мультиарендности.
Без мультиарендной архитектуры пришлось бы устанавливать для каждой организации-клиента отдельный экземпляр ПО на отдельном «железе». Понятно, что это дорого, ведь клиентам пришлось бы платить за такие выделенные для них серверы независимо от их реальной загрузки. Поэтому как только появились технологии, которые позволили делить аппаратные ресурсы между несколькими экземплярами приложения и надежно изолировать их друг от друга (виртуализация, контейнеризация), этой возможностью сразу воспользовались сервис-провайдеры. Но какими бы эффективными ни были эти технологии, все равно остаются накладные расходы на установку, поддержку и (иногда) лицензирование отдельных экземпляров прикладного ПО.
Аккаунты и виртуальные серверы.
На одной инсталляции (в одном контейнере Docker) Secure Authentication Server можно создать неограниченное количество аккаунтов, которые объединяются в дерево c «корнем», «ветвями» и «листьями». Аккаунт (он же тенант) — учетная запись организации-заказчика (с точки зрения сервис-провайдера) или подразделения, дочерней компании, филиала (с точки зрения головного подразделения) . Количество уровней такого дерева не ограничено, поэтому такая архитектура и называется многоуровневой (multi-tier). Любой родительский аккаунт является сервис-провайдером для дочернего, который, в свою очередь, может быть просто подписчиком (конечным потребителем ресурсов) или же виртуальным сервис-провайдером (который предоставляет часть ресурсов своим «дочкам»).
Каждый аккаунт обслуживается своим виртуальным сервером со своими набором пользователей, токенов OTP или PUSH, групп, настроек, политик. Виртуальный сервер имеет свой набор источников LDAP и свой набор агентов, от которых он принимает запросы на аутентификацию.
Планирование структуры.
Принципы создания аккаунтов могут быть разными. В корпоративных заказчиках можно использовать:
- Организационный (аккаунты для подразделений или дочерних компаний).
- Географический (аккаунты для городов, регионов или временных зон).
- Функциональный (пользователи объединяются по набору ресурсов, к которым им нужен доступ — например, HR, бухгалтерия, маркетинг и так далее).
- Ролевой (по уровню доступа к корпоративным информационным ресурсам — например, руководство, служба ИБ, удаленные сотрудники, временные сотрудники, сотрудники внешних организаций и так далее).
Так как пользователи Secure Authentication Server (SAS) в крупных компаниях обычно синхронизируются из каталога LDAP, структура аккаунтов может повторять структуру каталога LDAP с доменами и организационными единицами (Organizational Unit, OU).
В облачных провайдерах всё проще: для каждого заказчика создается его аккаунт-тенант, в котором при необходимости уже сам заказчик может самостоятельно создавать подчиненные аккаунты.
Управление в мультиарендной среде.
Управлять аккаунтом, то есть создавать и удалять дочерние аккаунты, изменять их тип (с подписчика на сервис-провайдера и наоборот) и срок действия могут только пользователи с ролью менеджера аккаунта. Менеджер аккаунта получает пул пользовательских лицензий из родительского аккаунта и сам в свою очередь может перераспределять их между своим и дочерними. Лицензии, распределенные в дочерний аккаунт, можно перераспределять дальше вниз по дереву аккаунтов.
Права управления виртуальными серверами есть у тех, кто их создал (то есть у менеджеров родительского аккаунта) и у назначенных операторов. При этом аккаунт-менеджер, хотя и может управлять виртуальными серверами дочерних аккаунтов, не имеет доступа к виртуальным серверам аккаунтов-«внучек». Благодаря этой особенности можно реализовать такие модели управления:
- Прямое: менеджеры аккаунта сами управляют виртуальными серверами аккаунтов-«дочек».
- Совместное: виртуальными серверами управляют менеджеры родительского аккаунта и специально назначенные операторы из числа пользователей этих виртуальных серверов.
- Делегированное: виртуальными серверами-«внучками» управляют специально назначенные операторы виртуальных серверов-«дочек», которым для этого присвоена роль менеджера своего аккаунта.
Узлы аутентификации.
Каждому виртуальному серверу SAS можно назначить свой набор узлов аутентификации (IP-адресов, с которых будут приходить запросы на аутентификацию по OTP или пуш-уведомлениям). Тем самым можно задать, какие целевые ресурсы будут доступны учетным записям из этого виртуального сервера. Когда пользователь обращается к целевому ресурсу, агент этого ресурса обращается к сервису аутентификации, тот определяет по IP-адресу узел аутентификации и направляет запрос к нужному виртуальному серверу. Этот запрос будет обрабатываться в соответствии с политиками, заданными на этом виртуальном сервере.
По умолчанию узел аутентификации доступен только пользователям виртуального сервера, в котором добавлен этот узел. Однако иногда требуется предоставить узел аутентификации также пользователям из дочерних аккаунтов. В этом случае можно указать те аккаунты, пользователям которых будет доступна аутентификация через этот узел. Но так как виртуальные серверы управляются автономно, пользователи из разных виртуальных серверов могут иметь совпадающие логины, и для того, чтобы различать этих пользователей и определять нужный виртуальный сервер, SAS поддерживает два режима разделения узлов аутентификации.
- При разделении узлов с помощью суффикса/префикса (режим «общий узел с разделителем» в консоли администрирования) используются домены аутентификации — строки символов, которые нужно добавлять к идентификатору пользователя (до или после него) при аутентификации через общий узел. Каждый домен сопоставляется со своим аккаунтом. В качестве домена аутентификации можно использовать суффиксы UPN (user@domain.com), домены Windows NT (DOMAIN\user) или любые другие произвольно выбранные администратором решения строки.
- Разделение узлов без суффикса/префикса (режим «общий узел» в консоли администрирования) используется, если пользователи сопоставляются с виртуальными серверами не по доменам, а только по логинам. Так как в решении могут быть учетные записи с совпадающими логинами, то в этом режиме нужная учетная запись пользователя определяется порядком поиска (перебора) виртуальных серверов аккаунтов, совместно использующих узел аутентификации.