Види WAF: хмарний, апаратний, серверний — що обрати

Коли зрозуміло, що таке WAF і навіщо він потрібен, постає практичне питання: який саме обрати. За способом розгортання Web Application Firewall (WAF) має три різновиди — хмарний, апаратний і серверний. Різниця не лише в ціні: змінюється те, хто відповідає за оновлення правил, де обробляється трафік і що станеться, коли фільтр вийде з ладу.

Хмарний WAF

Працює як послуга. Трафік до сайту спрямовують через платформу постачальника: вона перевіряє запити й передає далі лише ті, що пройшли фільтр.

Плюси: підключення за години, жодного власного обладнання, правила оновлює постачальник, зазвичай у комплекті — захист від об'ємних атак і кешування статики.
Мінуси: залежність від зовнішньої платформи; запити ваших клієнтів обробляються на її боці, а це питання довіри й вимог до персональних даних.
Кому підходить: більшості сайтів і бізнесів, які хочуть результат без адміністрування заліза.

Оскільки обробка йде в чужій інфраструктурі, тут доречні звичайні вимоги до безпеки хмарних сервісів (ISO/IEC 27017): умови обробки даних, журнали, реакція на інциденти.

Апаратний пристрій

Окремий пристрій у власній інфраструктурі — зазвичай поруч із рештою обладнання в дата-центрі.

Плюси: висока продуктивність, повний контроль, трафік не залишає периметр; пропускну здатність рахують заздалегідь, тож пікові навантаження прогнозовані.
Мінуси: висока вартість, потрібні фахівці й обслуговування; масштабувати складніше, ніж хмару.
Кому підходить: великим організаціям із власною інфраструктурою та суворими вимогами до того, де саме обробляються дані.

Серверний WAF: сервер робить усю роботу сам

Програмний модуль, який ставлять безпосередньо на вебсервер — там, де вже працює сам застосунок.

Плюси: нижча вартість, гнучке налаштування, тісна інтеграція з кодом, повний доступ до журналів.
Мінуси: споживає ресурси тієї самої машини, що обслуговує відвідувачів; потребує кваліфікованого супроводу; за наплаву запитів фільтр і застосунок конкурують за процесор.
Кому підходить: командам із власними адміністраторами, які хочуть контроль без окремого заліза.

Не лише для публічних сайтів

Фільтр запитів асоціюють із зовнішнім сайтом, але внутрішні системи — портали, панелі керування, кабінети підрядників — так само вразливі до атак на застосунок. Різниця в тому, що для них хмарна модель зазвичай недоречна: віддавати внутрішній трафік зовнішній платформі мало хто готовий. Тут природніше виглядають апаратний пристрій або модуль поруч із застосунком.

Порівняння: коротка шпаргалка

Критерій	Хмарний	Апаратний	Серверний
Швидкість запуску	години	тижні	дні
Хто оновлює правила	постачальник	ваша команда	ваша команда
Де обробляється трафік	у постачальника	у вас	на вашому вузлі
Вплив на ресурси сайту	немає	немає	є
Захист від об'ємних атак	зазвичай так	ні	ні
Вартість входу	низька	висока	низька

Питання, які забувають поставити

Тип розгортання — лише перше рішення. Далі йдуть речі, від яких залежить, чи працюватиме фільтр насправді:

Що буде при збої. Якщо фільтр перестане відповідати, трафік піде повз нього (сайт живий, але без перевірки) чи зупиниться зовсім (безпечно, але сайт лежить)? Обидва варіанти прийнятні — головне обрати свідомо.
Хто розшифровує HTTPS. Фільтр мусить бачити вміст запиту, тож у хмарної моделі доведеться довірити платформі сертифікат або дозволити їй завершувати захищене з'єднання на своєму боці.
Хто пише правила під ваш застосунок. Готові набори закривають масові атаки, решту доводиться описувати самим — і це не разова робота.
Чи побачите ви справжню адресу відвідувача. Коли перед сайтом стоїть посередник, у журналах може лишатися його адреса замість клієнтської — це ламає й аналітику, і блокування за IP.
Як швидко постачальник реагує на нові вразливості. Між появою масового прийому атак і оновленням готових правил минає час, і в різних платформ він відрізняється в рази.
Куди йдуть журнали й чи можна віддати їх у систему моніторингу.

Гібридні схеми

Три типи — не взаємовиключні. Поширена комбінація: хмарний фільтр на вході (він же гасить об'ємні атаки й роздає статику) плюс легкий модуль поруч із застосунком, який знає його логіку й ловить те, що зовнішня платформа пропустила через незнання специфіки.

Друга комбінація: апаратний пристрій на периметрі для внутрішніх систем і хмарна платформа для публічного сайту. Так контроль лишається там, де він критичний, а типові масові атаки відсікаються ще на підході.

Скільки це коштує насправді

Ціна входу оманлива. Порахуйте три складники:

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

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

Місце WAF у мережах компанії

Фільтр запитів не існує окремо: він стає ще однією ланкою на шляху до застосунку. Типова послідовність — мережевий екран на периметрі, далі балансувальник навантаження, потім фільтр запитів і лише тоді сам застосунок.

Кілька практичних наслідків:

Не дублюйте фільтри. Два рішення в ланцюжку означають подвійні хибні спрацювання й подвійний час розбору інциденту.
Врахуйте CDN. Якщо статику вже роздає CDN, хмарний фільтр часто вбудований у ту саму платформу — окреме рішення може виявитися зайвим.
Перевірте, що сайт недоступний в обхід. Коли фільтр стоїть перед доменом, а сервер відповідає на пряме звернення за адресою, зловмисник просто обійде захист. Прямий доступ мають закрити правила периметрового фільтра.

Якщо доведеться змінювати тип

Правила не переносяться між рішеннями автоматично: у кожного постачальника власний синтаксис і власна логіка винятків. Тому перехід — це завжди повторне налаштування, а не імпорт файлу.

Звідси проста порада: тримайте власні правила задокументованими окремо від інтерфейсу постачальника — які маршрути ви захищаєте, яких значень чекаєте в полях, де свідомо зробили винятки. Такий документ переживе будь-яку зміну платформи.

Про різні написання

У переліках рішень трапляються різні варіанти: web app firewall, web firewall, web server firewall — і всі вони означають той самий клас засобів. Так само WAF — firewall для вебзастосунків, а не окрема технологія. Чому в цієї сфери стільки назв, пояснюємо окремо.

Як обрати

Три питання, які знімають більшість сумнівів:

Чи є в команді той, хто супроводжуватиме правила? Якщо ні — беріть хмарний.
Чи можна віддавати трафік клієнтів зовнішній платформі? Якщо ні — лишається апаратний або серверний варіант.
Чи витримає ваш вузол додаткове навантаження? Якщо він і так працює на межі, модуль поруч із застосунком лише погіршить справу.
Чи потрібен вам захист від об'ємних атак «у комплекті»? Якщо так, хмарна модель закриває обидві задачі одразу.

Якщо відповіді суперечать одна одній, розгляньте гібридну схему — це не компроміс, а нормальна практика. Які атаки має зупиняти будь-який із цих варіантів — у статті Як WAF захищає сайт.