Мультиарендность в SaaS и B2B-сервисах: компании, филиалы, роли, данные и изоляция доступа

Мультиарендность, или multitenancy, - это архитектурный принцип, при котором один веб-сервис обслуживает много независимых клиентов: компаний, организаций, филиальных сетей, партнеров, школ, клиник, агентств, производственных групп или команд. Все они могут пользоваться одним продуктом, но их данные, настройки, пользователи, права, документы, платежи и интеграции должны быть разделены. На уровне интерфейса мультиарендность часто выглядит просто: пользователь входит в личный кабинет и видит свою компанию. Но внутри системы это один из самых ответственных слоев архитектуры. Нужно гарантировать, что сотрудник компании А не увидит заявки компании Б, администратор филиала не изменит настройки всей сети, бухгалтер не получит доступ к HR-документам, а менеджер подрядчика не сможет прочитать данные другого клиента через API. Для SaaS и B2B-сервисов мультиарендность влияет почти на все: модель данных, авторизацию, роли, приглашения пользователей, админ-панель, тарифы, лимиты, аналитику, интеграции, тестирование и поддержку. Если этот слой не продуман в начале, проект может долго выглядеть рабочим, но сломаться на первом крупном клиенте с несколькими филиалами, разными ролями и требованиями к безопасности.

Что такое tenant в SaaS и B2B-сервисе

Tenant - это отдельный клиентский контур внутри продукта. В русскоязычной практике его часто называют арендатором, клиентом, организацией, компанией, workspace, аккаунтом компании или пространством. Термин может отличаться, но смысл один: у tenant есть свои пользователи, данные, настройки и границы доступа. В B2B-продукте tenant обычно соответствует компании-клиенту. Например, бухгалтерский SaaS обслуживает разные организации, сервис заявок - разные управляющие компании, образовательная платформа - разные школы, CRM-портал - разных корпоративных клиентов. У каждой компании могут быть сотрудники, роли, филиалы, документы, заявки, платежи, интеграции и отчеты. Важно не путать tenant и пользователя. Один пользователь может быть сотрудником одной компании, а может участвовать в нескольких компаниях. Например, внешний бухгалтер обслуживает несколько юридических лиц, агент работает с разными клиентскими кабинетами, подрядчик подключен к нескольким проектам. Поэтому в зрелой архитектуре пользователь и компания - разные сущности, а между ними есть членство с ролью, статусом и правами.

Почему мультиарендность нельзя добавлять "потом"

На раннем этапе продукт часто делают для одного клиента или одной команды. В базе есть пользователи, заявки, документы, платежи и настройки. Все работает, пока данные принадлежат одной организации. Проблема начинается, когда появляется второй клиент, филиальная сеть или партнерская модель. Если в данных нет `company_id`, `tenant_id` или другой четкой связи с владельцем, разработчикам приходится срочно переделывать почти все запросы. Нужно добавить привязку к компании, мигрировать существующие записи, переписать фильтры, изменить API, обновить админку, поправить отчеты, проверить файлы, кэш, очереди и интеграции. Это дороже и рискованнее, чем заложить мультиарендность в модель с самого начала. Еще опаснее, когда tenant вроде бы добавили, но проверяют его выборочно. Один список фильтруется по компании, другой нет. Один endpoint проверяет доступ, другой доверяет ID из запроса. В интерфейсе кнопка скрыта, но API действие выполняет. Такие ошибки незаметны в демо, но критичны в реальном B2B-сервисе, потому что могут привести к утечке чужих данных.

Где мультиарендность особенно важна

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

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

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

Основные сущности: компания, филиал, команда, пользователь

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

Пользователь - это человек с email, телефоном, паролем, сессией и профилем. Компания - это контур данных. Филиал - часть компании с локацией, сотрудниками, расписанием, заявками или заказами. Членство связывает пользователя и компанию: один и тот же пользователь может быть администратором в одной компании и обычным участником в другой. Такая модель гибче, чем простая связка "user belongs to company". Она позволяет поддерживать внешних специалистов, холдинги, франшизы, агентства, бухгалтеров, партнеров и сотрудников, которые работают сразу в нескольких пространствах.

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

