Облако или коробочная версия Битрикс24: безопасность и отказоустойчивость для бизнеса с оборотом от 1 млрд рублей

Для бизнеса с оборотом от 1 млрд рублей облачный Битрикс24 выбирают, когда важны быстрый запуск и передача инфраструктурной эксплуатации поставщику; коробочную версию — когда нужны закрытый контур, глубокие интеграции с 1С и ERP, собственные правила обновлений, подключение корпоративных средств ИБ и управляемые RTO/RPO. Коробка не становится безопаснее автоматически: за её отказоустойчивость, резервное копирование, обновления и восстановление отвечает компания или её подрядчик. Облако не снимает с компании ответственность за права доступа, MFA, настройки процессов, данные и внешние интеграции.

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

Битрикс24 — корпоративная платформа для CRM, задач, коммуникаций, документов, проектов и автоматизации процессов. Компания может использовать её как облачный SaaS-сервис или развернуть коробочную редакцию в собственном ЦОД, на выделенной IaaS-инфраструктуре либо в private cloud.

Короткий ответ: когда выбирать облако, а когда коробку

Выбирайте облачный Битрикс24, если

• 🔹Компания использует стандартные CRM-процессы, задачи, проекты и коммуникации.
• 🔹Интеграции укладываются в штатные приложения, REST API и внешние сервисы.
• 🔹Нет требования к закрытому сетевому контуру.
• 🔹Не требуется собственный PHP-код или глубокая модификация платформы.
• 🔹Нет команды, готовой поддерживать серверы, СУБД, мониторинг, резервирование и аварийное восстановление.
• 🔹Важны предсказуемые операционные расходы, быстрый запуск и минимальная инфраструктурная нагрузка.

Рассматривайте коробочную версию Битрикс24, если

• 🔹Нужна интеграция с 1С, ERP, DWH, СЭД, HRM, внутренними API и корпоративной шиной данных.
• 🔹Требуется подключить Active Directory, LDAP, SSO, SIEM, DLP, EDR, WAF, NGFW или VPN.
• 🔹Битрикс24 должен работать в сегментированном или закрытом контуре.
• 🔹Нужны собственные правила обновлений, тестирования и отката релизов.
• 🔹Требуются нестандартные модули, доработка бизнес-логики или доступ к исходному коду.
• 🔹Есть собственная ИТ-команда либо SLA с интегратором и инфраструктурным провайдером.
• 🔹Компания обязана учитывать требования к сертифицированному ПО и проектировать защищённую информационную систему.

Коробочная Enterprise-версия Битрикс24 позиционируется для крупных компаний и государственных структур, поддерживает размещение в ЦОД заказчика или частном облаке и открытый код.

В чём разница между облаком и коробкой Битрикс24

Облачная версия Битрикс24 — это SaaS-модель: компания получает готовый сервис и начинает работу без установки серверов. Коробочная версия — self-hosted/on-premise-модель: программный продукт устанавливается в инфраструктуре организации или на выделенных ресурсах.

Разница важна не только для ИТ-отдела. Она определяет, кто отвечает за доступность системы, бэкапы, обновления, сеть, защиту от атак, производительность и восстановление после аварии.

Облако: поставщик отвечает за платформу

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

У клиента остаются обязанности:

• 🔹Настраивать роли и права доступа.
• 🔹Подключать MFA и контролировать пароли.
• 🔹Отключать доступ уволенным и переведённым сотрудникам.
• 🔹Управлять приложениями, вебхуками, API-ключами и интеграциями.
• 🔹Контролировать корректность роботов, бизнес-процессов и автоматизаций.
• 🔹Определять, какие данные допустимо выгружать и кто имеет к ним доступ.

Коробка: компания получает контроль и эксплуатационную ответственность

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

Для коробки требуется заранее определить:

1. 1. Где будет размещён production-контур: собственный ЦОД, IaaS или private cloud.
2. 2. Кто обслуживает ОС, веб-серверы, базу данных и сам Битрикс24.
3. 3. Кто отвечает за мониторинг, инциденты и эскалации 24/7.
4. 4. Как устроены резервные копии и в каких пределах восстанавливаются данные.
5. 5. Кто тестирует обновления и утверждает изменения.
6. 6. Как организован DRP — план аварийного восстановления.

Контроль без эксплуатации — не преимущество, а источник технического долга.

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

Безопасность Битрикс24 складывается из трёх уровней:

1. 1. Защита продукта и платформы: механизмы авторизации, права, шифрование, журналирование, обновления.
2. 2. Защита инфраструктуры: сегментация сети, WAF, VPN, SIEM, DLP, EDR, резервирование, мониторинг.
3. 3. Управление процессами: роли, регламенты, контроль доступа, обучение сотрудников, реакция на инциденты.

