Доступ и роли
Доступ определяет, кто и что видит и может делать в портале. Для владельца и администратора это не набор галочек, а модель ответственности: сотрудник работает со своими задачами и клиентами, руководитель видит свой отдел, а чужие данные остаются закрытыми, если доступ не выдан осознанно.
Эта страница объясняет модель доступа. Настройка живёт в разделе администрирования портала — см. Администрирование портала.
Роли
В основе доступа лежат три роли:
- Администратор — настраивает портал, права и политики; видит и управляет широким контуром.
- Руководитель — отвечает за свой отдел или направление; видит работу своей команды.
- Сотрудник — работает со своими задачами, клиентами и материалами.
Роль задаёт базовый уровень доступа, а точные права уточняются политиками по областям и модулям.
Области доступа
Доступ выдаётся не «ко всему сразу», а по областям. Область — это границы, в которых действует право: компания целиком, отдел, воронка продаж, этап, проект или конкретный пользователь.
Так один и тот же сотрудник может иметь широкий доступ в своём проекте и никакого — в чужом. Это позволяет открывать ровно то, что нужно для работы, не раскрывая лишнего.
Права: читать, изменять, управлять
В каждой области право складывается из уровней:
- Читать — видеть объекты и их содержимое;
- Создавать — заводить новые объекты;
- Изменять — редактировать существующие;
- Управлять — настраивать доступ и правила в этой области.
Разделяйте уровни осознанно: право видеть не означает право менять, а право работать не означает право раздавать доступ другим.
Режим доступа по умолчанию
Для модулей задаётся режим доступа по умолчанию — что происходит, когда явного правила нет:
- Строгий — по умолчанию доступ закрыт; открывается только то, что явно разрешено политикой. Подходит для чувствительных данных и крупных компаний.
- Открытый — по умолчанию доступ на чтение и работу открыт, а политики ограничивают отдельные области. Подходит для небольшой команды с высоким доверием.
Начинать безопаснее со строгого режима в модулях с клиентскими и финансовыми данными и открывать доступ по мере необходимости.
История изменений и обоснование
Изменение доступа — управленческое решение, а не незаметная правка. Поэтому при изменении политики система просит указать причину изменения, а история правок сохраняется: видно, кто, когда и почему менял доступ.
Это важно для контроля и разбора инцидентов: если кто-то увидел лишнее или, наоборот, потерял доступ, по истории понятно, какое изменение к этому привело.
Хорошие практики
- Выдавайте доступ по области и роли, а не «на всякий случай» на всю компанию.
- Разделяйте право видеть и право менять; право управлять доступом давайте узкому кругу.
- В модулях с клиентскими и финансовыми данными держите строгий режим по умолчанию.
- При изменении политики пишите понятную причину — она останется в истории.
- Периодически пересматривайте доступы: убирайте лишние, когда меняются роли и проекты.
Частые ошибки
- Выдают широкий доступ на всю компанию вместо доступа по области.
- Путают право видеть с правом менять — сотрудник случайно правит чужие данные.
- Оставляют открытый режим по умолчанию в модуле с чувствительными данными.
- Меняют политики без причины — потом невозможно разобрать, почему доступ стал таким.
- Не пересматривают доступы после смены роли или завершения проекта.