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