Многопортальная AI CRM: как изолировать данные клиентов в SaaS

Коротко о главном

Что такое tenant isolation

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

Это позволяет обновлять SaaS централизованно, не создавая отдельную кодовую базу на клиента.

База данных — только первый слой

Запрос к записи должен быть связан с workspace/tenant. Но дальше появляются документы, thumbnails, generated files, поисковые индексы, Redis, очереди, audit events и API-токены.

Если хоть один слой использует глобальный cache key или доверяет client-supplied tenantId, изоляция становится неполной.

ИИ добавляет новые границы

Agent получает контекст и tools. Поэтому перед каждым retrieval/tool-call система должна понимать, от чьего имени он работает. Нельзя передавать модели «все данные, а потом попросить не показывать чужие». Ограничение должно происходить до модели.

Секрет провайдера, наоборот, может быть общим платформенным ресурсом, но его usage и полномочия должны учитываться по tenant.

Файлы

Файл должен иметь серверно проверяемую связь с workspace и бизнес-объектом. Одной непредсказуемой ссылки недостаточно. Особенно опасны универсальные download-endpoints, которые не перепроверяют owner/workspace.

Для object storage нужен тот же принцип: namespace и подписанные URL выдаются после authorization.

Масштабирование без диска на каждого клиента

Изоляция логическая, а не обязательно физическая. Тысяча порталов не требует тысячу дисков. Гораздо эффективнее общий storage с tenant namespaces, квотами и возможностью распределять tenants между data clusters.

Физическое разделение можно применять к крупным или регулируемым клиентам как отдельный tier, не меняя модель продукта.