Ни облачная, ни коробочная модель не обеспечивают все три уровня автоматически.

Облачный Битрикс24: что должен сделать клиент

Для облачного контура минимальная программа безопасности должна включать:

• 🔹Двухфакторную аутентификацию (MFA) для всех сотрудников и особенно администраторов.
• 🔹Ролевую модель RBAC: доступ к CRM, диску, задачам и бизнес-процессам только по необходимости.
• 🔹Регулярный пересмотр пользователей и прав.
• 🔹Немедленное отключение доступов при увольнении или смене должности.
• 🔹Инвентаризацию подключённых приложений, вебхуков и API-интеграций.
• 🔹Ограничение прав интеграционных пользователей.
• 🔹Контроль выгрузок CRM, файлов и отчётов.
• 🔹План действий при компрометации учётной записи.

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

Коробочный Битрикс24: какие средства можно включить в корпоративный контур

Коробочная версия позволяет встроить портал в существующую ИБ-архитектуру:

Правило 3-2-1 означает: хранить не менее трёх копий данных, использовать минимум два разных типа носителей и держать хотя бы одну копию отдельно от production-контура.

Что не следует утверждать

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

• 🔹«Коробка полностью безопасна».
• 🔹«Облако не соответствует 152-ФЗ».
• 🔹«Сертификат ФСТЭК автоматически подтверждает соответствие всей системы».
• 🔹«Бэкапы гарантируют восстановление».
• 🔹«Собственный сервер исключает риск утечки данных».

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

152-ФЗ, ФСТЭК, КИИ и ГИС: что нужно учитывать

Вопрос соответствия требованиям регуляторов нельзя решить только выбором формата Битрикс24.

Сертификация продукта и соответствие системы — не одно и то же

Коробочная редакция «Энтерпрайз» имеет сертификат ФСТЭК России № 4750, выданный 13 декабря 2023 года и действующий до 13 декабря 2028 года. Официальная страница Битрикс24 указывает, что сертификация ФСТЭК не применима к облачной версии.

Это важно для проектов, в которых требуется использовать сертифицированное программное обеспечение. Но сертификат продукта не означает, что конкретная CRM, корпоративный портал или интеграционный контур автоматически соответствует требованиям для ИСПДн, КИИ или ГИС.

Для оценки соответствия обычно требуются:

1. 1. Определение состава обрабатываемых данных.
2. 2. Классификация или категорирование системы, если оно применимо.
3. 3. Модель угроз.
4. 4. Проектирование технических и организационных мер защиты.
5. 5. Настройка и документирование средств защиты.
6. 6. Проверка реализации требований.
7. 7. Аттестация или иная процедура оценки — если она обязательна для конкретного сценария.

Если проект затрагивает ИСПДн, КИИ, ГИС или внутренние политики ИБ, сначала проводится архитектурный и комплаенс-анализ, а затем выбирается вариант размещения Битрикс24.

Отказоустойчивость Битрикс24: как оценивать доступность

Для крупного бизнеса недостаточно понять, «работает ли портал». Нужно знать, может ли компания продолжать продажи, обслуживание клиентов, согласования, работу филиалов и обмен с ERP после аварии.

Термины, которые нужно согласовать до внедрения

Пример: если отдел продаж может работать без CRM максимум 2 часа, а компания готова потерять не более 15 минут изменений по сделкам, то целевые параметры будут такими:

• 🔹RTO: 2 часа.
• 🔹RPO: 15 минут.

Эти показатели определяют частоту резервного копирования, требования к репликации, резервной площадке, мониторингу и SLA с подрядчиками.

Что влияет на доступность облачного Битрикс24

В облачной модели поставщик отвечает за серверную инфраструктуру платформы. Но доступность бизнес-процесса зависит и от компонентов заказчика:

• 🔹Интернет-каналов офисов и филиалов.
• 🔹Интеграции с 1С, ERP и DWH.
• 🔹IP-телефонии.
• 🔹Почтовых сервисов.
• 🔹Внешних API.
• 🔹Корректности вебхуков и роботов.
• 🔹Доступности учётных записей сотрудников.
• 🔹Настроенного процесса работы при инциденте.

Поэтому нужно отдельно проверять не только SLA сервиса, но и сценарии: что будет, если недоступна телефония, остановилась интеграция с ERP или сотрудник не может пройти MFA.

Что требуется для отказоустойчивой коробочной версии

Один сервер с установленным Битрикс24 не является HA-архитектурой. Для высокой доступности корпоративного портала обычно проектируют следующие элементы:

• 🔹Два и более узла приложений.
• 🔹Балансировщик нагрузки.
• 🔹Отказоустойчивый кластер или репликацию СУБД.
• 🔹Раздельное хранилище файлов и резервных копий.
• 🔹Репликацию критичных данных.
• 🔹Мониторинг инфраструктуры, приложений, базы данных, дисков, API и интеграций.
• 🔹Централизованное логирование и алертинг.
• 🔹Раздельные среды development, test и production.
• 🔹Регламент обновлений и технического отката.
• 🔹Нагрузочное тестирование.
• 🔹DR-площадку или альтернативный сценарий восстановления.
• 🔹Регулярную проверку восстановления по утверждённому DRP.

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

Почему резервная копия не равна восстановлению

Резервная копия полезна только тогда, когда компания доказала, что может восстановить из неё работу системы.

Проверка резервного копирования должна дать измеримые ответы:

1. 1. Где хранятся копии и отделены ли они от production-контура?
2. 2. Кто имеет доступ к резервам и ключам шифрования?
3. 3. Сколько времени занимает восстановление?
4. 4. Какие данные будут потеряны в рамках RPO?
5. 5. Работают ли после восстановления CRM, файлы, роботы и интеграции?
6. 6. Есть ли инструкция, контакты и порядок эскалации?
7. 7. Фиксируется ли результат каждого теста восстановления?

Бэкап считается рабочим только после успешного тестового восстановления в пределах согласованного RTO и с допустимым RPO.

Интеграции с 1С и ERP: ключевой фактор выбора

Битрикс24 часто становится частью корпоративного ИТ-ландшафта, а не самостоятельной CRM. В этом случае решение зависит от того, как платформа взаимодействует с 1С, ERP, DWH, телефонией, СЭД, HRM, BI-системами и корпоративным каталогом пользователей.

Когда облачного Битрикс24 достаточно

Облачная модель обычно подходит, если:

• 🔹Используются типовые интеграции и приложения.
• 🔹Достаточно REST API, вебхуков и внешних коннекторов.
• 🔹Нет внутреннего API, закрытого от интернета.
• 🔹Нет требований к модификации исходного кода.
• 🔹Интеграции не требуют сложной очереди сообщений или собственной ESB.
• 🔹Бизнес готов адаптировать часть процессов под стандартную сервисную модель.

Когда коробочная версия Битрикс24 оправдана

Коробка чаще требуется при следующих условиях:

• 🔹Двусторонний обмен с 1С, 1С:ERP, SAP, корпоративной ERP или DWH.
• 🔹Связка с внутренними сервисами, недоступными из публичного интернета.
• 🔹Интеграция с Active Directory, LDAP, SSO, IAM, SIEM.
• 🔹Сложные пакетные обработки и большие объёмы обмена.
• 🔹Собственные PHP-модули, агентские задачи, доработки ядра или расширенная бизнес-логика.
• 🔹Требования к отдельному тестовому контуру.
• 🔹Необходимость контролировать время релизов и откат изменений.

ALPE Consulting внедряет и настраивает Битрикс24 для продаж, поддержки, управления проектами и автоматизации процессов. Для проектов с 1С, ERP и корпоративными системами правильная последовательность — сначала карта интеграций и критичных потоков данных, затем выбор модели размещения, а не наоборот.

TCO Битрикс24: считайте не лицензию, а стоимость владения

TCO — Total Cost of Ownership, совокупная стоимость владения. Для крупного бизнеса её нужно считать минимум на горизонте 3–5 лет.

TCO облачной версии

В стоимость облачного Битрикс24 входят:

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

TCO коробочной версии

Для коробки в расчёт дополнительно включают:

• 🔹Лицензию и обновления.
• 🔹Предпроектное обследование и проектирование архитектуры.
• 🔹Серверы, IaaS или private cloud.
• 🔹Резервные мощности и DR-площадку.
• 🔹Администрирование, DevOps и мониторинг.
• 🔹Средства ИБ.
• 🔹Бэкапы и тестовое восстановление.
• 🔹Нагрузочные испытания.
• 🔹Сопровождение и регламентные работы.
• 🔹Стоимость инцидентов и простоев.

TCO = лицензии + внедрение + инфраструктура + сопровождение + ИБ + развитие + стоимость риска простоя.

Не существует корректного правила «коробка выгоднее после определённого числа пользователей». На TCO влияют глубина интеграций, число филиалов, объём данных, требования к RTO/RPO, длительность проекта, корпоративные ИБ-стандарты и стоимость часа простоя.

Для финансового сравнения инфраструктурных сценариев используйте отдельную методику, позволяющую рассчитать TCO облачного и коробочного Битрикс24 на горизонте 3–5 лет.

