B2B-портал для клиентов: как открыть свои данные и не показать чужие

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

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

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

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

Портал не обязан с первого дня повторять ERP и CRM. Выберите один полезный сценарий: клиент отправляет заказ, видит его состояние и получает относящийся к нему документ. Для каждого этапа определите источник правды и скорость обновления. Если статус меняет менеджер вручную, не подписывайте его как «обновляется в реальном времени».

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

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

Для поддержки предусмотрите путь восстановления доступа с повторной проверкой личности и компании. Не позволяйте оператору вручную переставить пользователя к другому контрагенту по одному письму без проверенного основания.

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

Следующий шаг — согласовать матрицу прав и один клиентский сценарий на реальных, обезличенных примерах. Лишь после этого выбирайте интеграции и интерфейс кабинета: так легче оценить работу, чем по абстрактному списку «каталог, документы, чат».