Как изолировать данные клиентов SaaS

Определите арендатора системы

В многопользовательском продукте арендатор обычно соответствует организации клиента, но конкретная модель может быть иной. Один человек может участвовать в нескольких организациях, а одна организация — иметь подразделения. До архитектуры данных решите, какая сущность задаёт границу доступа и оплаты.

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

Выберите модель хранения по ограничениям

Общие таблицы с идентификатором арендатора, отдельные схемы и отдельные базы дают разные компромиссы по эксплуатации и разделению. Microsoft описывает архитектурные варианты хранения для многопользовательских систем. Выбор зависит от требований к доступу, нагрузке, восстановлению и сопровождению.

Ни один вариант не делает приложение автоматически безопасным. При отдельной базе можно ошибиться при выборе подключения; при общей — забыть ограничение запроса. Нужна сквозная модель контекста и проверок, а не только название схемы хранения.

Где должна работать изоляция

Добавьте к таблице собственные поверхности: уведомления, отчёты, индекс поиска и интеграции. Проверка только экранов кабинета оставляет значительную часть системы без внимания.

Не доверяйте контексту из браузера

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

Разведите право читать объект и менять его. Пользователь может иметь доступ к документу, но не к финансовым параметрам или управлению сотрудниками. Роли дополняются ограничениями конкретного объекта и состояния процесса, если это требуется продукту.

Учтите фоновые действия

Экспорт, рассылка и синхронизация часто выполняются после завершения пользовательского запроса. Задача должна сохранить контекст организации и идентификатор инициатора там, где это нужно для проверки. Не передавайте в очередь произвольные параметры без контроля при постановке и исполнении.

Если права отозваны между созданием и выполнением экспорта, определите ожидаемое поведение. Результат не должен оставаться доступным только потому, что ссылка была создана раньше. Сроки хранения и повторная проверка зависят от чувствительности данных и сценария.

Подготовьте негативные проверки

Создайте две тестовые организации с похожими объектами и пользователей с разными ролями. Проверьте подстановку чужого идентификатора в чтение, изменение, скачивание и экспорт. Затем отзовите участие и повторите действия с прежней сессией.

Добавьте проверку кэша: сначала запрос одной компании, затем похожий запрос другой. Проверьте фоновые результаты и уведомления. Цель — подтвердить отказ там, где операция выглядит технически корректной, но не разрешена этому участнику.

Свяжите изоляцию с эксплуатацией

Резервное копирование, восстановление отдельного клиента и удаление данных зависят от модели хранения. Эти операции стоит обсудить до масштабирования: восстановление общей базы может затронуть больше одной организации. Назначьте процедуру и ограничения заранее.

Тарифные лимиты тоже должны учитывать правильного арендатора. Однако право функции и доступ к чужим данным — разные проверки. Бесплатный тариф не разрешает обход изоляции, а оплаченная подписка не даёт пользователю полномочий администратора организации.

Пример отрицательной проверки экспорта

Создайте две организации с разными документами и пользователя только первой. Он формирует экспорт, после чего проверяющий подставляет идентификатор результата второй организации в тестовом запросе. Система должна отказать, даже если формат идентификатора корректен и файл существует.

Затем отзовите участие пользователя до завершения фоновой задачи. Ожидаемое поведение определяется политикой продукта: остановить выполнение, запретить получение результата или применить другой согласованный контроль. В любом случае прежний факт постановки задачи не должен автоматически предоставлять бессрочный доступ.

Проверьте общий кэш и временные ссылки. Если ключ кэша учитывает только номер отчёта без контекста, ответ может оказаться чужим. Если ссылка обходится без авторизации, её срок и область использования требуют отдельного анализа. Проверка API списка не покрывает эти поверхности.

В отчёте сохраняйте действие, роль, организацию, ожидаемый отказ и фактический результат без копирования чужого содержимого. Такой протокол полезен и для регрессии после изменения хранения. Он проверяет границу доступа, которую нельзя доказать только архитектурной схемой с двумя нарисованными базами данных.

Как проверить изоляцию вне основной таблицы базы

Добавьте к двум учебным организациям одинаковые названия объектов и разные значения. Проверьте поиск, кэш, экспорт, уведомления и фоновые отчёты. Ошибка может возникнуть в ключе кэша или контексте задания, даже когда основной запрос к базе фильтруется правильно.

Для восстановления одной организации отдельно проверьте, не затрагиваются ли соседние данные. Руководство Microsoft по многопользовательскому хранению помогает сравнить модели, но выбранная схема не заменяет испытаний приложения. Сохраняйте доверенный контекст клиента на всей цепочке обработки. При смене роли и завершении подписки повторяйте проверки: изоляция зависит не только от места хранения, но и от текущего права выполнять действие.