Архитектура плагинов Defense: CrowdStrike, Jamf, Baramundi

Коротко. Перестаньте оценивать платформу безопасности по размеру каталога интеграций. Важно, сколько времени нужно вашей команде, а не команде вендора, чтобы добавить интеграцию, которой в каталоге нет. Если ответ «полдня», вы успеваете за новыми угрозами; если «завести тикет партнёрской программы и ждать два квартала», вы от них отстаёте. Какой из вариантов вам достанется, решает форма интерфейса плагинов.

Страница каталога интеграций на сайте любого SOC-вендора одинаковой длины и одинакового содержания. EDR, MDM, сканеры уязвимостей, тикет-системы, чаты, облачные платформы: логотипы меняются, а утверждение остаётся тем же — «мы поддерживаем всё, что у вас уже есть».

Проверить это утверждение помогают два вопроса.

Первый: могут ли ваши инженеры написать новую интеграцию, не заводя тикет вендору? Второй: если да, сколько это займёт? «Полдня» — это совсем другая платформа, чем «две недели реверс-инжиниринга недокументированного интерфейса». Обе формально можно назвать расширяемыми.

В этом материале разбирается архитектура плагинов, используемая в модуле Defense платформы Krasper Suite — слое, который общается с системами защиты конечных точек, идентификации и управления устройствами. Три показательные интеграции: CrowdStrike (EDR), Jamf (MDM для Apple) и Baramundi (UEM). Они достаточно конкретны, чтобы доказать работоспособность подхода против реальных API очень разной формы; и одновременно они заменяют более длинный ответ: любую из них инженер заказчика может заменить или дополнить менее чем за час, опираясь на описанный ниже интерфейс.

Содержание

Налог на интеграции: для чего на самом деле нужна архитектура плагинов
Интерфейс плагина Defense
Обнаружение метаданных и регистрация
Свой плагин примерно в 50 строк
Проверка состояния, которую пропускает большинство плагинов
Жизненный цикл плагина: установка, включение, версии, вывод из эксплуатации
Почему три разных вендора доказывают подход

1. Налог на интеграции: для чего на самом деле нужна архитектура плагинов

Любая SOC-платформа платит налог на интеграции. Его форма зависит от того, как построена платформа.

Если интеграции только собственные — их пишет, поддерживает и поставляет вендор — налог проявляется как задержка. Новая версия вашего EDR меняет поле в API; вендор платформы замечает это через три недели; исправленная интеграция выходит в следующем квартальном релизе; всё это время в вашем покрытии обнаружения тихо зияет дыра.

Если интеграции собственные плюс партнёрская программа, налог смещается в сторону согласований. Нового вендора нужно провести через партнёрское соглашение, прежде чем интегрировать. Существующие интеграции хорошо поддерживаются; отсутствующие добавляются шесть-двенадцать месяцев, каким бы тривиальным ни было API.

Архитектура плагинов позволяет переложить налог на интеграции на инженеров, ближе всех стоящих к задаче, — на ваших. Хорошо спроектированный интерфейс плагинов означает, что новый EDR, новый MDM, новый источник активов может интегрировать ваша команда, в ваши сроки и под ваши требования безопасности. Вендор платформы поддерживает интерфейс; интеграции поверх него — работа, посильная любому грамотному инженеру.

2. Интерфейс плагина Defense

Плагин Defense в Suite — это всё, что реализует четыре контракта:

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

Три пункта очевидны; четвёртый (состояние) — как раз то, что чаще всего пропускают самодельные интеграции, и именно он определяет, сможет ли кто-то кроме автора разобраться с плагином в три часа ночи.

   ┌──────────────────────────────────────────────┐
   │  DefensePlugin (interface)                    │
   │                                               │
   │  + describe()        → PluginMetadata         │
   │  + discover_assets() → AssetRecord[]          │
   │  + ingest()          → AsyncIterator[Event]   │
   │  + execute(action)   → ActionResult           │
   │  + health()          → HealthReport           │
   └──────────────────────────────────────────────┘

Интерфейс плагина Defense: четыре обязательных метода

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

3. Обнаружение метаданных и регистрация

