Аудит изоляции клиентов SaaS-сервиса
Проверяем, что пользователи одного клиента SaaS или B2B-сервиса получают доступ только к данным своей организации. Прослеживаем контекст арендатора через API, базу, кеш, файлы, поиск, очереди, выгрузки и фоновые задания, затем исправляем критичные пути и добавляем регрессионные сценарии двух компаний. Результат подтверждает разделение чтения, изменения, скачивания и административных действий.
Когда стоит обратиться
Обычно к нам обращаются в таких ситуациях:
- Сервис хранит данные нескольких компаний в общей базе, а фильтр по организации повторяется вручную в разных запросах и обработчиках.
- API списка учитывает клиента, однако скачивание файла, экспорт, поиск или фоновая задача получает объект только по его идентификатору.
- Поддержка временно входит в кабинеты клиентов, и компании нужен управляемый журнал основания, времени и объёма административного доступа.
- Перед подключением крупного заказчика требуется проверить cross-tenant сценарии и показать воспроизводимые доказательства изоляции данных.
Что именно мы сделаем
Описываем модель клиентов, ролей и прохождение доверенного tenant context через сервис.
Проверяем API, данные, кеш, файлы, поиск, очереди и поддержку сценариями двух организаций.
Исправляем критичные пути и добавляем централизованные проверки владельца и области доступа.
Запускаем регрессионные cross-tenant тесты и передаём протокол с дальнейшими рекомендациями.
Что входит в стоимость
39 900 ₽ за всю работу
Описываем tenant context, пользователей, роли и поддержку, прослеживаем его через middleware и все хранилища. Тестируем BOLA/IDOR, массовые операции, кеш, signed URLs, поиск, очередь и offboarding. Исправляем критичные цепочки, проверяем RLS при наличии PostgreSQL и добавляем регрессионные тесты двух клиентов.
Что будет готово
Передадим вам
- Карта tenant context через API, базу, кеш, файлы, поиск, очереди, фоновые задачи и административный доступ.
- Реестр cross-tenant рисков с подтверждением, приоритетом, затронутым сценарием и выбранным исправлением.
- Исправления выбранных критичных путей и автоматические тесты с двумя организациями и разными ролями.
- Протокол повторной проверки и рекомендации по RLS, ключам, хранению файлов, журналу поддержки и offboarding.
Перед сдачей проверим
- Пользователи двух контрольных организаций видят и изменяют только свои объекты при прямых запросах, поиске, массовых операциях и выгрузке.
- Чужой идентификатор, ссылка на файл, ключ кеша и задание очереди проходят серверную проверку tenant context и дают контролируемый безопасный результат.
- Фоновая обработка и повтор задания сохраняют правильную организацию, а журнал связывает действие с пользователем, ролью и основанием доступа.
- Автоматический набор cross-tenant тестов стабильно проходит после исправлений и может запускаться командой при следующих изменениях сервиса.
Как это выглядит на практике
Счета двух компаний разделяются в API, кеше и хранилище
В B2B-кабинете API списка фильтрует счета по компании, а скачивание строит путь только по document_id. Redis хранит карточку по invoice_id, который может совпасть у разных клиентов. Переносим проверку принадлежности в общий слой репозитория, добавляем tenant prefix в ключ кеша и формируем временную ссылку после серверной авторизации.
Два аккаунта параллельно запрашивают одинаковые номера объектов, выгружают документы и запускают отправку через очередь. Каждый получает только свои счета, а журнал поддержки показывает организацию и основание доступа.
- 01
Создаём две организации с пересекающимися внутренними номерами счетов.
- 02
Переносим проверку владельца в общий серверный слой доступа к данным.
- 03
Добавляем tenant prefix в кеш и проверяем владельца перед выдачей файла.
- 04
Параллельно запускаем чтение, изменение, экспорт и фоновую отправку.
- 05
Подтверждаем разделение результатов и запись административных действий в журнал.
Что понадобится для работы
От вас
- Тестовый контур, две организации с разными данными и ролями, API-спецификация и схема базы.
- Доступ к middleware, data layer, кешу, object storage, поиску, очередям и обезличенным журналам.
- Контрольные файлы, выгрузки и уведомления, правила поддержки и контакт архитектора или ведущего разработчика.
Если у вас немного другая ситуация
Небольшие уточнения, которые помогают довести согласованный результат до рабочего состояния, уже учитываем в цене. Если по ходу работы появится отдельный крупный блок или понадобится платная лицензия, сначала обсудим варианты и стоимость. Расскажите о своей ситуации — подстроим план под неё.
- 3 000 ₽после подписания договора через Диадок
- 36 900 ₽после выполнения, демонстрации и приёмки результата
Предоплата входит в общую стоимость. Оставшуюся сумму оплачиваете после демонстрации и приёмки готовой работы.
Часто спрашивают
Об этой услуге
Что означает изоляция клиентов в multi-tenant сервисе?
Каждая операция получает доверенный контекст организации из аутентифицированной сессии или служебного задания и применяет его при доступе к объектам. Это относится к API, базе, кешу, файлам, поиску, экспорту и очередям. Проверка владельца выполняется на сервере, а результат подтверждается сценариями двух отдельных компаний.
Обязательно ли хранить каждого клиента в отдельной базе?
Архитектура зависит от риска, масштаба, требований клиентов и стоимости эксплуатации. Общая база способна обеспечивать сильную изоляцию при централизованном tenant context, обязательных фильтрах, ограничениях и тестах. Отдельная схема или база добавляет операционные свойства. Сначала проверяем текущую модель и показываем конкретные места для усиления.
Зачем проверять кеш и файлы, если API уже фильтрует данные?
Кеш, object storage и поисковый индекс часто обходят основной запрос к базе. Ключ только из object_id способен вернуть результат соседнего клиента, а временная ссылка может жить после изменения прав. Поэтому tenant входит в ключи и пути, а выдача файла проходит серверную проверку владельца и срока доступа.
Как проверяется доступ службы поддержки к данным клиента?
Фиксируем роли поддержки, основание входа, срок полномочий и доступные действия. Предпочтительна отдельная управляемая функция с подтверждением и журналом вместо использования клиентской учётной записи. В тестах проверяем начало и завершение доступа, смену организации, выгрузки и сведения, которые остаются в аудите.
Цена и изменения по ходу работы
Цена на странице окончательная?
Да. Перед началом мы сверяем исходные данные и фиксируем результат в договоре. Указанная на странице сумма покрывает согласованную работу целиком, даже если её техническая реализация потребует больше времени, чем ожидалось при оценке.
Что означает резерв незапланированных работ?
Это уже включённый в цену запас времени на небольшие связанные уточнения заказчика, которые появляются после старта: например, добавить поле, изменить формат уведомления или учесть ещё одно условие обработки.
Резерв рассчитывается по формуле: стоимость услуги × 30% ÷ 1 500 ₽. Для услуги за 30 000 ₽ это 6 часов. Эти часы относятся только к дополнительным, заранее незапланированным уточнениям. Они не являются сроком проекта и не ограничивают время на основную работу: согласованный результат мы выполняем полностью.
Можно уточнять детали уже во время работы?
Да. Небольшие связанные изменения обычно помещаются во включённый резерв и не требуют доплаты. Если новая идея заметно меняет результат или превращается в самостоятельную задачу, сначала обсудим подход и стоимость. Любое решение согласуем до выполнения.
Начало работы и оплата
Как оформляются договор и оплата?
Подписываем договор через Диадок. Предоплата составляет 3 000 ₽ и входит в общую стоимость услуги. Остаток оплачивается после демонстрации и приёмки готового результата.
Когда начинается срок выполнения?
Срок отсчитывается после согласования задачи, получения необходимых доступов и материалов, подписания договора и поступления предоплаты. Конкретную дату старта и плановый день готовности подтверждаем перед началом.
Как учитываются платные лицензии и внешние сервисы?
До старта проверяем, нужны ли тарифы, лицензии, сертификаты или дополнительные ресурсы внешних систем. Если они потребуются, заранее покажем варианты и стоимость. По возможности аккаунты и лицензии оформляются сразу на заказчика.
Проверка результата и гарантия
Как принимается готовая работа?
Вместе проверяем согласованные сценарии на контрольных данных или тестовой копии, а затем демонстрируем результат. Для интеграций сверяем передачу данных и обработку ошибок, для сайта — работу нужных страниц и действий пользователя, для отчёта — расчёты и обновление данных.
Какая гарантия действует после сдачи?
На выполненные изменения действует гарантия 3 месяца. Если в изменённой нами части обнаружится ошибка нашей реализации, проверим и исправим её без дополнительной оплаты. Переданные материалы, настройки и код остаются у заказчика.
Следующие шаги по защите
Связанные работы выстроены в практическом порядке. Можно начать с текущей задачи или перейти к соседнему этапу.
- 01Модель угроз для сайта, сервиса или интеграции
Разобрать потоки и tenant context
- 02Аудит изоляции клиентов SaaS-сервиса
Проверить разделение клиентов
- 03Изоляция данных клиентов через PostgreSQL RLS
Настроить PostgreSQL RLS