RBAC и аудит в CRM: как расти быстро, но безопасно

Знакомая история: стартап растёт, отдел продаж удваивается каждые полгода, подключаются интеграции с кучей сервисов — и вдруг выясняется, что стажёр видит финансовые отчёты, а уволенный полгода назад менеджер всё ещё может зайти в систему через забытый API-токен.

Это не выдуманный сценарий. Видели такое у компаний с оборотом в сотни миллионов, где безопасность откладывали «на потом» — а потом случался инцидент. Ниже разбираем, как выстроить контроль доступа, который защитит бизнес и не превратится в бюрократический ад.

Коротко для торопящихся

Если через пять минут совещание — вот главное. Подробности ниже.

• Принцип минимальных прав: сотрудник видит только то, что нужно для работы. Исключения — только по заявке и с конкретным сроком действия.
• Данные под замком: ограничивайте доступ по клиенту, региону, типу информации. Аудитируйте не только изменения, но и просмотры чувствительных данных.
• Интеграции — отдельная история: каждый внешний сервис получает свой токен с минимальными правами. Ротация — раз в квартал.
• Логи решают: записывайте кто, что, когда и откуда делал. Храните минимум полгода, настройте алерты на подозрительную активность.
• Регулярная гигиена: раз в квартал проверяйте, у кого какие доступы, убирайте лишнее, тестируйте систему «глазами» разных ролей.

Что такое RBAC и зачем он нужен

RBAC (Role-Based Access Control) — модель управления доступом, где права привязаны не к человеку, а к его роли. Менеджер по продажам получает один набор возможностей, бухгалтер — другой, руководитель — третий.

Звучит очевидно? На практике большинство компаний работают иначе. Новичку копируют права коллеги («сделай как у Васи»), потом добавляют доступы по мере необходимости, но никогда не убирают. Через год у «Васи» права почти как у админа — а почему, никто не помнит.

Грамотный RBAC решает три задачи одновременно:

• Защита от утечек: менеджер не может выгрузить базу клиентов, потому что у его роли просто нет такой кнопки.
• Порядок при масштабировании: когда команда растёт с 10 до 100 человек, вы не тратите недели на разбор «кто к чему имеет доступ».
• Соответствие требованиям: ISO 27001, GDPR, закон о персональных данных — все они требуют контроля доступа. С RBAC вы готовы к любому аудиту.

Какие роли нужны в CRM и что каждая из них должна видеть

Универсального рецепта нет — набор ролей зависит от структуры компании. Но есть базовые роли, которые встречаются почти везде. Вот как мы обычно рекомендуем их настраивать:

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

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

Как разграничить доступ к данным: не только «кто», но и «к чему»

Роли определяют, какие действия доступны пользователю. Но этого мало — нужно ещё ограничить, какие именно записи он видит. Менеджер московского офиса не должен видеть клиентов алматинского, а партнёрский канал продаж — внутренние сделки.

Мы рекомендуем разграничивать данные по нескольким измерениям:

• По принадлежности: сотрудник видит только «свои» сделки и клиентов, или записи своего сегмента (по отрасли, размеру, тарифу).
• По географии: ЕС, США, Казахстан — у каждой юрисдикции свои правила хранения и обработки данных. Физическое разделение упрощает соблюдение требований.
• По чувствительности поля: персональные данные, финансовая информация, NDA-материалы — маскируйте или полностью скрывайте для ролей, которым это не нужно.
• По командам: партнёры, внутренние продажи, сервис — каждая команда работает в своей «песочнице» с пересечением только там, где это необходимо.

На практике это означает: даже если сотрудник имеет право «просматривать карточки клиентов», он увидит только те карточки, которые относятся к его зоне ответственности. Это снижает и риски утечки, и информационный шум — не нужно листать сотни нерелевантных записей.

Шесть типичных ошибок

За годы работы насмотрелись на одни и те же косяки. Кажутся мелочью — пока не бахнет. Проверьте себя:

• «Универсальный» токен для всех интеграций. Один API-ключ с правами администратора, который знают пять разных подрядчиков. Утечёт — и вся система открыта.
• Экспорт без следа. Менеджер выгружает 50 000 контактов в Excel — и никто об этом не узнает, пока эти контакты не всплывут у конкурента.
• Смена владельца = доступ к чужим секретам. При передаче сделки новый менеджер получает и приватные заметки юристов, и внутреннюю переписку о рисках клиента.
• Аудит только на изменения. Кто-то просматривает карточки VIP-клиентов или платёжные данные — а в логах пусто, потому что «он же ничего не менял».
• «Временный» доступ навсегда. Дали расширенные права «на время закрытия квартала». Квартал закончился три года назад, права остались.
• BI-система как чёрная дыра. Дашборд подключён токеном, который читает всё: персональные данные, финансы, внутренние комментарии. Без лимитов и ограничений.