Новый плагин не требует переразвёртывания платформы. Цикл обнаружения подхватывает его из реестра плагинов, читает метаданные и делает доступным для настройки арендаторами. Метаданные описывают, что плагин заявляет как свои функции, какие учётные данные ему нужны, какие действия он поддерживает и какую версию контракта гарантирует.

   ┌──────────────────────────────────────────────┐
   │  PluginMetadata                               │
   │                                               │
   │  name: "acme-edr-plugin"                      │
   │  version: "1.2.0"                             │
   │  vendor: "acme"                               │
   │  capabilities:                                │
   │    - asset_discovery                          │
   │    - telemetry_ingest                         │
   │    - action.isolate_endpoint                  │
   │    - action.run_remediation_script            │
   │  credentials_schema: { ... JSON Schema ... }  │
   │  api_contract_version: "1"                    │
   └──────────────────────────────────────────────┘

Метаданные плагина: обнаружение и декларация возможностей

api_contract_version — несущее поле. Это версия интерфейса плагинов платформы, под который написан плагин, а не версия API вендора. Платформа отказывается загружать плагины, чью версию контракта не может обеспечить, и это исключает сценарий, когда старый плагин молча ведёт себя неправильно с более новым интерфейсом.

Возможности объявляются явно и подробно. У плагина, который умеет только обнаруживать активы, не будут запрашивать выполнение действий. Интерфейс оператора показывает, что плагин умеет, исходя из объявленных возможностей, поэтому не бывает сюрпризов «мы попробовали эту интеграцию, а она не поддерживает то, что нужно» через три недели после запуска.

4. Свой плагин примерно в 50 строк

Быстрее всего показать интерфейс, разобрав, как выглядит минимальный плагин. Пример ниже — набросок, иллюстративный и не готовый к продуктиву: интеграция вымышленного EDR-продукта Acme в Suite.

python

from suite_plugins import (
    DefensePlugin, PluginMetadata, AssetRecord,
    Event, ActionResult, HealthReport,
)
from suite_plugins.errors import UpstreamError


class AcmeEdrPlugin(DefensePlugin):

    def describe(self) -> PluginMetadata:
        return PluginMetadata(
            name="acme-edr-plugin",
            version="1.0.0",
            vendor="acme",
            capabilities=[
                "asset_discovery",
                "telemetry_ingest",
                "action.isolate_endpoint",
            ],
            credentials_schema={
                "type": "object",
                "required": ["api_token", "base_url"],
                "properties": {
                    "api_token": {"type": "string"},
                    "base_url": {"type": "string", "format": "uri"},
                },
            },
            api_contract_version="1",
        )

    async def discover_assets(self):
        async for raw in self.client.list_endpoints():
            yield AssetRecord(
                native_id=raw["device_id"],
                resolution_hints={
                    "serial": raw.get("serial_number"),
                    "mac": raw.get("primary_mac"),
                    "hostname": raw.get("hostname"),
                },
                os=raw.get("os_platform"),
                last_seen=raw.get("last_checkin_at"),
            )

    async def ingest(self):
        async for raw in self.client.stream_alerts():
            yield Event(
                event_type="edr.alert.created",
                native_id=raw["alert_id"],
                native_asset_id=raw["device_id"],
                severity=raw["severity"],
                payload=raw,
            )

    async def execute(self, action):
        if action.type == "isolate_endpoint":
            try:
                await self.client.isolate(action.target.native_id)
                return ActionResult.success()
            except UpstreamError as e:
                return ActionResult.failure(reason=str(e))
        return ActionResult.unsupported()

    async def health(self) -> HealthReport:
        try:
            await self.client.ping()
            return HealthReport.ok()
        except UpstreamError as e:
            return HealthReport.degraded(reason=str(e))

Минимальный EDR-плагин: иллюстрация, не продуктивный код

Пять методов и ни строки инфраструктурного кода. Плагин не ведёт собственную базу данных, не реализует свой слой аутентификации, не пишет собственную логику повторов. Этим занимаются базовый класс и рантайм. Автор плагина пишет только специфичный для вендора код и ничего больше.

Важен сам шаблон: каждый метод чисто ложится на контракт, который платформа уже понимает. AssetRecord — каноническая форма актива, которую ожидает резолвер платформы. Event — форма, на которую подписана шина событий. ActionResult — форма, понятная любому узлу плейбука. Плагин не изобретает словарь, он отображает словарь вендора в словарь платформы.

5. Проверка состояния, которую пропускает большинство плагинов

health() выглядит тривиально: обратиться к вышестоящей системе и вернуть «ок» или «деградировано». Настоящую проверку от формальной отличает конкретность.

