Безопасность Bitrix24: права, экспорт, приложения, входы и аудит

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

Защита Bitrix24 — это не одна галочка. Надежная модель сочетает минимально необходимые права, защищенный вход, учет интеграций, контроль критичных полей, регистрацию массовых операций, кадровые процедуры и готовность расследовать инцидент.

Проверять нужно не только доступ к порталу, но и то, что разрешенные пользователи и автоматизации делают с контактами, компаниями, лидами и сделками.

Содержание

1. Определить владельцев и критичные данные
2. Проверить администраторов и роли CRM
3. Защитить вход
4. Ограничить экспорт и массовые действия
5. Провести аудит приложений и вебхуков
6. Настроить историю и критичные поля
7. Подготовить увольнение и смену роли
8. Организовать расследование
9. Понимать ограничения покрытия
10. План проверки на 30 дней

1. Определить владельцев и критичные данные

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

Составьте перечень критичных объектов и полей:

• телефоны и email клиентов;
• ответственные и подразделения;
• стадии, суммы и даты сделок;
• пользовательские поля с договорными или финансовыми признаками;
• реквизиты и другие данные, которые компания считает чувствительными;
• связи между контактами, компаниями и сделками.

Не все поля одинаково важны. Массовая правка служебного комментария и очистка телефонов должны иметь разный приоритет. Для классификации используйте шаблон карты чувствительных полей.

2. Проверить администраторов и роли CRM

Администратор портала обладает широкими возможностями. Оставляйте этот статус только действующим ответственным, периодически пересматривайте список и документируйте замещение.

В CRM права назначаются через роли. Проверьте:

• кто может читать, добавлять, изменять и удалять элементы;
• кому доступна работа со всеми подразделениями;
• кто может экспортировать данные;
• кто меняет настройки CRM;
• кто выполняет массовые действия;
• какие права наследуют руководители и временные роли.

Принцип минимальных прав не означает, что каждый видит только свои карточки. Руководителю или службе качества нужен широкий доступ. Важно, чтобы он соответствовал роли и регулярно подтверждался.

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

3. Защитить вход

Включите двухфакторную аутентификацию и при необходимости сделайте ее обязательной для сотрудников. Проверьте, как восстанавливается доступ и кто может изменять настройки безопасности.

Если тариф и модель работы позволяют, рассмотрите ограничение доступа по IP для отдельных ролей. Помните, что динамические сети, командировки и мобильная работа требуют аккуратной настройки, а администратор может иметь особые ограничения.

Используйте Журнал событий и историю входов, когда они доступны. Проверяйте не только необычный IP, но и действия после входа. VPN или мобильная сеть могут объяснять адрес; массовые изменения после необычного входа повышают приоритет.

Срок хранения, набор полей и доступность журналов зависят от тарифа и версии Bitrix24. Не обещайте данные, которых портал фактически не предоставляет.

4. Ограничить экспорт и массовые действия

Штатный экспорт удобен для работы и одновременно создает риск образования копии базы. Проверьте, кому доступна функция и требуется ли она постоянно. Для разовой задачи выдавайте право на ограниченный срок по внутренней процедуре, если ваша модель ролей это позволяет.

История CRM может содержать записи об основных действиях, включая экспорт и изменение полей. Но это не универсальный контроль всех способов копирования: скриншоты, ручное переписывание, сторонние каналы и отдельные интерфейсы могут не отражаться одинаково.

Групповые действия и импорт требуют отдельного процесса:

1. заявка с владельцем и основанием;
2. точная выборка объектов;
3. список разрешенных полей;
4. рабочее окно;
5. тестовая партия;
6. источник восстановления;
7. контроль результата.

Проверяйте серии замен телефонов, смены ответственных, переводов сделок и удалений. Массовость — сигнал для контекста, а не автоматическое нарушение.

5. Провести аудит приложений и вебхуков

В разделе для разработчиков администратор может найти созданные приложения и вебхуки, увидеть их владельцев и доступы. Сформируйте реестр:

• название и назначение;
• бизнес- и технический владелец;
• пользователь, от имени которого работает источник;
• права и сущности;
• секрет хранится в защищенном хранилище;
• ожидаемый объем и рабочее окно;
• дата последней проверки;
• сценарий отключения.

Не помещайте токены и URL вебхуков в открытые таблицы, тикеты или комментарии CRM.

