Как разделить доступы клиентов и организаций в B2B-кабинете

Начните с модели отношений

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

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

Составьте матрицу действий клиента

Роли условные: их названия не задают готовую политику. Для каждого действия укажите область объектов и исключения. Разделите просмотр суммы, скачивание документа и массовый экспорт. Один экран может объединять данные с разными правилами, поэтому отсутствие кнопки не заменяет контроль конкретного запроса.

Продумайте приглашение

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

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

Проверяйте каждый путь к данным

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

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

Учитывайте изменение полномочий

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

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

Учебная проверка двух компаний

Пользователь имеет право заказа в компании А и только просмотра в компании Б. Он создаёт заявку в А, переключается на Б и пытается повторить действие с прежним идентификатором. Система проверяет фактическую принадлежность и полномочия, а не доверяет одному выбранному полю. После отзыва участия в А доступ к её документам прекращается по установленному правилу.

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

Что должно быть готово к запуску

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

Что делать с запоздавшим ответом после смены организации

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

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