qf разворачивается и работает в изолированном контуре: управляющий сервер (control plane, CP) автономен, агенты регистрируются по пину отпечатка CA, переданному вне основного канала (out-of-band, OOB), политики и обновления доставляются через локальное зеркало образов (registry-mirror), а локальный кэш применённой политики (offline-кэш) держит фильтрацию (enforcement) при недоступности управляющего сервера. Ни один компонент не обращается наружу (phone-home).
Закрытый контур (air-gap) — сегмент сети без доступа в интернет: КИИ, промышленный или государственный сегмент, изолированный периметр. qf работает в нём полностью. Управляющий сервер автономен, агенты регистрируются по пину отпечатка CA (OOB), политики и обновления доставляются через локальное зеркало образов, а локальный кэш держит фильтрацию при недоступности управляющего сервера. Ни один компонент не обращается наружу.
Работа в air-gap — штатный режим развёртывания qf с полным набором возможностей. Весь обмен остаётся внутри вашего периметра: регистрация агентов, доставка политик, обновления, телеметрия. Данные и ключи не покидают контур ни на одном шаге.
Автономность управляющего сервера, доверенная регистрация, локальная доставка и отсутствие внешних зависимостей — каждое звено работает без интернета.
Состояние управляющего сервера — ваш PostgreSQL и каталог PKI. Ни Kubernetes, ни etcd, ни облачных сервисов доверия. CP разворачивается как обычный сервис в изолированной сети и не требует никаких внешних зависимостей для работы.
Агент доверяет управляющему серверу по отпечатку CA, переданному вне основного канала (например, в конфиге при подготовке образа), а не по цепочке публичных удостоверяющих центров. Токен регистрации (enrollment) расходуется при первой успешной регистрации, соединение — только по mTLS. Агент применяет только тот пакет политики (bundle), чью подпись Ed25519 он проверил до применения (verify-before-apply): неподписанное или неверно подписанное не применяется.
Образы и пакеты агента (.deb/.rpm) ставятся из внутреннего локального зеркала образов вашего контура. Новые пакеты политики приходят от вашего управляющего сервера по подписанному каналу. Никаких обращений к внешним репозиториям или CDN.
Агент кэширует применённый пакет политики и продолжает фильтровать трафик, даже если управляющий сервер недоступен. При восстановлении связи агент переподключается и догоняет актуальную политику из буфера. Изоляция сети не снимает защиту.
Ни один шаг не требует доступа в интернет: всё делается внутри периметра, широкими окнами выкатки.
Образ управляющего сервера и пакеты агента (.deb/.rpm) заносятся в изолированную сеть и складываются во внутреннее локальное зеркало образов. Дальше контур не нуждается во внешних источниках.
CP поднимается на вашем PostgreSQL и каталоге PKI, генерирует собственный удостоверяющий центр и выпускает токены регистрации с преднастроенными метками. Управляющий сервер остаётся полностью внутри контура.
Агент получает адрес управляющего сервера, токен регистрации и отпечаток CA вне основного канала. При старте он проверяет отпечаток, регистрируется по mTLS и получает первый подписанный пакет политики. Ручных per-host шагов нет.
Политики меняются в вашем управляющем сервере, каскад доводит пакеты политики до затронутых агентов, аудит фиксирует состояние было → стало. Обновления агента — из локального зеркала образов. Весь цикл замкнут внутри периметра.
qf не обращается к внешним серверам ни за активацией, ни за телеметрией, ни за проверкой лицензии — механизма обращения наружу в продукте нет. Это можно проверить на сетевом уровне: в закрытом контуре агенту и управляющему серверу просто некуда звонить, и это не мешает им работать. Подпись Ed25519 на пакетах политики — подтверждение подлинности политики, а не лицензионный замок: механизма активации или проверки лицензии в продукте нет.
qf — отечественная разработка: замена ушедшим западным решениям по разграничению доступа между серверами без нового железа и без зависимости от внешних облаков. Внесение в реестр российского ПО запланировано на Q4 2026, сертификация ФСТЭК — на 2027. До фактического получения мы не заявляем ни наличие в реестре, ни сертификат ФСТЭК. Внедрение в регуляторно-чувствительных средах ведётся через интегратора.
Через интегратора →Да. Управляющий сервер автономен (ваш PostgreSQL и каталог PKI, без Kubernetes и etcd), агенты регистрируются по пину отпечатка CA (OOB), обновления ставятся из локального зеркала образов, а локальный кэш держит фильтрацию при недоступности управляющего сервера. Ни агент, ни управляющий сервер не обращаются к внешним серверам.
По отпечатку CA, переданному вне основного канала, — например, в конфиге при подготовке образа. Агент проверяет этот отпечаток при регистрации и соединяется с управляющим сервером только по mTLS. Публичная цепочка доверия и внешние удостоверяющие центры не нужны. Применяется только тот пакет политики, чью подпись Ed25519 агент проверил до применения.
Агент продолжает фильтровать трафик по последнему применённому пакету политики — он кэшируется локально. События буферизуются на диск. При восстановлении связи агент переподключается, догоняет актуальную политику и отдаёт накопленные события. Изоляция или сбой управляющего сервера не снимает защиту с хостов.
qf разграничивает горизонтальный доступ (east-west) между серверами на уровне L3/L4 по IPv4 — сети (CIDR), порты, протоколы, TCP-флаги. Вне охвата: прикладной уровень (L7/DPI); нераспознаваемый L4 (SCTP, GRE, ESP) проходит мимо правил; IPv6 по CIDR не фильтруется. По умолчанию датаплейн (data plane) работает в режиме fail-open — трафик не рвётся при потере связи. Поддержка — только Linux с ядром от 5.15. Подробнее о границах покрытия — на странице архитектуры.
qf — отечественная разработка. Внесение в реестр российского ПО — план на Q4 2026, сертификация ФСТЭК — 2027. До фактического получения мы не заявляем ни наличие в реестре, ни сертификат. Для регуляторно-чувствительных внедрений работаем через интегратора.