В этой статье
Проследите арендатора за пределами HTTP-запроса
Две организации используют общую систему бронирования, и у обеих есть бронь №42. Кеш только по номеру может выдать данные другой организации даже при правильных запросах БД. Риск повторяется в путях файлов, поисковых индексах, экспортах и фоновых уведомлениях.
Получайте арендатора из подтверждённого членства и проверяйте выбранную организацию на сервере. Передавайте контекст асинхронной работе: worker не наследует браузерную сессию. Ограничивайте им ID ресурсов и кеш. При смене организации администратором показывайте её в интерфейсе и перепроверяйте членство. Поле из браузера — запрос для валидации, не полномочие.
Идентификатор организации сопровождает запрос
Изоляция должна соблюдаться во всём процессе, включая фоновые задачи.
Идентификация
Аутентифицируйте отправителя и определите его организацию.
Авторизация
Проверьте операцию и целевую запись.
Граница данных
Последовательно применяйте выбранную модель изоляции.
Фоновая работа
Передавайте тот же контекст в задачи, экспорт и журналы.
Считайте арендатора системным инвариантом
Арендатор — не просто внешний ключ. Он задаёт полномочия, конфигурацию, изоляцию данных, учёт использования и действия при приостановке, экспорте или удалении.
Определите канонический контекст при аутентификации и передавайте в команды, запросы, фоновые задачи, кеши, файлы и телеметрию. Отсутствие контекста должно запрещать доступ, не выбирать арендатора по умолчанию.
Выбирайте изоляцию по последствиям и эксплуатации
Общие таблицы эффективны в эксплуатации, но требуют повсеместной изоляции строк и тестов. Отдельные схемы или БД усиливают изоляцию и усложняют миграции. Выбор зависит от чувствительности, риска шумного соседа, точности восстановления и возможностей команды.
Документируйте расположение настроек, секретов и ключей шифрования. Смешанная модель может изолировать только регулируемых или крупных арендаторов, но требует единого контракта маршрутизации и автоматизации жизненного цикла.
Спроектируйте жизненный цикл и восстановление до биллинга
Создание, приглашения, роли, смена тарифа, лимиты, приостановка и удаление должны быть идемпотентными процессами. Платёжный статус не должен незаметно становиться правами без описанного льготного периода и восстановления.
Наблюдайте использование и сбои по арендаторам без раскрытия персональных данных. Отрепетируйте экспорт и восстановление одного арендатора, проверьте, что сбой миграции не оставляет половину клиентов на несовместимых схемах.
Выбирайте изоляцию через сценарий восстановления
Общие таблицы упрощают эксплуатацию, отдельные схемы или БД — некоторые задачи изоляции и восстановления ценой миграций, подключений и мониторинга. Ни один вариант не отменяет авторизацию приложения. Сравните экспорт, индивидуальное восстановление и особый срок хранения одного арендатора.
PostgreSQL RLS ограничивает строки для роли БД, но владельцы и привилегированные роли могут обходить ограничения. Проверяйте под реальной ролью приложения, не только администратором. Если пул соединений переносит контекст запроса, проверяйте сброс между запросами. Политика БД должна усиливать границу приложения с тестами намеренного чтения и записи другого арендатора.
Изоляция — ещё и эксплуатационный выбор
Качественные компромиссы для проверки на вашей нагрузке. Все варианты требуют авторизации.
Прокрутите по горизонтали, чтобы прочитать таблицу →
| Топология | Преимущество эксплуатации | Что предусмотреть |
|---|---|---|
| Общие таблицы | Меньше БД в эксплуатации | Запросы, кеши и восстановление в контексте арендатора |
| Схема на арендатора | Логическое разделение структур арендаторов | Координация миграций и контекст соединений |
| БД на арендатора | Отдельные границы копирования и ресурсов | Миграции парка БД, ключи и мониторинг |
Проверьте полный жизненный цикл арендатора
Создание должно повторяться после прерывания: организация, первый администратор и настройки не должны оставлять невидимую половину аккаунта. Приостановка прекращает нужные действия, сохраняя данные поддержки. Удаление должно охватывать индексы, экспорты, файлы и копии, а не только строки основной БД.
Проверьте и шумного соседа. Большой импорт клиента не должен исчерпать все worker или блокировать малые интерактивные запросы. По возможности отслеживайте возраст очереди и ресурсы по арендаторам, затем выбирайте справедливое планирование или квоты. Архитектура должна объяснять конфиденциальность и качество сервиса каждой организации, в том числе при инцидентах.
Источники и дополнительное чтение
Документация проверена .
ВОПРОСЫ / РЕШЕНИЯ
Частые вопросы
Каждому арендатору нужна своя БД?+
Нет. Отдельные БД оправданы требованиями изоляции, масштаба, договора или восстановления, которые стоят дополнительной маршрутизации и эксплуатации.