Защита сайта и CRM на Битрикс: обеспечение безопасности данных

Главная
Блог
Защита сайта и CRM на Битрикс: обеспечение безопасности данных

Зачем вообще разбираться в битрикс безопасность данных, если «всё уже работает»

Фраза «у нас всё безопасно, ведь сайт открывается, CRM работает» звучит в большинстве компаний одинаково. Под ней обычно скрывается набор допущений: хостинг «как у всех», пароль администратора в стиле Name123, редкие обновления и уверенность, что «Битрикс же сам всё защищает». Это иллюзия контроля, а не реальная политика безопасности.

В проектах на 1С‑Битрикс и Битрикс24 хранятся данные, которые слишком дорогие, чтобы полагаться на удачу:

персональные данные клиентов: ФИО, телефоны, e‑mail, адреса доставки, иногда паспортные данные и ИНН;
связка заказов и людей: история покупок, методы оплаты, статусы, данные о возвратах;
коммерческая информация: закупочные цены, маржа, индивидуальные скидки для партнёров;
история общения в CRM: переговоры, комментарии менеджеров, договорённости с ЛПР;
данные сотрудников: номера телефонов, рабочая почта, иногда – доступ к корпоративным сервисам.

Утечки и атаки по этим системам бьют не только штрафами по 152‑ФЗ и требованиям регуляторов. Последствия куда болезненнее в операционном смысле:

остановка продаж: магазин или облачная CRM просто недоступны, колл‑центр завален звонками «ничего не работает»;
потеря доверия: новости о сливе базы клиентов распространяются быстрее любой рекламы;
шантаж: злоумышленники требуют выкуп за базу или за восстановление доступа;
подмена контента и скрытые редиректы: пользователи попадают на фишинговые страницы, а вы теряете репутацию и SEO;
массовые рассылки со взломанного сервера: домен и IP попадают в чёрные списки.

Проекты на Битрикс и безопасность данных — отдельная тема не случайно. Это, как правило, связка:

сайта, CRM и интеграций с телефонией, 1С, платёжными сервисами, мобильными приложениями;
типичных доработок «на коленке» от разных подрядчиков за годы существования проекта;
долгоживущей системы без регулярной технической поддержки, где никто не отвечает за общую картину рисков.

Разбираться в этих вопросах необходимо не только айтишникам. Статья особенно полезна:

владельцам интернет‑магазинов и сервисов на 1С‑Битрикс и в облачной Битрикс24;
руководителям отделов продаж и маркетинга, которые ежедневно работают с базой клиентов;
тем, кто заказывает доработки у специалистов и хочет уметь задавать жёсткие вопросы о безопасности, а не слышать «там всё защищено».

Реальные угрозы для проектов на Битрикс: от банальных вирусов до «тихих» утечек

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

Типичные сценарии атак на проекты 1С‑Битрикс и безопасность данных в них:

Подбор паролей к админке и CRM. Брутфорс по /bitrix/admin/, панелям управления Битрикс24 и почтовым ящикам, связанным с CRM. Слабый пароль администратора — самая частая точка входа.
Эксплуатация устаревших модулей. Старые версии ядра и компонентов содержат закрытые уязвимости, о которых можно узнать из публичных статей и форумов. Если обновления не ставились годами, взлом — вопрос времени.
Внедрение вредоносного кода через доработки. Сторонний модуль из маркетплейса, самописный компонент, не прошедший код‑ревью, или кривой деплой через FTP — удобный способ встроить «левый» PHP‑код или JS‑скрипт.
XSS и SQL‑инъекции в самописных формах. Компоненты, которые принимали «любое» значение из запроса и подставляли его в запрос к базе или в вывод HTML без фильтрации.

Чем опасны незаметные взломы, когда внешне «всё работает»:

из базы тихо выгружают персональные данные клиентов, но продажи продолжаются, и утечку замечают только, когда клиенты начинают жаловаться на подозрительные звонки;
в шаблон оплаты встраивается JS‑код, который отправляет данные карт на сторонний сервер (даже если платёжная форма не полностью у вас, можно подменить сумму, назначение, реквизиты);
в шаблоны писем и документов подмешиваются другие реквизиты, кошельки, QR‑коды — компания просто недополучает деньги;
на сервере создаются дополнительные «чёрные» учётки и бекдоры, а администратор этого не видит.

