Вернуться к статьям Личный кабинет редко ломается из-за одной неверной кнопки. Серьёзная проблема возникает, когда сотрудник партнёра открывает чужой акт по сохранённой ссылке, уволенный пользователь остаётся в системе или менеджер вручную меняет принадлежность документов после каждой реорганизации клиента. Такие ситуации появляются, если права проектируют после экранов и интеграций. Начинать нужно с того, кто действует в кабинете, с какими данными и по какому основанию.
Отделите человека от компании и объекта
В модели доступа есть как минимум три сущности. Пользователь — человек с учётной записью. Организация — компания или подразделение, от имени которого он работает. Ресурс — документ, заказ, заявка, оборудование, договор, счёт или прайс. Роль описывает доступные действия, но сама по себе не отвечает на вопрос, к каким ресурсам применяется это действие.
Например, право «скачивать документы» не должно открывать весь архив. Оно действует только для документов нужной организации, нужного статуса и, если это требуется процессом, назначенного договора. Связи лучше хранить явно: пользователь связан с организацией, ресурс связан с организацией или договором, а проверка сопоставляет обе стороны. Поле с названием клиента в документе для этого не годится: название может измениться, совпасть у разных компаний или не отражать юридическую связь.
До разработки составляют реестр ресурсов: владелец данных, допустимые действия, условия доступа, срок и событие отзыва права. Если для акта неясно, к какой организации он относится после перевода договора, правило не появится само в момент интеграции.
Роль — это набор разрешений, а не должность
Названия должностей плохо подходят для технической модели. Бухгалтер в одной компании скачивает закрывающие документы, в другой ещё и подтверждает реквизиты. Сервисный инженер может видеть оборудование только своей зоны. Поэтому роль лучше собирать из операций, а названия использовать как пояснение для бизнеса.
Минимальная матрица обычно содержит строки ролей и столбцы ресурсов. В ячейке указывают действие и ограничение. Например, администратор организации приглашает коллег только в свою компанию; согласующий видит документы, которые ждут его решения; внутренний менеджер открывает карточки закреплённого портфеля клиентов. Отдельно отмечают запреты. Пользователь, который смотрит счёт, не обязательно меняет реквизиты. Менеджер, который помогает с заявкой, не должен автоматически получать доступ к любому договору клиента.
Определите, кто управляет участниками
Приглашение пользователя — часть модели прав, а не только форма с полем email. Нужно решить, кто имеет право пригласить нового сотрудника, кто подтверждает его принадлежность к организации, когда приглашение истекает и что происходит при повторной регистрации. Администратор клиента может управлять коллегами в своей компании, но не должен менять внутренние роли поставщика или видеть сведения другой организации.
Почтовый домен может быть вспомогательным признаком, но не доказательством полномочий. У партнёра бывают личные адреса, подрядчики и общие домены нескольких компаний. Для чувствительных документов нужен отдельный маршрут: подтверждение внутренним менеджером, согласование администратором организации или заранее настроенное правило в мастер-системе.
Отдельно описывают перевод человека между организациями. Вопрос «оставить ли старые документы доступными» нельзя решать по факту обращения в поддержку. Нужен вариант по умолчанию и порядок исключения: кто его утверждает, на какой срок и как это отражается в журнале. Такой же порядок требуется для внешнего аудитора, временного консультанта и сотрудника, который заменяет коллегу на период отпуска.
Документу нужен собственный жизненный цикл
Один и тот же файл может менять аудиторию вместе со статусом. Черновик видят автор и внутренний проверяющий; опубликованный акт — представители организации; отозванный документ остаётся в архиве для ограниченной группы. Если кабинет показывает документы из CRM, учётной системы или файлового хранилища, для каждого источника нужно определить, где принимается окончательное решение о доступе.
Наследование доступа от заказа или договора удобно, но его нужно формализовать. Что произойдёт, если заказ перенесли между организациями? Станет ли старый документ недоступен сразу? Как обработать общий проект двух компаний? Без таких правил появляются «сиротские» вложения: файл либо видит слишком широкий круг людей, либо не видит никто из тех, кому он нужен.
Общий доступ по ссылке требует отдельного решения. Ссылка может быть одноразовой, действовать ограниченное время или вообще не применяться к документам с ограничениями. Скрытый URL не заменяет проверку права: сервер должен проверять пользователя и его отношение к объекту при каждом запросе к ресурсу.
Оформите требования так, чтобы их можно было принять
Фраза «показывать клиенту только его документы» не годится для разработки и тестирования. Она не говорит, кого считать клиентом, что делать с несколькими организациями и как обрабатывать временный доступ. Вместо неё нужна матрица «роль × ресурс × действие × условие» и набор сценариев на границах.
В требования включают список ролей и операций, правила принадлежности к организации и договору, жизненный цикл документа, сценарии приглашения и блокировки, а также негативные тесты. Журнал изменений должен показывать, кто и почему выдал или отозвал право.
Приёмку проводят на отдельных тестовых организациях. Создают пользователей с разными ролями и документы разных статусов, затем проверяют и разрешённые, и запрещённые действия. Успешный вход в свой кабинет не доказывает, что соседняя компания не получит доступ к тому же объекту.
Ошибки, которые обычно находят слишком поздно
Один общий аккаунт на организацию
Общий логин упрощает старт, но лишает систему персональной истории действий. Нельзя надёжно отозвать доступ у одного ушедшего сотрудника, а журнал не отвечает на вопрос, кто скачал документ. Индивидуальные учётные записи требуют настройки приглашений, зато позволяют управлять доступом адресно.
Права выдают «на время» без срока
Временное исключение быстро становится постоянным, если у него нет даты завершения и владельца. Для такого доступа нужны причина, согласующий, срок и проверка после отзыва. Если срок нельзя назвать, правило стоит вынести в основную матрицу и согласовать как постоянное.
Проверяют только интерфейс
Скрытая кнопка не защищает ресурс. Пользователь может открыть сохранённый адрес, воспользоваться поиском, экспортом или API. Контроль права должен работать там, где сервер отдаёт данные, а тесты должны покрывать все пути получения ресурса.
Смешивают права клиента и сотрудника поставщика
Внутренний менеджер и внешний представитель партнёра могут работать с одним заказом, но их полномочия различаются. Если их объединить одной ролью «пользователь», появятся опасные исключения. Разделение ролей и условий доступа проще поддерживать, чем растущий список ручных запретов.
Часто задаваемые вопросы
- Нужен ли администратор у каждой организации?
Не обязательно. Он нужен, если компания должна самостоятельно приглашать и блокировать коллег. В таком случае его полномочия ограничивают своей организацией и не смешивают с внутренними административными правами кабинета.
- Можно ли назначать роль по данным CRM?
Можно, если CRM признана источником истины для этой связи и определён момент обновления. В требованиях нужно предусмотреть конфликт между изменением в CRM и ручным действием в кабинете, а также порядок обработки ошибки обмена.
- Достаточно ли скрыть кнопку скачивания?
Нет. Серверная часть должна проверять право на конкретный файл или документ при каждом запросе. Кнопка в интерфейсе влияет на удобство, но не является механизмом защиты данных.
- Как дать доступ внешнему консультанту?
Создайте отдельную ограниченную роль, привяжите её к нужному объекту и задайте срок действия. Не стоит выдавать консультанту постоянную роль сотрудника только потому, что она уже существует.
- Что делать с доступом после увольнения?
Заранее определите источник события и срок блокировки. В приёмочных сценариях проверьте активную сессию, ранее открытые ссылки, API и другие способы получить данные, которые есть в конкретной реализации.
Итог
Проектирование доступа в личном кабинете — это работа с отношениями между человеком, организацией и ресурсом. Сначала согласуют матрицу операций, источники данных, исключения и негативные тесты. После этого можно выбирать технические механизмы авторизации и интеграции, понимая, какие правила они должны выполнять.