Периметровый файрвол защищает границу снаружи, но между платёжными и процессинговыми серверами внутри контура доступ остаётся открытым: одно проникновение распространяется на весь парк. qf — файрвол на каждом сервере (host-firewall) на eBPF: изолирует сегменты на уровне хоста, управляется из одной точки и записывает каждое изменение доступа «было → стало». Без нового сетевого железа и без облачной привязки.
qf — централизованный файрвол на каждом сервере на eBPF для финтех-инфраструктуры: центр управления (control plane) компилирует политики по меткам хостов и рассылает подписанные бандлы агентам, которые фильтруют трафик прямо в ОС. Так платёжные, процессинговые и корпоративные сегменты изолируются друг от друга, и это доказуемо на аудите. Разграничение доступа между серверами (microsegmentation) здесь описывается метками и группами объектов, а не ручной разметкой каждого узла.
Периметр держит границу снаружи, но доступ между серверами внутри контура ничем не ограничен: одно проникновение расходится по всему платёжному парку. qf закрывает именно этот внутренний доступ. Это не дубль периметрового файрвола, за который вы уже платите: тот работает на границе, а qf разграничивает доступ между серверами внутри неё. Такого слоя в периметровой схеме нет.
Требования к сегментации (ГОСТ Р 57580, PCI DSS) предполагают, что процессинг карт и платежей отделён от остальной сети, а доступ между сегментами минимально необходимый. Периметровый файрвол этот внутренний, горизонтальный доступ между серверами (east-west) не видит. Его и разграничивает qf: централизованно, метками и группами объектов, а не ручной правкой правил на каждом узле.
qf не сертифицирован и соответствие стандартам как факт не заявляет: внесение в реестр отечественного ПО планируем к Q4 2026, сертификацию ФСТЭК — на 2027. Сегодня это технический контроль сегментации и аудита: отечественная разработка, работа в закрытом контуре без обращений наружу, аудит-след. Он помогает выполнять требования стандартов и предъявлять доказательства проверяющему. Оценку соответствия проводит ваш аудитор или интегратор.
Процессинг, платёжный шлюз и корпоративный сегмент размечаются метками, а политика описывает, кто с кем может общаться. Применение правил выполняет eBPF-агент на самом хосте, без нового сетевого железа и без переклейки сети. Горизонтальный доступ между сегментами закрыт там, где периметр его не видит.
Любая правка политики проходит через центр управления и записывается в аудит-журнал с фиксацией «до» и «после». Проверяющему видно, кто, когда и что менял в правилах доступа между сегментами — детерминированно, без реконструкции по логам разрозненных хостов.
Срабатывания правил (Verdicts), системные события и аудит-журнал форвардятся в SIEM в форматах CEF, LEEF, ECS-JSON или RFC5424 по syslog, HTTP(S) или Kafka. Детерминированный файрвол не плодит ложных срабатываний, поэтому дежурная смена не разбирает лишний шум.
Для изолированных платёжных контуров центр управления автономен (ваш PostgreSQL и каталог PKI, без Kubernetes и etcd), агенты подключаются по OOB-пину отпечатка CA, обновления — из локального зеркала пакетов. Ни один компонент не обращается наружу (no phone-home), и это проверяемо на сетевом уровне. Агент работает в ядре с широкими привилегиями, это прямой фактор модели угроз, поэтому он применяет только то, что подписал центр управления: подпись бандла (Ed25519) проверяется до применения (verify-before-apply), канал агент↔CP — взаимный TLS (mTLS), а одноразовый токен подключения (enrollment) расходуется при первом соединении.
Включать блокировку на боевом платёжном парке страшно. qf ведёт к сегментации по умолчанию управляемо: сначала наблюдение, потом предпросмотр, и только потом запрет, с несколькими страховками.
Метки и группы объектов (ipset/portset/hostset) проставляются на хостах: процессинг, платёжный шлюз, БД, корпоративный сегмент. Сегментация описывается декларативно и хранится как код.
Политики работают в режиме логирования: qf показывает, какой трафик они бы затронули, но не блокирует. Реальная картина обмена между сегментами видна до любого запрета.
Перед применением предпросмотр (dry-run) показывает, какие хосты и правила изменятся, а радиус изменения (blast-preview) — сколько хостов затронуто. Наблюдаемый трафик по хостам виден на их страницах (счётчики и вердикты).
Блокировка по сегментам включается поэтапно. Дефолт продукта — трафик не рвётся при потере связи (fail-open, ALLOW); запрет по умолчанию (default-deny) — это режим, к которому переход осознанный, сегмент за сегментом, а не коробочное состояние.
Две страховки против самоотключения: fail-open по умолчанию (случайно отрезать хост от сети нельзя) и сторожевой таймер (dead-man watchdog). Если агент теряет связь с центром управления и не восстанавливает её за 60 секунд, он откатывается на предыдущий бандл. Это защита от потери связи, а не автоматическое обнаружение «плохой» политики.
Распределённый парк Linux управляется из одного центра управления; изменение политики доезжает до всех затронутых хостов автоматически, каскадом.
Один центр управления тянет более 5000 агентов, а масштаб доказывает скорость раскатки: политика на 500 хостов доезжает за 5–15 секунд. Ed25519 подтверждает аутентичность политики, это не механизм лицензирования.
Честный контур доверия важнее полного списка галочек. Молчание о границах — не аргумент для регулируемой среды.
qf проходит пилотную эксплуатацию в финтех-организации с распределённым парком Linux в регуляторно-чувствительной среде. Кейс уровня роли, без имён и логотипов: команда валидирует разграничение доступа между серверами на своём парке в режиме сосуществования (coexist) с текущими средствами защиты, поэтапно, а не одним переключением. Детали и референс уровня роли — по запросу под NDA.
Пилот →qf не сертифицирован и соответствие стандартам как факт не заявляет. Внесение в реестр отечественного ПО планируем к Q4 2026, сертификацию ФСТЭК — на 2027. Сегодня qf — технический контроль: реализует host-сегментацию и ведёт аудит изменений доступа «было → стало», что помогает выполнять требования этих стандартов к сегментации и предъявлять доказательства проверяющему. Оценку соответствия проводит ваш аудитор или профильный интегратор.
Дефолт продукта — трафик не рвётся при потере связи (fail-open, ALLOW), поэтому случайно отрезать хост от сети нельзя. Переход к запрету (default-deny) — поэтапный, с режимом наблюдения и предпросмотром изменений до применения. Дополнительно работает сторожевой таймер (dead-man watchdog): если агент теряет связь с центром управления и не восстанавливает её за 60 секунд, он откатывается на предыдущий бандл.
В SIEM форвардятся срабатывания правил (Verdicts), системные события и аудит-журнал изменений. Форматы — CEF, LEEF, ECS-JSON, RFC5424; транспорты — syslog (TCP/UDP/TLS), HTTP(S) и Kafka. События потоков (flow/conntrack) наружу не форвардятся — только перечисленные потоки.
Да. Центр управления автономен (ваш PostgreSQL и каталог PKI, без Kubernetes и etcd), агенты подключаются по OOB-пину отпечатка CA, обновления ставятся из локального зеркала пакетов (registry-mirror), а офлайн-кэш держит применение правил при недоступности CP. Механизма обращения наружу (phone-home) в продукте нет — это проверяемо на сетевом уровне.