При увольнении сотрудника интеграции могут быть сохранены на системном пользователе и продолжить работу. Поэтому проверка приложений обязательна: блокировка обычной учетной записи не всегда прекращает технический доступ.

Подробнее — в сценарии рискованных интеграций.

6. Настроить историю и критичные поля

История CRM хранит основные изменения элементов, однако набор записей зависит от настроек, прав и возможностей портала. Администратор обычно видит больше, чем рядовой пользователь.

Для внутреннего контроля определите:

• какие поля критичны;
• какой before/after нужен;
• кто должен видеть историю;
• сколько времени требуется хранить данные;
• какие значения нужно маскировать или минимизировать;
• как история связывается с инцидентом.

Veriqon сохраняет доступный before/after по выбранным контролируемым полям с момента подключения. Продукт не восстанавливает ретроспективу до установки и не копирует всю CRM по умолчанию.

Полное руководство по штатным возможностям и ограничениям: история изменений Bitrix24.

7. Подготовить увольнение и смену роли

Кадровый процесс должен синхронизировать бизнес, HR и администратора:

• передать контакты, компании, лиды, сделки и задачи;
• определить следующий контакт по активным клиентам;
• закрыть учетную запись в нужный момент;
• проверить приложения, вебхуки и технические роли;
• передать права администратора;
• сохранить факты в пределах полномочий;
• провести контроль после увольнения.

Bitrix24 предоставляет штатные действия для увольнения и передачи элементов, но перечень объектов следует проверять отдельно. Используйте комплект безопасного увольнения менеджера.

8. Организовать расследование

До инцидента определите минимальный процесс:

1. первичная фиксация;
2. владелец и критичность;
3. сохранение доступных источников;
4. хронология;
5. затронутые объекты;
6. бизнес-контекст и альтернативные объяснения;
7. решение и корректирующие меры.

Не называйте журнал готовым судебным доказательством. Юридически значимые действия требуют оценки профильного специалиста и соблюдения локальных документов.

Рабочие формы собраны в комплекте расследования инцидента CRM.

9. Понимать ограничения покрытия

Разные действия приходят из разных каналов. Карточка web, список, kanban, мобильный клиент, импорт и сторонняя интеграция могут предоставлять разные данные. Возможности зависят от тарифа, прав, облачной или коробочной версии и официальных API.

Хорошая система контроля показывает статус каждого канала: доступен, частично доступен, экспериментальный или недоступен. Если событие недоступно, отсутствие сигнала нельзя считать подтверждением безопасности.

Veriqon не обещает:

• видеть каждое открытие карточки;
• обнаруживать любой способ копирования;
• всегда определять устройство и географию входа;
• автоматически находить все приложения;
• блокировать или восстанавливать любые действия;
• доказывать намерение пользователя.

10. План проверки на 30 дней

Неделя 1: ответственность и доступ

• назначить владельцев базы, портала и интеграций;
• пересмотреть администраторов;
• выгрузить роли и исключения в защищенный рабочий документ;
• определить критичные объекты и поля.

Неделя 2: входы и технические источники

• проверить 2FA и историю входов;
• инвентаризировать приложения и вебхуки;
• назначить владельцев и сроки пересмотра;
• устранить секреты без владельца.

Неделя 3: массовые операции и увольнение

• ввести форму регистрации импорта;
• определить пороги серийных изменений;
• проверить процедуру увольнения;
• провести тест передачи объектов.

Неделя 4: реагирование и пилот

• провести учебный инцидент на демо-данных;
• проверить доступность журналов и корзины;
• зафиксировать пробелы покрытия;
• выбрать сценарии пилота Veriqon.

Итоговый чек-лист

• У каждого критичного процесса есть владелец.
• Список администраторов подтвержден.
• Роли CRM соответствуют обязанностям.
• 2FA включена по принятой политике.
• Экспорт и массовые действия ограничены.
• Интеграции и вебхуки учтены.
• Критичные поля классифицированы.
• Увольнение включает технические доступы.
• Процесс расследования протестирован.
• Ограничения покрытия документированы.

Официальные источники Bitrix24

• Ролевая модель прав в CRM
• Что такое История в CRM
• Как экспортировать данные из CRM
• Журнал событий
• Двухфакторная аутентификация
• Вебхуки и приложения

Проверить свой портал

Диагностика Veriqon фиксирует приоритетные риски и фактическое покрытие. Для первого обращения не требуются клиентские данные, пароли, токены или доступ администратора.