Права доступа и структура компании в коробочном Битрикс24

Короткий ответ

Права в Битрикс24 удобнее всего строить от структуры компании: сначала подразделения с руководителями, потом роли CRM — по функциям, а не по фамилиям. Базовая матрица простая: менеджер видит и редактирует только свои сделки, руководитель отдела — сделки своего отдела, директор — все, а экспорт клиентской базы закрыт для всех, кроме одного ответственного человека. Настраивается всё в CRM → Настройки → Права доступа, роли назначаются сотрудникам, отделам или группам.

Коробочная версия умеет то, чего нет в облаке: синхронизацию структуры и пользователей с Active Directory/LDAP (это корпоративный «справочник сотрудников», с которым портал сверяется сам), единый вход (SSO — один рабочий пароль на всё), ограничение доступа по IP и закрытый контур, журнал событий для спокойных расследований и тонкие доработки под холдинги с несколькими юрлицами.

Утечка клиентской базы в 90% случаев выглядит совсем не по-голливудски: никакого взлома — просто менеджер перед увольнением нажал «Экспорт» и унёс сделки за три года. Самое обидное, что право на эту кнопку в типовой настройке есть у всех: права в Битрикс24 обычно «настраивают потом», а «потом» так и не наступает. Мы в Interland внедряем коробочный Битрикс24 с 2015 года, и ролевая модель — первое, что мы приводим в порядок на каждом аудите. В этой статье спокойно разберёмся, как устроены права и структура, покажем готовую матрицу ролей и возможности коробки, ради которых её выбирают компании, где к безопасности относятся всерьёз.

Структура компании — фундамент, а не оргсхема для красоты

Структура в Битрикс24 (Сотрудники → Структура компании) — не картинка для презентаций: от неё зависят права «своего отдела», маршруты согласований, отчёты руководителям и подчинение в задачах. Правило здесь одно: структура в портале должна повторять реальное подчинение, а не штатное расписание из отдела кадров. Если руководитель отдела продаж на деле отвечает и за продажи, и за тендерный отдел — в структуре это должно быть видно, иначе половина сделок просто выпадет из его поля зрения. Для холдингов структуру удобнее строить от юрлиц: филиал или компания — ветка первого уровня, внутри — отделы; права и воронки потом аккуратно разводятся по этим веткам.

Как устроены права в CRM

Модель здесь ролевая: роль описывает, что можно делать с лидами, сделками, контактами и компаниями — читать, добавлять, менять, удалять, выгружать, загружать. Для каждой операции задаётся глубина: «свои», «своего отдела», «отдела с подотделами», «все». Роль назначается сотруднику, отделу или группе. Есть и совсем тонкая настройка — права по стадиям: например, менеджер не может сам перевести сделку в «Оплачено» — это делает бухгалтер или автоматика после реальной оплаты.

Вот типовая матрица, с которой мы начинаем почти каждый проект:

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

Что добавляет коробка

• Active Directory / LDAP. Корпоративный «справочник сотрудников», с которым портал синхронизируется сам: приняли человека в AD — он появился в портале в нужном отделе; заблокировали в AD — доступ в портал закрылся автоматически. Для компаний от сотни сотрудников это, честно говоря, единственный способ не разъехаться со структурой.
• Единый вход (SSO/NTLM). Сотрудник заходит в портал без отдельного пароля — тем же, каким входит в рабочий компьютер. Меньше паролей — меньше фишинга и меньше заявок «не могу войти».
• Контур и IP. Портал можно спрятать во внутренней сети или за VPN и пускать только с определённых адресов — облако так не умеет в принципе, мы подробно разбирали это в сравнении коробки и облака.
• Журнал событий. В коробке есть полный лог: кто смотрел, кто выгружал, кто менял права. Когда служба безопасности спросит «а кто открывал карточку этого клиента» — у вас будет ответ, а не пожимание плечами.
• Доработки модели. Исходный код открыт, поэтому можно строить нестандартные схемы: права по юрлицу в сделке, скрытие отдельных полей карточки по роли, свои проверки при переходе по стадиям.

Пять привычных ошибок — мы находим их на каждом втором аудите

• Все — администраторы. Портал настраивали на бегу, права раздали максимальные — «потом разберёмся». Проходит год, а любой менеджер по-прежнему может удалить воронку целиком.
• Экспорт по умолчанию. Кнопка выгрузки доступна каждому, а в журнал не заглядывает никто (в облаке его, к слову, толком и нет).
• Права по фамилиям, а не по ролям. «Пете дали как у Васи, плюс ещё чуть-чуть» — и через два года объяснить эту модель не может уже никто. Роли должны совпадать с функциями: менеджер, руководитель отдела продаж, маркетолог, бухгалтер, администратор.
• Нет процедуры увольнения. Правильное прощание с сотрудником — по сути одна операция: деактивировать пользователя (вся история при этом остаётся), передать сделки и задачи преемнику и заглянуть в журнал выгрузок за последний месяц. В коробке с AD первая часть происходит сама.
• Один администратор — и это подрядчик. Админ-доступ должен быть минимум у двух людей самой компании; подрядчику — отдельная учётка, которую видно в журнале. Мы настаиваем на этом, даже когда портал сопровождаем сами.

Как навести порядок: процесс на один день

• 1. Актуализируйте структуру — реальное подчинение, руководители в каждом отделе, филиалы отдельными ветками.
• 2. Опишите роли по функциям — обычно их 4–6, каждой роли достаточно одной строки в матрице, как в таблице выше.
• 3. Настройте роли CRM и назначьте их отделам, а не людям: тогда новый сотрудник получает права автоматически, просто по месту в структуре.
• 4. Закройте экспорт и удаление — оставьте одной роли и включите контроль по журналу.
• 5. Проверьте стадийные права — финальные стадии двигают только те, кто отвечает за деньги (или автоматика).
• 6. Заведите процедуру увольнения — чек-лист из трёх пунктов и один конкретный ответственный.

На коробочном портале к этому добавляется связка с AD/LDAP и настройка контура — ещё полдня-день работы. Так мы делали, например, при восстановлении и настройке коробочного портала для «Проектного Центра Сибири» и переводе НЗМО на коробку.

Честное ограничение

Ролевая модель не заменит управленческую дисциплину: если руководитель сам пересылает выгрузки в мессенджеры, никакие права не спасут. Работает и обратное: слишком жёсткие права (когда менеджер не видит даже контактов коллег в отпуске) порождают теневые Excel-файлы — а это хуже любой утечки. Баланс простой: закрыть массовые операции (экспорт, удаление, смену настроек), а ежедневную работу оставить свободной.

Вывод

Права доступа — это полчаса настройки, которые защищают главный актив CRM: вашу клиентскую базу. Формула простая: структура повторяет реальное подчинение, роли собраны по функциям и назначены отделам, экспорт — событие, а не кнопка, финальные стадии под контролем, а увольнение — спокойная процедура, а не пожарная тревога. Коробка добавляет к этому AD/LDAP, единый вход, IP-контур и журнал событий — те самые механизмы, ради которых её выбирают компании с требованиями к безопасности.

Interland — золотой партнёр 1С-Битрикс в Новосибирске: внедряем и настраиваем коробочный Битрикс24, наводим порядок в правах на уже работающих порталах и строим CRM с нуля от трёх рабочих дней. Напишите нам в чат — бесплатно и без обязательств посмотрим вашу ролевую модель. Обычно уже первый взгляд на права экспорта окупает весь разговор — и спится после этого спокойнее.