План реагування на інциденти

Чинний з: 2 червня 2026 р.

Цей План реагування на інциденти («План») визначає, як STANDOUT Inc. («ми», «нас») виявляє, реагує, відновлюється та навчається на інцидентах безпеки, збоях сервісу та витоках даних, що впливають на сервіс VATES («Сервіс»). План спирається на NIST SP 800-61 Rev.2 та ISO/IEC 27035 і побудований на принципі, що автоматизовані інструменти моніторингу слугують передньою лінією виявлення.

1. Мета та сфера застосування

Цілі цього Плану:

• Своєчасно виявляти події, що можуть вплинути на доступність, конфіденційність чи цілісність Сервісу.
• Визначити процедури стримування та відновлення, що мінімізують вплив.
• Дотримуватися зобов’язань щодо повідомлення уражених Клієнтів та регуляторних органів.
• Забезпечити безперервне вдосконалення операційної якості через структурований післяінцидентний аналіз.

Цей План застосовується до робочого середовища Сервісу (EC2, Cloudflare та пов’язані SaaS-постачальники), каналу зв’язку від Сервісу до висхідних AI-постачальників та всіх сховищ, що містять дані Клієнта.

2. Визначення інциденту та класифікація серйозності

2.1 Визначення інциденту

Для цілей цього Плану інцидентом є будь-яка подія, що відповідає одному чи кільком із наступного:

• Підозра на несанкціонований доступ, компрометацію облікових даних або проникнення в систему.
• Несанкціоноване розкриття, зміна чи втрата даних Клієнта, включно з персональними даними.
• Простій чи значне погіршення продуктивності, що впливає на основну функціональність Сервісу.
• Загрози безпеці, включно із зараженням шкідливим ПЗ, програмами-вимагачами чи атаками на ланцюг постачання.
• Операційна помилка, неправильне налаштування чи дефект програмного забезпечення, що призводить до великомасштабного впливу.

2.2 Класифікація серйозності

Кожен інцидент класифікується в момент виявлення в один із наступних рівнів серйозності:

• P1 (Critical): повний простій Сервісу або підтверджений витік даних, що стосується персональних даних. Потребує негайного реагування.
• P2 (High): значне погіршення основної функціональності, недоступність для окремих Клієнтів або аномалії автентифікації. Початкове реагування потрібне протягом однієї години.
• P3 (Medium): часткове погіршення функціональності чи зниження продуктивності за наявності обхідних шляхів. Реагування протягом робочих годин прийнятне.
• P4 (Low): події з обмеженим впливом на користувачів, незначне відхилення цілісності журналів або знижена надлишковість інструментів моніторингу. Опрацьовуються в наступному запланованому циклі перегляду.

3. Структура реагування

3.1 Відповідальна особа

Відповідальною особою за цей План є Takuya Aoki, Managing Director STANDOUT Inc. та керівник розробки VATES. Уся повнота повноважень щодо прийняття рішень та зовнішнього повідомлення під час інциденту зосереджена у відповідальної особи.

3.2 Автоматизовані інструменти виявлення

Сервіс підтримує повністю автоматизований безперервний моніторинг, що складається з наступних інструментів. Вони працюють незалежно від відповідальної особи та ініціюють негайне сповіщення, щойно досягнуто порогових умов.

• Cloudflare Health Check: зондує робоче джерело з кількох географічних точок з інтервалом 60 секунд.
• HetrixTools: моніторить робочі кінцеві точки з кількох глобальних точок каналом, незалежним від Cloudflare.
• Sentry: фіксує винятки застосунку в реальному часі та сповіщає відповідальну особу.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): блокує відомі шаблони атак у режимі Block.
• Cloudflare DDoS Protection: безперервно й автоматично пом’якшує DDoS-атаки на мережевому рівні, рівні SSL/TLS та рівні HTTP.
• Anomaly Detection Batch (systemd timer): сканує журнали аудиту кожні п’ять хвилин і виявляє три категорії: висока частота запитів, висока частота відмов в авторизації та спроби перебору.
• Rate Limiting: обмеження частоти запитів для кожного орендаря на кінцевих точках використання та обмеження на основі IP на кінцевих точках автентифікації, що автоматично відхиляє надлишковий трафік.
• Configurable Security Alerts: Клієнти можуть обирати, які операційні події (низький баланс, вхід із нового місця, заблокований доступ, повторні невдалі входи) ініціюють сповіщення електронною поштою, з пороговими значеннями чутливості для кожної події.
• Audit Log Infrastructure: записує кожен виклик API у стійкий до підробки журнал аудиту на ланцюжку гешів (SHA-256, порядковий номер для кожного орендаря) та консолідує записи для незалежної перевірки.
• Status Dashboard (9 health pills): візуалізує аудит, аномалії, GeoIP, резервні копії, пакет видалення, покриття каталогу, відхилення звіряння, killswitch та стан сервісу на одному екрані.
• Automated Backup: шифрує знімки SQLite за допомогою GPG AES-256 та зберігає 30 щоденних поколінь.

3.3 Делегування передньої лінії реагування автоматизації

