Безопасность данных в Bitrix24 для финансовых компаний

Финансовые компании — банки, МФО, страховые брокеры, лизинговые операторы — работают с персональными данными, платёжной информацией и коммерческой тайной одновременно. Утечка из CRM для них означает не только штрафы по 152-ФЗ, но и потерю лицензии, исков клиентов и репутационных последствий. Поэтому вопрос «а насколько безопасен Битрикс24» возникает на первой же встрече по внедрению.

Короткий ответ: сам по себе Битрикс24 даёт достаточный набор инструментов защиты, но «из коробки» он настроен на удобство, а не на паранойю. Разберём, что именно нужно донастроить, где ограничения облачной версии и когда финансовой компании стоит смотреть в сторону коробки.

Облако или коробка: главный архитектурный выбор

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

Облачный Битрикс24 размещается на серверах вендора (дата-центры в России, что важно для 152-ФЗ). Вендор отвечает за инфраструктурную защиту: шифрование трафика по TLS, резервное копирование, защиту от DDoS. Вы отвечаете за то, что происходит внутри портала: права доступа, пароли сотрудников, интеграции.

Коробочная версия разворачивается на ваших серверах или в вашем частном облаке. Полный контроль над данными, возможность изолировать CRM в закрытом контуре без выхода в интернет, интеграция с корпоративными SIEM и DLP-системами. Обратная сторона — ответственность за патчи, бэкапы и защиту сервера ложится на вашу ИТ-службу или подрядчика.

На практике: если у компании есть требования службы безопасности уровня «данные не покидают наш контур» — выбор предрешён в пользу коробки. Если таких требований нет, а команда до 100 человек — облако закрывает задачу при правильной настройке. Подробнее о различиях редакций мы писали в разделе о Битрикс24.

Разграничение прав доступа: фундамент защиты

80% инцидентов с данными в CRM — это не хакеры, а сотрудники с избыточными правами. Менеджер, который видит базу всех клиентов компании, может выгрузить её в Excel за две минуты. В финансовой сфере это критично: клиентская база МФО или страхового брокера — готовый актив для конкурентов и мошенников.

Что настраиваем в первую очередь:

• Роли в CRM (раздел «CRM → Настройки → Права доступа»). Менеджер видит только свои сделки и контакты, руководитель отдела — своего отдела, доступ ко всей базе — у 2-3 человек максимум.
• Запрет экспорта. Галочка «Экспорт» в правах роли — снимаем у всех, кому он не нужен по должности. Выгрузка клиентской базы должна быть событием, а не рутиной.
• Ограничение по воронкам. Если ипотечный отдел и отдел автокредитования работают в одном портале — каждый видит только свою воронку.
• Права на удаление. Удаление сделок и контактов — только у администраторов. «Случайно» стёртая история взаимодействия с клиентом — частый способ замести следы махинаций.
• Скрытие реквизитов. Банковские реквизиты и паспортные данные клиентов показываем только тем ролям, которым они нужны для работы.

Типичная ошибка: выдать всем роль «Менеджер» с настройками по умолчанию, где включён просмотр всей базы «для удобства поиска дублей». Дубли искать можно и через права «чтение без деталей» — настройка занимает лишний час, но закрывает главный канал утечек.

Аутентификация и контроль входа

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

1. Двухфакторная аутентификация — обязательна для всех, без исключений. Включается в настройках безопасности портала, работает через OTP-приложение или SMS.
2. Политика паролей: минимальная длина, сложность, срок действия. В коробке настраивается гибко, в облаке — базовые требования есть по умолчанию.
3. Ограничение по IP (коробка): доступ к порталу только из офисной сети или через VPN. Для банков это часто обязательное требование СБ.
4. Процедура увольнения: блокировка аккаунта в день увольнения, переназначение сделок руководителю, проверка истории действий за последние 2 недели. Заведите чек-лист и встройте его в процесс — разовые «не забудь отключить» не работают.
5. Журнал действий. В коробочной версии доступен детальный аудит: кто, когда и что смотрел, менял, выгружал. Раз в квартал его должен кто-то читать, иначе журнал — мёртвая функция.

Интеграции и внешние каналы: слабое звено

CRM сама по себе может быть защищена отлично, но данные утекают через подключённые сервисы. В финансовых компаниях типичный портал связан с телефонией, почтой, WhatsApp/Telegram-коннекторами, скоринговыми сервисами, сайтом с формами заявок.

На что обратить внимание:

• Мессенджер-коннекторы. Многие сторонние интеграции WhatsApp проксируют переписку через свои серверы — персональные данные клиентов проходят через третью сторону. Проверяйте, где обрабатываются данные, и требуйте от поставщика коннектора условия обработки ПДн.
• REST API и вебхуки. Каждый токен доступа — это потенциальная дыра. Правило: отдельный токен на каждую интеграцию, минимально необходимые скоупы, ревизия активных токенов раз в квартал. Токены уволенных разработчиков — удалять сразу.
• Почта. Письма клиентов с реквизитами и сканами документов попадают в CRM автоматически. Убедитесь, что доступ к таким письмам в карточке сделки ограничен теми же правами, что и к самой сделке.
• Формы на сайте. Заявки на кредит собирают паспортные данные — передача в CRM должна идти по защищённому каналу, а на сайте нужно согласие на обработку ПДн.

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

Соответствие 152-ФЗ и требованиям регуляторов

Битрикс24 — это инструмент, а не готовое соответствие закону. Оператором персональных данных остаётся ваша компания, и отвечаете перед Роскомнадзором тоже вы. Что нужно сделать организационно и технически:

• Включить CRM в перечень информационных систем ПДн и в модель угроз.
• Заключить с вендором (для облака) соглашение о поручении обработки ПДн.
• Определить уровень защищённости системы и подтвердить выполнение мер из приказа ФСТЭК №21 — для коробки это делается на уровне вашей инфраструктуры.
• Настроить в CRM механизмы работы с согласиями: где хранится согласие клиента, как отзывается, кто отвечает за удаление данных по запросу субъекта.
• Для компаний под надзором ЦБ — учесть требования к защите информации и критической инфраструктуре. Здесь, как правило, без коробочной версии и закрытого контура не обойтись.

Важный нюанс: облачный Битрикс24 хранит данные в РФ, что закрывает требование о локализации. Но «данные в России» и «система соответствует 152-ФЗ» — разные вещи. Соответствие обеспечивается комплексом мер, и настройка CRM — только его часть.

Резервное копирование и восстановление

В облаке вендор делает бэкапы сам, но восстановление «как было вчера в 14:00» по вашему запросу — не гарантированная услуга, а на старших тарифах доступен функционал резервного копирования портала. В коробке бэкапы — полностью ваша зона ответственности.

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

1. Полный бэкап ежедневно, инкрементальные — каждые 3-4 часа.
2. Хранение копий на отдельном сервере или в другом ДЦ — бэкап рядом с боевой базой не защищает ни от чего.
3. Тестовое восстановление раз в квартал. Бэкап, который ни разу не восстанавливали, считается отсутствующим.
4. Шифрование архивов — в бэкапе та же клиентская база, и его утечка равносильна утечке из CRM.

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

Можно ли использовать облачный Битрикс24, если мы МФО?

Можно, если нет внутренних требований СБ о размещении данных только в собственном контуре. Облако хранит данные в РФ, поддерживает 2FA и разграничение прав. Но при росте компании и ужесточении требований регулятора будьте готовы к миграции на коробку — это отдельный проект на 1-3 месяца.

Как запретить менеджерам выгружать клиентскую базу?

В настройках прав доступа CRM снимите у роли право на экспорт, ограничьте просмотр чужих сделок и контактов, отключите доступ к API для рядовых пользователей. Полностью исключить утечку (фото экрана никто не отменял) технически невозможно, но массовую выгрузку — вполне.

Что делать с аккаунтами уволенных сотрудников?

Блокировать в день увольнения (не удалять — иначе потеряется история), переназначить ответственным по сделкам руководителя, отозвать API-токены и проверить журнал действий за последние недели. Встройте это в регламент увольнения вместе с возвратом пропуска.

Нужен ли отдельный сервер для коробочной версии?

Да, желательно выделенный сервер или изолированная ВМ с регламентированным доступом. Совмещение CRM с другими сервисами на одной машине расширяет поверхность атаки и усложняет расследование инцидентов.

Настройка безопасности Битрикс24 под требования финансовой компании — это не пара галочек в админке, а проект: модель прав, регламенты, интеграционный контур, соответствие 152-ФЗ. Команда D7 внедряла Битрикс24 для компаний с повышенными требованиями к защите данных и поможет выстроить систему, которая пройдёт проверку и службы безопасности, и регулятора. Оставьте заявку на консультацию — разберём вашу ситуацию и предложим вариант архитектуры.