Облачная защита или модуль на сайте: чем отличаются подходы

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

Подход первый: облако перед сайтом

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

Что это даёт.

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

Отпечаток TLS. Тот, кто терминирует защищённое соединение, видит особенности самого подключения: набор шифров, порядок расширений. По ним браузер отличается от библиотеки ещё до первого HTTP-заголовка. Модулю внутри сайта эти данные недоступны.

Работу с любым сайтом. Неважно, на чём он сделан и есть ли к нему доступ.

Чего это стоит.

Управления доменом. Серверы имён переводятся на провайдера. Обратный переезд — снова смена DNS и ожидание распространения.

Всего трафика. Через посредника проходит содержимое форм, корзин и личных кабинетов.

Точки отказа. Провайдер недоступен — недоступен и сайт. Это не гипотеза: крупные сбои случаются у всех.

Подход второй: модуль внутри сайта

Трафик идёт напрямую на ваш сервер, а решение принимает код внутри самого сайта. Он собирает признаки визита, спрашивает внешний сервис и применяет ответ.

Что это даёт.

Ничего не меняется в маршруте. DNS остаётся вашим, запросы идут как шли. Отключение — удаление одной строки.

Нет точки отказа. Если сервис решений недоступен, модуль пропускает посетителя. Сайт работает.

Видно поведение на самом сайте. Что человек делал на странице, двигал ли мышью, как заполнял форму. На уровне облака это доступно только через отдельный скрипт.

Решение принимается раньше отрисовки. При правильном подключении бот не доходит ни до CMS, ни до базы.

Чего это стоит.

Не защищает от заливания. Миллион запросов в секунду дойдёт до сервера. Это отдельная задача, и решается она на уровне хостинга или сетевого фильтра.

Нужен доступ к коду сайта. Для конструкторов остаётся только JS-скрипт с его ограничениями.

Нет отпечатка TLS.

Как выбирать

Смотрите на то, что болит.

Заливают трафиком до отказа — нужна фильтрация на сетевом уровне. Модуль тут бессилен.

Парсят каталог, спамят формы, скликивают рекламу, накручивают поведенческие факторы — это осмысленный автоматический трафик, а не заливание. Здесь модуль проще, дешевле и безопаснее по последствиям отказа.

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

На что смотреть в любом случае

Что произойдёт при недоступности защиты. Правильный ответ — сайт продолжает работать. Если ответ другой, вы поменяли одну проблему на другую, причём новая случится в самый неудачный момент.

Можно ли отключить защиту, не зависимо от самого сервиса. Кнопка в чужом кабинете при аварии этого кабинета бесполезна.

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