Аудит фиксирует каждую правку политики до и после. Вердикты (verdicts) сработавших правил и системные события агентов пересылаются (форвардинг) в ваш SIEM в стандартных форматах. Детерминированный межсетевой экран (firewall): каждый вердикт — это сработавшее правило, которое вы задали, поэтому в SIEM меньше шума.
Наблюдаемость в qf — это три потока данных о доступе: аудит изменений «было → стало» по каждой правке политики, события с хостов (вердикты правил, соединения, системные события) и пересылка части этих потоков в SIEM. Каждое изменение доступа фиксируется до и после, а сработавшие правила и события агентов уходят в ваш SIEM в стандартных форматах.
Аудит записывает действия в управляющем сервере (control plane, CP): кто, когда и что изменил в политике, группах объектов, хостах и токенах, со снимком «было» и «стало». Это отвечает на вопрос «кто поменял это правило» без реконструкции по логам. Вердикты сработавших правил показывают горизонтальный доступ между серверами (east-west) — тот слой, который периметровый межсетевой экран (firewall) не видит. Аудит «было → стало» связывает каждое такое правило с тем, кто его изменил. Агенты передают события и счётчики обратно в CP, а CP нормализует и пересылает выбранные потоки во внешний SIEM.
Изменения применяются только из подписанного (Ed25519) бандла, проверенного до применения (verify-before-apply), а агент и управляющий сервер общаются по взаимному TLS (mTLS), поэтому и аудит-след, и события из привилегированного агента в ядре доказуемы для проверяющего, а не берутся на веру. Подробнее модель доверия — на странице «Безопасность и аудит».
Четыре потока сигналов о доступе: от пакета на TC-хуке до правки политики в управляющем сервере.
Событие сработавшего правила на TC-хуке: какое правило, источник, назначение, протокол, порт, вердикт pass или drop. Срабатывает детерминированно: это ваше правило, а не эвристика.
Наблюдаемый трафик хоста по таблице соединений (conntrack): TCP/UDP/ICMP и состояния new / established / invalid. Видны на странице хоста в наблюдаемости qf; наружу в SIEM не пересылаются.
Каждая мутация в управляющем сервере — политики, группы объектов, хосты, токены — с записью до и после, автором и временем. Отвечает регулятору и на вопрос «кто изменил это правило».
Метрики попаданий по правилам и объём трафика, которые агенты передают в CP. Полезны для наблюдения за раскаткой разграничения доступа между серверами; это метрики qf, а не поток в SIEM.
У qf нет карты сети, графа зависимостей, визуализации топологии и AI-генерации политик. Наблюдаемость qf — это потоки событий и обзор соединений на странице каждого хоста (flow-explorer), а не рисованная карта, которую надо поддерживать. Что закрывать, видно по вердиктам правил, потоковым событиям и аудиту «было → стало»: по фактам доступа, а не по угаданной топологии.
Управляющий сервер нормализует выбранные потоки в стандартный формат и доставляет их выбранным транспортом.
Пересылаются вердикты правил (rule-logs), системные события агентов и аудит-лог «было → стало». Потоковые события и счётчики остаются в наблюдаемости qf и наружу не уходят.
Событие нормализуется под приёмник: RFC5424 (syslog), CEF, LEEF или ECS-JSON. Один и тот же поток можно отдавать в формате, который уже понимает ваш SIEM.
Доставка по syslog (TCP/UDP/TLS), HTTP(S) или в Kafka. Kafka здесь — транспорт, а не формат: события едут в выбранном формате поверх выбранного канала.
Ваш SIEM получает детерминированные события межсетевого экрана и аудит доступа. Корреляция и алертинг остаются на стороне SIEM: qf отдаёт факты, а не эвристику.
Наружу уходят вердикты, системные события и аудит: то, что нужно SOC и комплаенсу. Потоковые события (conntrack) и счётчики остаются в qf, чтобы не заливать SIEM объёмом каждого соединения.
Явная граница между тем, что пересылается наружу, и тем, что остаётся в наблюдаемости qf.
| Поток | Что это | Пересылка в SIEM |
|---|---|---|
| Вердикты правил (rule-logs) | Сработавшее правило: pass / drop, источник, назначение, порт | Да |
| Системные события | Жизненный цикл агента: применение бандлов, крепление, ошибки | Да |
| Аудит «было → стало» | Кто и что изменил в политике, группах объектов, хостах, токенах | Да |
| Потоковые события (conntrack) | Наблюдаемый трафик хоста по таблице соединений | Нет — только в qf |
| Счётчики попаданий | Метрики попаданий по правилам и объёмы трафика | Нет — только в qf |
Форматы пересылки: RFC5424 / CEF / LEEF / ECS-JSON. Транспорты: syslog (TCP/UDP/TLS) / HTTP(S) / Kafka. Kafka — транспорт, не формат.
Ingest пишет события в партиционированные таблицы PostgreSQL; пересылка нормализует выбранные потоки под приёмник.
~24k событий/с — потолок одного узла PostgreSQL, а не общая пропускная способность. Пересылка отдаёт вердикты, системные события и аудит; потоковые события и счётчики наружу не уходят.
Вердикт в qf — это факт срабатывания вашего правила, а не эвристическая догадка. Наружу уходят вердикты и аудит доступа, поэтому в SIEM приходят объяснимые события, а не фон ложных срабатываний. Корреляцию и пороги алертов вы задаёте на стороне SIEM.
Вердикты сработавших правил (rule-logs), системные события агентов и аудит-лог «было → стало». Потоковые события (conntrack) и счётчики попаданий не пересылаются — они остаются в наблюдаемости qf, чтобы не заливать SIEM объёмом каждого соединения.
Форматы: RFC5424 (syslog), CEF, LEEF и ECS-JSON. Транспорты: syslog (TCP/UDP/TLS), HTTP(S) и Kafka. Kafka — это транспорт, а не формат: событие едет в выбранном формате поверх выбранного канала.
Нет. У qf нет карты сети, графа зависимостей и AI-генерации политик. Что закрывать, видно по вердиктам правил, потоковым событиям на странице хоста (flow-explorer) и аудиту «было → стало» — по фактам доступа, а не по угаданной топологии.
Каждую мутацию в управляющем сервере — политики, группы объектов, хосты, токены — со снимком «было» и «стало», автором и временем. Это отвечает на вопрос «кто изменил это правило» и даёт запись для регулятора без реконструкции по логам.
qf — детерминированный межсетевой экран: вердикт — это сработавшее правило, которое вы задали, а не эвристическая детекция. Поэтому в SIEM приходят объяснимые события, а не поток ложных срабатываний. Пороги алертов и корреляцию вы задаёте на стороне SIEM.