Компания как главный контур данных

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

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

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

Филиалы и подразделения

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

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

• название;
• адрес;
• часовой пояс;
• график работы;
• сотрудников;
• свои заявки;
• свои заказы;
• свой склад или остатки;
• свои документы;
• свои настройки уведомлений;
• свои отчеты;
• ограничения по доступу.

Роли: глобальные и внутри компании

В мультиарендном сервисе роли бывают разных уровней. Есть глобальные роли платформы и роли внутри конкретного tenant. Глобальные роли принадлежат команде владельца продукта:

Роли внутри компании принадлежат клиенту:

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

• super admin;
• support;
• sales manager;
• moderator;
• finance;
• technical admin.
• владелец компании;
• администратор компании;
• администратор филиала;
• менеджер;
• сотрудник;
• бухгалтер;
• наблюдатель;
• внешний подрядчик;
• пользователь с ограниченным доступом.

RBAC, ABAC и реальные права доступа

RBAC - это управление доступом через роли. Например, роль "бухгалтер" может видеть счета и платежи, роль "менеджер" - заявки, роль "администратор филиала" - сотрудников своего филиала. Это понятная модель, удобная для первого релиза. ABAC - это управление доступом через атрибуты. Решение зависит не только от роли, но и от свойств пользователя, ресурса, компании, филиала, тарифа, статуса или контекста. Например, менеджер может видеть заявки только своего филиала, только в своем регионе и только в статусах, где он назначен ответственным. На практике в B2B-сервисах часто нужна комбинация:

AWS в руководстве по multi-tenant SaaS authorization отдельно подчеркивает, что авторизация в таких системах усложняется из-за множества API, tenant-условий, свойств пользователей и состояний приложения. Поэтому права лучше делать централизованными и повторяемыми, а не разбросанными по каждому контроллеру.

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

Tenant context: откуда система понимает текущую компанию

Tenant context - это понимание системой, в каком клиентском контуре выполняется запрос. Без него невозможно надежно фильтровать данные и проверять права. Контекст может определяться:

Нельзя слепо доверять tenant ID, который пришел от клиента в заголовке, query-параметре или теле запроса. Пользователь может изменить значение вручную. Сервер должен проверить, что пользователь действительно состоит в этой компании, имеет нужную роль и может выполнить действие над конкретным ресурсом. Хорошая практика - определять tenant context в начале обработки запроса и передавать его через все слои приложения: API, сервисы, репозитории, логи, очереди, фоновые задачи и интеграции.

• по выбранной компании в интерфейсе;
• по поддомену;
• по домену клиента;
• по workspace ID в URL;
• по членству пользователя;
• по токену авторизации;
• по API-ключу;
• по интеграционному аккаунту.

Изоляция данных: общая база, схемы или отдельные базы

Есть несколько архитектурных подходов к хранению данных tenants.

Общая база и общие таблицы

Все компании хранятся в одной базе, а таблицы содержат `tenant_id` или аналогичное поле. Это самый распространенный и экономичный подход для старта. Он упрощает разработку, аналитику, миграции и эксплуатацию, но требует дисциплины: каждый запрос к tenant-данным должен учитывать tenant context. Подход подходит для многих SaaS на ранней и средней стадии, если данные не требуют жесткой физической изоляции.

Отдельные схемы

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

Отдельные базы

Каждый tenant хранится в отдельной базе. Это дает сильную изоляцию и может быть важно для крупных клиентов, регуляторных требований или enterprise-сегмента. Минусы - сложная эксплуатация, миграции, мониторинг, резервное копирование, обновления и сводная аналитика.

Гибридная модель

Часть клиентов работает в общей базе, а крупные или чувствительные клиенты выносятся в отдельные базы или контуры. Это гибко, но требует зрелой DevOps- и архитектурной практики. Гибридную модель не стоит выбирать без реальной причины. Microsoft Azure в архитектурных материалах описывает мультиарендность как решение, которым пользуются несколько tenants, и отдельно выделяет, что при проектировании нужно учитывать compute, storage, networking, data, identity, messaging, governance, compliance и cost management. То есть это не только таблица с `tenant_id`, а вся архитектура сервиса.

