Plan reagowania na incydenty
Obowiązuje od: 2 czerwca 2026
Niniejszy Plan reagowania na incydenty („Plan") określa, w jaki sposób STANDOUT Inc. („my", „nas") wykrywa incydenty bezpieczeństwa, zakłócenia usługi i naruszenia danych wpływające na usługę VATES („Usługa"), reaguje na nie, odzyskuje po nich sprawność i wyciąga z nich wnioski. Plan odwołuje się do NIST SP 800-61 Rev.2 oraz ISO/IEC 27035 i opiera się na zasadzie projektowej, zgodnie z którą zautomatyzowane instrumenty monitorujące stanowią pierwszą linię wykrywania.
1. Cel i zakres
Celami niniejszego Planu są:
- Terminowe wykrywanie zdarzeń mogących wpłynąć na dostępność, poufność lub integralność Usługi.
- Zdefiniowanie procedur ograniczania i odzyskiwania, które minimalizują wpływ.
- Wypełnienie obowiązków powiadamiania wobec dotkniętych Klientów i organów regulacyjnych.
- Umożliwienie ciągłego doskonalenia jakości operacyjnej poprzez ustrukturyzowaną analizę poincydentalną.
Niniejszy Plan ma zastosowanie do środowiska produkcyjnego Usługi (EC2, Cloudflare i powiązani dostawcy SaaS), ścieżki komunikacyjnej od Usługi do nadrzędnych dostawców AI oraz całej pamięci masowej przechowującej dane Klienta.
2. Definicja incydentu i klasyfikacja dotkliwości
2.1 Definicja incydentu
Na potrzeby niniejszego Planu incydentem jest każde zdarzenie odpowiadające jednemu lub większej liczbie z poniższych:
- Podejrzenie nieautoryzowanego dostępu, kompromitacji poświadczeń lub włamania do systemu.
- Nieautoryzowane ujawnienie, zmiana lub utrata danych Klienta, w tym danych osobowych.
- Awaria lub znaczące pogorszenie wydajności wpływające na podstawową funkcjonalność Usługi.
- Zagrożenia bezpieczeństwa, w tym infekcja malware, ransomware lub ataki na łańcuch dostaw.
- Błąd operacyjny, błędna konfiguracja lub defekt oprogramowania skutkujący wielkoskalowym wpływem.
2.2 Klasyfikacja dotkliwości
Każdy incydent jest w momencie wykrycia klasyfikowany do jednego z następujących poziomów dotkliwości:
- P1 (Krytyczny): Całkowita awaria Usługi lub potwierdzone naruszenie danych obejmujące dane osobowe. Wymaga natychmiastowej reakcji.
- P2 (Wysoki): Znaczące upośledzenie podstawowej funkcjonalności, niedostępność dla określonych Klientów lub anomalie uwierzytelniania. Reakcja początkowa wymagana w ciągu jednej godziny.
- P3 (Średni): Częściowe upośledzenie funkcjonalne lub pogorszenie wydajności z dostępnymi obejściami. Reakcja w godzinach pracy jest akceptowalna.
- P4 (Niski): Zdarzenia o ograniczonym wpływie na użytkownika, drobny dryf integralności logów lub zmniejszona redundancja instrumentów monitorujących. Rozwiązywane w kolejnym zaplanowanym cyklu przeglądu.
3. Struktura reagowania
3.1 Osoba odpowiedzialna
Osobą odpowiedzialną za niniejszy Plan jest Takuya Aoki, Managing Director w STANDOUT Inc. i kierownik rozwoju VATES. Wszelkie uprawnienia decyzyjne oraz uprawnienia do powiadomień zewnętrznych podczas incydentu są skonsolidowane w osobie odpowiedzialnej.
3.2 Zautomatyzowane instrumenty wykrywania
Usługa utrzymuje w pełni zautomatyzowaną, ciągłą postawę monitorowania złożoną z następujących instrumentów. Działają one niezależnie od osoby odpowiedzialnej i wyzwalają natychmiastowe powiadomienie po spełnieniu warunków progowych.
- Cloudflare Health Check: Sonduje produkcyjny serwer origin z wielu geograficznych punktów obserwacyjnych w 60-sekundowych odstępach.
- HetrixTools: Monitoruje produkcyjne punkty końcowe z wielu globalnych punktów obserwacyjnych przez ścieżkę niezależną od Cloudflare.
- Sentry: Przechwytuje wyjątki aplikacji w czasie rzeczywistym i powiadamia osobę odpowiedzialną.
- Cloudflare WAF (Managed Rules + OWASP Core Ruleset): Blokuje znane wzorce ataków w trybie Block.
- Cloudflare DDoS Protection: Ciągle i automatycznie łagodzi ataki DDoS w warstwie sieciowej, warstwie SSL/TLS i warstwie HTTP.
- Wsad wykrywania anomalii (systemd timer): Skanuje logi audytu co pięć minut i wykrywa trzy kategorie: wysoką częstotliwość żądań, wysoki wskaźnik odmów autoryzacji oraz próby brute-force.
- Rate Limiting: Ograniczanie liczby żądań na najemcę na punktach końcowych użycia oraz ograniczanie oparte na IP na punktach końcowych uwierzytelniania, automatycznie odrzucające nadmiarowy ruch.
- Konfigurowalne alerty bezpieczeństwa: Klienci mogą wybrać, które zdarzenia operacyjne (niskie saldo, logowanie z nowej lokalizacji, zablokowany dostęp, powtarzające się nieudane logowania) wyzwalają powiadomienia e-mail, z progami czułości dla każdego zdarzenia.
- Infrastruktura logu audytu: Rejestruje każde wywołanie API w odpornym na manipulacje logu audytu w łańcuchu skrótów (SHA-256, sekwencja na najemcę) i konsoliduje wpisy do niezależnej weryfikacji.
- Pulpit statusu (9 health pills): Wizualizuje audyt, anomalie, GeoIP, kopię zapasową, wsad usuwania, pokrycie katalogu, dryf uzgodnień, killswitch oraz kondycję usługi na jednym ekranie.
- Zautomatyzowana kopia zapasowa: Szyfruje migawki SQLite za pomocą GPG AES-256 i przechowuje 30 dziennych generacji.
3.3 Delegowanie reagowania pierwszej linii do automatyzacji
Etapy wykrywania i triage są realizowane przez powyższe zautomatyzowane instrumenty jako pierwsza linia. Osoba odpowiedzialna interweniuje wyłącznie po otrzymaniu powiadomień o przekroczeniu progu. Taki projekt zapewnia, że całodobowe pokrycie wykrywania jest fizycznie ustanowione bez zależności od lokalizacji czy dostępności osoby odpowiedzialnej.
4. Proces reagowania
4.1 Wykrywanie
Gdy jeden lub więcej zautomatyzowanych instrumentów opisanych w Sekcji 3.2 wykryje anomalię, osoba odpowiedzialna jest natychmiast powiadamiana za pośrednictwem Sentry, poczty e-mail oraz alertów pulpitu. Zgłoszenia Klientów są odbierane na adres [email protected] i rejestrowane w tym samym przepływie.
4.2 Triage
Po otrzymaniu powiadomienia osoba odpowiedzialna potwierdza dotkliwość, badając:
- Zakres wpływu (wszyscy Klienci / określony Klient / pojedyncza instancja).
- Czy dotknięte są dane osobowe, poświadczenia uwierzytelniania lub informacje rozliczeniowe.
- Udział czynników zewnętrznych (awarie nadrzędnego dostawcy AI, awarie Cloudflare, awarie AWS).
- Korelację ze znanymi wzorcami ataków (logi WAF, wyniki wykrywania anomalii, alerty GeoIP).
4.3 Ograniczanie
W zależności od dotkliwości stosuje się jeden lub więcej z następujących środków ograniczających:
- Zawieszenie dotkniętych instancji za pośrednictwem maszyny stanów w celu natychmiastowej izolacji.
- Dodanie źródłowych adresów IP do listy zablokowanych (na Klienta lub globalnie).
- Masowe unieważnienie sesji według JWT jti.
- Aktywacja killswitch (całkowite wstrzymanie ruchu, środek ostateczny).
- Aktywacja trybu Cloudflare „Under Attack Mode" przeciwko atakom L7.
4.4 Odzyskiwanie
Po ograniczeniu przyczyny źródłowe są eliminowane i wykonywane są następujące działania:
- Przywrócenie z kopii zapasowej w razie potrzeby (procedury udokumentowane w docs/RESTORE.md).
- Rotacja dotkniętych poświadczeń (klucze API, sekrety JWT, klucze szyfrowania kopii zapasowych itd.).
- Zastosowanie łatek, poprawek konfiguracji i korekt kodu w środowisku produkcyjnym.
- Weryfikacja w środowiskach staging i produkcyjnym.
- Kontynuowana obserwacja przez co najmniej 24 godziny za pośrednictwem instrumentów monitorujących.
4.5 Poincydentalnie
Po potwierdzeniu odzyskania sprawności osoba odpowiedzialna:
- Dokumentuje oś czasu, przyczynę źródłową, zakres wpływu oraz działania reagujące.
- Identyfikuje i włącza środki zapobiegawcze do mapy drogowej implementacji.
- W stosownych przypadkach powiadamia dotkniętych Klientów oraz organy regulacyjne (patrz Sekcja 5).
- Przekazuje ulepszenia z powrotem do niniejszego Planu i powiązanych dokumentów operacyjnych.
5. Powiadamianie Klientów i organów regulacyjnych
5.1 Powiadomienie o naruszeniu danych osobowych
Jeśli potwierdzone zostanie nieautoryzowane pozyskanie, utrata lub ujawnienie danych osobowych, przekazujemy powiadomienie zgodnie z:
- Ogólne rozporządzenie UE o ochronie danych (GDPR) Artykuł 33: Powiadomienie organu nadzorczego w ciągu 72 godzin od powzięcia wiadomości.
- GDPR Artykuł 34: W przypadku stwierdzenia wysokiego ryzyka powiadomienie dotkniętych osób, których dane dotyczą, bez zbędnej zwłoki.
- Ustawa o ochronie informacji osobowych (Japonia): Zgłoszenie do Komisji Ochrony Informacji Osobowych oraz powiadomienie osób, których dane dotyczą, zgodnie z obowiązującymi rozporządzeniami i przepisami wykonawczymi.
- Inne obowiązujące jurysdykcje: Powiadomienia wymagane przez obowiązujące krajowe lub regionalne przepisy o ochronie danych.
5.2 Powiadomienie o zakłóceniu usługi
W przypadku zakłóceń usługi sklasyfikowanych jako P1 lub P2 powiadamiamy dotkniętych Klientów bez zbędnej zwłoki, w tym o przewidywanym harmonogramie odzyskania sprawności oraz o wszelkich środkach tymczasowych. Kanałami powiadamiania są [email protected] oraz konsola administracyjna Usługi.
5.3 Metoda powiadamiania
Powiadomienia są dostarczane przede wszystkim e-mailem na zarejestrowany adres Klienta, uzupełniane w razie potrzeby banerami w konsoli administracyjnej.
6. Post-Mortem i cykl uczenia się
Po incydencie P1 lub P2 osoba odpowiedzialna przeprowadza Post-Mortem i dokumentuje następujące pozycje. Dokument jest przechowywany wewnętrznie i udostępniany Klientom oraz audytorom na żądanie.
- Oś czasu zdarzeń od wykrycia do odzyskania sprawności.
- Analizę przyczyny źródłowej (czynniki techniczne i operacyjne).
- Skwantyfikowany zakres wpływu.
- Ocenę procesu reagowania.
- Środki zapobiegawcze i docelowe terminy.
Post-Mortemy są prowadzone jako Blameless Post-Mortems, skupione na poprawie strukturalnej, a nie na odpowiedzialności indywidualnej.
7. Utrzymanie i przegląd Planu
7.1 Przegląd okresowy
Niniejszy Plan jest przeglądany co najmniej raz w roku, a także po każdym istotnym incydencie, przy istotnych zmianach architektury Usługi oraz przy zmianach obowiązujących przepisów prawa i regulacji.
7.2 Historia zmian
Historia zmian niniejszego Planu jest utrzymywana wewnętrznie i udostępniana Klientom oraz audytorom na żądanie.
8. Kontakt
Aby zgłosić incydent lub zadać pytania dotyczące niniejszego Planu:
STANDOUT Inc.
E-mail: [email protected]
Ostatnia aktualizacja: 2 czerwca 2026