Коробка меняет не функциональность, а зону ответственности
Когда компания переходит с облачного Битрикс24 на коробочную версию, руководитель обычно рассуждает так: «Данные будут у нас на сервере — значит, безопаснее». Формально это верно. Практически — вместе с сервером к вам переезжает и вся ответственность за периметр: за то, кто и откуда открывает портал, что происходит при утечке пароля менеджера, кто увидит базу клиентов, если ноутбук сотрудника окажется в чужих руках.
В облаке этот слой закрыт вендором. В коробке его строите вы. И пока в офисе сидят все сотрудники, вопрос почти не стоит — портал живёт во внутренней сети, снаружи он недоступен. Но стоит появиться торговому представителю в Шымкенте, бухгалтеру на удалёнке и подрядчику-маркетологу, как встаёт задача: дать удалённый доступ к Битрикс24 в коробке так, чтобы это не превратилось в дыру в корпоративной сети.
Ниже — разбор того, как эта задача решается на практике: какие есть архитектурные варианты, что даёт сама платформа, где проходит граница между технической мерой и организационным регламентом.
Три архитектуры удалённого доступа: чем они реально отличаются
Выбор здесь не про «безопасно или небезопасно», а про баланс между защитой, удобством и стоимостью поддержки. Вариантов, по сути, три.
Первый — публикация портала в интернет. Сервер получает внешний адрес и доменное имя, доступ закрывается средствами самого приложения: HTTPS, двухфакторная аутентификация, ограничения по адресам, права доступа. Это самый удобный для пользователей сценарий: сотрудник открывает браузер или мобильное приложение из любой точки и работает. Плата за удобство — портал виден снаружи, а значит, к нему будут стучаться сканеры и боты, и защита приложения должна быть выстроена всерьёз.
Второй — закрытый периметр и VPN для CRM. Портал остаётся во внутренней сети без внешнего адреса, а удалённый сотрудник сначала поднимает VPN-туннель до корпоративной сети и только потом открывает Битрикс24. Снаружи портала как бы не существует — сканировать нечего. Это самый строгий вариант, и его выбирают компании с чувствительными данными: медицина, финансы, госконтракты.
У него две цены. Первая — удобство: сотруднику нужно каждый раз подключаться, а мобильная работа усложняется. Вторая — вы переносите точку отказа на VPN-шлюз: если он лёг, портал недоступен всем удалённым, и разбираться нужно быстро. Плюс сам VPN становится критичным объектом: скомпрометированный аккаунт даёт доступ уже не к одному приложению, а ко всей внутренней сети, если сегментация не настроена.
Третий — комбинированная схема. Портал публикуется наружу, но перед ним ставится обратный прокси или шлюз, который берёт на себя терминацию HTTPS, фильтрацию трафика и, при необходимости, дополнительный слой аутентификации. Административная часть при этом остаётся доступной только из внутренней сети или из-под VPN. Для большинства компаний среднего размера это разумный компромисс: рядовые сотрудники работают без лишних действий, а самая опасная часть системы спрятана.
Как выбирать между ними? Практический ориентир такой. Если в компании нет отраслевых требований к изоляции данных, а удалённых сотрудников больше пяти и они работают с мобильных устройств — берите публикацию с полноценной защитой приложения. Если удалённых немного, они технически подкованы и работают с корпоративных ноутбуков, а данные чувствительные — закрытый периметр окупится. Если у вас разные категории пользователей — рядовые менеджеры и администраторы с полными правами — почти наверняка правильным окажется третий вариант, где для разных ролей действуют разные правила входа.
Что даёт сама платформа: модуль «Проактивная защита»
Коробочный Битрикс24 построен на платформе 1С-Битрикс, и вместе с ней вы получаете модуль «Проактивная защита» — набор механизмов, которые в облаке недоступны как настройки, потому что там их конфигурирует вендор. Это тот случай, когда коробка действительно даёт больше контроля, и грех этим не воспользоваться.
По документации 1С-Битрикс модуль включает, в частности: проактивный фильтр (WAF), веб-антивирус, журнал вторжений, контроль целостности файлов, контроль активности, защиту сессий, стоп-лист, одноразовые пароли, аудит безопасности PHP-кода и панель безопасности, где можно выбрать один из уровней — стандартный, высокий или повышенный.
Разберём то, что напрямую влияет на удалённый доступ.
Проактивный фильтр фильтрует входящий трафик и блокирует значительную часть известных атак на веб-приложения. Настраивается он в разделе «Настройки → Проактивная защита → Проактивный фильтр». У фильтра три варианта реакции: он может модифицировать опасные данные (например, разрывать конструкцию запроса), удалять их либо работать в пассивном режиме — только фиксировать. Дополнительно можно включить занесение IP-адреса нарушителя в стоп-лист на заданный период и запись попыток в журнал событий. Для страниц, где фильтр мешает штатной работе, задаются маски исключений.
Контроль активности — механизм защиты от чрезмерно активных пользователей и программных роботов, в том числе от перебора паролей. Для портала, опубликованного в интернет, это обязательная настройка: без неё любой открытый наружу вход рано или поздно получит поток автоматических попыток авторизации.
Защита сессий закрывает сценарий, при котором злоумышленник получает данные уже авторизованной сессии. Модуль умеет хранить данные сессий в собственных таблицах вместо стандартного хранилища и периодически менять идентификатор сессии; период задаётся параметром «Время жизни идентификатора, в секундах». Учтите: и защита сессий, и проактивный фильтр недоступны в редакции «Старт».
Защита административного раздела позволяет ограничить доступ к административной части по IP-адресам. Это ровно тот механизм, который делает возможной комбинированную схему из предыдущего раздела: сам портал открыт, а вход в админку — только из офисной сети или из-под VPN.
Контроль целостности файлов проверяет, не изменялись ли файлы ядра и системных областей продукта. Для портала, открытого наружу, это способ заметить постороннее вмешательство: если в системных файлах появились правки, которых не делал ваш подрядчик, вы узнаете об этом не через полгода, а сразу. Смежная с этим вещь — журнал вторжений, в котором фиксируются события, связанные с потенциальными угрозами; срок хранения записей задаётся настройками главного модуля, и его стоит проверить отдельно — короткий срок хранения обесценивает сам журнал.
Отдельно про панель безопасности и уровни. Соблазн выставить сразу «повышенный» велик, но делать это стоит осознанно: часть механизмов меняет поведение системы и может затронуть кастомные доработки и интеграции, если они писались без оглядки на фильтрацию. Правильный порядок — сначала включить проактивный фильтр в пассивном режиме, посмотреть неделю журнал, добавить маски исключений там, где срабатывания ложные, и только затем переводить фильтр в боевой режим и поднимать уровень. Иначе первым результатом усиления защиты станет сломанная выгрузка в 1С или переставшая работать форма на сайте.
Двухфакторная аутентификация: точка, с которой начинается всё остальное
Если из всей статьи внедрить только один пункт, пусть это будет двухфакторная аутентификация. Причина простая: удалённый доступ — это доступ по паролю, а пароль утекает. Через фишинг, через переиспользование на стороннем сайте, через сохранённую сессию на домашнем компьютере, к которому есть доступ у кого-то ещё.
В Битрикс24 схема двухэтапного входа устроена так: сначала логин и пароль, затем одноразовый код, ограниченный по времени и действующий однократно. Код генерирует приложение — Bitrix24 OTP либо любое другое с поддержкой TOTP.
Порядок настройки по документации: администратор сначала включает двухфакторную аутентификацию для себя (личный профиль → «Безопасность» → «Включить»), а затем может сделать её обязательной для сотрудников через «Настройки → Безопасность → Двухфакторная аутентификация → Обязательно для всех сотрудников». При этом задаётся срок: сотрудники, которые не настроят вход за указанный период, просто не смогут зайти в портал. Сотрудник со своей стороны заходит в профиль, нажимает «Безопасность → Подключить», сканирует QR-код и подтверждает настройку кодом из приложения.
Заранее продумайте два сценария, на которых обычно спотыкаются. Первый — потеря телефона: для этого есть резервные коды в разделе «Безопасность → Резервные коды», и их нужно выдать сотруднику до того, как телефон потерялся. Второй — смена устройства: в том же разделе предусмотрен пункт «У меня поменялся телефон». Если не рассказать про это на старте, служба поддержки получит поток обращений в первую же неделю после включения обязательного режима.
Ограничение доступа по адресам и права: два разных инструмента
Ограничение доступа по IP-адресам — понятный механизм: администратор задаёт, с каких адресов сотрудники могут входить, причём список можно назначать индивидуально, например только для финансового отдела. В облачной версии настройка живёт в разделе «Настройки → Безопасность → Ограничение доступа по IP-адресам», работает не на всех тарифах, и есть важное исключение: администратора портала ограничить по IP нельзя — иначе при смене адреса система осталась бы без управления.
Для удалённых сотрудников этот инструмент работает только при статическом адресе. У человека, работающего из дома или из кафе, адрес динамический, и жёсткий список превратится в ежедневный поток заявок «не могу войти». Отсюда практическое правило: ограничение по адресам применяйте к ролям с высоким уровнем прав и к административной части, а для рядовых удалённых сотрудников делайте ставку на двухфакторную аутентификацию и права доступа.
Права — это второй, не технический, а смысловой контур защиты. В коробочном Битрикс24 доступ выстроен через группы пользователей: «Сотрудники» — самая массовая группа с минимальными правами, далее «Отдел кадров», «Руководство», «Маркетинг», затем «Администратор корпоративного портала» и, наконец, «Администратор системы» с полными правами на портале.
Ключевая ошибка, которую мы видим у клиентов регулярно: удалённому сотруднику на всякий случай выдают права уровнем выше, чем нужно, «чтобы не мешать работать». В результате менеджер, работающий из дома, технически может выгрузить всю базу контактов. Никакой VPN от этого не спасает — доступ-то легальный. Разграничение прав по группам и настройка видимости в CRM — это не бюрократия, а прямое снижение ущерба на случай, если учётная запись всё-таки будет скомпрометирована.
Пример из практики: как это выглядит в работающей компании
Приведём иллюстративный, но типичный для нашей практики сценарий. Дистрибьюторская компания, около 60 человек: офис и склад в Алматы, восемь торговых представителей в регионах, удалённый бухгалтер и подрядчик по маркетингу. Коробочный Битрикс24 изначально стоял во внутренней сети, доступа снаружи не было вообще — представители заносили сделки задним числом, приезжая в офис. CRM отражала реальность с опозданием в несколько дней.
Решение собрали в комбинированной логике. Портал опубликовали наружу под собственным доменом и HTTPS. Административную часть закрыли по IP — офисная сеть плюс адреса двух системных администраторов. Включили проактивный фильтр в режиме удаления опасных данных с занесением нарушителей в стоп-лист, контроль активности и защиту сессий с регулярной сменой идентификатора. Двухфакторную аутентификацию сделали обязательной для всех, дав месяц на настройку и заранее раздав резервные коды.
Отдельно переработали права. Торговые представители получили доступ только к своим сделкам и контактам, без выгрузки списков. Подрядчику-маркетологу открыли ровно один раздел и рабочую группу, без CRM. Бухгалтеру — счета и документы, без клиентской базы целиком.
Что изменилось по сути: данные стали попадать в CRM в день сделки, а не в конце недели, и при этом объём того, что видит каждый удалённый пользователь, стал заметно меньше, чем был до публикации портала. Правильно выстроенный удалённый доступ часто снижает риски по сравнению с исходным состоянием: он заставляет наконец навести порядок в правах.
Пять ошибок, которые мы разбираем чаще всего
Портал опубликовали, защиту не включили. Самый частый сценарий: подрядчик открыл внешний доступ, чтобы сотрудники могли работать из дома, и на этом остановился. Проактивная защита стоит в настройках по умолчанию, двухфакторной аутентификации нет, админка доступна из любой точки мира.
HTTPS «для галочки». Сертификат установлен, но часть внутренних ссылок и интеграций ходит по HTTP, часть страниц отдаётся смешанным содержимым. Для удалённого доступа это критично: сотрудник может подключаться из открытой сети, где трафик перехватывается тривиально.
Общие учётные записи. Одна учётка на отдел, «чтобы не платить за лишние». При удалённой работе это означает, что вы не сможете ни разграничить права, ни понять, кто именно совершил действие, ни отозвать доступ у конкретного человека при увольнении.
Не отзывают доступ при увольнении. В офисе уволенный сотрудник физически перестаёт попадать в сеть. У удалённого сотрудника доступ живёт ровно столько, сколько живёт учётная запись, — и часто это месяцы после последнего рабочего дня.
Нет резервного копирования и плана восстановления. К безопасности доступа это относится напрямую: если что-то пойдёт не так, единственное, что вернёт бизнес в рабочее состояние, — это проверенная резервная копия, с которой кто-то хотя бы раз пробовал восстановиться.
Разбор и устранение таких вещей — обычная часть работы, которую мы ведём в рамках проектов по внедрению и настройке Битрикс24: чаще всего задача звучит как «дайте удалёнку», а по факту начинается с наведения порядка в правах и обновлении платформы.
Регламент, без которого технические меры не держатся
Любая схема доступа деградирует со временем, если её не поддерживать. Минимальный набор правил, который стоит зафиксировать письменно и назначить ответственного:
Матрица доступа. Документ, где для каждой должности прописано, к каким разделам и данным есть доступ. Именно на него опирается администратор, когда заводит нового сотрудника, — иначе права выдаются «как у соседа», и уровень доступа со временем расползается вверх.
Процедура ввода и вывода сотрудника. Что создаётся при найме, что отключается в день увольнения. Отзыв доступа должен быть частью процесса расставания, а не задачей, которую вспоминают через месяц.
Регулярный пересмотр прав. Раз в квартал — сверка фактических прав с матрицей. Сотрудники переходят между отделами, проекты закрываются, подрядчики заканчивают работу, а доступы остаются.
Обновления платформы. Коробка требует, чтобы кто-то следил за выходом обновлений и устанавливал их. Это не косметика: значительная часть публично известных проблем безопасности в любых веб-приложениях закрывается именно обновлением.
Разбор журналов. Журнал вторжений и история входов полезны только тогда, когда их кто-то смотрит. Достаточно короткого регулярного ритуала — просмотр аномалий раз в неделю.
Технические настройки — это разовая работа на несколько дней. Регламент — постоянная. И именно он определяет, будет ли ваша схема доступа рабочей через год или превратится в набор исключений, добавленных «на один раз». Начинать при этом стоит не с выбора между внешней публикацией и VPN, а с двух вещей, которые дают наибольший эффект при минимальных вложениях: обязательная двухфакторная аутентификация и честно выстроенная матрица прав. Всё остальное — архитектура, шлюзы, фильтры — надстраивается поверх и без этих двух пунктов работает вхолостую.
Частые вопросы
Обязательно ли поднимать VPN, чтобы сотрудники работали с коробочным Битрикс24 из дома?
Нет. VPN — один из вариантов, а не единственно возможный. Портал можно опубликовать в интернет и защитить средствами платформы: HTTPS, обязательная двухфакторная аутентификация, проактивный фильтр, контроль активности, защита сессий и ограничение доступа к административной части по IP. VPN выбирают, когда требования к защите данных особенно высоки либо этого требует отраслевое регулирование. При этом VPN сам становится критичным узлом, за которым нужно следить.
Можно ли ограничить вход в портал по IP-адресу для удалённых сотрудников?
Технически да — ограничение задаётся администратором и может назначаться индивидуально для конкретных пользователей. Но у сотрудников, работающих из дома, адрес обычно динамический, поэтому такой список придётся постоянно править. На практике ограничение по адресам разумно применять к административной части и к ролям с высокими правами, а для рядовых удалённых пользователей опираться на двухфакторную аутентификацию и права доступа.
Что делать, если сотрудник потерял телефон с приложением для одноразовых кодов?
В Битрикс24 предусмотрены резервные коды — они находятся в разделе «Безопасность» в профиле пользователя, и выдавать их нужно заранее, при первичной настройке. Для случая замены устройства там же есть отдельный пункт «У меня поменялся телефон». Если резервные коды не были сохранены, восстановление доступа ложится на администратора портала.
Чем защита в коробке принципиально отличается от облака?
Набором доступных вам настроек и распределением ответственности. В облаке инфраструктурный уровень закрывает вендор, вы управляете правами и входом. В коробке вы дополнительно получаете модуль «Проактивная защита» с проактивным фильтром, веб-антивирусом, журналом вторжений, контролем целостности файлов и уровнями безопасности — но и отвечаете за сервер, обновления, сертификаты и резервные копии самостоятельно.
Сколько времени занимает настройка безопасного удалённого доступа?
Зависит от исходного состояния. Если платформа обновлена, а права более-менее в порядке, техническая часть — публикация, сертификат, настройки защиты, включение двухфакторной аутентификации — обычно укладывается в несколько рабочих дней. Дольше всего идёт не техника, а разбор прав: нужно понять, кому что действительно нужно, и согласовать это с руководителями подразделений.