Środki Techniczne i Organizacyjne (TOM)

1. Wprowadzenie i zakres

Niniejszy dokument opisuje środki techniczne i organizacyjne (Technical and Organizational Measures, dalej: „TOM”) wdrożone przez Pure Technology Arkadiusz Klijewski (dalej: „Pure Alpha” lub „Procesor”) w celu zapewnienia bezpieczeństwa przetwarzania danych osobowych zgodnie z art. 32 RODO.

Pure Alpha jest platformą w pełni chmurową (cloud-native). Procesor nie utrzymuje własnych serwerowni, data center ani sprzętu fizycznego — całość infrastruktury produkcyjnej działa w chmurze enterprise w EOG (region UE), z komponentem AI dostarczanym przez dostawcę LLM enterprise w EOG oraz warstwą brzegową (globalny CDN + ochrona wolumetryczna). Z tego względu środki opisane poniżej odnoszą się do bezpieczeństwa chmury, aplikacji i procesów, a nie do fizycznej ochrony obiektów — za bezpieczeństwo fizyczne centrów danych odpowiada dostawca chmury w modelu współdzielonej odpowiedzialności. Pełna lista sub-procesorów wraz z imiennym wskazaniem dostawców oraz ocenami skutków transferu (TIA) dostępna jest dla Klientów korporacyjnych po podpisaniu umowy poufności (NDA) — zob. portal wniosków.

Środki zostały dobrane z uwzględnieniem stanu wiedzy technicznej, kosztu wdrożenia oraz charakteru, zakresu, kontekstu i celów przetwarzania, jak również ryzyka naruszenia praw lub wolności osób fizycznych, w oparciu o art. 32 RODO oraz Wytyczne Europejskiej Rady Ochrony Danych (EROD). Pure Alpha realizuje program przygotowania do certyfikacji ISO/IEC 27001 (status: w przygotowaniu) oraz przygotowania do ISO/IEC 42001 (zarządzanie systemami AI — w przygotowaniu). Bezpieczeństwo fizyczne i dostępność centrów danych dostawcy chmury objęte są raportami SOC 2 Type II oraz ISO/IEC 27001 wystawianymi i utrzymywanymi przez dostawcę chmury (model delegowany).

2. Zarządzanie bezpieczeństwem informacji

• Zakres ISMS — system zarządzania bezpieczeństwem informacji obejmuje platformę Pure Alpha, infrastrukturę chmurową, procesy wytwarzania oprogramowania oraz zespoły mające dostęp do danych.
• Role i odpowiedzialności — wyznaczono osoby odpowiedzialne za ochronę danych (IOD, o ile wymagany), bezpieczeństwo informacji (CISO / odpowiednik) oraz zespół bezpieczeństwa. Odpowiedzialności są udokumentowane i rozliczalne.
• Cykl przeglądów — polityki i kontrole bezpieczeństwa podlegają przeglądowi co najmniej kwartalnie oraz po istotnych zmianach.

3. Kontrola dostępu

