Моніторинг — огляд¶
Моніторинг — це автоматизація detection services. Замість того, щоб руками запускати сканування і перевіряти результати, ви налаштовуєте розклади і отримуєте сповіщення тільки коли щось знайдено.
Концепція continuous monitoring¶
Безпека — це не "одноразовий audit раз на квартал". Це безперервний процес:
- Безперервне сканування — нові витоки з'являються щодня. Рідкісні скани = пропущені інциденти.
- Real-time сповіщення — швидкість реакції критична. Дамп на pastebin живий кілька годин до індексації.
- Closed-loop — кожен finding має lifecycle: new → acknowledged → resolved. Платформа треш
MTTR(Mean Time To Resolve).
Компоненти моніторингу¶
| Компонент | Що робить | Деталі |
|---|---|---|
| Розклади сканування | Коли і як часто запускати кожен detection service | Розклади |
| Сповіщення | Куди надсилати alerts (email, webhook) | Сповіщення |
| Правила | Які findings тригерять сповіщення (по severity, тегах) | Сповіщення |
| Audit log | Хто і коли робив які дії з findings | Розділ Settings |
Рекомендована конфігурація¶
Базова стратегія для типової компанії:
| Сервіс | Частота | Severity для alert |
|---|---|---|
| HIBP | Щодня | High+ |
| Pastebin | Щогодини | Medium+ |
| GitHub | Щогодини | High+ |
| GitLab | Щогодини | High+ |
| Ransomware | Кожні 6 годин | Critical (завжди) |
Можна додати другий канал сповіщень — наприклад, Slack-webhook для не-critical і email тільки для critical, щоб не топити inbox.
Quiet hours¶
Якщо у вас є робочі години (наприклад, Mon-Fri 9-18), можна налаштувати:
- Critical — завжди надходять одразу.
- High/Medium/Low — batched dispatch у робочі години.
Налаштування — Settings → Notifications → Quiet hours.
Що далі¶
- Розклади сканування — як створити і налаштувати.
- Сповіщення — канали і правила.