Безопасная multi-tenancy в Lino

Добавление поддержки Tenant

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

lino feature tenant add

Ассистент генерирует основу для регистрации Tenants, связи пользователей, определения текущего Tenant, распространения через контекст приложения и интеграции с аутентификацией. ITenantContext представляет Tenant, определенный по subdomain, host или slug, а IUserContext представляет пользователя, аутентифицированного по JWT, включая TenantId, для которого он был аутентифицирован.

После генерации проверьте, какие сущности действительно принадлежат Tenant, а какие являются global. Эта проверка является частью моделирования продукта: multi-tenancy — это не только создание таблицы Tenants, но и решение, какие правила, экраны, разрешения, данные и операции зависят от текущего Tenant, проверенного Lino.

• Tenant-scoped: заказы, продукты клиента, настройки компании, клиенты CRM или любые данные, принадлежащие конкретной организации.
• Global: публичный каталог платформы, планы, внутренние операционные ресурсы, административные настройки или данные, используемые до выбора Tenant.
• Hybrid: global данные с настройкой по Tenant, требующие явного моделирования, чтобы избежать некорректного дублирования или утечки правил.

В модульном монолите модуль tenancy обычно является владельцем исходной сущности Tenant. Другие модули, такие как catalog или CRM, не должны обращаться к этой сущности напрямую. Когда им нужно знать Tenant, они могут хранить shadow entities с минимально необходимыми полями, наполняемые integration events, такими как создание или обновление Tenant.

Tenant context

С функцией Tenant Lino централизует определение текущего Tenant и предоставляет это значение через ITenantContext. Этот контекст представляет Tenant, определенный из subdomain, host или slug запроса, включая сведения вроде TenantId и slug, когда Tenant найден.

В аутентифицированных потоках IUserContext читает пользователя из JWT. Этот JWT также содержит TenantId, для которого пользователь был аутентифицирован. Lino сравнивает Tenant из IUserContext с Tenant из ITenantContext, предотвращая доверие бизнес-правил расходящимся контекстам.

В сгенерированных или добавленных позже функциях всегда предпочитайте эти абстракции вместо повторного ручного чтения claims или получения произвольного TenantId в каждом handler. Это сохраняет commands, queries, страницы и интеграции на одной source of truth и сохраняет механизмы безопасности, уже реализованные Lino.

Background Jobs, потребители событий и интеграции также нуждаются в контексте. Job, который обрабатывает tenant-scoped продукты, клиентов или пользователей, должен явно получать, какой Tenant обрабатывается, потому что нет активного HTTP-запроса, из которого ITenantContext и IUserContext можно было бы автоматически вывести.

Tenant-scoped сущности

Tenant-scoped сущности содержат identifier Tenant и участвуют в query filters. Благодаря этому обычный поток не должен вручную помнить о применении TenantId во всех queries; функция должна использовать проверенный контекст и фильтры, сгенерированные Lino.

• Включайте Tenant в aggregates, которые принадлежат конкретной организации.
• Настраивайте индексы с учетом Tenant и часто запрашиваемых полей.
• Используйте ITenantContext и IUserContext в commands и queries вместо получения Tenant как изолированного источника полномочий.
• В imports и jobs явно определяйте, какой Tenant обрабатывается.

Tenant-scoped сущность принадлежит одному Tenant. Если сущность выглядит так, будто принадлежит нескольким Tenants, рассматривайте это как решение моделирования: возможно, она global, возможно, нужна копия по Tenant, или, возможно, отсутствует промежуточная сущность, представляющая связь. Продукт, клиент или пользователь также может иметь разный смысл в разных модулях; в таких случаях shadow entity с несколькими полями может быть правильнее, чем совместное использование исходной сущности.

Также различайте ссылку и ownership. Продукт в catalog может ссылаться на Tenant, но это не означает, что catalog управляет lifecycle Tenant. Модуль tenancy остается владельцем создания, активации, домена, branding и режима изоляции; catalog хранит только данные, необходимые для фильтрации и проверки собственного потока.

• Индексы: комбинируйте TenantId с полями, используемыми для поиска, сортировки и уникальности по Tenant.
• Commands: применяйте операцию в текущем проверенном Tenant, когда сущность tenant-scoped.
• Queries: удерживайте пагинацию, фильтры и счетчики в том же контексте, проверенном Lino.
• Events: включайте достаточно контекста, чтобы consumers могли обновлять projections, не обращаясь к producer ненадлежащим образом.

Изоляция данных

Изоляция может выполняться по колонке, schema или отдельной базе данных. Выбор зависит от стоимости, объема, договорных требований и операционных возможностей.

Для большинства SaaS на ранней стадии колонка по Tenant с global filters и централизованным контекстом является прагматичной отправной точкой. Lino помогает с этой основой; ваша проверка должна подтвердить, что tenant-scoped aggregates содержат правильный Tenant, а новые queries продолжают использовать текущий Tenant, проверенный сгенерированными абстракциями.

В модульных сервисах изоляция Tenant и изоляция модуля — разные заботы. Модуль Catalog может иметь таблицу продуктов с TenantId; модуль CRM может иметь клиентов с TenantId; а модуль Tenancy остается владельцем исходной регистрации Tenants. Наличие одного и того же identifier не разрешает прямой доступ между модулями.

Roles и разрешения по Tenant

В SaaS пользователь может быть администратором в одном Tenant и оператором в другом. Lino генерирует основу для работы со связью user-Tenant, а разрешения функций должны оцениваться внутри активного контекста, проверенного framework.

Также существуют административные разрешения вне Tenant. Экран эксплуатации платформы может быть доступен только в системном контексте, тогда как страницы вроде продуктов и клиентов могут требовать active Tenant. Такое разделение ясно показывает, когда действие является global, а когда оно зависит от Tenant, определенного в ITenantContext, и пользователя, аутентифицированного в IUserContext.

• Моделируйте roles по Tenant, когда разрешения различаются по организациям.
• Используйте текущий контекст в проверках авторизации страниц, commands и queries.
• Держите claims компактными, помещая в token только то, что должно участвовать в аутентифицированном потоке.
• Отзывайте или обновляйте tokens при изменении критических разрешений.

JWT и безопасность Tenant

Когда функция Tenant активна, Lino использует JWT как источник контекста аутентифицированного пользователя. IUserContext читает claims пользователя и TenantId из token, не превращая JWT в копию базы данных.

• Поддерживайте issuer, audience, подпись и срок действия настроенными корректно.
• Используйте Tenant, проверенный Lino, вместо принятия ручной смены, основанной только на header, route или payload экрана.
• Избегайте слишком больших claims; раздутые tokens усложняют эксплуатацию и обновление.
• Записывайте logs доступа с пользователем, Tenant и операцией, когда поток требует аудита.

В приложениях с subdomains, таких как acme.dev.localhost и globex.dev.localhost, ITenantContext представляет Tenant, определенный для запроса. IUserContext представляет аутентифицированного пользователя и Tenant, присутствующий в JWT. Lino сравнивает эти два контекста, чтобы предотвратить использование token, выданного для одного Tenant, в контексте другого Tenant.

Авторизация также остается контекстной. Разрешение просматривать продукты, например, действует внутри Tenant, где оно было выдано и для которого пользователь был аутентифицирован. При создании новых функций используйте уже доступные разрешения и контексты вместо создания обходных путей, которые получают отдельный TenantId и игнорируют аутентифицированный поток.