Если узнали себя хотя бы в одном пункте — это нормально. Ненормально — ничего с этим не делать.

Логи — ваша страховка

Контроль доступа — полдела. Вторая половина — понимать, что происходит в системе. Когда (не «если», а «когда») случится инцидент, понадобятся логи. И не просто «кто залогинился», а полная картина: кто, что, когда, откуда и с каким результатом.

Вот что обязательно должно попадать в журнал:

• Базовая информация о каждом действии: пользователь и его роль, объект и конкретное поле, время в UTC, IP-адрес и устройство, результат — успех или ошибка.
• Просмотр чувствительных данных: не только изменения, но и чтение персональных данных, финансовых полей, скачивание файлов, массовые выборки больше определённого порога.
• Операции с правами: изменение ролей, создание и удаление API-токенов, смена владельцев записей, расширение видимости.

Логи бесполезны, если на них никто не смотрит. Настройте автоматические алерты на подозрительную активность:

• Резкий рост количества экспортов или скачиваний
• Вход из непривычной страны или с нового устройства
• Попытки повысить себе права или обойти ограничения (ошибки 401/403)

И последнее: храните логи минимум 180 дней в неизменяемом виде. Злоумышленник, получивший доступ к системе, первым делом попытается подчистить следы. Если логи лежат на отдельном защищённом хранилище — у него ничего не выйдет.

Как дать минимум прав и не парализовать работу

«Минимум прав» звучит просто, но на практике вызывает сопротивление. Люди жалуются, что им «ничего не дают», руководители боятся, что процессы встанут. Вот подход, который работает:

1. Начните с инвентаризации. Составьте список всех объектов в CRM (контакты, сделки, счета, отчёты), всех возможных действий (просмотр, создание, редактирование, экспорт, удаление) и текущих ролей. Это скучно, но без этого вы не поймёте масштаб проблемы.
2. Уберите админов из повседневной работы. Оставьте 1-2 человека с полными правами, и пусть они используют эти аккаунты только для администрирования. Для обычной работы — отдельные учётки с обычными правами. Обязательно включите двухфакторную аутентификацию.
3. Введите систему заявок на расширенный доступ. Нужны права на что-то сверх базового набора? Заявка с обоснованием и сроком действия. Срок истёк — доступ автоматически отзывается.
4. Регулярно проверяйте «глазами пользователя». Раз в месяц заходите под тестовыми аккаунтами разных ролей и смотрите, что видит обычный менеджер, что — бухгалтер, что — стажёр. Часто обнаруживаете лишнее.
5. Требуйте подтверждения для критичных операций. Экспорт всей базы, снятие маскировки с персональных данных, выдача админских прав — всё это должно требовать одобрения второго человека. Это не бюрократия, это страховка от ошибок и злоупотреблений.

Главное — не пытайтесь сделать всё сразу. Начните с самых рискованных мест (экспорт данных, доступ к финансам), потом расширяйте охват.

Чек-лист: проверьте прямо сейчас

Распечатайте и пройдитесь с командой. Где стоит «нет» или «не знаю» — там точка для улучшения.

• Роли задокументированы. Есть понятный список: кто к чему имеет доступ и почему. Все админы защищены двухфакторной аутентификацией.
• Данные разделены. Команды видят только свои записи. Чувствительные поля скрыты или замаскированы для тех, кому не положено.
• Интеграции под контролем. У каждого внешнего сервиса свой токен с минимальными правами. Токены ротируются раз в квартал, ограничены по IP.
• Логи настроены правильно. Фиксируются не только изменения, но и просмотры чувствительных данных. Алерты настроены и приходят нужным людям.
• Регулярный пересмотр. Раз в квартал проверяете: кто уволился, чьи права устарели, какие подрядчики больше не работают.
• Есть план на случай инцидента. Знаете, кто дежурит, как быстро заблокировать токен или аккаунт, кого уведомлять.
• Система протестирована. Вы хотя бы раз попробовали сделать то, чего делать нельзя (массовый экспорт, повышение прав) — и убедились, что сработала защита.

Идеально, если этот чеклист станет частью квартального ревью. Занимает пару часов, экономит месяцы разбирательств после инцидента.

Частые вопросы

Готовы навести порядок?

Настройка контроля доступа — не разовая акция, а процесс. Но первые результаты можно получить быстро. Мы помогаем компаниям выстроить систему ролей, настроить логирование и убедиться, что CRM защищает данные, а не создаёт риски.