В начале проекта кажется, что ролей будет две: «админ» и «пользователь». Через полгода появляются менеджеры, бухгалтеры, внешние партнёры, клиенты с доступом к своим данным — и права начинают прописывать в коде точечно. Так рождаются уязвимости и баги. Модель доступа стоит продумать на этапе проектирования — это одна из базовых задач в разработке веб-приложений.
Коротко: разделите две оси — к каким данным пользователь имеет доступ (арендатор, организация, проект) и какие действия может выполнять (роль и права). Проверяйте права на сервере для каждого запроса и записывайте важные действия в журнал.
Мультиарендность: чьи это данные
Если продуктом пользуются разные компании, данные каждой должны быть изолированы. Основные подходы:
| Подход | Как работает | Когда подходит |
|---|---|---|
| Общая база с идентификатором арендатора | Каждая запись помечена ID организации | Большинство SaaS, быстрый старт |
| Отдельная схема на арендатора | Свой набор таблиц для каждого клиента | Повышенные требования к изоляции |
| Отдельная база на арендатора | Полная изоляция | Крупные клиенты, регуляторные требования |
Модели прав доступа
- RBAC (по ролям): роли с наборами прав — владелец, администратор, менеджер, наблюдатель. Просто и понятно.
- Права по ресурсам: «просмотр», «создание», «редактирование», «удаление» для каждого раздела — гибче, удобно для CRM и бэк-офисов.
- Правила по атрибутам (ABAC): доступ зависит от свойств — «менеджер видит только свои сделки». Мощно, но сложнее в поддержке.
Что заложить с самого начала
- Идентификатор организации в каждой бизнес-таблице.
- Проверка прав на сервере, а не только скрытие кнопок в интерфейсе.
- Приглашения пользователей с ролью и сроком действия ссылки.
- Журнал аудита: кто, что и когда изменил.
- Отдельные права для экспорта данных и удаления.
Типичные ошибки
- Права проверяются только на фронтенде — API открыт для всех авторизованных.
- Идентификаторы записей последовательные и не проверяются на принадлежность организации.
- Роли «зашиты» в код без возможности настройки.
- Нет журнала действий — невозможно разобрать инцидент.
Частые вопросы
Можно ли добавить мультиарендность позже?
Можно, но дорого: придётся мигрировать данные и переписывать запросы. Если продукт будет обслуживать несколько компаний, закладывайте её сразу.
Нужен ли единый вход (SSO)?
Для корпоративных клиентов часто да, но в MVP его можно отложить. Подробнее о приоритетах — в нашей статье про MVP для SaaS.
Как это связано с CRM?
Права по ресурсам — основа любой CRM: менеджеры видят свои сделки, руководители — отдел. Мы используем ту же модель в CRM/ERP-системах, а данные из других сервисов подключаем через API.
Проектируете продукт с ролями и клиентскими кабинетами? Оставьте заявку на странице «Веб-приложения» — спроектируем модель данных, доступа и аудита до старта разработки.