Сценарии применения¶
Эта страница отвечает на вопрос «из чего складывается работающее решение целиком» для четырёх сценариев, ради которых Security Hub обычно и внедряют. Для каждого показано, кто с кем взаимодействует, в каком порядке и что при этом входит в поставку, а что вы разворачиваете и администрируете сами.
Security Hub — место, где находки сводятся воедино и получают жизненный цикл. Он не заменяет ни сканеры, ни систему сборки, ни трекер задач: без них сценарии не работают, поэтому на схемах эти компоненты показаны явно.
Как читать схемы
Одна и та же нотация используется на всех схемах ниже:
- Синие блоки со сплошной рамкой — компоненты, входящие в поставку Security Hub: backend, worker, веб-интерфейс, DomainScope, плагины.
- Серые блоки с пунктирной рамкой — то, что вы разворачиваете и администрируете сами: система сборки и её сканеры, Jira, мессенджеры, провайдер SSO, NetBox, LLM-сервис.
- Блоки-цилиндры — хранилища данных.
Двусторонние обмены показаны одной стрелкой с двумя номерами (например «4, 7»), а порядок шагов — отдельной схемой последовательности: так на структурной схеме не возникает пересечений. Номера шагов совпадают на обеих схемах и в таблице под ними.
Backend, worker и база данных во всех сценариях одни и те же и разворачиваются один раз — см. Развёртывание.
Сценарий 1. Консолидация находок из системы сборки¶
Самый частый сценарий. У команды уже есть сканеры в конвейере сборки: статический анализ, проверка зависимостей, образов контейнеров, конфигураций инфраструктуры. Каждый пишет свой отчёт, и никто не видит общей картины. Security Hub становится единой точкой: конвейер отправляет отчёт, Hub разбирает его, убирает дубликаты и ведёт находки дальше.
Кто с кем взаимодействует¶
flowchart TD
subgraph CustomerCI["Ваш контур"]
Scanner["Сканеры<br/>SAST, SCA, образы, IaC"]
CI["Задание сборки"]
end
subgraph HubBox["Входит в Security Hub"]
API["Backend<br/>REST API"]
Queue["Очередь задач"]
Worker["Worker<br/>разбор и дедупликация"]
UI["Веб-интерфейс"]
end
DB[("PostgreSQL")]
Files[("Хранилище отчётов")]
Scanner --> |"1"| CI
CI --> |"2, 4"| API
API --> |"3"| Files
API --> |"5"| Queue
Queue --> |"6"| Worker
Worker <--> |"7, 8"| DB
Worker --> |"9"| Queue
UI --> |"10"| API
classDef hub fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111827
classDef ext fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray:4 3,color:#111827
classDef store fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111827
class API,Queue,Worker,UI hub
class Scanner,CI ext
class DB,Files storeВ каком порядке это происходит¶
sequenceDiagram
autonumber
participant CI as Задание сборки
participant API as Backend
participant FS as Хранилище отчётов
participant Q as Очередь задач
participant W as Worker
participant DB as PostgreSQL
participant UI as Веб-интерфейс
CI->>CI: запуск сканера, получен SARIF
CI->>API: POST отчёта с ключом сервисной учётной записи
API->>FS: сохранение файла, определение формата
API-->>CI: 202 Accepted, идентификаторы отчёта и задачи
API->>Q: постановка задачи разбора
Q->>W: выдача задачи
W->>DB: разбор, расчёт хеша дедупликации, сверка
W->>DB: создание новых и обновление известных находок
W->>Q: задачи-следствия: Jira, уведомления, AI-триаж
UI->>API: аналитик работает со списком находокРасшифровка шагов¶
| Шаг | Что происходит |
|---|---|
| 1 | Задание сборки запускает сканер и получает отчёт в формате SARIF 2.1.0. Поддерживается также прямой приём формата выгрузки SonarQube. |
| 2 | Задание отправляет файл на POST /api/v1/products/<id>/reports с заголовком X-API-Key. Ключ принадлежит сервисной учётной записи с правом загрузки в этот продукт. |
| 3 | Backend проверяет ключ и права, сохраняет файл в хранилище отчётов и определяет формат — по явному полю format либо по содержимому. |
| 4 | Backend сразу отвечает 202 Accepted и возвращает идентификатор отчёта и идентификатор фоновой задачи. Обработка асинхронная: счётчиков найденного в этом ответе нет. |
| 5 | Backend создаёт запись отчёта в состоянии «ожидает» и ставит задачу разбора в очередь. |
| 6 | Worker забирает задачу из очереди. |
| 7 | Worker разбирает файл под жёсткими лимитами и для каждого результата считает хеш дедупликации по правилу и местоположению — имя сканера в хеш не входит. |
| 8 | Находки, которых ещё не было, создаются со статусом «новая»; уже известные обновляются, к ним добавляется ещё один источник. |
| 9 | Worker ставит в очередь задачи-следствия: создание задачи в Jira, уведомления, разбор языковой моделью — каждая только если соответствующая интеграция включена. |
| 10 | Аналитик видит находки в интерфейсе: подтверждает, отклоняет как ложное срабатывание, назначает срок, передаёт в работу. |
Что нужно с вашей стороны¶
- Сканеры, умеющие выгружать SARIF. Формат стандартный: его поддерживают распространённые инструменты статического анализа, проверки зависимостей, образов и конфигураций.
- Сервисная учётная запись в Hub и ключ к ней, положенный в защищённые переменные вашей системы сборки. Ключ показывается один раз при создании.
- Продукт в Hub, в который загружаются отчёты. Продукты группируются в проекты; права выдаются на любом из двух уровней.
Подробности настройки: Загрузка SARIF.
Сценарий 2. Непрерывное обследование внешнего периметра¶
Второй сценарий не требует ни системы сборки, ни собственных сканеров. DomainScope самостоятельно обследует периметр по заданному списку доменов и диапазонов адресов: находит поддомены, проверяет, что за ними отвечает, сканирует порты, сертификаты и веб-приложения — и отдаёт результат в Hub тем же способом, что и внешние сканеры, в формате SARIF.
Отдельно DomainScope предлагает расширить периметр: обнаружив адрес или домен, которого нет в списке, он отправляет предложение, а администратор Hub подтверждает или отклоняет его в интерфейсе. Периметр не расширяется автоматически.
Кто с кем взаимодействует¶
flowchart TD
subgraph DSBox["Входит в Security Hub"]
DS["DomainScope"]
OpenVAS["OpenVAS<br/>сканер CVE"]
ZAP["OWASP ZAP<br/>сканер веб-приложений"]
API["Backend Hub"]
UI["Веб-интерфейс"]
end
DSDB[("БД DomainScope")]
Perimeter["Ваш внешний периметр<br/>домены, адреса, сервисы"]
NetBox["NetBox<br/>инвентарь адресов"]
DS --> |"1"| Perimeter
DS <--> |"2, 3"| DSDB
DS <--> |"4"| OpenVAS
DS <--> |"5"| ZAP
DS --> |"6"| API
DS --> |"7"| API
NetBox <--> |"8"| DS
UI --> |"9"| API
classDef hub fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111827
classDef ext fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray:4 3,color:#111827
classDef store fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111827
class DS,OpenVAS,ZAP,API,UI hub
class Perimeter,NetBox ext
class DSDB storeВ каком порядке это происходит¶
sequenceDiagram
autonumber
participant DS as DomainScope
participant Net as Внешний периметр
participant DSDB as БД DomainScope
participant Sc as OpenVAS и ZAP
participant API as Backend Hub
participant NB as NetBox
participant UI as Веб-интерфейс
DS->>Net: цикл обследования: поддомены, DNS, порты, TLS
DS->>DSDB: сохранение результатов с указанием источника
DSDB-->>DS: текущее состояние периметра
DS->>Sc: запуск проверки CVE по найденным узлам
DS->>Sc: запуск проверки веб-приложений
DS->>API: выгрузка находок отчётом SARIF
DS->>API: предложение добавить новый узел в периметр
DS->>NB: сверка и обновление инвентаря адресов
UI->>API: администратор подтверждает предложениеРасшифровка шагов¶
| Шаг | Что происходит |
|---|---|
| 1 | DomainScope по расписанию обходит периметр: перебирает поддомены, разрешает имена, сканирует порты, снимает параметры TLS-сертификатов. Периодичность каждого цикла настраивается отдельно. |
| 2 | Результаты сохраняются в собственную базу DomainScope с пометкой, откуда узел стал известен, — это позволяет потом разобраться в происхождении каждой записи. |
| 3 | Следующий цикл сверяется с сохранённым состоянием и видит изменения: появившийся порт, исчезнувший узел, истекающий сертификат. |
| 4 | По найденным узлам запускается проверка известных уязвимостей через OpenVAS. |
| 5 | По найденным веб-сервисам запускается активная проверка через OWASP ZAP. |
| 6 | DomainScope формирует отчёт SARIF и загружает его в Hub — тем же эндпоинтом и с тем же видом ключа, что и любой внешний сканер. Дальше находка проходит тот же путь, что в сценарии 1. |
| 7 | Обнаружив узел вне заданного периметра, DomainScope отправляет предложение о его добавлении. |
| 8 | Опционально: DomainScope сверяется с NetBox — берёт оттуда адреса и зоны как источник периметра и возвращает обнаруженное. |
| 9 | Администратор Hub видит предложение в интерфейсе и принимает решение. Периметр не расширяется без подтверждения. |
Что нужно с вашей стороны¶
- Отдельный экземпляр PostgreSQL для DomainScope — с базой Hub он не разделяется.
- Разрешённый исходящий доступ к обследуемому периметру и, если сканеры обновляют свои базы, к источникам обновлений.
- Согласование факта активного сканирования: OpenVAS и OWASP ZAP выполняют активные проверки, а не только наблюдение.
Подробности: Обзор DomainScope, Управление сканерами.
Сценарий 3. Триаж, задачи и контроль сроков¶
Находка сама по себе ничего не меняет. Этот сценарий — про то, что происходит между «сканер что-то сообщил» и «проблема устранена»: кто разбирает поток, как отсеивается шум, как работа попадает к исполнителю и что происходит, когда срок выходит.
Все три механизма — разбор языковой моделью, задачи в Jira и уведомления — включаются независимо друг от друга. Ни один не включён по умолчанию.
Кто с кем взаимодействует¶
flowchart TD
subgraph HubBox["Входит в Security Hub"]
API["Backend"]
Worker["Worker"]
SLA["Контроль сроков"]
Sandbox["Песочница<br/>проверка гипотез"]
UI["Веб-интерфейс"]
end
LLM["LLM-сервис"]
Jira["Jira"]
Chat["Мессенджеры и почта"]
DB[("PostgreSQL")]
Worker <--> |"1, 2"| LLM
Worker <--> |"3"| Sandbox
Worker --> |"4"| DB
UI --> |"5"| API
Worker <--> |"6, 9"| Jira
SLA --> |"7"| DB
SLA --> |"8"| Chat
Worker --> |"10"| Chat
classDef hub fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111827
classDef ext fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray:4 3,color:#111827
classDef store fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111827
class API,Worker,SLA,Sandbox,UI hub
class LLM,Jira,Chat ext
class DB storeВ каком порядке это происходит¶
sequenceDiagram
autonumber
participant W as Worker
participant L as LLM-сервис
participant S as Песочница
participant DB as PostgreSQL
participant U as Аналитик
participant J as Jira
participant C as Мессенджеры
W->>L: разбор новой находки с контекстом
L-->>W: вердикт и предложенные проверки
W->>S: выполнение проверок в изоляции
W->>DB: сохранение вердикта и комментария
U->>DB: подтверждение находки в интерфейсе
W->>J: создание задачи по шаблону проекта
W->>DB: запуск таймера срока устранения
W->>C: предупреждение о приближении срока
J-->>W: задача закрыта, статус возвращается в Hub
W->>C: уведомление об исправленииРасшифровка шагов¶
| Шаг | Что происходит |
|---|---|
| 1 | Если разбор языковой моделью включён, worker отправляет ей находку с контекстом: правило, местоположение, фрагмент кода или параметры сервиса. |
| 2 | Модель возвращает вердикт — например, «похоже на ложное срабатывание» с оценкой уверенности — и, при необходимости, набор проверок, которые подтвердили бы или опровергли догадку. |
| 3 | Проверки выполняются в изолированной песочнице с ограниченным набором разрешённых команд, лимитом времени и лимитом объёма вывода. Сама модель ничего не запускает. |
| 4 | Вердикт и обоснование сохраняются как комментарий к находке. Автоматически статус меняется только у находок, которых ещё не касался человек. |
| 5 | Аналитик просматривает находку и принимает решение: подтвердить, отклонить как ложное срабатывание, принять риск на срок, отложить до внешнего события. |
| 6 | При подтверждении, если интеграция с Jira включена, worker создаёт задачу по шаблону проекта. Тип задачи может зависеть от того, какой сканер нашёл проблему. |
| 7 | С переходом в работу запускается таймер срока устранения. Срок зависит от критичности и настроек проекта. |
| 8 | При приближении срока и при его нарушении отправляются уведомления в настроенные каналы. |
| 9 | Если включена обратная синхронизация, Hub периодически опрашивает Jira и закрывает находки, чьи задачи достигли завершающего статуса. Есть и обратный путь — приём уведомления от самой Jira. |
| 10 | Об исправлении отправляется уведомление; закрытые за период находки могут собираться в сводку. |
Что нужно с вашей стороны¶
- Для разбора языковой моделью — доступ к LLM-сервису, совместимому по
API, и решение о том, какие данные о находках допустимо ему передавать. В
промышленной среде адрес сервиса обязан использовать
https. - Для Jira — учётная запись бота, права на создание задач в нужных проектах и шаблон задачи. Обращения к Jira по умолчанию запрещены к локальным и внутренним адресам — это защита от подделки запросов на стороне сервера, и её приходится ослаблять явно, если Jira развёрнута внутри периметра.
- Для уведомлений — бот в Telegram или MAX, входящий webhook Mattermost либо параметры SMTP-сервера.
Подробности: AI-триаж и песочница, Jira, Уведомления.
Сценарий 4. Связь находок с инвентарём¶
Находка «на адресе 203.0.113.10 открыт порт 8080 с известной уязвимостью» превращается в работу только тогда, когда понятно, чей это узел, что на нём крутится и кому писать. Эти сведения лежат не в сканере, а в системе учёта активов — NetBox, CMDB, системе управления парком устройств.
Security Hub забирает их двумя способами: собственной интеграцией с NetBox и плагинами, которые исполняются в изолированном процессе и общаются с внешними системами через ограниченный набор разрешённых обращений.
Кто с кем взаимодействует¶
flowchart TD
subgraph HubBox["Входит в Security Hub"]
API["Backend"]
Worker["Worker"]
Runner["Среда исполнения<br/>плагинов"]
Plugin["Плагин<br/>обогащения"]
UI["Веб-интерфейс"]
end
CMDB["Система учёта активов<br/>CMDB, парк устройств"]
NetBox["NetBox"]
DB[("PostgreSQL")]
Worker --> |"1"| Runner
Runner --> |"2"| Plugin
Plugin --> |"3, 4"| CMDB
Runner --> |"5"| Worker
Worker --> |"6"| DB
API <--> |"7"| NetBox
UI --> |"8"| API
classDef hub fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#111827
classDef ext fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray:4 3,color:#111827
classDef store fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#111827
class API,Worker,Runner,Plugin,UI hub
class CMDB,NetBox ext
class DB storeВ каком порядке это происходит¶
sequenceDiagram
autonumber
participant W as Worker
participant R as Среда исполнения плагинов
participant P as Плагин обогащения
participant C as Система учёта активов
participant DB as PostgreSQL
participant API as Backend
participant NB as NetBox
participant U as Аналитик
W->>R: появилась новая находка, требуется обогащение
R->>P: запуск плагина в отдельном процессе
P->>C: запрос сведений об узле
C-->>P: владелец, назначение, окружение
R->>W: результат в виде меток
W->>DB: метки сохраняются у находки
API->>NB: сверка адресов периметра
U->>API: фильтрация и разбор находок по меткамРасшифровка шагов¶
| Шаг | Что происходит |
|---|---|
| 1 | Появление находки ставит фоновую задачу обогащения. Обогащение можно запустить и вручную для уже существующих находок. |
| 2 | Плагин запускается в отдельном процессе, а не внутри backend. Прямого доступа к базе данных Hub у него нет. |
| 3 | Всё общение с внешним миром идёт через фиксированный набор из четырёх обращений к среде исполнения: выполнить HTTP-запрос, получить секрет, получить секрет проекта, записать сообщение в журнал. Адреса, к которым плагину разрешено обращаться, ограничены списком; секреты выдаются по запросу и в самом плагине не хранятся. |
| 4 | Система учёта возвращает сведения об узле: владелец, назначение, окружение. |
| 5 | Плагин возвращает результат в виде меток. |
| 6 | Метки сохраняются у находки и становятся доступны для фильтрации, поиска и правил маршрутизации. |
| 7 | Параллельно работает собственная интеграция с NetBox: адреса и зоны оттуда служат источником периметра, а в карточке находки адрес становится ссылкой на поиск в NetBox. |
| 8 | Аналитик отбирает находки по владельцу, окружению или назначению узла — а не только по критичности. |
Что нужно с вашей стороны¶
- Система учёта активов с доступным API и учётная запись только на чтение.
- Решение о том, какие поля из неё допустимо переносить в Hub.
- Для NetBox — токен доступа и договорённость о метках, по которым различаются учтённые и обнаруженные адреса.
Подробности: Плагины, NetBox, Происхождение записей.