• RBAC — kontrola dostępu oparta na rolach (Role-Based Access Control) zarówno na poziomie aplikacji, jak i infrastruktury.
• MFA / 2FA — uwierzytelnianie wieloskładnikowe: jednorazowe kody czasowe TOTP (RFC 6238 — np. Google Authenticator, Authy) dla użytkowników z dostępem do paneli administracyjnych Platformy oraz logowanie biometryczne passkey w standardzie WebAuthn / FIDO2 (Face ID / Touch ID) dla aplikacji pracowniczej (Employee App); uzupełnione jednorazowymi kodami awaryjnymi (backup codes).
• Zasada najmniejszych uprawnień (least privilege) — dostęp przyznawany wyłącznie w zakresie niezbędnym do realizacji zadań. Na poziomie bazy danych wdrożono dedykowane role PostgreSQL o wąskim zakresie (osobne role do migracji schematu, do operacji aplikacji oraz do odczytu, a także role wyspecjalizowane dla pojedynczych funkcji) — aplikacja produkcyjna nie łączy się z bazą jako konto z pełnymi uprawnieniami; poświadczenie nadrzędne (master) pozostaje wyłącznie awaryjne (break-glass).
• Rozdział obowiązków (separation of duties) — krytyczne operacje wymagają zaangażowania więcej niż jednej osoby lub roli; ścisłe oddzielenie środowisk i poświadczeń deweloperskich od produkcyjnych (osobne role bazodanowe dla wdrażania zmian schematu i dla pracy aplikacji).
• Dostęp administracyjny do chmury — zarządzany przez tożsamości IAM dostawcy chmury; dostęp do powłoki kontenerów realizowany wyłącznie przez audytowane mechanizmy administracyjne dostawcy chmury, zamiast otwartego dostępu sieciowego (brak publicznych portów administracyjnych, brak długowiecznych kluczy SSH).
• Przegląd dostępów — kwartalny przegląd uprawnień i odbieranie zbędnych dostępów.

4. Bezpieczeństwo aplikacji

• Bezpieczny cykl wytwarzania (SDLC) — udokumentowany proces wytwarzania oprogramowania z wbudowanymi bramkami bezpieczeństwa.
• Obowiązkowy przegląd kodu (code review) — każda zmiana podlega przeglądowi przed wdrożeniem.
• Analiza statyczna kodu — reguły bezpieczeństwa lintera (ESLint) oraz bramki pre-push w potoku CI wykrywające typowe błędy i wycieki sekretów.
• Skanowanie zależności (SCA) — okresowy przegląd bibliotek zewnętrznych pod kątem znanych podatności (npm audit) przy zmianach zależności.
• Bramki bezpieczeństwa przed wdrożeniem — automatyczne kontrole przed publikacją (pre-push / build): m.in. weryfikacja kompletności sekretów i braku błędnych konfiguracji uprawnień bazy danych.
• Aktywne ograniczanie OWASP Top 10 — w warstwie aplikacji i WAF mitygowane są m.in. wstrzyknięcia SQL, XSS, podrabianie żądań i nadużycia sesji; ochrona uzupełniona o limitowanie przepustowości i walidację danych wejściowych (schematy walidacji po stronie serwera).
• Uwierzytelnianie poczty wychodzącej — rekordy SPF, podpisy DKIM oraz polityka DMARC dla domeny nadawczej, ograniczające podszywanie się i phishing.
• Testy penetracyjne — przeprowadzane corocznie oraz doraźnie (ad-hoc) dla istotnych wydań.

5. Bezpieczeństwo infrastruktury (chmura)

• Architektura w pełni chmurowa — warstwa obliczeniowa działa na kontenerach serverless dostawcy chmury (bez serwerów zarządzanych przez Procesora), baza danych na zarządzanej usłudze PostgreSQL w konfiguracji Multi-AZ (wiele stref dostępności), region UE (EOG).
• Segmentacja sieci — wydzielona chmura wirtualna (VPC) z podziałem na podsieci prywatne i publiczne; zasoby danych (baza, cache) w podsieciach prywatnych bez publicznego dostępu; reguły grup bezpieczeństwa ograniczające ruch do niezbędnego minimum.
• Szyfrowanie w spoczynku — dane szyfrowane kluczami zarządzanymi w systemie zarządzania kluczami kryptograficznymi (KMS) dostawcy chmury: baza danych (encryption at rest), magazyn plików obiektowy (SSE-KMS), cache (at-rest) oraz kopie zapasowe. Wybrane dane wrażliwe (np. numery rachunków bankowych) szyfrowane są dodatkowo na poziomie aplikacji (AES-256-GCM).
• Szyfrowanie w tranzycie — komunikacja wymuszana po TLS 1.2+, z włączonym HSTS oraz polityką bezpieczeństwa treści CSP (Content Security Policy) opartą o nonce.
• Ochrona przed DDoS — warstwa brzegowa (globalny CDN, ochrona wolumetryczna) uzupełniona o zaporę aplikacji webowej (WAF) dostawcy chmury.
• Zapora aplikacji webowych (WAF) — WAF dostawcy chmury z regułami zarządzanymi oraz ograniczaniem przepustowości (rate limiting); ruch DNS i SSL kierowany przez warstwę brzegową (proxy).
• Izolacja wielodostępna (multi-tenancy) — dane każdego hotelu są logicznie izolowane na poziomie aplikacji i bazy (każde zapytanie ograniczone identyfikatorem hotelu); dostęp do danych jednego administratora jest niedostępny dla innych.

