Как мы заменили Kerio Control на «Континент 4»: опыт внедрения на производстве Зачем вообще менять то, что работало У нас на периметре годами стоял Kerio Control от GFI. Работал он, честно говоря, неплохо — для своих задач в своё время это был разумный выбор. Но к началу года уравнение перестало сходиться: вендор зарубежный, платёжная схема и техподдержка — под вопросом, в реестре отечественного ПО его отродясь не было, а у нас требования регуляторов никто не отменял. Стандартная мотивация импортозамещения, только у предприятия она не абстрактная: если периметр встанет, встанет производство. Выбор у нас был небогатый, что и хорошо — меньше галлюцинаций при выборе. Ключевые требования сформулировали так: решение в реестре отечественного ПО и с сертификатами ФСТЭК, а для криптошлюзовой части — и ФСБ; полноценный NGFW: межсетевое экранирование, IDS/IPS, контроль приложений, URL-фильтрация; VPN с поддержкой ГОСТ для каналов между площадками и удалённого доступа; вменяемая работа с политиками безопасности — мы изначально рассматривали и импорт, и пересоздание правил с нуля; возможность кластера высокой доступности. «Континент 4» от «Кода Безопасности» закрыл весь список: это UTM-платформа, где в одном узле собраны межсетевой экран, детектор атак, контроль приложений, URL-фильтрация и VPN-шлюз с ГОСТ-шифрованием. К моменту нашего выбора у актуальной сборки был комплекс сертификатов — ФСТЭК (межсетевой экран типа «А», 4-й класс защиты, СОВ уровня сети 4-го класса, 4-й уровень доверия) и ФСБ (средство криптографической защиты класса КС2). Для нас это означало, что одной платформой можно закрывать и периметр, и требования по защите информации, без зоопарка из разрозненных коробок. Этап 1. Инвентаризация и «разбор старого дома» Прежде чем что-то покупать, мы неделю занимались неприятной работой: выгружали и раскладывали по полочкам существующую конфигурацию Kerio. Итог был отрезвляющий: за годы эксплуатации накопилось около 50 правил фильтрации, из которых заметная часть дублировала друг друга, часть ссылалась на давно выключенные серверы, а пара правил «временно открыли на месяц» жила уже четвёртый год. Совет, который я вынес из этого этапа: миграция — лучший повод провести ревизию. Из 50 правил мы забраковали почти треть ещё до того, как хоть одно из них попало в новую систему. Дальше пересоздавать стало проще. Этап 2. Пилот на копии трафика «Континент 4» поставляется в аппаратных узлах безопасности разных классов — от настольных моделей для филиалов до производительных платформ для ЦОД, плюс есть виртуальное исполнение. Мы взяли на пилот IPC-R50 — компактный узел начального уровня: настольный, но с креплением в стойку, четырьмя гигабитными портами и одним SFP; в режиме UTM он держит до 1 Гбит/с, в чистом режиме межсетевого экрана — до 1,8 Гбит/с. Для нашей нагрузки этого хватило с запасом, а цену за такую платформу уже не стыдно показывать руководству. Развёртывали параллельно основному шлюзу. Пилот проверял четыре вещи: Пропускная способность под нашим реальным профилем трафика. Заявленные цифры — это цифры вендора; нас интересовало, что будет в режиме UTM, когда одновременно работают МЭ, IPS и глубокий анализ пакетов. Прогнали боевой трафик через новый узел и мерили. Политики безопасности. Вендорские утилиты импорта у «Континента 4» есть, но заточены под предыдущие версии «Континента» и Check Point — для Kerio готового конвейера не существует. Мы взвесили вариант с переносом правил через экспорт в таблицы и сознательно решили пересоздать все 50 с нуля. Соображений было два: во-первых, после ревизии лишнего осталось немного; во-вторых, модель политик у «Континента» другая — в рамках одного правила можно собрать сразу все механизмы защиты: МЭ, NAT, контроль приложений, детектор атак. Старые цепочки из Kerio в такой формат конвертировались бы криво, проще было описать заново: взяли вычищенный список из инвентаризации и адаптировали каждое правило под новую систему.