Bezpieczeństwo — Attestia.eu

Wersją wiążącą jest wersja polska. Wersja angielska ma charakter informacyjny.

Wersja / Version: 1.0 Data wejścia w życie / Effective date: 2026-04-22 Ostatnia aktualizacja / Last updated: 2026-04-22 Dokumenty powiązane:

• Załącznik A do DPA (Środki techniczne i organizacyjne) — attestia.eu/terms
• Polityka Prywatności sekcja 11 (Bezpieczeństwo danych) — attestia.eu/privacy
• Polityka Prywatności sekcja 12 (Naruszenia ochrony danych) — attestia.eu/privacy

1. Nasze podejście do bezpieczeństwa

Attestia jest platformą SaaS dla compliance — a to oznacza, że powierzone nam dane (opisy Systemów AI Organizacji, dokumentacja compliance, Dziennik audytu) stanowią często tajemnicę przedsiębiorstwa. Bezpieczeństwo nie jest dla nas funkcją — jest warunkiem koniecznym prowadzenia tej działalności.

Niniejsza strona opisuje naszą postawę bezpieczeństwa: architekturę, mechanizmy ochronne, procedury reagowania na incydenty oraz kanał odpowiedzialnego zgłaszania podatności. Jest uzupełnieniem Załącznika A do DPA (Środki techniczne i organizacyjne) — tam znajduje się formalna specyfikacja wynikająca z umowy powierzenia.

Określenia pisane wielką literą mają znaczenie nadane im w Regulaminie Attestia.eu.

2. Infrastruktura i dane w UE

Zasada: Dane Organizacji, Dokumenty Compliance i dane przetwarzane przez AI pozostają w granicach UE/EOG. Szczegółowa lista podprocesorów: attestia.eu/subprocessors.

3. Szyfrowanie

3.1. W tranzycie (in transit)

• TLS 1.3 dla wszystkich połączeń HTTPS (wymuszony na poziomie CDN Vercel).
• HSTS włączony z flagą includeSubDomains i preload.
• Słabsze wersje TLS (1.0, 1.1) są odrzucane.
• Połączenia baza ↔ aplikacja oraz aplikacja ↔ Azure OpenAI są szyfrowane TLS 1.3.

3.2. W spoczynku (at rest)

• AES-256 na poziomie bazy danych PostgreSQL (Supabase).
• AES-256 na woluminach Azure (Azure Storage Service Encryption).
• Klucze zarządzane przez dostawców (Supabase/Azure KMS). Rotacja zgodnie z cyklami dostawców.

3.3. Haseł

• bcrypt (Supabase Auth, domyślna konfiguracja — cost factor 10+).
• Minimalne wymagania: 8+ znaków, detekcja haseł z rainbow tables.
• Nie logujemy haseł w czystej postaci w żadnym etapie przetwarzania.

4. Kontrola dostępu i uwierzytelnianie

5. Dziennik audytu (Audit Log)

Zgodnie z art. 18 EU AI Act oraz § 12.4 Regulaminu, Platforma prowadzi niezmienny Dziennik audytu:

• Hash-chain — każdy wpis zawiera hash SHA-256 poprzedniego wpisu (model łańcucha Merkle-light).
• Append-only — brak możliwości modyfikacji ani usunięcia wpisów.
• Zakres — każda istotna operacja compliance (utworzenie/edycja Klasyfikacji, generowanie Dokumentu, akceptacja rekomendacji AI, eksport danych, zmiany ról).
• Retencja — 10 lat od daty ostatniego wpisu, w formie pseudonimizowanej (identyfikatory Użytkowników i Organizacji zastępowane nieodwracalnymi hashami po rozwiązaniu umowy).
• Dostęp — tylko dla uprawnionych ról w Organizacji + wewnętrznego zespołu Attestia w trybie break-glass z własnym logiem.

Dziennik audytu jest elementem obrony przed manipulacją historią decyzji compliance i dowodem należytej staranności w przypadku audytu regulatora.

6. Pseudonimizacja przy AI

Opisy Systemów AI wysyłane do Azure OpenAI są pseudonimizowane przed wysyłką:

• Usuwane: nazwa Organizacji, imiona i nazwiska Użytkowników, adresy e-mail, identyfikatory Konta, dane rozliczeniowe.
• Zachowywane: treść merytoryczna opisu Systemu AI (niezbędna do klasyfikacji).
• Odwzorowanie pseudonim → rzeczywisty identyfikator jest przechowywane wyłącznie po stronie Attestia i nie jest wysyłane do AI.

Dzięki temu nawet w scenariuszu kompromitacji Azure OpenAI (pomimo zobowiązań umownych Microsoft) dane Organizacji nie są bezpośrednio atrybuowalne.

Szczegóły: § 7 ust. 5 Regulaminu + sekcja 4.3 Polityki Prywatności + attestia.eu/transparency.

7. Backupy i ciągłość działania

8. Monitoring i wykrywanie incydentów

• Sentry — monitoring błędów aplikacji, alerty na anomalie.
• Supabase logs — logi zapytań bazy danych, detekcja nietypowych wzorców.
• Vercel analytics — monitoring dostępności (uptime).
• Alerting — alerty na krytyczne błędy aplikacji, nieautoryzowane próby dostępu do zasobów administracyjnych, podejrzane wzorce API calls.
• Śledzenie zależności (CVE) — automatyczne skanowanie zależności npm (Dependabot / GitHub Advanced Security) + manualny przegląd alertów.