6. Zarządzanie tożsamością

• Uwierzytelnianie — sesje aplikacyjne oparte o NextAuth (tokeny JWT o ograniczonym czasie życia); osobne, dedykowane ścieżki uwierzytelnienia dla aplikacji pracowniczej (w tym logowanie passkey WebAuthn / FIDO2).
• Zarządzanie sesją — limity czasu sesji, rotacja i unieważnianie tokenów; porównania sekretów w czasie stałym (constant-time) dla odporności na ataki czasowe.
• Polityka haseł — wymogi długości i złożoności, ochrona przed atakami siłowymi (blokada konta po serii nieudanych prób, odpowiedzi w czasie stałym maskujące istnienie konta). Hasła przechowywane wyłącznie jako skróty bcrypt (koszt 12) wzmocnione sekretnym „pepper” (HMAC-SHA-256) trzymanym poza bazą danych w menedżerze sekretów — sam zrzut bazy nie wystarcza do złamania haseł offline.
• Zarządzanie sekretami — sekrety przechowywane w zarządzanym sejfie sekretów dostawcy chmury z automatyczną rotacją (cykl 90 dni); rotacja realizowana przez dedykowaną funkcję, bez ujawniania wartości operatorowi. Sekrety nigdy nie są przechowywane w kodzie źródłowym ani w plikach konfiguracyjnych repozytorium.

7. Monitoring i rejestrowanie zdarzeń

• Centralne monitorowanie — gromadzenie i korelacja logów oraz metryk w zarządzanym systemie monitoringu i alertów dostawcy chmury (logi aplikacji, infrastruktury i dostępu), śledzenie żądań rozproszonych oraz rejestr zdarzeń API chmury (cloud audit trail).
• Niezmienne logi audytowe — operacje na danych rejestrowane w trybie append-only w bazie danych; integralność zapewnia łańcuch skrótów (hash-chain) — każdy wpis zawiera kryptograficzny skrót SHA-256 powiązany ze skrótem poprzedniego wpisu, co umożliwia wykrycie modyfikacji lub usunięcia rekordu po jego zapisaniu.
• Alarmowanie — automatyczne wykrywanie i powiadamianie o podejrzanych wzorcach aktywności (alarmy kierowane na dedykowany kanał administratora), w tym alarmy o nieautoryzowanej eskalacji uprawnień i błędach zapisu ścieżki audytowej.
• Retencja logów — operacyjne logi bezpieczeństwa przechowywane są zgodnie z polityką retencji właściwą dla danego strumienia (z zachowaniem zasady minimalizacji), a ścieżka audytowa zdarzeń na danych — przez okres wymagany obowiązkami rozliczalności (art. 5 ust. 2 RODO).

8. Kopie zapasowe i odtwarzanie po awarii (DR)

