Feature 01 / 04
Фундамент
Мультитенант по дизайну, а не задним числом
Helpdash построен tenant-first. Каждый запрос несёт границу пространства на уровне данных; у каждого пространства — свои строки, префикс хранилища, роли и аудит-журнал. Нет ни одного пути — ни аутентифицированного, ни анонимного — где scope тенанта был бы опциональным. Для инженерных и security-команд: это та архитектура, которую вы бы запросили при procurement-ревью.
Результаты
Гарантии изоляции, переживающие аудит
Мультитенант — не feature flag. Это модель данных: row-level scope на каждом чтении и записи, team-aware RBAC, изолированное хранилище, подписанный аудит-журнал. Procurement, SOC 2, ISO 27001 — ответы в каждой форме одни и те же.
Feature 02 / 04
RBAC на уровне пространства
роли живут внутри тенанта, права не утекают за границу
Feature 03 / 04
Префикс хранилища на пространство с подписанными короткоживущими URL — никакого общего bucket, никакого cross-tenant path traversal
Feature 04 / 04
Tamper-evident аудит-журнал хранится после удаления пространства, чтобы перекрывать регуляторные окна хранения
Внутри модели
Как Helpdash делает мультитенант скучным
Feature 01 / 03
Глобальная граница запросов
Глобальный scope на каждой модели автоматически фильтрует по ключу тенанта. Забыть границу в call site структурно невозможно — фреймворк прокидывает её на уровне данных.
Feature 02 / 03
RBAC на уровне команды
Роли и права tenant-aware — роль агента в пространстве A не видна в пространстве B. Никаких случайных переносов прав между кабинетами.
Feature 03 / 03
Хранилище на тенанта
Префиксы файловой системы (tenants/{id}/) привязывают каждую загрузку к пространству. URL подписаны, короткоживущие, проверяются по тенанту в момент выдачи.
FAQ
Frequently asked questions
Какая модель БД?
Единая общая схема с ключом тенанта на каждой бизнес-записи. Модели используют трейт BelongsToTenant, который ставит глобальный query scope; чтения и записи наследуют границу автоматически. Cross-tenant доступ требует явного, audited override на уровне приложения.
Как резолвится тенант на каждом запросе?
Аутентифицированные роуты игнорируют X-Tenant-Slug и host-заголовки — авторитетен подписанный workspace-claim внутри JWT, точка. Неаутентифицированные роуты (логин, публичные доки) резолвят по заголовку → поддомену → query string в указанном приоритете, со списком зарезервированных имён (www, api, admin) против коллизий.
Что фактически видит аудитор?
Подписанный append-only аудит-журнал на пространство, сохраняемый после удаления тенанта, экспортируемый в ваш SIEM. Плюс ORM scope: однострочное доказательство, что любой запрос tenant-bound — обычно этого достаточно для SOC 2 CC6.1 и ISO 27001 A.9.4.1.
Посмотрите на модель изоляции в своём пространстве
Поднимите два пространства в одном логине и посмотрите, как они никогда друг друга не видят — ни в API, ни в UI, ни в хранилище. Бесплатно, без карты.