Что Такое Мультитенантность?
Мультитенантность — это архитектура, при которой один экземпляр ПО обслуживает множество клиентов (тенантов). Данные каждого тенанта изолированы, но они разделяют код приложения, инфраструктуру и часто одну базу данных.
Большинство современных SaaS-продуктов — Slack, Jira, Salesforce, Shopify — мультитенантны. Как QA-инженеру, работающему с SaaS, понимание тестирования мультитенантности необходимо: утечки данных между тенантами могут привести к судебным искам и регуляторным штрафам.
Паттерны Мультитенантной Архитектуры
| Паттерн | Описание | Сложность тестирования |
|---|---|---|
| Общая БД, общая схема | Все тенанты в одной БД с колонкой tenant_id | Наивысший риск |
| Общая БД, отдельные схемы | Одна БД, каждый тенант со своей схемой | Средний риск |
| Отдельные БД | Каждый тенант со своей БД | Низший риск |
| Гибридный | Комбинация в зависимости от уровня | Сложно |
Критические Области Тестирования
Изоляция Данных
Самая важная категория тестирования. Каждая операция с данными должна быть ограничена текущим тенантом.
Тесты на уровне API:
- Доступ к ресурсам другого тенанта через подмену ID в URL
- Доступ через подмену идентификатора тенанта в заголовках
- SQL injection для обхода фильтрации по тенанту
- Массовые операции, которые могут случайно включить данные других тенантов
Тесты на уровне UI:
- Результаты поиска показывают только данные текущего тенанта
- Выпадающие списки и автодополнение предлагают только элементы текущего тенанта
- Отчёты и дашборды агрегируют только данные текущего тенанта
Конфигурация Тенанта
Каждый тенант может настраивать: брендинг, роли и разрешения, workflow, интеграции, пользовательские поля.
Проверяйте, что изменения конфигурации Тенанта A не затрагивают Тенанта B.
Уровни Подписки и Feature Gating
| Функция | Free | Pro | Enterprise |
|---|---|---|---|
| Пользователи | 5 | 50 | Безлимит |
| Хранилище | 1 ГБ | 50 ГБ | 500 ГБ |
| API доступ | Нет | Да | Да |
| SSO | Нет | Нет | Да |
| Свой домен | Нет | Да | Да |
Матрица тестирования:
- Функция доступна на нужном уровне
- Функция заблокирована на более низких (сообщение, а не падение)
- Upgrade немедленно включает новые функции
- Downgrade корректно ограничивает функции
- Лимиты применяются корректно
Роли Пользователей Внутри Тенанта
| Роль | Типичные разрешения |
|---|---|
| Owner | Полный контроль, биллинг, удаление тенанта |
| Admin | Управление пользователями, настройки, данные |
| Member | Создание и редактирование своего контента |
| Viewer | Только чтение |
| Guest | Ограниченный доступ к конкретным ресурсам |
Упражнение: Сценарии Тестирования Мультитенантного SaaS
Вы тестируете SaaS для управления проектами (аналог Jira/Asana) с тремя уровнями: Free, Pro и Enterprise.
Сценарий 1: Тестирование Изоляции Данных
Создайте два аккаунта: Тенант A (Acme Corp) и Тенант B (Beta Inc).
| Шаг | Действие | Ожидаемый результат |
|---|---|---|
| 1 | Как Тенант A, создать проект «Alpha» | Проект виден только Тенанту A |
| 2 | Как Тенант B, получить список проектов | «Alpha» НЕ виден |
| 3 | Как Тенант B, запросить GET /api/projects/{alpha-id} | 404 Not Found (не 403) |
| 4 | Как Тенант A, искать «Alpha» | Найдено в результатах |
| 5 | Как Тенант B, искать «Alpha» | Не найдено |
| 6 | Как Тенант A, экспортировать проекты | Экспорт содержит только проекты Тенанта A |
Сценарий 2: Feature Gating
| Шаг | Действие | Ожидаемый результат |
|---|---|---|
| 1 | Как Free, попытаться включить SSO | Предложение «Upgrade до Enterprise» |
| 2 | Как Free, попытаться добавить 6-го пользователя | Предложение «Upgrade до Pro» |
| 3 | Как Pro, включить свой домен | Функция доступна |
| 4 | Upgrade Free → Pro | Новые функции доступны немедленно |
| 5 | Downgrade Pro → Free | Функции ограничены, данные сохранены |
Сценарий 3: Cross-Tenant Безопасность
| Шаг | Действие | Ожидаемый результат |
|---|---|---|
| 1 | Как admin Тенанта A, скопировать endpoint ресурса | /api/tenants/a/projects/123 |
| 2 | Как admin Тенанта B, вызвать этот endpoint | 404 — нет утечки данных |
| 3 | Как Тенант A, подменить tenant_id в заголовке | Запрос отклонён |
| 4 | Как неавторизованный пользователь | 401 Unauthorized |
Решение: Типичные Мультитенантные Баги
Баг 1: Cross-tenant данные в поиске Глобальный поисковый индекс не фильтровал по tenant_id. Исправление: Добавить фильтр tenant_id ко всем поисковым запросам.
Баг 2: 403 вместо 404 для cross-tenant ресурсов Возврат 403 вместо 404 раскрывает существование ресурса у другого тенанта. Исправление: Всегда возвращать 404.
Баг 3: Брендинг тенанта закэширован между сессиями Лого и цвета предыдущего тенанта кэшировались при переключении. Исправление: Инвалидировать кэш UI при смене тенанта.
Баг 4: Обход лимита через API Лимит 5 пользователей на Free применялся в UI, но не в API. Исправление: Применять лимиты на уровне API/БД.
Баг 5: Downgrade не ограничивал функции После downgrade с Pro на Free свой домен оставался активным. Исправление: Проверять ограничения при смене плана.
Стратегия Тестирования SaaS
Поддерживайте минимум три тенант-аккаунта в тестовой среде:
- Тенант Free — для тестирования лимитов и промптов upgrade
- Тенант Pro — для тестирования среднего уровня функций
- Тенант Enterprise — для тестирования полного набора
Каждый тенант должен иметь пользователей во всех ролях.
Ключевые Выводы
- Изоляция данных — наивысший приоритет в мультитенантных приложениях
- Всегда возвращайте 404 (не 403) при cross-tenant доступе для предотвращения раскрытия информации
- Feature gating должен применяться на уровне API, а не только UI
- Тестируйте переходы между уровнями подписки: upgrade, downgrade и судьбу данных и функций
- Поддерживайте отдельные тестовые тенанты для каждого уровня с пользователями во всех ролях
- Изменения конфигурации одного тенанта никогда не должны затрагивать другой