• Automatyczne kopie zapasowe bazy danych — migawki zarządzanej bazy danych z retencją 35 dni oraz odtwarzanie do dowolnego punktu w czasie (Point-in-Time Recovery).
• Składowanie geo-redundantne — kopie zapasowe i kluczowe pliki replikowane między dwoma odrębnymi regionami Unii Europejskiej (cross-region replication magazynu obiektowego, snapshoty DR w odrębnym regionie EOG).
• Niezmienność kopii (S3 Object Lock — GOVERNANCE) — kluczowe magazyny kopii (m.in. dane płacowe oraz kopie DR) objęte blokadą obiektów uniemożliwiającą usunięcie/nadpisanie w okresie retencji — ochrona przed ransomware i działaniem nieuprawnionym (tzw. immutability).
• Zobowiązania RTO/RPO — docelowe parametry odtwarzania określone w SLA (zob. SLA).
• Automatyczne, comiesięczne ćwiczenie DR — cykliczne (miesięczne) odtworzenie najnowszej kopii DR do izolowanego, jednorazowego środowiska w regionie zapasowym (EOG) z pomiarem rzeczywistego czasu odtworzenia (RTO) i automatycznym usunięciem zasobu po teście — weryfikacja, że kopie są faktycznie odtwarzalne, a nie jedynie tworzone.

9. Zarządzanie incydentami

• Plan reagowania na incydenty (Incident Response Plan) — udokumentowane role, procedury eskalacji i komunikacji.
• Notyfikacja naruszeń w 72 h — procedura zgłaszania naruszeń ochrony danych Administratorowi bez zbędnej zwłoki, nie później niż w ciągu 72 godzin od stwierdzenia (art. 33 RODO). Dedykowany punkt kontaktowy ds. naruszeń: info@purealphahotel.pl.
• Przegląd poincydentalny (post-incident review) — analiza przyczyn źródłowych i wdrażanie działań naprawczych.
• Plan komunikacji z klientami — zdefiniowane kanały i treści informowania Administratorów.

10. Bezpieczeństwo pracowników

• Weryfikacja przed zatrudnieniem (background checks) — w zakresie dozwolonym przepisami prawa.
• Zobowiązania do poufności — wszyscy pracownicy i współpracownicy mający dostęp do danych podlegają umowom o zachowaniu poufności.
• Szkolenia z bezpieczeństwa — coroczne szkolenia podnoszące świadomość zagrożeń (w tym phishing).
• Procedura offboardingu — niezwłoczne odbieranie dostępów po zakończeniu współpracy.

11. Bezpieczeństwo dostawców (sub-procesorów)

• Ocena bezpieczeństwa sub-procesorów — przed powierzeniem przetwarzania oceniane są środki bezpieczeństwa dostawcy.
• Umowy DPA + SCC — z każdym sub-procesorem zawierana jest umowa powierzenia, a w przypadku transferu poza EOG — Standardowe Klauzule Umowne.
• Coroczny przegląd dostawców — okresowa weryfikacja zgodności i poziomu bezpieczeństwa.

12. Zgodność (Compliance)

• Program zgodności z RODO — rejestr czynności przetwarzania, oceny ryzyka, procedury realizacji praw osób.
• ISO/IEC 27001 — status: w przygotowaniu (program wdrożenia ISMS w toku).
• ISO/IEC 42001 (zarządzanie systemami AI) — status: w przygotowaniu.
• Coroczny audyt zewnętrzny — w zakresie, w jakim ma zastosowanie do uzyskanych certyfikacji.

13. Prawo do audytu

• Prawo audytu Klienta — Administrator ma prawo do audytu zgodności na zasadach określonych w DPA (§14).
• Ograniczenia częstotliwości — co do zasady nie częściej niż raz w roku, chyba że zachodzi uzasadnione podejrzenie naruszenia lub żądanie organu nadzorczego.
• Alokacja kosztów — koszty audytu inicjowanego przez Administratora ponosi Administrator, z wyjątkiem audytów ujawniających istotne naruszenia po stronie Procesora.
• Raporty zastępcze — obowiązek audytowy może być zrealizowany poprzez udostępnienie aktualnych raportów audytowych Procesora (ISO/IEC 27001 — po uzyskaniu certyfikacji, status: w przygotowaniu) oraz raportów dostawcy chmury (SOC 2 Type II / ISO/IEC 27001) dla warstwy infrastruktury, w modelu współdzielonej odpowiedzialności.