План реагування на інциденти безпеки
QR Branding API — ст. 33–34 GDPR
| Поле | Значення |
|---|---|
| Контролер | QR Branding (Quartzon) |
| Дата | 2026-03-08 |
| Версія | 1.0 |
| Наступний перегляд | 2026-09-08 |
1. Мета
Встановити структуровану процедуру виявлення, реагування та повідомлення про порушення безпеки, що зачіпають персональні дані, відповідно до вимог ст. 33 GDPR (повідомлення наглядового органу) і ст. 34 (повідомлення суб’єктів даних).
2. Визначення
| Термін | Визначення |
|---|---|
| Порушення захисту персональних даних | Порушення безпеки, що призводить до випадкового чи незаконного знищення, втрати, зміни або несанкціонованого розкриття персональних даних (ст. 4(12) GDPR) |
| Інцидент безпеки | Будь-яка подія, що порушує конфіденційність, цілісність або доступність системи, незалежно від того, чи стосується вона персональних даних |
| Нульовий момент (T0) | Момент, коли інцидент виявлено або про нього стало відомо |
3. Класифікація інцидентів
Рівень 1 — Критичний (порушення захисту персональних даних)
- Розкриття вмісту QR із персональними даними (vCard, email, номери телефонів)
- Розкриття промптів ШІ користувачів
- Витік ключів API (RapidAPI, провайдери LLM)
- Несанкціонований доступ до Application Insights із даними користувачів
- Компрометація ланцюга постачання (шкідлива залежність NuGet)
Рівень 2 — Високий (інцидент безпеки без підтвердженого залучення персональних даних)
- Успішне використання вразливості (SSRF, ін’єкція тощо)
- Тривала відмова в обслуговуванні
- Компрометація конвеєра CI/CD (GitHub Actions)
- Несанкціонований доступ до Azure App Settings або секретів
- Аномальна поведінка провайдера LLM (відповіді з даними інших користувачів)
Рівень 3 — Середній (локалізований інцидент)
- Спроби атак, виявлені й заблоковані обмеженням частоти
- Виявлено сканування вразливостей
- Залежність з опублікованою CVE (використання не підтверджено)
- Погіршення роботи сервісу через зловживання ресурсами
Рівень 4 — Низький (інформаційна подія)
- Невдалі спроби автентифікації
- Звичайні спрацювання обмеження частоти
- Сповіщення про продуктивність (холодні старти, тайм-аути)
4. Процедура реагування
Фаза 1: Виявлення та сортування (T0 → T0+1h)
| Крок | Дія | Відповідальний |
|---|---|---|
| 1.1 | Визначити джерело сповіщення (Application Insights, GitHub Security Advisories, повідомлення користувача, моніторинг) | Технічна команда |
| 1.2 | Класифікувати інцидент за рівнем (розділ 3) | Технічна команда |
| 1.3 | Задокументувати, що виявлено, коли, як і орієнтовний масштаб | Технічна команда |
| 1.4 | Для рівня 1 або 2: негайно передати питання відповідальному за захист даних | Технічна команда |
Фаза 2: Стримування (T0+1h → T0+4h)
| Крок | Дія |
|---|---|
| 2.1 | Негайне стримування залежно від типу інциденту: |
| - Витік ключа API → негайно змінити його в Azure App Settings і в провайдера | |
| - Використана вразливість → розгорнути термінове виправлення або вимкнути уражений ендпоінт | |
| - SSRF/ін’єкція → заблокувати шаблон атаки на етапі перевірки | |
| - Компрометація CI/CD → відкликати токени GitHub, перевірити останні коміти | |
| 2.2 | Зберегти докази (журнали Application Insights, знімки конфігурації) |
| 2.3 | Перевірити ефективність стримування |
| 2.4 | Оцінити, чи зачеплено персональні дані → визначити, чи є це порушенням за GDPR |
Фаза 3: Повідомлення за GDPR (за потреби)
Ст. 33 — Повідомлення наглядового органу (протягом 72 год від T0)
Потрібне лише тоді, коли порушення створює ризик для прав і свобод фізичних осіб.
Зміст повідомлення:
- Характер порушення (які дані, орієнтовна кількість суб’єктів даних)
- Контактні дані контролера
- Імовірні наслідки порушення
- Вжиті або заплановані заходи для його усунення
Коли повідомлення НЕ потрібне:
- Інциденти доступності (DoS) без розкриття даних
- Успішно заблоковані спроби атак
- Інциденти, що стосуються лише неперсональних даних (конфігурація, код)
Контекст QR Branding: Оскільки сервіс працює без збереження стану й не зберігає персональних даних, більшість інцидентів не є порушенням захисту персональних даних. Винятками можуть бути:
- Розкриття журналів Application Insights із метаданими запитів
- Перехоплення трафіку під час передачі (малоймовірно завдяки TLS)
- Аномальна поведінка провайдера LLM, що розкриває промпти інших користувачів
Ст. 34 — Повідомлення суб’єктів даних
Потрібне лише тоді, коли порушення створює високий ризик для прав і свобод.
Не потрібне, якщо:
- Дані були зашифровані або анонімізовані
- Вжито заходів, які гарантують, що ризик більше не може реалізуватися
- Це потребувало б непропорційних зусиль (у такому разі робиться публічне повідомлення)
Фаза 4: Усунення та відновлення (T0+4h → T0+48h)
| Крок | Дія |
|---|---|
| 4.1 | Визначити й усунути першопричину |
| 4.2 | Застосувати постійні патчі або виправлення |
| 4.3 | Виконати регресійні тести |
| 4.4 | Розгорнути в продакшн через CI/CD (GitHub Actions → Azure) |
| 4.5 | Перевірити, що виправлення діє в продакшні |
| 4.6 | Пильно відстежувати стан протягом 48–72 год після виправлення |
Фаза 5: Після інциденту (T0+48h → T0+2 тижні)
| Крок | Дія |
|---|---|
| 5.1 | Повністю задокументувати інцидент (хронологія, вплив, реагування) |
| 5.2 | Провести аналіз першопричин (RCA) |
| 5.3 | Визначити запобіжні покращення |
| 5.4 | Оновити DPIA, якщо інцидент виявив раніше не враховані ризики |
| 5.5 | Оновити цей план, якщо виявлено прогалини в процедурі |
| 5.6 | Поділитися отриманими уроками (без чутливих даних) |
5. Реєстр інцидентів (ст. 33(5))
Кожен інцидент має бути зареєстрований, незалежно від того, чи потребує він повідомлення органу. Реєстр має містити:
| Поле | Опис |
|---|---|
| ID інциденту | Унікальний ідентифікатор (INC-YYYY-NNN) |
| Дата/час виявлення | T0 |
| Дата/час стримування | Завершення фази 2 |
| Класифікація | Рівень 1–4 |
| Опис | Що сталося |
| Зачеплені дані | Категорії персональних даних, яких це стосується (за наявності) |
| Зачеплені суб’єкти даних | Орієнтовна кількість |
| Першопричина | Результат RCA |
| Вжиті заходи | Дії зі стримування та виправлення |
| Повідомлення органу | Так/Ні, дата, номер |
| Повідомлення суб’єктів даних | Так/Ні, дата, канал |
| Розв’язання | Остаточний статус і дата закриття |
6. Ключові контакти
| Роль | Контакт |
|---|---|
| Технічний керівник | Команда QR Branding |
| Конфіденційність/DPO | support@qr-branding.com |
| RapidAPI Platform | Підтримка RapidAPI |
| Microsoft Azure Support | Портал Azure |
Наглядові органи (довідково)
| Країна | Орган | Вебсайт |
|---|---|---|
| Іспанія | AEPD | aepd.es |
| ЄС (загалом) | EDPB | edpb.europa.eu |
7. Навчання
Щонайменше одне навчання з реагування на інциденти на рік проводиться для того, щоб:
- Перевірити, що процедура працює
- Виміряти час реагування
- Виявити прогалини в можливостях чи комунікації
- Ознайомити команду з процесом
Документ створено 2026-03-08. Наступний плановий перегляд: 2026-09-08.