Триада 
Тендеры и лиды
Информация
Около 70-80% сайтов, которые мы делаем, собраны на Битриксе. По интернет-магазинам порядка 60%. Это следствие того, как устроен российский рынок: типовое решение проще лицензировать, проще передавать между подрядчиками, под него легче закрывать регуляторные требования, и сотрудники заказчика уже умеют в нем работать.
Я Сергей Суханов, основатель и гендиректор компании «Триада». Ниже разбор того, что происходит, когда коробочный функционал сталкивается с требованиями информационной безопасности крупного заказчика, и какие приемы помогают выкрутиться, не ломая платформу.
Битрикс — это не продукт, а платформа. На одном ядре сделаны два разных продукта:
«1С-Битрикс: Управление сайтом» —CMS для сайтов и интернет-магазинов
«Битрикс24» — CRM, корпоративный портал, HRM
Ядро общее, но сущности и типовые паттерны различаются. Практический вывод: разработчик, который уверенно делает кастом на «Управлении сайтом», не равен разработчику по «Битрикс24». Мы нанимаем под портал отдельно и проверяем опыт именно по «Битрикс24». Исключения делаем осознанно, когда задача лежит в общей для ядра части и риска нет. Если вы нанимаете подрядчика или собеседуете разработчика, уточняйте продукт, а не платформу. «Опыт Битрикса 5 лет» не говорит ни о чем.
Большая часть рынка — это консультанты, которые умеют настраивать дефолт. Настроить воронки, подключить готовый платежный модуль, собрать каталог — несложно, и для этого есть тысячи компаний.
Разработка начинается там, где нужно:
изменить дефолтное поведение ядра;
написать функциональность, которой в коробке нет;
сделать интеграцию, не предусмотренную модулями;
переработать интерфейс, оставив его работоспособным после обновлений.
К нам такие задачи обычно приходят по остаточному принципу: кто-то взялся, не справился, задача дошла дальше по цепочке. Ниже три ситуации, которые повторяются у разных заказчиков, и то, как мы их обходим.
Классика закрытого контура. Заказчику нужны календари. В Битриксе календари есть из коробки. Но корпоративные календари хранятся на защищенном сервере, доступном по определенному протоколу, и служба информационной безопасности этот протокол не откроет. Не «после согласования», а в принципе.
Первый инстинкт неопытной команды — переписать модуль календарей под свой источник данных. Это тупик: вы получаете форк, который рассыпется на первом же обновлении платформы.
Прием: коннектор-прокладка. Пишется слой, который удовлетворяет требованиям ИБ и отдает данные в том формате, который ждет штатный модуль. Пользователь внутри портала работает с дефолтным календарем и ничего не замечает, служба безопасности не получает открытого наружу протокола, модуль остается обновляемым.
Общее правило, которое экономит годы жизни: не трогайте ядро, подменяйте источник данных. Почти любая задача «коробка умеет не то» решается на уровне слоя между коробкой и внешней системой, а не внутри коробки.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13829 тендеров
проведено за восемь лет работы нашего сайта.
История, которую мы наблюдали со стороны, когда к крупному заказчику заходили конкуренты. В «Битрикс24» есть телефония: клиент звонит на горячую линию, оператор внутри портала снимает трубку. Включается, грубо говоря, двумя галочками. Коллеги искренне не понимали, почему в закрытом контуре это не работает. Для них стало новостью, что телефония ходит через интернет, а интернета там нет.
И вы не придете в службу безопасности со словами «откройте интернет, чтобы звонить». В лучшем случае получите отдельные порты на промежуточных серверах под конкретный список IP, и согласование займет месяцы.
Прием: поменять инициатора соединения. Входящее соединение снаружи в закрытый контур — это то, что безопасность режет почти всегда. Исходящий опрос изнутри контура наружу — то, на что она соглашается существенно чаще, потому что контролируется периметром и не требует открытой точки входа.
То есть вместо «внешний сервис стучится к нам» строится «наша система сама периодически спрашивает внешний сервис». Логика работы сохраняется, модель угроз меняется принципиально. Битрикс так из коробки не умеет, поэтому эту часть приходится переделывать руками. Но на переговорах с ИБ разница между push и pull — часто единственный аргумент, который вообще позволяет согласовать интеграцию. Проверьте этот паттерн на своих застрявших задачах. Интеграции, которые «невозможно согласовать», нередко согласуются после разворота направления вызова.
Повторяю это как мантру, потому что по моим наблюдениям значительная часть людей, принимающих технические решения, об этом просто не думает. Не потому что не знают, а потому что это не их ежедневная работа.
Между «код написан» и «продукт работает в enterprise» лежит слой, который вспоминают последним:
тонкая настройка сервера под конкретную нагрузку;
зависимости от библиотек, часть которых уязвима, а часть входит в списки запрещенных;
мониторинг угроз, то есть поток свежих данных о скомпрометированных решениях, который обновляется если не ежедневно, то еженедельно.
Последний пункт обычно выглядит абстрактным, пока не случается что-то вроде истории 21 октября. В тот день PHP выпустил экстренные патчи сразу к двум критическим уязвимостям ядра — CVE-2026-109618 и CVE-2026-109619, их уже окрестили php2shell. Обе относятся к классу use after free и позволяют неаутентифицированному злоумышленнику выполнить произвольный код на сервере. Затронуты 8.5.x до 8.5.12, 8.4.x до 8.4.27, 8.3.x до 8.3.36 и 8.2.x до 8.2.35, а 8.1 и старше вендор уже не обновляет вовсе. Proof of concept появился в день раскрытия.
Игнорирование угрозы такого уровня открывает доступ к вашим продуктам любому желающему. И сколько бы вы ни согласовывали периметр со службой безопасности, непропатченный интерпретатор обнуляет всю эту работу. Когда вы внедряете коробку в компанию с многомиллиардным оборотом, внутренние процедуры не дадут поставить ее «как в документации». Там свои требования к библиотекам, свои требования к СУБД.
Частый запрос последних лет — PostgreSQL вместо MySQL. Коробочный «Битрикс24» на PostgreSQL вендор выпустил в мае 2024 года, с тех пор картина выровнялась: в документации по миграции списка ограничений уже нет. Но прямого подтверждения, что все модули на всех редакциях работают на PostgreSQL, вендор тоже не публикует. Поэтому перед тем как обещать заказчику сроки, сверьтесь с документацией под вашу конкретную редакцию, а не с опытом двухлетней давности.
И отдельно: Битрикс довольно монолитен, но часть его функциональности — это обращения к отдельным сервисам. Каждый такой сервис порождает отдельный разговор с безопасностью. Инвентаризуйте их на старте, а не на этапе приемки.
То, что мы прогоняем до оценки сроков. Эти вопросы экономят месяцы:
Какие функции продукта требуют выхода наружу? Телефония, почта, подсказки адресов, карты, платежные шлюзы, push-уведомления, лицензионные проверки. Выпишите все до старта.
Какие прокси и файрволы будут защищать эти эндпоинты? Определите это сразу после инвентаризации и составьте четкую схему. Она всегда требуется при согласовании инфраструктуры и при дальнейшей поддержке. Без схемы разговор со службой безопасности не начинается, а когда через год придет новая команда поддержки, восстанавливать логику будет не по чему.
Какие из внешних вызовов можно развернуть на pull вместо push? По каждой внешней интеграции сразу готовьте вариант с опросом изнутри.
Что из нужного заказчику хранится в системах, доступ к которым не дадут? Для каждой — решение через коннектор, а не через правку модуля.
Какая СУБД и какая версия? И сверьтесь с текущей документацией вендора по поддержке.
Какие библиотеки попадут в контур и нет ли их в запрещенных списках? Проверять до разработки.
Как вы узнаете о критической уязвимости в стеке и за сколько накатите патч? Ответ «прочитаем в новостях» означает, что вы узнаете последними.
Что происходит при обновлении платформы? Если ответ «мы не знаем», значит в проекте уже есть правка ядра.
Отдельная школа мысли утверждает, что внутрянка битриксовых продуктов противоречит здравому смыслу, а интерфейсы можно было сделать в разы понятнее. Я слышу этот аргумент регулярно, в том числе от людей, которым доверяю.
Моя позиция: личное эго разработчика — плохой советчик в вопросах бизнеса. Собственного эго это тоже касается. Возьмите 1С. Российская бухгалтерия живет в ней 15-20 лет. Скажете, что интерфейс неудобный, будете правы. Поменяйте в корне подходы и логику, дайте людям принципиально другую систему, и завтра они не смогут работать.
Поэтому спор «удобно или нет» для меня не про эстетику. Вопрос всегда один: во что обойдется переучивание сотни человек и окупится ли оно тем, что вы считаете улучшением. А там, где дефолтного функционала действительно не хватает, работает подход из трех приемов выше: прокладка вместо форка, разворот направления вызова вместо боя с ИБ, инвентаризация внешних зависимостей до старта.