Отдельный пласт угроз — CRM и Битрикс24, где сосредоточен центр принятия решений по продажам:

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

Короткие реальные кейсы:

маркетолог создал временный доступ подрядчику «на время акции». Логин с правами администратора CRM никому не мешал, пока через полгода с него не выгрузили всю базу клиентов, включая историю сделок и маржу;
на хостинге с общим аккаунтом FTP на одном из соседних сайтов обнаружили вирус. Через те же ключи атакующие получили доступ к вашему коду, внедрили скрипты, которые отправляли содержимое базы на внешний сервер.

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

Базовые инструменты безопасности в Битрикс, которые часто вообще не трогают

Парадокс: 1С‑Битрикс и Битрикс24 уже содержат мощные средства защиты, но в большинстве проектов они либо отключены, либо включены «по умолчанию» без осознанных настроек. Разберём ключевые инструменты, которые стоит хотя бы проверить.

Модуль «Проактивная защита» позволяет:

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

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

Веб‑антивирус в Битрикс эффективен как дополнительный уровень, но не как единственное решение. Он:

отлавливает известные сигнатуры вредоносного кода в HTML, JS и PHP;
может временно очищать вывод страниц, если в шаблон попал посторонний код;
помогает обнаружить массовую подмену файлов после взлома.

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

Контроль целостности файлов — один из недооцененных инструментов. Его стоит:

запустить после чистой установки и основных доработок, чтобы зафиксировать «эталонное» состояние;
регулярно проверять, особенно после крупных изменений, обновлений или работы подрядчиков;
обращать внимание не только на «подозрительные» файлы, но и на новые PHP‑файлы в неожиданных директориях: /upload/, /bitrix/cache/, корень сайта.

Журнал безопасности (и лог авторизации) обеспечивает прозрачность. В нём полезно отслеживать:

многочисленные неуспешные попытки входа с одного IP или по одному логину;
входы в админку в необычное время и с новых стран/регионов;
изменения прав пользователей и создание новых администраторов;
массовое удаление или экспорт данных.

Отдельный блок — настройки авторизации и сессий:

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

Двухфакторная аутентификация в Битрикс и безопасность Битрикс24 резко повышают уровень защиты учёток. Минимально она должна быть обязательной для:

администраторов системы и серверов;
пользователей с полным доступом к CRM и отчётам по марже;
ответственных за финансы и настройки интеграций с банком, 1С, телефонией.

Чтобы сотрудники не саботировали 2FA, стоит:

использовать удобное мобильное приложение‑аутентификатор, а не только SMS на телефон;
объяснить, что это защита не «от своих», а от захвата их же аккаунта;
заранее продумать процедуру восстановления доступа при утрате телефона.

Ограничение доступа к административной части:

смена стандартного URL входа иногда полезна против массовых автоматизированных атак, но это скорее дополнительный слой, чем основа защиты;
фильтрация по IP или подсетям для критичных аккаунтов (только офис, только VPN) даёт реальный выигрыш по безопасности;
запрет входа администраторам с незащищённых устройств и общих компьютеров.

Что можно проверить уже сейчас без разработчика:

включён ли модуль «Проактивная защита» и веб‑антивирус;
какая политика паролей действует для пользователей, есть ли минимальные требования;
используется ли HTTPS на всех страницах с формами и авторизацией;
есть ли в списке пользователей учётки, о которых никто не помнит, с правами администратора.

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

Инфраструктура, хостинг и HTTPS: когда всё ломается не из-за Битрикс

Даже идеально настроенный Битрикс не спасёт, если под ним стоит слабое окружение: общий FTP для десятков сайтов, устаревший PHP, бэкапы в той же папке, что и продакшен. Безопасность — это связка приложения и инфраструктуры.

Выбор хостинга влияет на безопасность не меньше, чем качество кода:

специализированный хостинг под 1С‑Битрикс обычно обеспечивает рекомендованные версии PHP, MySQL, корректные права доступа к файлам и отдельные учётки для разных проектов;
дешёвый shared‑хостинг с «одним FTP на всё» создаёт риск, что взлом одного сайта приведёт к компрометации остальных;
отсутствие регулярных обновлений ОС и серверных программ повышает шансы успешной атаки по известным уязвимостям;
серверы, расположенные в неподконтрольных юрисдикциях, усложняют выполнение требований по хранению персональных данных.

