Розклади сканування¶
ScanSchedule — це правило, як часто і коли запускати конкретний detection service.
Як створити¶
- Schedules → New Schedule.
- Вибрати тип скану: HIBP / Pastebin / Code (GitHub+GitLab) / Ransomware.
- Задати назву — для зручності, наприклад "GitHub hourly — production domains".
- Налаштувати параметри (нижче).
- Save.
Параметри¶
Frequency (частота)¶
hourly— кожну годину.every_6h— кожні 6 годин.daily— раз на добу.weekly— раз на тиждень.monthly— раз на місяць.disabled— пауза (зберігається, але не виконується).
Start at (час старту)¶
Якщо ви не хочете, щоб сканування починалось одразу при створенні розкладу — поставте конкретний datetime у майбутньому. Корисно:
- Уникнути сплесків навантаження одночасно з ранковим браузингом дашборда.
- Скани вночі (наприклад,
02:00 UTC) — менш помітні в логах вашої інфраструктури.
Active (вкл/викл)¶
Тимчасова пауза без втрати налаштувань. Корисно при:
- Дебагу false positives — на час відключаєте розклад, налаштовуєте фільтри, вмикаєте знову.
- Обмеженні quota — наприклад, ви перевершили місячний ліміт HIBP API і хочете дочекатись наступного місяця.
Linked report (прив'язаний звіт)¶
Опційно — кожен скан буде автоматично оновлювати прив'язаний звіт. Корисно для:
- Регулярних звітів CISO — звіт завжди свіжий.
- Compliance audits — auditor бачить актуальні дані.
- Customer-facing reports (для MSSP) — клієнт автоматично отримує оновлення.
Приклади розкладів¶
Маленька компанія (10 співробітників)¶
| Schedule | Type | Frequency | Start | Linked report |
|---|---|---|---|---|
| Daily HIBP | HIBP | daily | 02:00 | Weekly CISO report |
| Hourly Pastebin | Pastebin | hourly | — | — |
| Hourly Code | Code | hourly | — | — |
| Ransomware watch | Ransomware | every_6h | — | Monthly board report |
Enterprise (1000+ співробітників)¶
Як вище, плюс: - Multiple HIBP schedules для різних доменів (subsidiaries). - Окремий розклад на critical DataSources з частотою hourly. - Окремий розклад на legacy/low-priority — щотижня.
Як це працює технічно¶
Розклади виконує Celery Beat — внутрішній планувальник. У момент часу T:
- Планувальник бачить, що для цього розкладу настав час.
- Створює task у черзі.
- Worker підбирає task і виконує сканування.
- Зберігає знахідки, оновлює linked report, надсилає сповіщення.
Якщо worker перевантажений — task стоїть у черзі, scheduler не пропускає cycle.
Що зробити якщо¶
Розклад не виконується?
- Перевірити Active стан.
- Перевірити, чи detection service підключений і має валідний API-ключ.
- Перевірити Audit log у Settings — там видно помилки.
Дублюються запуски? Може статись, якщо створили два розклади з однаковими параметрами. Перевірте, нема дублів.
Скан виконується надто довго?
Деякі скани (Org-based GitHub великої організації) можуть тривати години. Частота every_6h для них правильніша, ніж hourly — інакше скан наступного раунду стартує до завершення попереднього.