Один сервер — сотни арендаторов: как мультитенантность экономит ресурсы и упрощает администрирование
Представьте холдинг с десятком дочерних компаний. У каждой — свои сотрудники, свои токены, свои политики безопасности. И каждой нужна двухфакторная аутентификация. Ставить отдельный сервер для каждой организации — дорого и сложно. Держать всех в одной базе — рискованно.
Решение есть, и оно называется многоуровневой мультиарендностью (multi-tier multi-tenant). В Secure Authentication Server (SAS) от MFASOFT эта архитектура позволяет на одном экземпляре продукта обслуживать множество организаций — с собственными настройками, пользователями и журналами аудита. Подробнее — мультитенантность.
«Иерархия аккаунтов и их операторов позволяет реализовать централизованное, делегированное или совместное администрирование виртуальных серверов, воплощая принцип многоуровневой мультиарендности».
Что такое мультитенантность и зачем она нужна
Мультитенантность (multi-tenant) — это архитектурный принцип, при котором один экземпляр программного продукта обслуживает нескольких независимых пользователей (арендаторов). Каждый арендатор получает собственные настройки, политики и данные, но использует общую инфраструктуру.
Пользователи, их токены и целевые ресурсы распределяются по аккаунтам. Аккаунты могут создаваться по разным принципам:
- Функциональному. По целевым ресурсам.
- Географическому. По регионам.
- Ролевому. По функциям пользователей.
- Организационному. По подразделениям или организациям.
🔑 Ключевой вывод: Мультитенантность — это способ обслуживать многих клиентов без дублирования инфраструктуры. Один сервер, одна инсталляция — но у каждого арендатора свой «виртуальный» сервер аутентификации.
Много арендаторов
Один экземпляр — много организаций.
Изоляция
Свои политики и данные.
Иерархия
Многоуровневое дерево аккаунтов.
Делегирование
Сервис-провайдеры и подписчики.
Аудит
Свой журнал у каждого аккаунта.
Экономия
Без дублирования инфраструктуры.
Архитектура SAS: независимые модули
Сервер аутентификации Secure Authentication Server состоит из нескольких независимых модулей, каждый из которых выполняет определённый набор функций.
Модули SAS
- Модуль аутентификации. Для проверки одноразовых паролей и ПИН-кодов.
- Консоль управления. Для настройки и администрирования решения.
- Модуль активации. Для активации выданных пользователю токенов.
- Портал самообслуживания. Для самостоятельного сброса ПИН-кода и синхронизации токенов.
- Модуль синхронизации LDAP. Приём информации от агентов LDAP и запись в базу данных SAS.
- Модуль отчётности. Формирование отчётов по шаблонам с запуском мгновенно или по расписанию.
Как это работает для пользователя
- Вход. Пользователь обращается к целевому ресурсу и видит форму входа.
- Идентификатор. Вводит свой логин.
- Одноразовый пароль. Получает с устройства и вводит с ПИН-кодом.
- Проверка. Целевой ресурс отправляет данные на сервер аутентификации.
- Результат. Сервер проверяет данные в своей базе.
✅ Совет: Модульная архитектура позволяет масштабировать решение постепенно. Начните с базовых модулей — аутентификации и консоли управления — и добавляйте остальные по мере необходимости.
Иерархия аккаунтов: сервис-провайдеры и подписчики
Все аккаунты связаны в многоуровневое дерево. Это позволяет реализовать централизованное, делегированное или совместное администрирование виртуальных серверов.
Типы аккаунтов
- Подписчики. Аккаунты подразделений или организаций, которые используют решение только для себя.
- Сервис-провайдеры. Аккаунты, которые могут не только пользоваться решением, но и предоставлять доступ к нему другим аккаунтам.
Что получает каждый аккаунт
- Свой виртуальный сервер аутентификации. Тот же экземпляр продукта, но со своими настройками.
- Собственные политики. Относящиеся только к этому аккаунту.
- Операторы. Свои администраторы.
- Список пользователей. Только свои сотрудники.
- Пул токенов. Собственные токены.
- Журнал аудита. Свои события.
- Список узлов аутентификации. Свои целевые ресурсы.
Пример иерархии
Организация-арендатор может сама стать провайдером и предоставлять доступ своим субарендаторам — таким же сервис-провайдерам или конечным подписчикам. В среде одной организации этот принцип позволяет делегировать управление разным подразделениям.
⚠️ Важно: Не путайте мультитенантность с простым разделением пользователей по группам. Здесь каждый аккаунт — это полноценный виртуальный сервер со своей инфраструктурой и политиками.
Сравнение: мультитенантность vs изолированные инсталляции
| Параметр | Мультитенантность (SAS) | Отдельные инсталляции |
|---|---|---|
| Инфраструктура | Один экземпляр | Много серверов |
| Стоимость владения | Ниже | Выше |
| Администрирование | Централизованное или делегированное | Разрозненное |
| Изоляция данных | Виртуальные серверы | Физическая |
| Масштабирование | Добавление аккаунта | Новый сервер |
| Обновления | Одновременно для всех | По отдельности |
Мультитенантность выигрывает по стоимости и удобству администрирования. Отдельные инсталляции — только если требуется физическая изоляция по требованиям регуляторов.
Сценарии использования мультитенантности
Архитектура multi-tier multi-tenant подходит для разных задач. Вот основные сценарии.
Холдинги и группы компаний
- Делегирование. Каждое подразделение управляет своими пользователями.
- Централизация. Головная компания контролирует политики.
- Изоляция. Данные подразделений не пересекаются.
Сервис-провайдеры
- Предоставление услуг. Провайдер предлагает MFA своим клиентам.
- Субаренда. Клиенты могут создавать своих подписчиков.
- Масштабирование. Добавление новых клиентов без новых серверов.
Облачные решения
- Мультиарендная модель. Один экземпляр для многих клиентов.
- Гибкость. Настройка под каждого арендатора.
- Экономия. Общая инфраструктура.
🔑 Совет: Если вы предоставляете ИТ-услуги, мультитенантность SAS позволит вам предложить клиентам MFA как сервис — без развёртывания отдельного сервера для каждого.
Чек-лист внедрения мультитенантной аутентификации
Перед внедрением проверьте эти пункты — они помогут избежать ошибок.
- Структура. Как будут организованы аккаунты: по подразделениям, регионам, клиентам?
- Иерархия. Кто будет сервис-провайдером, а кто — подписчиком?
- Администрирование. Централизованное, делегированное или совместное?
- Изоляция. Нужна ли физическая изоляция для отдельных арендаторов?
- Токены. Как будет распределяться пул токенов между аккаунтами?
- Аудит. Как будут храниться журналы разных аккаунтов?
- Масштабирование. Сколько арендаторов планируется в перспективе?
- Сертификация. Нужна ли сертифицированная версия для регуляторов?
Мультитенантность — это не просто техническая функция. Это способ строить бизнес на аутентификации: обслуживать многих клиентов эффективно, безопасно и с минимальными затратами.
Частые вопросы о мультитенантности
Это когда один программный продукт обслуживает нескольких независимых клиентов (арендаторов). У каждого — свои настройки, пользователи и данные, но инфраструктура общая.
Подписчики используют решение только для себя. Сервис-провайдеры могут не только пользоваться решением, но и предоставлять доступ к нему другим аккаунтам — субарендаторам или конечным подписчикам.
Свой виртуальный сервер аутентификации с собственными настройками и политиками, операторами, списком пользователей, пулом токенов, журналом аудита и списком узлов аутентификации.
Да. Иерархия аккаунтов и их операторов позволяет реализовать централизованное, делегированное или совместное администрирование виртуальных серверов.
Да. Разные аккаунты могут соответствовать подразделениям одной организации. Это позволяет делегировать управление разным подразделениям и дочерним организациям, в том числе по сервисной модели.
Модуль аутентификации, консоль управления, модуль активации, портал самообслуживания, модуль синхронизации LDAP и модуль отчётности. Каждый выполняет свой набор функций.
По электронной почте support@mfasoft.ru или по телефону +7 (495) 228-02-08. Также можно оставить заявку на сайте mfasoft.ru.