Етапи виявлення та сортування виконуються наведеними вище автоматизованими інструментами як передня лінія. Відповідальна особа втручається лише після отримання сповіщень про перевищення порогу. Такий підхід забезпечує фізичне встановлення цілодобового покриття виявлення без залежності від місцезнаходження чи доступності відповідальної особи.

4. Процес реагування

4.1 Виявлення

Коли один чи кілька автоматизованих інструментів, описаних у Розділі 3.2, виявляють аномалію, відповідальна особа негайно сповіщається через Sentry, електронну пошту та сповіщення інформаційної панелі. Звіти Клієнтів приймаються на [email protected] і потрапляють у той самий потік як тікети.

4.2 Сортування

Отримавши сповіщення, відповідальна особа підтверджує серйозність, вивчаючи:

• Обсяг впливу (усі Клієнти / окремий Клієнт / окремий екземпляр).
• Чи зачіпаються персональні дані, облікові дані автентифікації чи платіжна інформація.
• Причетність зовнішніх факторів (збої висхідних AI-постачальників, збої Cloudflare, збої AWS).
• Кореляцію з відомими шаблонами атак (журнали WAF, результати виявлення аномалій, сповіщення GeoIP).

4.3 Стримування

Залежно від серйозності застосовується один чи кілька з наступних заходів стримування:

• Призупинення уражених екземплярів через машину станів для негайної ізоляції.
• Додавання IP-адрес джерела до списку заборон (для кожного Клієнта або глобально).
• Масове відкликання сеансів за JWT jti.
• Активація killswitch (повна зупинка трафіку, захід останньої інстанції).
• Активація Cloudflare «Under Attack Mode» проти атак рівня L7.

4.4 Відновлення

Після стримування усуваються першопричини та виконується таке:

• Відновлення з резервної копії за потреби (процедури задокументовано в docs/RESTORE.md).
• Ротація уражених облікових даних (ключі API, секрети JWT, ключі шифрування резервних копій тощо).
• Застосування патчів, виправлень конфігурації та коду до робочого середовища.
• Перевірка на середовищах staging та production.
• Продовження спостереження щонайменше 24 години через інструменти моніторингу.

4.5 Після інциденту

Після підтвердження відновлення відповідальна особа:

• Документує хронологію, першопричину, обсяг впливу та дії реагування.
• Визначає й включає запобіжні заходи в дорожню карту впровадження.
• За потреби сповіщає уражених Клієнтів та регуляторні органи (див. Розділ 5).
• Повертає покращення в цей План та пов’язані операційні документи.

5. Повідомлення Клієнтів та регуляторів

5.1 Повідомлення про витік персональних даних

Якщо підтверджено несанкціоноване отримання, втрату чи розкриття персональних даних, ми надаємо повідомлення відповідно до:

• EU General Data Protection Regulation (GDPR) Article 33: повідомлення наглядового органу протягом 72 годин з моменту, коли стало відомо.
• GDPR Article 34: у разі виявлення високого ризику — повідомлення уражених суб’єктів даних без невиправданої затримки.
• Act on the Protection of Personal Information (Японія): звітування до Personal Information Protection Commission та повідомлення суб’єктів даних відповідно до застосовних урядових розпоряджень та правил.
• Інші застосовні юрисдикції: повідомлення, що вимагаються застосовними національними чи регіональними законами про захист даних.

5.2 Повідомлення про збій сервісу

Для збоїв сервісу, класифікованих як P1 чи P2, ми повідомляємо уражених Клієнтів без невиправданої затримки, включно з очікуваним строком відновлення та будь-якими проміжними пом’якшеннями. Каналами повідомлення є [email protected] та консоль адміністрування Сервісу.

5.3 Спосіб повідомлення

Повідомлення надсилаються переважно електронною поштою на зареєстровану адресу Клієнта, доповнюючись за потреби банерами в консолі адміністрування.

6. Post-Mortem та цикл навчання

Після інциденту P1 чи P2 відповідальна особа проводить Post-Mortem і документує наступні пункти. Документ зберігається всередині компанії та розкривається Клієнтам і аудиторам за запитом.

• Хронологію подій від виявлення до відновлення.
• Аналіз першопричини (технічні та операційні фактори).
• Кількісно оцінений обсяг впливу.
• Оцінку процесу реагування.
• Запобіжні заходи та цільові строки.

Post-Mortem проводяться як Blameless Post-Mortems, зосереджені на структурному вдосконаленні, а не на індивідуальній відповідальності.

7. Підтримання та перегляд Плану

7.1 Періодичний перегляд

Цей План переглядається щонайменше щороку, а також після будь-якого значного інциденту, при суттєвих змінах архітектури Сервісу та при змінах застосовних законів і норм.

7.2 Історія редакцій

Історія редакцій цього Плану ведеться всередині компанії та розкривається Клієнтам і аудиторам за запитом.

8. Контакти

Щоб повідомити про інцидент або поставити запитання щодо цього Плану:

STANDOUT Inc.
Email: [email protected]

Останнє оновлення: 2 червня 2026 р.