Облачная или локальная CRM: приватность и контроль над данными

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

Как устроены обе модели

Облачная CRM (SaaS)

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

Договор с провайдером фиксирует SLA — обычно доступность 99,9%, то есть до 8,7 часа простоя в год. Провайдер также определяет, в какой юрисдикции стоят серверы и каких субпроцессоров он привлекает: хостинг, рассылки, аналитику. Клиент на этот перечень почти не влияет, максимум — получает уведомление об изменениях.

Локальная CRM (on-premise)

Компания покупает лицензию (разовую или годовую), устанавливает систему на собственный сервер или арендованный выделенный хост и обслуживает её сама. Физический доступ к дискам, конфигурация СУБД, расписание бэкапов, сетевой периметр — всё под контролем ИТ-отдела. Никакой третьей стороны между компанией и её данными нет, если не считать разработчика ПО, который поставляет обновления.

Обратная сторона — операционная нагрузка. Нужен администратор, который следит за патчами, местом на дисках, репликацией и журналами. Пропущенное обновление безопасности в on-premise — прямой риск: уязвимость останется открытой, пока её не закроют вручную, тогда как в облаке патч раскатывается на всех клиентов централизованно, часто в день выхода.

Приватность данных: где проходят реальные различия

Юрисдикция и локализация

Для российских компаний действует 152-ФЗ: персональные данные граждан РФ при сборе должны записываться в базы на территории России. Европейский GDPR требует контролировать трансграничную передачу и заключать с провайдером DPA — соглашение об обработке данных. Облачный вендор с дата-центрами в нужной стране закрывает формальное требование, но фактический доступ к данным остаётся у его сотрудников: инженеров поддержки, администраторов СУБД. On-premise снимает этот вопрос полностью — круг лиц с доступом определяет сама компания.

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

Шифрование и ключи

Серьёзные облачные CRM шифруют данные при передаче (TLS 1.2/1.3) и при хранении (AES-256). Слабое место — ключи: обычно ими управляет провайдер, значит, технически он способен расшифровать содержимое. Схема BYOK (bring your own key), когда ключи хранятся на стороне клиента в аппаратном модуле HSM, встречается в корпоративных тарифах, но повышает цену в разы и поддерживается не всеми системами.

В on-premise шифрование настраивает сама компания: прозрачное шифрование СУБД, шифрование дисков через LUKS или BitLocker, собственный центр сертификации для внутреннего TLS. Ключи не покидают периметр. Правда, и ошибки конфигурации — незашифрованный бэкап на сетевой шаре, самоподписанный сертификат с истёкшим сроком — тоже целиком на совести собственного администратора.

Инциденты и утечки

Статистика утечек не даёт однозначного победителя. Облачные провайдеры атакуют чаще, потому что взлом одной платформы открывает данные тысяч компаний, но и защищаются они сильнее: круглосуточный SOC, bug bounty, регулярные пентесты, сертификация ISO 27001 и SOC 2 Type II. Типичная утечка из on-premise выглядит иначе: уволенный сотрудник с неотозванным доступом, RDP-порт, открытый в интернет, сервер без патчей два года. Малый бизнес без выделенного безопасника защищает локальную систему хуже, чем это делает средний облачный вендор.

Контроль: что получаете и что отдаёте

Контроль — это не только «где лежат данные». Он складывается из нескольких плоскостей.

Доступы и аутентификация. On-premise интегрируется с Active Directory или LDAP напрямую, политика паролей и MFA задаётся доменными средствами, доступ извне закрывается VPN. Облако предлагает SSO через SAML или OAuth, но перечень настроек ограничен тем, что реализовал вендор. Если нужна экзотика — вход только с корпоративных устройств по клиентским сертификатам — облачный тариф может этого просто не уметь.

Обновления. В SaaS новые версии приходят принудительно. Интерфейс меняется без согласования, автоматизации иногда ломаются после релиза, откатиться нельзя. В on-premise компания сама решает, когда обновляться: сначала тестовый контур, регрессионные проверки интеграций, потом продакшен. Цена такой свободы — отставание от актуальной версии и накопление технического долга.

Кастомизация и интеграции. Локальная версия открывает доступ к исходному коду (если лицензия это разрешает), к базе данных напрямую, к серверным скриптам. Можно написать интеграцию с самописной учётной системой на уровне SQL, что в облаке недостижимо — там только REST API с лимитами на число запросов, например 2 запроса в секунду на пользователя. Для компании с десятком нестандартных интеграций это аргумент решающего веса.