Проверка, возвращающая «ок» или «сбой», почти бесполезна. Оператор узнаёт, что интеграция сломана; он не узнаёт почему. И автора плагина всё равно поднимут по тревоге.

Полезная проверка возвращает структуру, достаточную для сортировки:

   ┌────────────────────────────────────────────┐
   │  HealthReport                               │
   │                                             │
   │  status: ok | degraded | down               │
   │  upstream_reachable: bool                   │
   │  auth_valid: bool                           │
   │  rate_limit_remaining: int | null           │
   │  last_successful_call: timestamp            │
   │  message: human-readable detail             │
   └────────────────────────────────────────────┘

Отчёт о состоянии: структурированный сигнал для разбора

Теперь оператор с первого взгляда видит, что интеграция не работает из-за того, что три часа назад не прошла аутентификация, а не из-за проблем сети и не из-за ограничения частоты запросов на стороне вендора. Он меняет учётные данные в настройках арендатора, и плагин восстанавливается без единой правки кода.

Платформа вызывает health() у каждого плагина с заданной периодичностью и выводит результат на операционный дашборд. Тот же вызов выполняется как проверка готовности перед запуском любого плейбука, который зависит от плагина. Плейбук никогда не отрабатывает молча против заведомо сломанной интеграции.

6. Жизненный цикл плагина: установка, включение, версии, вывод из эксплуатации

У жизни плагина четыре фазы, каждая с явной семантикой.

При установке новый плагин загружается или подтягивается из реестра. Платформа проверяет метаданные и версию контракта и регистрирует его как доступный для настройки арендаторами, хотя ни у кого он ещё не активен.

Дальше арендатор включает его, задав учётные данные. Платформа прогоняет их через проверку схемы, один раз вызывает health(), чтобы убедиться, что конфигурация рабочая, и только затем помечает плагин активным для этого арендатора. Неуспешная проверка на этом шаге не даст ему выйти в работу в сломанном состоянии.

Новые версии ставятся рядом со старой. Арендаторы мигрируют по отдельности, а не все разом, поэтому никто не вынуждает обновлять весь парк; версия с ломающим изменением поднимает api_contract_version, а предыдущая остаётся устанавливаемой для тех, кто ещё не перешёл.

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

Этот жизненный цикл невзрачен, но несущий. Без него интеграции копятся бесконечно, никто не уверен, какие ещё поддерживаются, и операционная поверхность тихо растёт, пока очередной инцидент не покажет, какие интеграции месяцами были сломаны. Жизненный цикл делает состояние интеграций видимым и проверяемым свойством платформы.

7. Почему три разных вендора доказывают подход

Три интеграции, которые мы поставляем в модуле Defense (CrowdStrike, Jamf и Baramundi), существуют как эмпирическое доказательство того, что описанный интерфейс обобщается на очень разные вышестоящие системы.

CrowdStrike отдаёт высоконагруженный поток оповещений и REST API для действий; ingest() плагина подписывается на поток, execute() вызывает REST-эндпоинты. Jamf ориентирован на Apple, устроен как MDM и оперирует своим словарём устройств и профилей конфигурации; плагин отображает этот словарь в канонические формы активов и действий, на которых говорит остальная платформа. Baramundi закрывает UEM с уклоном в Windows, с патчингом и инвентаризацией ПО; плагин обрабатывает массовое перечисление активов и события установки программ.

Эти три вендора предлагают совершенно разные стили API и доменные модели, и всё же все они доходят до платформы через один и тот же интерфейс плагинов, и каждый реализуется одним инженером менее чем за день. В этом и смысл архитектуры. Сами интеграции почти второстепенны; важно, что интерфейс делает их взаимозаменяемыми.

Если у вас четвёртый EDR, другой MDM или UEM, под который мы ничего не писали, вы реализуете тот же интерфейс. Платформе не нужно знать о вендоре заранее.

Заключение

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

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

Дополнительное чтение

Plugin Architectures in Production Systems, шаблоны проектирования расширяемых платформ
NIST SP 800-128: Руководство по управлению конфигурациями с фокусом на безопасность
MITRE D3FEND: техники усиления и изоляции, на которые опираются EDR-интеграции

Архитектура плагинов Defense: интеграция CrowdStrike, Jamf и Baramundi менее чем за 30 минут