Битрикс24 часто воспринимают как готовый защищённый сервис: компания выбирает тариф, настраивает CRM, подключает телефонию и интеграции — и вопрос безопасности вроде бы закрыт.
На практике это не так.
Платформа предоставляет механизмы защиты, но значительная часть рисков возникает не из-за «дыры в Битрикс24», а из-за того, кому компания выдала доступ, какие права оставила сотрудникам, какие приложения подключила и что происходит с учётными записями после кадровых изменений.
Поэтому безопасность Битрикс24 правильнее рассматривать не как одну настройку при внедрении, а как постоянный управленческий процесс.
Ниже — практический подход, ориентированный не на специалиста по информационной безопасности, а на собственника, директора или руководителя подразделения, который отвечает за систему и данные компании.
Что именно нужно защищать
В Битрикс24 обычно сосредоточено гораздо больше информации, чем просто список клиентов.
Это могут быть:
- контакты и реквизиты клиентов;
- история переговоров;
- коммерческие предложения и документы;
- информация о сделках и ценах;
- задачи и внутренняя переписка;
- персональные данные сотрудников и клиентов;
- финансовая или управленческая информация;
- файлы и договоры;
- данные из телефонии, почты и других интеграций.
Поэтому вопрос безопасности звучит не как «защищён ли Битрикс24?», а как:
Кто внутри и за пределами компании может получить доступ к конкретным данным, что этот человек может с ними сделать и нужен ли ему такой доступ вообще?
Именно этот вопрос руководителю стоит задавать регулярно.
1. Права пользователей: принцип «не больше необходимого»
Одна из наиболее распространённых организационных ошибок — выдавать сотруднику больше прав, чем требуется для его работы.
Например, менеджеру по продажам не обязательно иметь возможность видеть и редактировать все сделки компании. Руководителю отдела может быть достаточно доступа к данным своего подразделения. Финансовому сотруднику может понадобиться работа с определёнными документами, но не со всей CRM.
В CRM Битрикс24 можно настраивать роли и уровни доступа: например, разрешить пользователю работать со своими элементами, с элементами своего отдела или со всеми элементами. Права также можно задавать отдельно для чтения, добавления, изменения, удаления, импорта и экспорта данных.
Для руководителя здесь важен не интерфейс настройки, а принцип:
если сотруднику не нужна возможность делать что-либо для работы, эта возможность не должна выдаваться «на всякий случай».
Особое внимание стоит уделять правам:
- просмотра всей CRM;
- редактирования чужих сделок;
- удаления данных;
- экспорта CRM;
- изменения настроек CRM;
- управления правами других пользователей;
- приглашения и удаления сотрудников.
Причём недостаточно посмотреть только одну роль. В Битрикс24 пользователь может иметь несколько ролей, и при пересечении прав применяется более высокий уровень доступа. Это может привести к ситуации, когда руководитель считает сотрудника ограниченным одной ролью, а дополнительная роль фактически расширяет его возможности.
Для собственника полезный контрольный вопрос: если завтра этот сотрудник уйдёт к конкуренту, сможет ли он перед этим выгрузить или изменить существенно больше информации, чем необходимо для его текущей работы?
Если ответ «да» — права стоит пересмотреть.
2. Роли в CRM — это не формальность
Чем крупнее компания, тем опаснее ситуация, когда права настраиваются индивидуально «по просьбе».
Сегодня менеджеру дали доступ к одной группе сделок, завтра — к другой, затем добавили ещё одно исключение. Через год никто уже не помнит, почему конкретный человек обладает конкретными полномочиями.
Лучше строить права вокруг понятных ролей:
- менеджер по продажам;
- старший менеджер;
- руководитель отдела;
- маркетолог;
- бухгалтер;
- оператор;
- администратор;
- внешний подрядчик.
А затем определить, что именно может делать каждая роль.
Это упрощает и безопасность, и аудит. Если сотрудник меняет должность, руководителю проще поменять его роль, чем вручную вспоминать десятки отдельных разрешений.
При этом следует регулярно проверять и сами роли. Битрикс24 позволяет создавать, копировать, изменять и удалять роли CRM, а также показывает пересечение ролей конкретного пользователя.
Важная деталь
Не стоит автоматически считать роль «руководитель» безопасной заменой роли «администратор».
Администратор Битрикс24 обладает существенно более широкими полномочиями: он может управлять настройками и доступами, CRM и другими инструментами. Администраторские права можно назначить практически любому сотруднику, поэтому их следует выдавать осознанно.
3. Администраторов должно быть немного
Администратор — это не просто «опытный пользователь».
Это человек, который потенциально способен изменить правила доступа для остальных сотрудников и существенно повлиять на работу всего портала.
Поэтому список администраторов должен быть коротким и понятным.
Руководителю стоит периодически задавать три вопроса:
- Кто сейчас является администратором?
- Зачем каждому из них нужны эти права?
- Что произойдёт с системой, если один из них завтра покинет компанию?
В Битрикс24 список администраторов можно найти среди сотрудников, а активный администратор может отозвать административные права у другого администратора.
Особенно опасна практика:
«Дадим админку подрядчику, чтобы ему было проще».
Если подрядчику действительно требуется доступ администратора, это должно быть осознанным исключением с понятным сроком и ответственным со стороны компании.
4. Увольнение сотрудника — это часть информационной безопасности
Процедура увольнения должна включать не только кадровые и бухгалтерские действия.
Она должна включать закрытие доступа к корпоративным системам.
В Битрикс24 при увольнении сотрудник теряет доступ к порталу, при этом его рабочая история — задачи, файлы, разговоры и другие данные — сохраняется. Ответственных за CRM, задачи и другие данные можно передать другим сотрудникам.
Это важно: удалять пользователя «чтобы исчезли все его данные» не требуется и зачастую было бы неправильно с точки зрения сохранения рабочей истории.
Но есть более сложный момент — интеграции.
Если у уволенного сотрудника были активные вебхуки, Битрикс24 предлагает либо отключить их вместе с увольнением, либо оставить активными. Во втором случае интеграция может быть передана системному пользователю и продолжить работать. При этом доступ к данным через такой webhook сохраняется у любого, у кого есть ссылка на webhook.
Именно поэтому увольнение нельзя сводить к одному нажатию «Уволить».
При увольнении необходимо выяснить:
- какие CRM-данные были закреплены за сотрудником;
- какие задачи и процессы требуют передачи;
- какие интеграции он создавал;
- какие вебхуки или приложения связаны с его работой;
- кому должны перейти рабочие функции;
- не остались ли у сотрудника активные внешние способы доступа.
5. Общие логины и пароли — плохая управленческая практика
Формат:
manager@company / один пароль для всех менеджеров
кажется удобным, пока всё работает.
Но с точки зрения управления это почти всегда проблема.
Если несколько человек используют одну учётную запись, компания теряет нормальную персональную ответственность:
- непонятно, кто изменил данные;
- сложнее расследовать инцидент;
- увольнение одного человека требует смены общего пароля;
- бывший сотрудник может сохранить доступ;
- невозможно корректно связать действия с конкретным пользователем.
Гораздо правильнее использовать индивидуальные учётные записи и назначать каждому сотруднику собственную роль.
Отдельная проблема — передача пароля администратора между сотрудниками или подрядчиками. Это превращает учётную запись в общий ключ, которым невозможно нормально управлять.
6. Двухфакторная аутентификация полезна, но не заменяет управление доступами
В актуальной документации Битрикс24 двухфакторная аутентификация рассматривается как дополнительный уровень защиты при входе. Администратор может сделать её обязательной для всей компании.
Это важная мера.
Но она не отвечает на вопрос:
«Имеет ли этот человек право видеть эту CRM?»
Двухфакторная аутентификация защищает учётную запись от определённого класса атак. Она не исправляет ошибочно выданные права.
Поэтому нельзя рассуждать так:
«У всех включена двухфакторная аутентификация, значит безопасность настроена».
Правильнее:
аутентификация защищает вход; права определяют, что пользователь сможет сделать после входа.
7. Внешние подрядчики: доступ должен быть ограниченным и временным
Интеграторы, маркетинговые агентства, разработчики, консультанты и другие подрядчики нередко получают доступ к Битрикс24.
Сам факт такого доступа не является проблемой. Проблемой становится отсутствие контроля.
Если стороннему специалисту нужен доступ к проекту, CRM или определённой группе данных, не стоит автоматически давать ему полный доступ к порталу.
В Битрикс24 существуют механизмы работы с внешними пользователями, в том числе экстранет, предназначенные для поставщиков, подрядчиков и других партнёров с ограниченным доступом. Внешние пользователи не получают доступ ко всем внутренним данным компании.
В современных сценариях также используются коллабы для взаимодействия с внешними командами и клиентами.
Но руководителю важнее не название механизма, а правило:
подрядчик должен видеть только то, что ему действительно нужно для работы.
И желательно заранее определить:
- кто отвечает за его доступ со стороны компании;
- какие данные ему разрешены;
- на какой срок выдан доступ;
- кто должен закрыть доступ после завершения проекта;
- какие интеграции он создаёт;
- что произойдёт с этими интеграциями после окончания договора.
8. Приложения и интеграции — отдельный слой риска
Битрикс24 можно расширять приложениями из маркетплейса, вебхуками, локальными приложениями и другими интеграциями.
Именно здесь иногда появляется опасная иллюзия:
«Это всего лишь приложение для телефонии/рассылок/аналитики».
На самом деле приложение может запрашивать доступ к корпоративным данным.
Актуальная документация Битрикс24 прямо рекомендует перед установкой приложения проверять запрашиваемые разрешения и понимать, какие данные приложение сможет использовать. За обработку данных внутри приложения отвечает его разработчик.
Есть и ещё одна организационная тонкость: после установки маркетплейс-приложения доступ к нему по умолчанию может быть открыт всем пользователям. Администратор может ограничить его конкретными сотрудниками или подразделениями.
Поэтому при аудите нужно составить список:
- какие приложения установлены;
- зачем каждое из них нужно;
- кто ими пользуется;
- какие права они запрашивают;
- кто является владельцем интеграции;
- используется ли приложение до сих пор;
- можно ли удалить его без ущерба для бизнеса.
Вебхуки особенно важно не забывать
В Битрикс24 можно посмотреть созданные интеграции, их разрешения и создателя, вебхуки могут создавать пользователи, а администратор видит все интеграции.
Для бизнеса это означает простое правило:
каждая интеграция должна иметь владельца, назначение и понятный статус.
Интеграция, про которую никто не знает, — плохая интеграция с точки зрения управления.
9. Не все риски решаются настройками Битрикс24
Даже идеально настроенные роли не защищают компанию от организационных ошибок.
Например:
- сотрудник отправил клиентскую базу не тому адресату;
- подрядчику оставили доступ после завершения договора;
- пароль администратора хранится в общем чате;
- сотрудник использует один пароль в нескольких сервисах;
- бывший сотрудник всё ещё имеет доступ к корпоративной почте;
- интеграция продолжает работать после увольнения её владельца;
- новый сотрудник получил роль старого сотрудника «по аналогии».
Это уже вопросы процессов компании.
Поэтому безопасность Битрикс24 должна быть связана с кадровыми процедурами, регламентом доступа и ответственностью руководителей.
10. Периодический пересмотр доступов — обязательная процедура
Права почти никогда не становятся неправильными в момент их выдачи.
Они становятся неправильными со временем.
Компания меняется:
- сотрудники переходят между отделами;
- появляются новые подразделения;
- меняются обязанности;
- закрываются проекты;
- уходят подрядчики;
- появляются новые приложения;
- меняется структура CRM.
А права часто остаются прежними.
Поэтому полезно проводить периодическую проверку доступа — например, раз в квартал или хотя бы несколько раз в год, в зависимости от размера и чувствительности бизнеса.
При таком пересмотре стоит проверить:
Пользователи
- Все ли сотрудники действительно работают в компании?
- Нет ли забытых приглашений?
- Нет ли лишних учётных записей?
- Совпадает ли структура пользователей со штатной структурой?
Администраторы
- Кто имеет административные права?
- Нужны ли они каждому из этих людей?
- Нет ли бывшего сотрудника или подрядчика среди администраторов?
CRM
- Кто видит все сделки?
- Кто может редактировать чужие сделки?
- Кто может удалять данные?
- Кто может экспортировать CRM?
- Кто может менять настройки и права?
Интеграции
- Какие приложения установлены?
- Какие вебхуки существуют?
- Кто их создал?
- Нужны ли они сейчас?
- Нет ли интеграций бывших сотрудников?
Внешние пользователи
- Кто из подрядчиков всё ещё имеет доступ?
- Какие проекты им доступны?
- Действуют ли договоры?
- Не стал ли доступ шире, чем требуется?
11. Что проверить при аудите уже существующего портала
Если компания получила Битрикс24 «в наследство» от предыдущего администратора, подрядчика или другого руководителя, не стоит сразу начинать с переделки CRM.
Сначала нужно понять, что фактически существует сейчас.
Первый уровень — карта пользователей
Составьте перечень всех пользователей и сопоставьте его со штатной структурой.
Отдельно отметьте:
- действующих сотрудников;
- уволенных;
- внешних пользователей;
- подрядчиков;
- администраторов;
- пользователей с необычно широкими правами.
В Битрикс24 для управления структурой существуют отдельные права на приглашение пользователей, управление разрешениями и увольнение сотрудников.
Второй уровень — карта прав
Для ключевых должностей ответьте:
Что именно этот пользователь может увидеть?
и:
Что именно он может изменить, удалить или выгрузить?
Особенно важно проверить не только стандартные роли, но и индивидуальные назначения.
Третий уровень — карта интеграций
Нужно установить:
- какие приложения используются;
- какие интеграции существуют;
- какие вебхуки активны;
- кто их создал;
- какие разрешения у них есть;
- какие системы получают данные из Битрикс24.
Четвёртый уровень — история входов
В актуальном Битрикс24 функция история входов позволяет администраторам просматривать устройства и IP-адреса, с которых сотрудники входили в систему; документация указывает хранение истории входов в течение 180 дней. Доступность функции зависит от тарифа.
Это полезный инструмент не для постоянной слежки за сотрудниками, а для проверки подозрительных случаев и понимания фактической картины доступа.
Если обнаружен неизвестный вход, Битрикс24 также позволяет завершить сеансы на других устройствах.
Пятый уровень — приложения
Необходимо проверить не только наличие приложений, но и их фактическую необходимость.
Особенно подозрительны:
- приложения, которые никто не может объяснить;
- старые интеграции;
- решения бывших подрядчиков;
- приложения с широкими разрешениями;
- интеграции, созданные пользователями, которые уже не работают в компании.
12. Что проверить при передаче Битрикс24 на сопровождение
Передача портала новому интегратору — подходящий момент для «обнуления» старых договорённостей.
Нужно передать не только логин администратора.
Компании стоит зафиксировать:
- Кто является владельцем портала со стороны бизнеса.
- Кто является ответственным администратором.
- Какие подрядчики имеют доступ.
- Какие интеграции существуют.
- Кто является владельцем каждой интеграции.
- Какие права имеет сопровождающая компания.
- На какой срок предоставлен доступ.
- Как доступ будет отозван после окончания договора.
- Где документированы ключевые настройки.
- Кто принимает решение о выдаче новых прав.
Особенно важно не передавать подрядчику единственную административную учётную запись компании.
У компании должен оставаться собственный контроль над порталом.
Если подрядчик использует индивидуальную учётную запись, после завершения работ её можно лишить доступа без необходимости менять общий пароль, который затем придётся распространять среди других сотрудников.
13. Что должен спрашивать собственник у подрядчика
Не обязательно разбираться в технических деталях.
Достаточно задать несколько управленческих вопросов:
«Кто сейчас имеет права администратора?»
Если ответ нельзя быстро получить — уже есть проблема управления.
«Какие интеграции у нас подключены и кто за них отвечает?»
Если никто не знает — необходимо провести инвентаризацию.
«Может ли менеджер выгрузить всю CRM?»
Ответ должен быть основан на конкретной настройке прав, а не на предположении.
«Что происходит с доступом подрядчика после завершения работ?»
Должна существовать понятная процедура отзыва.
«Что произойдёт с интеграциями, если сотрудник, который их создавал, уволится?»
Это особенно важно с учётом поведения вебхуков при увольнении их владельца.
«Когда мы в последний раз пересматривали права пользователей?»
Если ответа нет годами, скорее всего, пора проводить аудит.
14. Безопасность — это не одна настройка
Главная ошибка руководителя — искать одну кнопку, которая называется «Сделать безопасно».
Такой кнопки нет.
Условно безопасность Битрикс24 можно представить как несколько слоёв:
1. Учётные записи
Кто может войти в систему?
2. Аутентификация
Насколько хорошо защищён сам вход?
3. Права
Что пользователь может делать после входа?
4. Данные
Какие CRM, документы и проекты ему доступны?
5. Интеграции
Какие внешние системы имеют доступ к данным?
6. Люди
Что происходит при переводе, увольнении или подключении подрядчика?
7. Контроль
Как компания понимает, что права и доступы всё ещё соответствуют реальной работе?
Даже сильная защита одного слоя не компенсирует провал другого.
Например, двухфакторная аутентификация не исправит ситуацию, если бывшему подрядчику оставили доступ к корпоративному проекту. А идеально настроенная CRM не поможет, если сотрудникам выдали общий пароль администратора.
15. Минимальная управленческая политика
Для большинства компаний не требуется создавать многотомный регламент.
Достаточно установить несколько понятных правил:
Первое. Каждый сотрудник использует индивидуальную учётную запись.
Второе. Администраторские права выдаются только тем, кому они действительно необходимы.
Третье. Права сотрудников соответствуют их должности и рабочим задачам.
Четвёртое. При увольнении доступ к Битрикс24 и связанным интеграциям проверяется как часть стандартной процедуры увольнения.
Пятое. Доступ подрядчиков ограничивается необходимыми проектами и данными и закрывается после окончания работ.
Шестое. Новое приложение или интеграция подключаются после проверки их назначения и запрашиваемых разрешений.
Седьмое. Права пользователей, список администраторов и интеграции периодически пересматриваются.
Восьмое. Компания понимает, кто отвечает за Битрикс24 и кто принимает решения о выдаче доступа.
Это уже существенно лучше, чем попытка «один раз настроить безопасность» при внедрении.
Итог: вопрос безопасности — это вопрос управления
Битрикс24 предоставляет достаточно много встроенных механизмов контроля: роли и права в CRM, управление администраторами, двухфакторную аутентификацию, контроль входов, ограничение доступа к приложениям и инструменты управления внешними пользователями.
Но ни один из этих механизмов не определяет за компанию, кому именно нужно дать доступ и когда его необходимо забрать.
Поэтому зрелый подход выглядит не как:
«Мы настроили Битрикс24, теперь всё безопасно».
А как:
«Мы знаем, кто имеет доступ к нашим данным, зачем он ему нужен, какие полномочия ему предоставлены, какие внешние системы подключены и как мы регулярно проверяем, что всё это по-прежнему соответствует бизнесу».
Это и есть главное различие между безопасной настройкой и безопасной эксплуатацией.
Именно эксплуатация — а не первоначальное внедрение — определяет, насколько долго система останется управляемой.