Row-Level Security и защита на уровне базы

В некоторых системах полезно добавлять защиту не только в коде приложения, но и на уровне базы данных. Например, PostgreSQL поддерживает Row-Level Security: политики строк могут ограничивать, какие записи доступны пользователю или роли для чтения, вставки, изменения и удаления. RLS не отменяет проверки в приложении. Это дополнительный слой защиты. Он может снизить риск ошибки, когда разработчик забыл добавить `tenant_id` в запрос, но требует аккуратного проектирования, тестов и понимания ограничений. Неправильные политики могут создать проблемы с производительностью, миграциями или административными операциями. Для большинства проектов важно правило: изоляция должна быть системной. Нельзя рассчитывать только на внимательность разработчика в каждом новом запросе. Лучше использовать общие репозитории, middleware, scopes, политики доступа, тесты и, где уместно, защиту на уровне базы.

Файлы, кэш, очереди и логи тоже должны быть изолированы

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

Например, если кэш-ключ строится только по `user_id`, а в системе один пользователь может быть в нескольких компаниях, он может получить данные из неправильного пространства. Если файл хранится по прямому URL без проверки прав, другой пользователь может скачать чужой документ. Если фоновая задача отправляет отчет без tenant context, письмо может уйти не тому клиенту. OWASP в Multi Tenant Security Cheat Sheet отдельно выделяет риски cross-tenant data leakage, IDOR, broken tenant isolation, shared cache keys, storage isolation, tenant onboarding/offboarding и tenant-specific logging. Эти риски возникают не в теории, а в обычных продуктах, где мультиарендность считается "простым фильтром".

• файловом хранилище;
• путях к документам;
• публичных и подписанных ссылках;
• кэше;
• очередях задач;
• фоновых обработчиках;
• поисковом индексе;
• логах;
• аналитических событиях;
• экспортах;
• резервных копиях;
• уведомлениях;
• webhook-событиях.

Приглашения пользователей и членство в компании

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

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

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

Переключение между компаниями

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

Личный кабинет компании

Личный кабинет в мультиарендном B2B-сервисе должен показывать не просто профиль пользователя, а рабочее пространство компании. Обычно в нем нужны:

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

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

Админ-панель владельца платформы

Владелец SaaS или B2B-сервиса должен управлять tenants через отдельную админ-панель. Это не то же самое, что кабинет клиента. В админке платформы обычно нужны:

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

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

Тарифы, лимиты и [биллинг](articles/platezhi-v-veb-servise/) в мультиарендном SaaS

В SaaS тариф обычно привязан не к отдельному человеку, а к компании. Это значит, что лимиты и доступы нужно считать на уровне tenant. Тариф может ограничивать:

Если лимиты хранятся только на уровне пользователя, корпоративные сценарии становятся неудобными. Компания может оплатить тариф на 20 сотрудников, пригласить команду, открыть несколько филиалов и использовать общие документы. Все это должно считаться в рамках tenant. При неуспешной оплате тоже важно не ломать доступ грубо. Бизнес может дать grace period, ограничить создание новых объектов, оставить чтение данных, уведомить администратора компании и не блокировать рядовых сотрудников без понятного сообщения. Подробнее общую SaaS-логику можно связать со статьей Разработка SaaS-платформы.

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

API в мультиарендном сервисе

API - одно из самых рискованных мест для tenant isolation. В интерфейсе можно скрыть чужие данные, но если API принимает `company_id`, `branch_id` или `document_id` без проверки принадлежности, пользователь может попытаться получить чужой ресурс напрямую. Нужно предусмотреть:

OWASP описывает IDOR как уязвимость, при которой приложение использует внутренние идентификаторы объектов и не проверяет, что пользователь имеет право на конкретный ресурс. В мультиарендном SaaS это особенно опасно: подмена ID может привести не просто к чужой записи пользователя, а к данным другой компании. Эта часть напрямую связана с темой разработки платформы с API, потому что API в мультиарендном продукте должен быть защищен не только аутентификацией, но и tenant-aware авторизацией.