HTTPS и корректно настроенные сертификаты — не косметика. Это базовый уровень защиты канала между браузером и сервером. Особенно важно:

использовать HTTPS для всего домена, а не только страницы логина или оплаты;
запретить смешанный контент (когда часть файлов подгружается по HTTP) — иначе шифрование теряет смысл;
включить актуальные протоколы (TLS 1.2 и выше), отключить заведомо небезопасные;
автоматизировать продление сертификатов, чтобы сайт не «падал» каждый год в один и тот же день.

Права доступа к файлам и серверам — ещё один слой защиты. Безопасная схема подразумевает:

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

Резервные копии в контексте инфраструктуры — отдельный вопрос безопасности хранения:

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

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

Какие версии PHP, MySQL и ОС используются, как часто ставятся обновления безопасности?
Разделены ли аккаунты на сервере по проектам, есть ли другие сайты в той же учётке, что и наш?
Где хранятся резервные копии: на том же сервере или в отдельном хранилище/дата‑центре?
Как организован доступ разработчиков к серверам: по логину/паролю, по SSH‑ключам, через VPN?
Есть ли регламент реакции в случае инцидента (подозрение на взлом, вирусы, утечки)?

Чёткие ответы на эти вопросы позволяют понять, насколько инфраструктура соответствует задачам безопасности и стоит ли менять хостинг или усиливать администрирование.

CRM и Битрикс24: доступы, роли и контроль действий сотрудников

Большинство утечек ценнейших данных происходит не через фронт сайта, а из CRM. Безопасность Битрикс24 и коробочной CRM‑модуля 1С‑Битрикс — это в первую очередь управление доступом сотрудников и партнёров.

Наиболее чувствительные данные в CRM:

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

Ролевая модель доступа должна быть построена так, чтобы:

менеджер видел только «свои» лиды и сделки или сегмент по отделу, а не всю базу;
партнёрам и фрилансерам выдавались ограниченные права без доступа к полной истории и отчётам;
количество администраторов CRM было минимальным, а роль «администратор» назначалась осознанно и с фиксацией в регламенте.

Управление жизненным циклом доступа — ключ к предотвращению утечек при смене команды:

в день увольнения сотрудника его доступ к CRM, почте и другим сервисам должен быть отключён, а не «как‑нибудь потом»;
временные доступы подрядчикам стоит ограничивать по дате и уровню прав, а не выдавать «как себе»;
нужно учитывать скрытые точки входа: интеграции с телефонией, ботами, внешними приложениями. Забытые токены доступа — частая причина неожиданной активности.

Контроль действий пользователей в CRM и Битрикс24 включает:

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

Организационные меры часто дают больший эффект, чем технические:

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

Ответьте себе на простой вопрос: кто сейчас может зайти в вашу CRM или Битрикс24 под логином администратора? Если точного списка нет — это уже сигнал к пересмотру системы доступа и усилению контроля.

Как понять, что ваш Битрикс-проект небезопасен: чек‑лист для владельца

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

Обновлялось ли ядро Битрикс и модули за последние 3–6 месяцев?
Если нет — высока вероятность известных уязвимостей и ошибок, уже описанных в публичных источниках.
Включён ли HTTPS на всём сайте, а не только на одной странице оплаты?
Если формы логина, регистрации, заявки и личные кабинеты открываются по HTTP — данные пользователей не защищены при передаче.
Есть ли в CRM и Битрикс24 настроенные роли и ограничения доступа, или «все всё видят»?
Если любой менеджер видит всю базу и отчёты по марже — риск утечки изнутри очень высок.
Включены ли стандартные механизмы защиты (проактивная защита, веб‑антивирус, журнал безопасности)?
Если нет — вы добровольно отказываетесь от части готового функционала защиты.
Используется ли двухфакторная аутентификация хотя бы для администраторов и ключевых пользователей?
Отсутствие 2FA резко упрощает захват учётки при утечке пароля.
Есть ли регламент по отключению доступов у уволенных сотрудников и партнёров?
Если учётки «висят» месяцами после ухода людей — доступ к данным сохраняется у неизвестного круга лиц.
Где и как хранятся бэкапы: на том же сервере или в отдельном защищённом хранилище?
Бэкап в соседней папке на сервере, где произошёл взлом или шифрование, почти бесполезен.
Кто из внешних подрядчиков сейчас имеет доступ к админке, CRM, серверу?
Если точного списка нет и доступы не ревизуются — вы не управляете этим риском.
Проводилась ли когда‑нибудь проверка сайта на вирусы и посторонний код, включая директорию /upload/?
Если ни разу — есть шанс, что вредонос уже живёт в системе незаметно.
Есть ли ответственный за безопасность Битрикс‑проекта (не обязательно отдельная должность, но зафиксированная роль)?
Отсутствие ответственного означает, что никто не контролирует регулярные задачи: обновления, проверки, ревизию прав.

