Интеграция с SOC
GRC не живёт отдельно от SOC — картина активов и рисков всплывает прямо на кейсе.
12.1. Виджет бизнес-влияния кейса
Когда активы связаны с кейсом (вручную или автосопоставлением), деталь кейса
показывает виджет Business Impact (case_business_impact) и таблицу активов
(asset_table), которые показывают радиус поражения: каких активов касается
инцидент, их критичность и к каким информационным системам они относятся. Связь
двусторонняя — из кейса вы доходите до его активов, а из вкладки Cases актива — до
его кейсов (ограничено самыми недавними, soft-deleted кейсы исключены).
12.2. Рекомендации приоритета
Когда бизнес-критичный актив связан с кейсом, виджет Business Impact показывает чип рекомендации — например, «GRC recommends High severity (asset: PAY-DB, criticality critical)» — с кнопками Apply и Dismiss. Рекомендация исходит из высшей критичности связанного актива плюс радиус поражения (повышение на один уровень, когда активы охватывают ≥2 информационные системы, ≥3 связанных актива или инцидент направления source high/critical) и появляется только как строгое повышение над текущей severity кейса.
По умолчанию ничто не меняется автоматически:
- Apply задаёт severity через атомарный путь severity кейса (он пишет событие таймлайна и запись аудита; имя подходящей политики SLA показывается, но SLA консультативен, не форсируется).
- Dismiss сохраняет текущий приоритет и подавляет рекомендацию.
Команды, желающие «без рук», могут подписать конкретные типы инцидентов на auto-apply в Settings → GRC → Case-priority recommendation (раздел 10.7). Даже тогда ручное переопределение оператора всегда побеждает и записывается устойчиво, и каждое применение / переопределение пишется в аудит-лог.
12.3. Связи кейс ↔ актив
Связи активов на кейсе — это то, что питает и виджет бизнес-влияния, и движок риска актива: открытый кейс на активе повышает риск этого актива (и риск систем, в которые он сворачивается), питает реестр рисков и — для провалившегося привязанного контроля — может открыть элемент ремедиации. Это петля, превращающая активность SOC в управляемый риск.
Приложение. Ежедневные фоновые задания
Модуль GRC запускает набор ежедневных фоновых заданий (гейтятся
ENABLE_GRC_SCHEDULERS, плюс ENABLE_ASSET_SYNC для синхронизации). Они
идемпотентны и выполняются раз в день:
| Задание | Что делает |
|---|---|
| Exception expiry | Переводит просроченные утверждённые исключения в expired и уведомляет (та же работа, что ручной Run expiry sweep) |
| Reminder sweep | Уведомляет ответственного владельца(ев) заранее о приближающемся истечении исключения, ревью политики, ревью риска, просроченном treatment action, просроченной ремедиации, due кампании и due запроса доказательств, а также просроченной аттестации политики |
| Risk snapshot | Пересчитывает риск каждого живого актива, пишет не более одной базовой точки на актив в день для графика тренда риска, затем обновляет каждый rollup системы |
| Posture snapshot | Пишет один организационный снимок posture в день (coverage %, org risk, счётчики пробелов контролей) для графиков тренда дашборда |
| Control checks | Плановые запуски проверок контролей возвращают вердикты и — когда авторемедиация вкл — открывают элемент ремедиации при провале |
| Digest delivery | Когда opt-in еженедельный дайджест включён, доставляет один дайджест на получателя за ISO-неделю (в приложении + по почте) |
| Asset sync | Тянет каждый настроенный источник синхронизации активов (гейтится ENABLE_ASSET_SYNC) |
Семантика напоминаний. Свёртка напоминаний уведомляет на каждом пороге
days-before (grc.reminder_days, по умолчанию T-30 / T-7 / T-0). Она
идемпотентна по дизайну: она забирает строку леджера (entity, threshold, target date) перед уведомлением, поэтому повтор или пропущенный запуск никогда не уведомят
дважды, а перенос даты перевзводит напоминания на новую дату. Каждое уведомление
доставляется в собственном тенанте получателя, в приложении и по почте.
← К оглавлению · Руководство администратора · Руководство аналитика