Матрица выбора: облако, private cloud или корпоративный контур

Если большинство ответов находится в средней колонке, не следует автоматически покупать коробку. Правильный следующий шаг — предпроектный аудит: определить критичные процессы, RTO, RPO, интеграции, модель доступа, требования ИБ и TCO.

Если окончательное решение пока не принято, проверьте практические признаки того, что облачного Битрикс24 уже недостаточно.

Три типовых сценария

Сценарий 1. Облачный Битрикс24 для стандартизированных процессов

Подходит компании, которая использует CRM, задачи, проекты, коммуникации и типовые автоматизации. Интеграции не требуют закрытого контура, а собственная команда не готова постоянно поддерживать HA-инфраструктуру.

Преимущество: быстрый старт и снижение нагрузки на инфраструктурную команду.

Ограничение: нужно заранее проверить границы кастомизации и критичные внешние зависимости.

Сценарий 2. Коробочный Битрикс24 в private cloud

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

Преимущество: компромисс между сервисной инфраструктурой и контролируемым контуром.

Ограничение: SLA, RACI, резервирование и ответственность между заказчиком, облачным провайдером и интегратором должны быть закреплены документально.

Сценарий 3. Коробочный Битрикс24 в корпоративном контуре

Подходит организации с закрытой инфраструктурой, строгими политиками ИБ, внутренними IAM/SSO/SIEM-системами и критичными интеграциями.

Преимущество: максимальная управляемость архитектуры.

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

Чек-лист: 15 вопросов перед выбором Битрикс24

1. 1. Какие процессы нельзя останавливать больше чем на 1–2 часа?
2. 2. Какой RTO согласован для CRM, документов, согласований и интеграций?
3. 3. Какой RPO допустим для сделок, задач, обращений и файлов?
4. 4. Какие системы должны обмениваться данными с Битрикс24?
5. 5 Требуется ли интеграция с 1С, ERP, DWH, СЭД, HRM?
6. 6. Нужны ли AD/LDAP, SSO, VPN, SIEM, DLP, EDR или WAF?
7. 7. Требуется ли закрытый сетевой контур?
8. 8. Нужны ли собственные модули и доработка исходного кода?
9. 9. Кто отвечает за обновления ОС, СУБД и Битрикс24?
10. 10. Есть ли тестовый контур и процедура отката релизов?
11. 11. Где хранятся резервные копии?
12. 12. Когда последний раз выполнялось тестовое восстановление?
13. 13. Сколько стоит один час простоя продаж, сервиса или согласований?
14. 14. Как выглядит TCO решения на горизонте 3–5 лет?
15. 15. Кто является владельцем архитектуры и эксплуатационной модели?

Помимо технического владельца компании нужен бизнес-руководитель, отвечающий за цели и приоритеты платформы. Подробнее — в материале о том, кто отвечает за Битрикс24 в компании.

Когда нужна консультация

Архитектурная консультация нужна, если компания:

• 🔹Планирует внедрение Битрикс24 для нескольких подразделений, филиалов или юридических лиц.
• 🔹Сравнивает облако, коробку в private cloud и on-premise-размещение.
• 🔹Планирует миграцию из облачного Битрикс24 в коробочную версию.
• 🔹Интегрирует CRM с 1С, ERP, DWH, телефонией, AD/LDAP или СЭД.
• 🔹Получила требования от службы информационной безопасности.
• 🔹Не определила RTO/RPO, DRP, SLA и распределение ответственности.
• 🔹Хочет рассчитать TCO на горизонте 3–5 лет.

АЛЬПЕ Консалтинг внедряет и настраивает Битрикс24 для продаж, поддержки, управления проектами и автоматизации бизнес-процессов. На консультации имеет смысл разбирать не «какую редакцию купить», а критичные процессы, интеграции, требования ИБ, стоимость простоя и эксплуатационную модель.

Краткие выводы

• 🔹Облако или коробка Битрикс24 выбираются по модели ответственности, а не по стереотипу о безопасности.
• 🔹Коробочная версия оправдана при закрытом контуре, сложных интеграциях, высоких ИБ-требованиях, кастомизации и готовности поддерживать инфраструктуру.
• 🔹Облачная версия подходит крупному бизнесу, если стандартная сервисная модель отвечает требованиям процессов, интеграций и управления рисками.
• 🔹RTO, RPO, DRP, SLA и стоимость простоя нужно определить до покупки лицензии и проектирования инфраструктуры.
• 🔹Резервная копия не подтверждает отказоустойчивость: это делает только регулярное успешное тестовое восстановление.