• tenant context для каждого API-запроса;
• проверку членства пользователя;
• проверку принадлежности ресурса tenant;
• проверку роли и действия;
• tenant-scoped API keys;
• отдельные ключи для интеграций;
• ограничение доступа внешних систем;
• rate limiting на tenant;
• логи API с tenant context;
• тесты на подмену ID.

Интеграции для разных компаний

В B2B-сервисе каждая компания может подключать свои внешние системы: CRM, 1С, ERP, склад, телефонию, платежи, рассылки, BI, SSO или webhook endpoint. Интеграции тоже должны быть изолированы. Для каждой интеграции нужно хранить:

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

• tenant;
• тип интеграции;
• credentials;
• настройки;
• права;
• статус;
• дату последней синхронизации;
• ошибки;
• историю событий;
• ответственного администратора.

Аналитика по tenant, филиалам и ролям

Аналитика в мультиарендном продукте должна отвечать на вопросы владельца платформы и клиента. Владелец платформы смотрит:

Клиентская компания смотрит:

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

• количество активных компаний;
• рост tenants;
• активность пользователей;
• использование функций;
• оплату тарифов;
• нагрузку;
• ошибки;
• churn;
• поддержку;
• конверсию onboarding.
• свои заявки;
• свои документы;
• сотрудников;
• филиалы;
• выполнение задач;
• финансовые показатели;
• активность команды;
• SLA;
• отчеты по подразделениям.

Onboarding и offboarding tenants

Мультиарендность начинается не после входа пользователя, а с создания компании. Нужно продумать onboarding tenant. Onboarding может включать:

Offboarding не менее важен. Когда компания уходит, нужно понять, что делать с ее данными:

OWASP отдельно выделяет onboarding/offboarding как важный риск мультиарендных приложений. Если tenant удален только из интерфейса, но его файлы, токены, webhooks и фоновые задачи продолжают жить, это не полноценное отключение.

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

Производительность и "шумный сосед"

В общей инфраструктуре один крупный или проблемный tenant может влиять на других. Это называют noisy neighbor problem. Например, одна компания запускает тяжелый экспорт, импортирует миллион строк, делает много API-запросов или создает большое количество фоновых задач. Если лимитов нет, остальные клиенты могут почувствовать замедление. Нужно продумать:

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

• лимиты API;
• квоты на фоновые задачи;
• очереди с tenant context;
• приоритеты задач;
• ограничения экспорта;
• лимиты файлов;
• пагинацию;
• индексы;
• мониторинг нагрузки по tenant;
• отдельные ресурсы для enterprise-клиентов.

Безопасность мультиарендного SaaS

Безопасность в мультиарендном сервисе не сводится к паролю и HTTPS. Главный вопрос: может ли один tenant получить доступ к данным другого tenant через интерфейс, API, файлы, кэш, поиск, отчеты, логи или интеграции. Базовые меры:

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

• проверять tenant ownership для каждого ресурса;
• не доверять tenant ID из клиента без серверной проверки;
• использовать tenant-scoped запросы;
• закрывать прямой доступ к файлам;
• изолировать кэш-ключи;
• учитывать tenant в очередях;
• логировать tenant context;
• ограничивать роли поддержки;
• делать аудит действий;
• тестировать подмену ID;
• проверять экспорты;
• защищать API-ключи;
• шифровать чувствительные данные, если это требуется;
• удалять или архивировать данные по правилам.

Тестирование изоляции доступа

Мультиарендность нельзя проверить одним успешным сценарием. Нужно специально пытаться нарушить границы доступа. Минимальный набор тестов:

Нужно тестировать не только запрет доступа, но и отсутствие утечек в мелочах: счетчики, названия файлов, подсказки поиска, ошибки API, URL документов, email-уведомления, webhooks и логи. Подробнее общую подготовку к запуску можно связать со статьей Тестирование веб-сервиса перед запуском.