Выход и переносимость. Прекращение подписки в облаке означает экспорт данных в CSV или через API за ограниченный срок, после чего база удаляется. История изменений, файлы, настройки автоматизаций при экспорте частично теряются. Локальная база остаётся у компании навсегда — даже если вендор уйдёт с рынка, система продолжит работать без обновлений.

Сравнение по ключевым критериям

Критерий	Облачная CRM	On-premise CRM
Физическое хранение данных	Дата-центр провайдера	Серверы компании
Ответственность за безопасность	Разделённая: платформа — вендор, доступы — клиент	Полностью на компании
Запуск	Дни, иногда часы	Недели: закупка, установка, настройка
Обновления	Автоматические, принудительные	Ручные, по графику компании
Доступ извне офиса	Из коробки	Требует VPN или публикации через reverse proxy
Кастомизация	В рамках API и настроек вендора	До уровня кода и базы данных
Соответствие 152-ФЗ / GDPR	Зависит от юрисдикции дата-центра и DPA	Контролируется напрямую
Зависимость от вендора	Высокая: тарифы, лимиты, закрытие сервиса	Низкая: система работает автономно
Требования к ИТ-штату	Минимальные	Администратор обязателен

Стоимость владения: считаем на горизонте трёх лет

Сравнивать цену подписки с ценой лицензии напрямую нельзя — у моделей разная структура затрат. Возьмём условную компанию на 50 пользователей.

Статья затрат	Облако, 3 года	On-premise, 3 года
Лицензии / подписка	~1 500 ₽/польз./мес → 2,7 млн ₽	Разовая лицензия ~600 тыс. ₽ + продление обновлений ~200 тыс. ₽/год → 1,2 млн ₽
Сервер и инфраструктура	0 ₽	Сервер, ИБП, резервное хранилище → 400–700 тыс. ₽
Администрирование	0 ₽ (входит в подписку)	0,3–0,5 ставки администратора → 1,5–2,5 млн ₽
Внедрение и настройка	150–400 тыс. ₽	300–800 тыс. ₽
Итого (порядок)	~3–3,2 млн ₽	~3,4–5,2 млн ₽

Цифры ориентировочные, но пропорция типична: до 100–150 пользователей облако дешевле за счёт нулевых затрат на железо и администрирование. Перелом наступает на больших командах — подписка растёт линейно с числом пользователей, а стоимость сервера и админа почти не меняется, обслуживает он 50 человек или 500. Компании на 300+ рабочих мест on-premise часто обходится в полтора-два раза дешевле на пятилетнем горизонте.

Скрытые статьи тоже распределяются по-разному. В облаке это доплаты за расширение диска, за дополнительные API-запросы, за корпоративные функции вроде журналов аудита, которые вендор выносит в старшие тарифы. В on-premise — простой во время сбоя (без дежурной смены восстановление может занять сутки), замена вышедшего из строя оборудования, миграция при апгрейде СУБД.

Практический сценарий: клиника выбирает CRM

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

1. Классификация данных. Юрист и главврач составляют перечень: ФИО, телефоны, диагнозы, история посещений. Диагнозы — специальная категория по 152-ФЗ, уровень защищённости ИСПДн выше базового.
2. Проверка облачного варианта. У провайдера запрашивают: юрисдикцию дата-центров, аттестат соответствия требованиям ФСТЭК для нужного уровня защищённости, список субпроцессоров, шаблон поручения на обработку данных. Два из трёх рассмотренных SaaS-вендоров аттестата не имеют — отпадают.
3. Оценка on-premise. Локальная версия закрывает требования регулятора, но в штате нет администратора. Найм — плюс 1,2 млн ₽ в год к бюджету, аутсорс — риск допуска подрядчика к медицинским данным, что требует отдельного договора и контроля.
4. Компромисс. Клиника выбирает гибрид: локальная CRM в аттестованном сегменте хранит карточки пациентов и диагнозы, облачный сервис — только маркетинг и обезличенные заявки с сайта. Синхронизация идёт в одну сторону, из облака внутрь, по идентификатору заявки без медицинских полей.
5. Закрепление процедур. Прописываются регламенты: бэкап локальной базы каждые 4 часа с хранением копии в сейфе, ежеквартальный пересмотр прав доступа, отзыв учётных записей в день увольнения сотрудника.

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

