Безопасность Битрикс под нагрузкой: что ломается первым

Интернет-магазин на 1С-Битрикс может начать отдавать 502 не из-за одной большой атаки, а из-за нескольких обычных запросов: посетители одновременно пересчитывают корзины, агенты запускают тяжёлые задания, а форма загрузки принимает файлы без жёстких ограничений. В результате заканчиваются PHP-воркеры, место на диске или соединения с базой. Ниже — разбор для 1С-Битрикс: Управление сайтом ветки 24.x с актуальными обновлениями безопасности; совместимость PHP и базы данных нужно сверять с требованиями конкретного релиза.

Что в Битрикс ломается первым

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

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

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

Первый слой: PHP-воркеры и длинные запросы

Битрикс выполняет PHP-код в рабочих процессах PHP-FPM или через другой настроенный обработчик. Число воркеров конечно. Если каждый из них занят пересчётом каталога, созданием отчёта или внешним HTTP-запросом, новые пользователи будут ждать даже для получения простой страницы.

Что проверять на ревью

• В обработчиках событий нет синхронных запросов к сторонним API без короткого тайм-аута.
• Формирование выгрузок, PDF, архивов и больших отчётов не выполняется в обычном пользовательском запросе.
• Ограничения PHP согласованы с веб-сервером: тайм-аут прокси не должен быть меньше времени, необходимого легитимной операции.
• Логи показывают URI, время ответа, код статуса и размер ответа, но не записывают пароли, токены и персональные данные целиком.

Проверяйте не только среднее время ответа. Для продакшена важнее 95-й и 99-й перцентили: именно они показывают, сколько ждёт небольшая доля пользователей во время пика. Если один тип POST-запроса стабильно держит воркер десятки секунд, добавление ещё одного воркера лишь отсрочит проблему.

Сессии, корзина и блокировки

Корзина, избранное и авторизация делают запросы пользователя не полностью статeless. В Битрикс это особенно заметно на страницах, где одновременно работают AJAX-обновление корзины, пересчёт скидок и оформление заказа.

Типичная ошибка — считать любой AJAX-запрос дешёвым. Если он открывает сессию, меняет её и обращается к каталогу, несколько таких запросов могут выстроиться в очередь. На фронтенде это выглядит как «кнопка зависла», а на сервере — как занятые PHP-воркеры.

Как отличить проблему сессий от медленного SQL

1. Сравните запросы одного авторизованного пользователя и анонимного посетителя. Если задержка появляется только с авторизацией, смотрите сессию, корзину и обработчики событий.
2. Проверьте параллельные запросы браузера в DevTools и их время ожидания до получения ответа. Длинное ожидание при маленьком времени выполнения на сервере указывает на очередь или блокировку.
3. Сопоставьте эти данные с логами PHP-FPM и базы. Если SQL выполняется быстро, а запрос всё равно долго ждёт, ищите блокировку сессии или другой общий ресурс.

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

Агенты: тихий источник пиков

Агенты Битрикс могут выполняться во время пользовательского запроса или через cron — в зависимости от конфигурации и режима запуска. Первый вариант удобен на небольшом сайте, но под нагрузкой превращает случайный визит в запуск фоновой работы.

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

• Соберите список самых долгих агентов и укажите для каждого владельца, периодичность и максимальный объём одной порции.
• Запускайте предсказуемые фоновые работы отдельным планировщиком, если это поддерживается вашей конфигурацией и документацией редакции.
• Не допускайте параллельного запуска одной и той же задачи: нужен признак выполнения или другой механизм взаимоисключения.
• Разделяйте время выполнения агента и время ожидания внешнего сервиса. Это разные причины деградации и разные способы исправления.

Загрузка файлов: безопасность против удобства

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

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

Отдельно контролируйте суммарную квоту. Ограничение «один файл не больше 10 МБ» не защищает от тысячи таких файлов: место на диске закончится раньше, чем сработает большинство средств мониторинга.

Кеш: ускоряет чтение, но не лечит запись

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

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

База данных и соединения

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

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

Где подход ломается

Нельзя свести безопасность Битрикс под нагрузкой к установке защитного модуля или прокси-фильтра. WAF может отсечь часть вредных запросов, но не исправит агент, который каждую минуту читает весь каталог. Кеш не спасёт оформление заказа. Увеличение PHP-воркеров не поможет, если база уже упёрлась в лимит соединений.

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

Что делать дальше

Составьте карту ресурсов: PHP-воркеры, база, Redis или другое хранилище сессий, диск, внешние API и фоновые задания. Для каждого ресурса запишите допустимый предел и сигнал, после которого начинается деградация. Затем проведите тест с постепенным ростом параллельности и сохраните профиль запросов.

В продакшене первым делом смотрите 99-й перцентиль ответа, количество 502/504, очередь PHP-FPM, свободное место, число соединений с базой, длительность агентов и ошибки загрузки файлов. Следующий практический шаг — разобрать один самый дорогой сценарий, а не менять настройки сервера вслепую.