• создать две или три компании;
• создать пользователей с разными ролями;
• добавить филиалы;
• заполнить данные в каждой компании;
• проверить списки;
• проверить карточки ресурсов;
• подменить `company_id`;
• подменить `branch_id`;
• подменить ID документа, заявки, платежа, файла;
• проверить API напрямую;
• проверить экспорт;
• проверить поиск;
• проверить кэш;
• проверить уведомления;
• проверить фоновые задачи;
• проверить отчеты;
• проверить права поддержки.

Типичные ошибки в мультиарендности

Первая ошибка - считать tenant обычным полем фильтра. На самом деле это граница безопасности и бизнес-логики. Вторая ошибка - связывать пользователя только с одной компанией, хотя в будущем появятся агентства, подрядчики, бухгалтеры, холдинги и несколько workspace. Третья ошибка - проверять права только на frontend. Кнопки можно скрывать для удобства, но защита должна быть на backend. Четвертая ошибка - забывать про файлы, кэш, очереди и логи. Утечка может произойти не только через SQL-запрос. Пятая ошибка - делать суперпользователя без аудита. Сотрудники платформы должны иметь ограниченные права, а чувствительные действия должны логироваться. Шестая ошибка - не тестировать подмену ID. Именно такие проверки часто находят реальные проблемы доступа. Седьмая ошибка - смешивать роли платформы и роли клиента. Администратор tenant не равен администратору всего сервиса. Восьмая ошибка - не учитывать филиалы в модели данных. Потом каждую заявку, задачу и отчет приходится переделывать.

Что включить в первый релиз

В первом релизе не обязательно делать enterprise-уровень с отдельными базами, SSO, сложными политиками и гибкой матрицей прав. Но базовая мультиарендность должна быть надежной. Для MVP обычно достаточно:

Филиалы, подразделения, кастомные роли, SSO, отдельные базы, расширенные политики и enterprise-настройки можно добавлять постепенно. Главное - не запускать B2B-сервис с архитектурой "все данные общие, потом отфильтруем".

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

Как описать мультиарендность в ТЗ

Чтобы получить точную оценку разработки, в ТЗ нужно описать не только функции, но и границы доступа. Стоит указать:

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

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

Как Wcoders подходит к мультиарендности

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

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

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

FAQ

Чем мультиарендность отличается от обычных ролей?

Роли отвечают на вопрос "что пользователь может делать". Мультиарендность отвечает еще и на вопрос "в каком клиентском контуре он это делает". Пользователь может быть менеджером, но только в своей компании или филиале.

Можно ли сделать SaaS без мультиарендности?

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

Что лучше: общая база или отдельная база для каждого клиента?

Зависит от требований. Общая база проще и дешевле на старте, отдельные базы дают более сильную изоляцию, но усложняют эксплуатацию. Для многих SaaS подходит общая база с надежным tenant-scoping, а для крупных enterprise-клиентов можно рассматривать гибридную модель.

Нужно ли делать филиалы в первом релизе?

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

Может ли один пользователь быть в нескольких компаниях?

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

Почему недостаточно скрывать чужие данные в интерфейсе?

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

Нужен ли аудит действий?

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

Как тестировать tenant isolation?

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

Итог

Мультиарендность в SaaS и B2B-сервисах - это фундамент, который определяет, как продукт работает с компаниями, филиалами, ролями, данными и безопасностью. Это не просто поле `tenant_id`, а система границ: кто к чему относится, кто что видит, кто что может менять и как сервис не допускает смешивания данных разных клиентов. Хорошая мультиарендная архитектура помогает продукту расти: подключать новых клиентов, добавлять филиалы, развивать роли, продавать тарифы, подключать интеграции, строить аналитику и обслуживать enterprise-сценарии. Плохая архитектура делает каждую новую B2B-функцию дорогой и рискованной. Если сервис планируется для нескольких компаний, мультиарендность нужно проектировать с первого релиза. Не обязательно сразу делать сложную enterprise-платформу, но компания, членство, роли, tenant context, проверка доступа и тесты изоляции должны быть в основе продукта.