Когда веб-приложение или CRM делается «для своих», логика доступа часто ограничивается одним аккаунтом администратора. Через полгода в системе работают 10–15 человек, и каждый видит всё: клиентскую базу, финансовые отчёты, переписку. Это не просто неудобство, а прямой риск: значительная часть утечек данных происходит из-за внутренних пользователей, а не хакеров извне. Грамотная система ролей на этапе разработки стоит недорого, а её отсутствие оборачивается уволенными менеджерами, ушедшими клиентами и разбирательствами. В этой статье разберём, как разграничить права для сотрудников, менеджеров и клиентов так, чтобы это работало на бизнес, а не мешало ему.
Что такое роли и права доступа
Роль — это набор разрешений, привязанный к должности, а не к конкретному человеку. У роли «Менеджер по продажам» может быть право просматривать заказы и менять их статусы, но не право удалять их или выгружать всю клиентскую базу. Когда человек приходит в компанию или уходит из неё, вы просто назначаете ему готовую роль — не настраивая доступ заново. Основа любого разграничения — принцип минимальных привилегий: каждый пользователь получает ровно те права, которые нужны для работы, и ни одним больше. Это единственный подход, который масштабируется без хаоса.Базовый набор ролей для типового бизнеса
Большинству компаний достаточно 5–6 ролей. Вот проверенный стартовый набор:- Владелец / директор — полный доступ: финансы, отчёты, управление пользователями.
- Администратор системы — технические настройки и управление учётными записями, без доступа к коммерческим данным.
- Руководитель отдела — видит работу своих подчинённых и аналитику своего направления, но не чужие отделы.
- Менеджер / сотрудник — только свои заказы, клиенты и задачи.
- Бухгалтер — финансовые документы и платежи, без клиентской переписки.
- Клиент — личный кабинет: свои заказы, счета, документы и баланс.
Минимальные привилегии на практике
Самый частый спор с заказчиком звучит так: «Дайте менеджерам видеть все заказы, вдруг что-то случится». Практика показывает обратное. Когда менеджер видит только своих клиентов, растёт дисциплина и исчезает риск «уноса» базы при увольнении. Когда же система открыта всем, достаточно одного уволенного сотрудника с сохранённым паролем, чтобы потерять годы работы. Правило простое: по умолчанию доступ запрещён, а каждое разрешение — осознанное решение. Добавить право потом можно за час, откатить последствия утечки — иногда невозможно.Как составить матрицу прав: пошаговый план
Матрица прав — это таблица «функции системы × роли», где для каждой пары отмечено, разрешено действие или нет. Составить её можно без технических знаний:- Выпишите все функции системы: просмотр заказов, редактирование цен, выгрузка базы, удаление записей, изменение настроек.
- Выпишите все роли и категории пользователей, включая клиентов и подрядчиков.
- Для каждой ячейки задайте вопрос: «Если этот человек сделает это действие — чем это грозит бизнесу?»
- Прогоните матрицу через реальные сценарии: «день из жизни менеджера», «жалоба клиента», «внезапное увольнение сотрудника».
- Согласуйте с руководителями отделов и зафиксируйте в техническом задании.
Типичные ошибки при разграничении доступа
За годы работы с корпоративными системами мы видим одни и те же просчёты:- Один общий аккаунт на всех — «admin» с простым паролем. Ни персональной ответственности, ни понимания, кто что делал.
- Права «на вырост»: сотруднику сразу выдают всё, «чтобы потом не бегать». Отбирать обычно уже некому и некогда.
- Проверка прав только в интерфейсе: кнопку скрыли, а запрос к серверу всё равно проходит. Настоящая проверка должна выполняться на стороне сервера.
- Отсутствие журнала действий — при инциденте невозможно восстановить картину.
- Статичная модель: процессы меняются, а роли не пересматриваются годами.
Что спросить у подрядчика о технической реализации
Красивый интерфейс не гарантирует безопасности — важна архитектура. Спросите у команды, как реализована модель доступа: профессиональный подход — это ролевая модель, где права хранятся на сервере и проверяются при каждом запросе к API, а не просто «спрятанные кнопки» в браузере. Уточните, ведётся ли журнал действий пользователей — кто, когда и что менял; без него расследовать инцидент невозможно. Не лишними будут двухфакторная аутентификация для администраторов, автоматическое завершение сессий и возможность изменить роль за минуту без обращения к разработчикам. Если на вопросы отвечают общими фразами про «защищённый личный кабинет» — это повод насторожиться.Отдельная зона ответственности: личный кабинет клиента
Клиентская часть — самое уязвимое место, потому что доступ к ней есть у людей за пределами компании. Классическая ошибка разработки — когда клиент, изменив цифру в адресе страницы, может открыть чужой заказ или чужой документ (уязвимость класса IDOR). Каждый пользователь должен видеть только свои данные, а принадлежность записи к аккаунту обязана проверяться на сервере. Учитывайте и законодательство: персональные данные клиентов обрабатываются по 152-ФЗ, и разграничение доступа — часть требований к их защите. И не показывайте клиентам лишнее: закупочные цены, маржу, внутренние комментарии менеджеров.Жизненный цикл доступа: от найма до увольнения
Система ролей работает, только если ею управляют. При найме — создаётся персональная учётная запись с минимальной ролью, никаких «общих паролей на отдел». При переводе — роль меняется в тот же день, а не «когда до рук дойдут». При увольнении — доступ блокируется немедленно, до подписания обходного листа. Раз в квартал полезно проводить ревизию: кто какие роли имеет, совпадает ли это с текущими обязанностями, нет ли «мёртвых» учётных записей бывших сотрудников. Доступы должны жить вместе со штатным расписанием — это дисциплина, которая занимает 15 минут в месяц и экономит миллионы при инциденте.Разграничение прав — та часть системы, которую проще всего заложить на этапе проектирования и сложнее всего дорабатывать, когда в приложении уже работают десятки людей и накоплена клиентская база. Не откладывайте: составьте матрицу прав, утвердите набор ролей и включите эти требования в техническое задание. Это защита денег, данных и репутации, а не формальность ради разработчиков. Если планируете веб-приложение, CRM или личный кабинет и хотите, чтобы система доступа была продумана с первого дня — напишите нам, поможем спроектировать ролевую модель под ваши бизнес-процессы.