Когда on-premise оправдан, а когда избыточен

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

• регулятор или отраслевой стандарт прямо требует хранить данные в контролируемом контуре (банковская тайна, гостайна, медицина, оборонные контракты);
• в компании больше 150–200 пользователей CRM, и подписка на горизонте пяти лет дороже собственной инфраструктуры;
• есть ИТ-отдел, способный закрывать патчи в течение недели после выхода и держать работающее резервное копирование с проверкой восстановления;
• бизнес-процессы требуют доработок на уровне кода или прямых запросов к базе, которые облачный API не покрывает;
• интернет-канал в офисе нестабилен, а работа отдела продаж не должна останавливаться при его падении.

Если ни одно условие не выполняется, on-premise превращается в дорогую игрушку: компания платит за контроль, которым не пользуется, и берёт на себя риски, с которыми не справляется. Стартапу на 10 человек локальный сервер не добавит приватности — он добавит единственную точку отказа под столом у офис-менеджера.

Краевой случай — компании под санкционными рисками. Уход зарубежного SaaS-вендора с рынка означает потерю системы за 30–90 дней уведомления. Локальная лицензия в этой ситуации продолжает работать бессрочно, пусть и без обновлений. После 2022 года этот сценарий перестал быть теоретическим, и часть российских компаний мигрировала в on-premise именно по этой причине, а не из-за требований к данным.

FAQs

Облачная CRM соответствует 152-ФЗ?

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

Можно ли переехать из облака в on-premise позже?

У систем с двумя редакциями (та же Битрикс24 или ряд западных платформ) миграция предусмотрена: выгружается резервная копия портала и разворачивается на своём сервере. Теряются обычно интеграции, завязанные на облачную инфраструктуру, и часть маркетинговых инструментов. У чисто облачных CRM переезд означает экспорт данных и внедрение другой системы с нуля — закладывайте 2–4 месяца.

Кто отвечает за утечку данных из облачной CRM?

Перед субъектами персональных данных и регулятором отвечает оператор — то есть компания-клиент, а не провайдер. С провайдера можно взыскать убытки в рамках договора, если утечка произошла по его вине, но штраф Роскомнадзора и репутационный ущерб лягут на компанию. Поэтому DPA и раздел договора об ответственности стоит читать до подписания, а не после инцидента.

Насколько безопасно хранить клиентскую базу у SaaS-провайдера?

У крупного провайдера с сертификацией ISO 27001, круглосуточным мониторингом и bug bounty технический уровень защиты выше, чем у среднего малого бизнеса с одним системным администратором. Главные остаточные риски облака — доступ персонала вендора к данным и запросы госорганов в его юрисдикции. Если эти риски для вас неприемлемы, безопасность как таковая — не аргумент против облака; аргумент — контроль.

Что происходит с данными после отказа от облачной подписки?

Провайдер даёт окно на выгрузку — обычно от 30 до 90 дней, затем данные удаляются, включая резервные копии (сроки удаления бэкапов пропишите в договоре отдельно). Выгрузка через CSV теряет связи между сущностями и файлы; полноценный экспорт делается через API и требует технической подготовки. Планируйте выход из сервиса на этапе входа в него.

Достаточно ли VPN, чтобы безопасно открыть on-premise CRM для удалённых сотрудников?

VPN закрывает канал, но не заменяет остальную гигиену: MFA на входе в систему, ограничение прав по ролям, журналирование действий, своевременные патчи самой CRM. Публиковать локальную CRM в интернет напрямую, без VPN или хотя бы reverse proxy с MFA, нельзя — сканеры находят открытые панели входа за часы, а подбор паролей начинается в тот же день.

Заключение

Облако и on-premise решают одну задачу разными компромиссами. SaaS покупает компании скорость запуска и снимает операционную нагрузку ценой зависимости от вендора и разделённого контроля над данными. Локальное развёртывание отдаёт полный контроль и предсказуемость, но требует зрелого ИТ-отдела и окупается только на масштабе или под давлением регулятора. Решение стоит принимать от классификации данных: сначала определите, какие сведения вы обрабатываете и что о них говорит закон, затем считайте стоимость владения на 3–5 лет с учётом персонала и скрытых доплат, и только потом сравнивайте интерфейсы и функции. Гибридная схема — чувствительные данные внутри периметра, массовые процессы в облаке — часто оказывается практичнее чистых вариантов и позволяет не выбирать между приватностью и удобством.