Міграція зі старого enterprise-WAF: практичний чек-лист
Чому міграцію WAF відкладають роками
Старий корпоративний WAF рідко тримають, бо він хороший. Його тримають, бо страшно чіпати: він стоїть перед продакшном, ніхто до кінця не знає, які саме правила й винятки за роки накопичилися, і будь-яка помилка при переїзді ризикує або зламати сайт, або відкрити діру. Тому команди роками платять за рішення, яке переросли, — не тому, що воно найкраще, а тому, що міграція здається стрибком у прірву.
Насправді безпечна міграція — це не стрибок, а послідовність кроків, де на кожному етапі можна зупинитися й відкотитися. Ось чек-лист, який знімає більшу частину ризику.
Крок 1. Інвентаризація того, що у вас реально є
Перш ніж щось переносити, треба знати, що переносите:
- Які домени й маршрути взагалі проходять крізь поточний WAF.
- Які кастомні правила й винятки накопичилися — особливо ті, що додавали «щоб не заважало». Частина з них давно неактуальна, частина маскує реальні проблеми.
- Де завершується TLS і як зараз видаються сертифікати.
- Що ви логуєте і які вимоги до зберігання на вас поширюються — тут стане в пригоді окрема стаття про GDPR-логування.
Цей крок часто найкорисніший сам по собі: команди виявляють правила, про призначення яких уже ніхто не пам’ятає.
Крок 2. Паралельний прогін, а не різкий перемикач
Золоте правило: новий WAF має попрацювати поряд зі старим, перш ніж щось замінить. Спрямуйте копію трафіку — або трафік тестового піддомену — через нову платформу, лишивши продакшн на старому рішенні. Так ви побачите, як новий фільтр поводиться на вашому реальному трафіку, без жодного ризику для живих користувачів.
Тут допомагає автоматичний випуск сертифікатів: для кожного домену видається окремий сертифікат Let’s Encrypt для кожного тенанта, тож підняти TLS на новій платформі не означає ручної метушні з ключами.
Крок 3. Спершу детекція, потім блокування
Коли трафік уже йде крізь нову платформу, не вмикайте блокування одразу. Запустіть правила в режимі детекції: вони фіксують, що заблокували б, у незмінному аудит-логу, але нічого не ріжуть. Кілька днів такого спостереження показують дві речі — чи ловить новий фільтр реальні атаки і, головне, чи не чіпає він легітимний трафік. Це та сама обережність, що лежить в основі тюнінгу хибних спрацювань: ви налаштовуєте пороги на живих даних, перш ніж дати правилам право блокувати.
Базовий набір правил OWASP покриває поширені класи атак «з коробки», тож більшість кастомних правил старого WAF, які ви так боялися переносити, виявляються або вже покритими, або непотрібними.
Крок 4. Поетапний перепис DNS
Фінальний крок — переспрямувати справжній трафік. Робіть це поступово:
- Почніть із менш критичного піддомену.
- Знизьте TTL DNS заздалегідь, щоб відкат був швидким.
- Переведіть маршрут, поспостерігайте за аудит-логом і метриками.
- Лише переконавшись, що все чисто, переходьте до наступного домену.
Якщо щось піде не так, ви повертаєте DNS назад — і завдяки низькому TTL відкат займає хвилини, а не години. Ніякого моменту «все або нічого».
Крок 5. Виведення старого WAF
Аж коли весь трафік стабільно йде крізь нову платформу й аудит-лог чистий, старе рішення можна відключати. Не поспішайте: тримайте його як запасний варіант ще якийсь час, доки не з’явиться повна впевненість.
Порівняння з конкретними спадковими рішеннями за ціною й підходом — на наших сторінках зіставлення, наприклад проти Imperva, а загальну картину того, як влаштований наш конвеєр, дає сторінка як це працює.
Чого ми не обіцяємо
Ми не кажемо, що міграція «безризикова» — будь-яка зміна перед продакшном потребує уваги. Ми кажемо інше: за паралельного прогону, режиму детекції й поетапного перепису DNS ризик розбивається на маленькі оборотні кроки, а не один страшний перемикач. Накладні витрати нової платформи на затримку тримаються в межах проєктного бюджету — як ми його вимірюємо.
Плануєте переїзд зі спадкового WAF і хочете зробити це без простою? Напишіть нам.