Развёртывание и инфраструктура

Топология

%%{init: {"theme": "base", "themeVariables": {"fontFamily": "-apple-system, Segoe UI, Helvetica, Arial, sans-serif", "primaryColor": "#eef2f7", "primaryTextColor": "#0b0b0b", "primaryBorderColor": "#5b6b7c", "lineColor": "#5b6b7c", "secondaryColor": "#eef4ff", "tertiaryColor": "#f4f3f0", "clusterBkg": "#f9f9f7", "clusterBorder": "#c3c2b7", "edgeLabelBackground": "#fcfcfb", "actorBkg": "#eef2f7", "actorBorder": "#5b6b7c", "actorTextColor": "#0b0b0b", "actorLineColor": "#5b6b7c", "signalColor": "#52514e", "signalTextColor": "#0b0b0b", "labelBoxBkgColor": "#eef4ff", "labelBoxBorderColor": "#5b6b7c", "labelTextColor": "#0b0b0b", "loopTextColor": "#0b0b0b", "noteBkgColor": "#fdf3d9", "noteBorderColor": "#c98500", "noteTextColor": "#3d2f00", "activationBorderColor": "#5b6b7c", "activationBkgColor": "#eef4ff", "sequenceNumberColor": "#ffffff"}}}%%
flowchart TB
    subgraph Perimeter["Периметр сети заказчика"]
        direction TB
        subgraph CPHost["Хост(ы) контрольной плоскости"]
            CP["Контрольная плоскость (Go)"]
            PG[("PostgreSQL")]
            IdP["OIDC / IdP, совместимый с Keycloak"]
            Loki[("Grafana Loki\n(SIEM)")]
            CP --- PG
            CP --- IdP
            CP --- Loki
        end
        WS1["Агенты на рабочих станциях"]
        WS1 -- "получение подписанной политики /\nобезличенные сигналы состояния и события" --> CP
    end
    Internet(["Для принятия решений о применении политик\nдоступ в интернет не требуется"])
    Perimeter -.необязательно: обновление каталога,\nобновление ленты данных об угрозах.-> Internet

Контрольная плоскость по замыслу развёртывается внутри периметра сети заказчика. Поскольку оценка политик выполняется локально (см. Механизм применения политик и цепочка доверия) а телеметрия передаётся асинхронно, для продолжения работы механизмов применения политик доступ в интернет не требуется. Работа в изолированном от внешней сети контуре режим работы полноценно поддерживается: рабочая станция с последним подписанным снимком политики продолжает корректно применять политики даже при полной недоступности контрольной плоскости или интернета. Единственное, что выигрывает от наличия связи — неблокирующие фоновые функции: получение более новой подписанной политики, синхронизация обезличенного журнала аудита и, если включено, обновление каталогов обновлений или лент данных об угрозах, которые отслеживает контрольная плоскость.

Состав контрольной плоскости

Модель установки на рабочих станциях

Установка намеренно разделена на две отдельные задачи: одноразовую первичную первичную настройку платформы и последующие непрерывные централизованные обновления.

1. Первичная настройка выполняется один раз с помощью установщика, соответствующего платформе — это пакет, разворачиваемый через MDM, вместе с конфигурационным профилем на macOS (инструменты класса Jamf/Kandji/Intune/Mosyle/Workspace ONE), подписанный пакет deb/rpm через менеджер пакетов парка машин на Linux, либо пакет, доставляемый через Intune/SCCM/GPO на Windows. Первичная настройка на каждой платформе создаёт локальное хранилище доверенных ключей (см. Идентификация, доступ и управление парком агентов) и регистрирует рабочую станцию в контрольной плоскости с помощью короткоживущего токена регистрации, привязанного к организации.
2. Все последующие обновления централизованно контролируются — агент самостоятельно, по собственному расписанию, переходит к целевой подписанной версии из каталога версий контрольной плоскости.

В частности, на Linux каждый из уровней применения политик (перехватчики командной оболочки, LD_PRELOAD и монитор ядра fanotify) можно выборочно включать или отключать для конкретного хоста на этапе установки — это полезно при наличии рабочей нагрузки с известной несовместимостью — без отключения остальных средств защиты.

Почему приоритет отдан развёртыванию в инфраструктуре организации

Архитектурное решение, описанное в разделе Обзор архитектуры — локальное принятие решений без синхронного обращения к серверу — имеет прямое инфраструктурное следствие: продукт продолжает надёжно применять политики защиты, когда сегмент сети заказчика изолирован по требованиям соответствия или когда требование к локализации данных исключает любую облачную контрольную плоскость как услугу. Установка внутри собственного периметра заказчика — это целевой сценарий развёртывания по умолчанию, под который архитектура была спроектирована изначально.

Далее: Безопасность самого инструмента защиты.