Если у вас 3–4 и более ответов «нет», стоит провести ревизию безопасности: как минимум обсудить ситуацию с текущими разработчиками, а лучше — заказать независимый аудит. Критичными являются вопросы про HTTPS, обновления, роли в CRM, 2FA и бэкапы.

Процессы вместо «разовой настройки»: обновления, бэкапы, аудит, обучение

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

Обновления — основа живой системы безопасности:

ядро Битрикс и модули стоит обновлять не реже раза в 1–2 месяца для активных проектов и хотя бы раз в квартал для небольших сайтов;
жизнь годами без обновлений приводит к накоплению уязвимостей и несовместимостей с новыми версиями PHP, сервера, внешних API;
чтобы минимизировать риск «обновились — всё сломалось», нужно иметь тестовый стенд, процедуру отката и понятный регламент: кто, когда и как ставит обновления.

Бэкапы и их проверка:

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

Ответственность за бэкапы должна быть закреплена письменно: кто именно (хостер, администратор, подрядчик) отвечает за создание, хранение, проверку и срок хранения копий. Это можно и нужно прописывать в договоре на поддержку и разработку.

Регулярный аудит безопасности:

внутренними силами можно раз в 1–3 месяца проходить чек‑лист, проверять журналы безопасности, ревизовать список пользователей и их ролей;
внешний аудит имеет смысл заказывать при смене подрядчика, перед запуском крупной рекламной кампании, интеграцией новых критичных сервисов или после подозрительного инцидента;
по итогам аудита стоит сформировать план изменений с приоритетами: что необходимо сделать немедленно, а что — в ближайшие месяцы.

Обучение сотрудников — самый недорогой и при этом один из самых эффективных инструментов:

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

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

Когда нужна помощь разработчиков и интеграторов, и как не ошибиться с выбором

Часть задач по безопасности вполне решаема силами компании: ревизия доступов, включение 2FA, базовый чек‑лист. Но есть зоны, куда без опытной команды лучше не лезть, чтобы не создать новые уязвимости.

Не стоит пытаться самостоятельно закрывать следующие вопросы:

настройка серверной инфраструктуры, прав доступа к файлам и серверам, организация VPN и SSH‑ключей;
аудит и рефакторинг самописных модулей, интеграций с платёжными и внешними сервисами, мобильными и веб‑приложениями;
построение сложных ролевых моделей в CRM и Битрикс24, интеграция с телефонией, 1С, другими системами уровня предприятия.

Пора привлекать специалистов, если:

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

Критерии выбора команды по Битрикс и безопасности данных:

опыт не только в разработке сайтов, но и в комплексных проектах: сайт + CRM + интеграции + мобильное приложение;
готовность начать с аудита и предложить поэтапный план усиления безопасности, а не «сразу всё переписать»;
прозрачность: фиксация, какие настройки выполняются, где будут храниться бэкапы, какие логины создаются, какие изменения вносятся в код;
умение говорить на языке бизнеса: объяснять риски и решения без нагнетания страха и лишней техно‑терминологии.

Наша команда занимается разработкой и поддержкой мобильных приложений, веб‑сервисов, CRM‑систем, игр, сайтов и интернет‑магазинов, включая проекты на 1С‑Битрикс и Битрикс24. Мы помогаем:

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

Если по чек‑листу из этой статьи у вас нашлись «дыры», а уверенности в уровне защиты сайта или CRM нет, имеет смысл начать с консультации. Мы разберём текущую ситуацию, предложим конкретные шаги и поможем выстроить систему безопасности так, чтобы она эффективно работала, а не мешала бизнесу расти.