9. Procedura reagowania na incydenty (Incident Response)

9.1. Klasyfikacja incydentów

9.2. Tryb zgłaszania naruszeń ochrony danych

W przypadku potwierdzonego lub podejrzewanego naruszenia ochrony danych osobowych:

1. ≤ 24 godziny od stwierdzenia — powiadomienie Organizacji, której dane zostały dotknięte (art. 4 DPA — Załącznik nr 1 do Regulaminu). Treść powiadomienia: opis charakteru naruszenia, kategorie i przybliżona liczba osób i rekordów, dane kontaktowe, prawdopodobne konsekwencje, zastosowane lub proponowane środki.
2. ≤ 72 godziny od stwierdzenia — zgłoszenie do Prezesa UODO (art. 33 RODO), jeżeli dotyczy danych, dla których Attestia jest administratorem. Zgłoszenia dokonuje się przez e-PUAP lub system ZSRN.
3. Bez zbędnej zwłoki — zawiadomienie osób, których dane dotyczą, w przypadku wysokiego ryzyka dla ich praw lub wolności (art. 34 RODO).

Kontakt ws. incydentów bezpieczeństwa: privacy@attestia.eu (docelowo: security@attestia.eu).

10. Zarządzanie podatnościami (Vulnerability Management)

• Automatyczne aktualizacje zależności — Dependabot skonfigurowany na daily scan.
• Monitoring CVE — alerty z GitHub Advanced Security + powiadomienia od dostawców infrastruktury (Supabase, Vercel, Azure, Stripe).
• Priorytetyzacja: CVE wg CVSS Base Score — Critical ≤ 24h, High ≤ 7 dni, Medium ≤ 30 dni.
• Testy penetracyjne — planowane kwartalnie [TODO: pierwsze testy — Q4 2026].
• Przegląd kodu — każda zmiana code review przed merge do main; osobny „security review" dla zmian dotyczących autoryzacji, RLS, przetwarzania danych.
• SAST/DAST — narzędzia do statycznej i dynamicznej analizy kodu są w planach [ROADMAP].

11. Odpowiedzialne zgłaszanie podatności (Responsible Disclosure)

Doceniamy pracę społeczności security. Jeżeli zidentyfikowałeś/-aś potencjalną podatność w Attestia:

11.1. Zasady

• Zgłaszaj do: privacy@attestia.eu (docelowo: security@attestia.eu) — z prefiksem [SECURITY] w temacie.
• NIE publikuj szczegółów podatności publicznie przed naszym potwierdzeniem naprawy.
• NIE eksploatuj podatności poza zakresem koniecznym do jej zademonstrowania.
• NIE naruszaj prywatności innych Użytkowników — jeśli przypadkowo uzyskałeś/-aś dostęp do cudzych danych, natychmiast zaprzestań i zgłoś nam to.
• Daj nam czas — standardowy okres naprawy: 90 dni od potwierdzenia (w zależności od krytyczności).

11.2. Co zgłaszać

Wszystko, co ma realny impakt na bezpieczeństwo lub prywatność Użytkowników i Organizacji:

• Podatności autentykacji/autoryzacji.
• Naruszenia Row-Level Security / izolacji danych.
• Injection (SQL, XSS, SSRF, Command Injection, Template Injection).
• Zdalne wykonanie kodu (RCE).
• Błędy w implementacji kryptograficznej.
• Eksfiltracja danych, CSRF krytyczny, Account Takeover.

11.3. Co nie kwalifikuje się

• Brak nagłówków typu X-Frame-Options / CSP bez demonstracji realnego impaktu.
• DoS / DDoS bez realnej demonstracji wpływu.
• Brute-force bez pokazania obejścia rate limitingu.
• Samoistnie włączony XSS (self-XSS).
• Social engineering kierowany na pracowników Attestia lub klientów.
• Brak SPF/DKIM na domenach nie używanych do e-maili transakcyjnych.

11.4. Nasze zobowiązanie

• Potwierdzenie przyjęcia zgłoszenia: w ciągu 72 godzin (dni robocze).
• Wstępna ocena: w ciągu 7 dni od potwierdzenia.
• Status naprawy: komunikowany co najmniej co 14 dni do zamknięcia zgłoszenia.
• Uznanie (acknowledgement): za zgodą zgłaszającego — umieścimy podziękowanie na hall of fame [PLANOWANE PO LAUNCH].
• Bug bounty: na etapie MVP nie oferujemy programu finansowego; rozważamy uruchomienie po osiągnięciu stabilności produktu [ROADMAP].

11.5. Zakres (Scope)

12. Zgodność i certyfikaty

13. Szkolenia i kultura bezpieczeństwa

• Onboarding bezpieczeństwa dla każdego nowego członka zespołu — zasady przetwarzania danych klientów, polityka haseł, zasady korzystania z urządzeń.
• Przegląd polityk — coroczny.
• Szkolenia okresowe — dostosowane do ewoluującego krajobrazu zagrożeń (phishing, supply-chain, AI-specific threats).
• Tajemnica — wszyscy pracownicy i współpracownicy zobowiązani do zachowania tajemnicy (spójnie z § 17 Regulaminu — Poufność).

14. Historia zmian

15. Kontakt