ProfitroomHub
Strona główna / Bezpieczeństwo

Whitepaper bezpieczeństwa

Niniejszy whitepaper opisuje techniczne i organizacyjne środki bezpieczeństwa, które ProfitroomHub stosuje wobec platformy, modułów i danych przez nie przepływających. Jest przeznaczony dla CISO lub IT leada hotelu lub portfela oceniającego nasze moduły. Ostatnia aktualizacja: 24 sierpnia 2026.

1. Architektura w skrócie

Platforma ProfitroomHub to zestaw bezstanowych workerów i współdzielony magazyn metadanych działający w dwóch regionach UE. Workerzy pobierają elementy pracy z kolejki, wywołują odpowiednie API strony trzeciej (Profitroom, OTA, zmostkowany PMS) i zapisują wyniki z powrotem do kolejki. Nie ma trwałych danych gościa na samych workerach — dane gościa żyją krótko w pamięci podczas operacji synchronizacji i są odrzucane po zakończeniu operacji. Wpisy dziennika audytu (źródło, cel, typ operacji, znacznik czasu, id korelacji — bez danych osobowych) są zapisywane do tamper-evident magazynu logów retencjonowanego przez 90 dni.

2. Hosting

Hosting podstawowy: Hetzner Online GmbH, Frankfurt (Niemcy), wewnątrz EOG. Hosting zapasowy: OVH Cloud SAS, Warszawa (Polska), wewnątrz EOG. Oba to certyfikowane ISO 27001 data centry z fizyczną ochroną 24/7, biometrycznymi kontrolami dostępu, N+1 redundantnym zasilaniem i chłodzeniem. Żadne obciążenie produkcyjne nie działa poza EOG.

3. Szyfrowanie

  • W transporcie: TLS 1.3 z nowoczesnymi zestawami szyfrowania (tylko AEAD, wymagana forward secrecy, wymiana kluczy RSA wyłączona). Certyfikaty wydawane przez Let's Encrypt z 90-dniową rotacją.
  • W spoczynku: AES-256 na każdym wolumenie trwałego magazynu. Backupy szyfrowane oddzielnym kluczem przechowywanym w hardware security module.
  • Pseudonimizacja: identyfikatory gości są pseudonimizowane w spoczynku — surowy email gościa jest hashowany SHA-256 + per-tenant solą przed magazynowaniem; surowa wartość jest obecna tylko w pamięci podczas aktywnej synchronizacji.

4. Uwierzytelnianie i kontrola dostępu

Uwierzytelnianie klienta jest bezhasłowe: podpisane linki dostępowe dostarczane mailem, ważne 15 minut, jednorazowe. Wewnętrzne (personelu) uwierzytelnianie używa SSO z kluczami sprzętowymi FIDO2 jako drugim czynnikiem. Dostęp produkcyjny jest ograniczony do małego imiennego zestawu inżynierów, poddanego kwartalnemu przeglądowi dostępów przez IOD. Każdy dostęp produkcyjny jest logowany z tożsamością operatora, zasobem, operacją i czasem — logi są niezmienne przez 90 dni.

5. Segmentacja sieci

Platforma działa w VPC z trzema tierami: (i) tier krawędziowy hostujący publiczne API i stronę marketingową; (ii) tier workera, który pobiera elementy pracy i wywołuje API stron trzecich; (iii) tier danych hostujący magazyn metadanych i dziennik audytu. Ruch między tierami jest domyślnie odrzucany; przechodzą tylko jawnie dozwolone protokoły i porty. Tier danych nie ma bezpośredniej trasy do publicznego internetu.

6. Bezpieczeństwo API strony trzeciej

Każdy moduł uwierzytelnia się w swoim API strony trzeciej przy użyciu client credentials OAuth 2 lub podpisanych tokenów specyficznych dla dostawcy, przechowywanych w sejfie sekretów z automatyczną 90-dniową rotacją. Gdy dostawca wspiera allowlisting IP, nasze IP workerów są przypięte i komunikowane dostawcy. Gdy dostawca wspiera mTLS, używamy go. Każde wywołanie API strony trzeciej jest logowane z id korelacji, opóźnieniem i wynikiem — bez danych osobowych w payloadzie logu.

7. Logowanie, monitoring i alerting

Logi aplikacji idą do centralnego pipeline'u, gdzie są pozbawiane PII przy wchodzeniu i retencjonowane przez 30 dni. Metryki są publikowane do stacku Prometheus + Grafana, a alerty odpalają do roty on-call 24/7 przez PagerDuty. Śledzenie błędów (Sentry) używa scrubbingu payloadu, aby usunąć wszelkie potencjalne PII przed zapisaniem zdarzenia.

8. Reakcja na incydenty

ProfitroomHub utrzymuje udokumentowany plan reakcji na incydenty przeglądany dwa razy w roku i drylowany raz w roku w ćwiczeniu stołowym. Po potwierdzeniu naruszenia danych osobowych IOD jest powiadomiony w ciągu 60 minut; dotknięci klienci są powiadamiani w ciągu 48 godzin; AZLP jest powiadamiane w ciągu 72 godzin, gdy naruszenie wymagające zgłoszenia jest potwierdzone. Przegląd po incydencie jest publikowany w changelogu z zredagowanym identyfikatorem operatora.

9. Backup i odtwarzanie po awarii

Codzienne szyfrowane backupy są retencjonowane przez 30 dni. Recovery time objective (RTO) to 4 godziny, recovery point objective (RPO) to 24 godziny. Ćwiczenia pełnego przywracania są wykonywane kwartalnie, z wynikiem zapisywanym w logu audytu IOD.

10. Zarządzanie podatnościami

Cała infrastruktura jest skanowana co tydzień pod kątem znanych CVE; zależności są skanowane przy każdym buildzie (Snyk + GitHub Dependabot). CVE o krytycznej surowości są łatane w ciągu 24 godzin; wysokie w ciągu 7 dni; średnie w ciągu 30 dni; niskie w ciągu 90 dni. Zewnętrzne testy penetracyjne są zlecane corocznie niezależnemu dostawcy zarejestrowanemu CREST; zredagowane podsumowanie jest dostępne na mocy NDA.

11. Bezpieczny cykl życia rozwoju

Każda zmiana kodu jest peer-reviewowana, poddana analizie statycznej (Semgrep) i skanowaniu zależności przed merge. Wdrożenie produkcyjne przechodzi przez pipeline z podpisanymi artefaktami; niepodpisane artefakty są odrzucane przez runtime. Sekrety nigdy nie żyją w kodzie źródłowym — są wstrzykiwane w runtime z sejfu.

12. Bezpieczeństwo personelu

Każdy inżynier z dostępem produkcyjnym przeszedł sprawdzenie przeszłości odpowiednie dla jurysdykcji, w której zamieszkuje. Każdy kontrakt zawiera klauzulę poufności, która przetrwa rozwiązanie. Rozwiązanie wyzwala natychmiastowe cofnięcie kredencjałów produkcyjnych.

13. Zgodność

ProfitroomHub uzgadnia się z kontrolami ISO 27001; corocznie prowadzimy wewnętrzny audyt względem kontroli ISO 27001:2022 i publikujemy podsumowanie na żądanie. Gdy klient wymaga formalnej certyfikacji (np. dla procesu procurement obejmującego całą sieć), możemy zlecić zewnętrzny audyt po kosztach.

14. Kontakt

Zgłoszenia bezpieczeństwa: security@profitroomhub.org (klucz PGP na żądanie). Bug bounty: brak publicznego programu, ale odpowiedzialne zgłoszenia są potwierdzane w changelogu i nagradzane indywidualnie.

15. Zarządzanie ryzykiem strony trzeciej

Każdy sub-processor wymieniony w DPA podlega corocznemu przeglądowi ryzyka: żądany raport SOC 2 lub ISO 27001, odświeżana ocena wpływu transferu, przeglądany rekord poziomu usług. Gdy sub-processor nie może utrzymać poziomu zapewnienia, którego wymagamy, migrujemy obciążenie do alternatywy w ciągu 90 dni.

16. Klasyfikacja danych

Klasyfikujemy dane w cztery kategorie: Publiczne (strony marketingowe, changelog), Wewnętrzne (zagregowana analityka), Poufne (konfiguracja klienta, tickety wsparcia), Zastrzeżone (dane osobowe gościa, dane faktury). Dane Zastrzeżone są szyfrowane w spoczynku AES-256, szyfrowane w transporcie TLS 1.3 i pseudonimizowane na polu identyfikatora. Dostęp do danych Zastrzeżonych jest ograniczony do workerów, które ich potrzebują dla konkretnej operacji synchronizacji; magazyn metadanych nigdy nie eksponuje danych Zastrzeżonych ogólnemu zapytaniu.

17. Szczegółowe playbooki reakcji na incydent

Utrzymujemy playbooki dla następujących typów incydentów: (i) podejrzewana kompromitacja kredencjałów, (ii) podejrzewane naruszenie danych, (iii) awaria produkcji dłuższa niż 15 minut, (iv) kompromitacja API strony trzeciej, (v) atak DDoS lub wolumetryczny, (vi) wskaźniki ransomware'u na jakiejkolwiek stacji roboczej, (vii) nieautoryzowany dostęp fizyczny do biura. Każdy playbook wymienia natychmiastowe kroki, matrycę eskalacji, szablon komunikacji z klientem i listę kontrolną przeglądu po incydencie. Playbooki są drylowane dwa razy w roku (raz stołowo, raz na żywym ogniu).

18. Cykl życia pracownika

Onboarding: sprawdzenie przeszłości odpowiednie dla jurysdykcji, podpisana umowa poufności, klucz sprzętowy wydany osobiście, szkolenie z polityki bezpieczeństwa i niniejszego whitepapera. Bieżąco: kwartalny przegląd dostępów, coroczne szkolenie odświeżające bezpieczeństwo, symulacja phishingu dwa razy w roku. Offboarding: kredencjały produkcyjne cofnięte w ciągu godziny od rozwiązania, sprzęt zwrócony w ciągu jednego dnia roboczego, urządzenia osobiste z jakimikolwiek danymi firmy wyczyszczone (BYOD jest odradzane i mocno ograniczone).

19. Polityka bring-your-own-device

Urządzenia osobiste nie są autoryzowane do dostępu produkcyjnego. Inżynierowie z dostępem produkcyjnym używają firmowych laptopów z pełnym szyfrowaniem dysku, zainstalowanym agentem EDR, wymuszonym patch-management. Gdy urządzenie osobiste jest używane do casualowej pracy (email, dokumentacja), musi mieć włączone pełne szyfrowanie dysku i być zapisane w konsoli MDM — inaczej nie otrzymuje firmowej poczty.

20. Bezpieczeństwo integracji strony trzeciej

Każda integracja z API strony trzeciej (Profitroom, OTA, zmostkowane systemy PMS) podlega przeglądowi bezpieczeństwa przed uruchomieniem: mechanizm uwierzytelniania (minimum OAuth 2, preferowane mTLS), bezpieczeństwo transportu (TLS 1.3), postawa limitów szybkości, postawa obsługi błędów, uzgodnienie klasyfikacji danych, przechowywanie sekretów. Wynik przeglądu jest zapisywany i referowany ze strony modułu w changelogu.

21. Bezpieczeństwo fizyczne

Nasza infrastruktura produkcyjna jest hostowana w certyfikowanych ISO 27001 data centrach (Hetzner Frankfurt, OVH Warszawa). Nie mamy on-premise sprzętu produkcyjnego. Nasze biuro w Podgoricy nie przechowuje danych produkcyjnych — inżynierowie łączą się z produkcją przez VPN z uwierzytelnianiem FIDO2. Fizyczny dostęp do biura jest logowany i przeglądany co miesiąc.

22. Podsumowanie ciągłości biznesu

RTO 4 godziny, RPO 24 godziny. Pełne ćwiczenie disaster-recovery kwartalnie. Failover z Hetzner Frankfurt do OVH Warszawa jest automatyczny dla ruchu odczytu i ręczny (30-minutowa aktywacja) dla ruchu zapisu. Dane każdego klienta mają zawsze co najmniej dwie kopie w dwóch lokalizacjach EOG.

23. Inwentarz kryptografii

Szyfrowanie symetryczne: AES-256-GCM. Asymetryczne: Ed25519 dla podpisywania, X25519 dla uzgadniania kluczy. Hashowanie: SHA-256 dla treści, Argon2id dla jakiegokolwiek materiału podobnego do hasła (rzadkie — jesteśmy passwordless po stronie klienta). Wszystkie algorytmy są corocznie przeglądane względem wytycznych ENISA i NIST. Wycofane algorytmy (SHA-1, RSA-1024, RC4, DES) nie są obecne w żadnej ścieżce kodu produkcyjnego.

24. Zarządzanie zmianą

Każda zmiana produkcyjna przechodzi przez: pull request, co najmniej jeden peer review, analizę statyczną (Semgrep, ESLint), skan zależności (Snyk, Dependabot), test integracyjny, sign-off, wdrożenie przez pipeline z podpisanymi artefaktami. Zmiany awaryjne (hotfix P1) mogą skompresować to do 30-minutowego cyklu z post-hoc przeglądem następnego dnia roboczego.

25. Zarządzanie sekretami

Wszystkie sekrety (tokeny API, kredencjały bazy, klucze podpisujące) żyją w klastrze HashiCorp Vault z dynamicznymi sekretami tam, gdzie upstream to wspiera, i statyczną rotacją sekretów, gdzie nie. Żaden sekret nigdy nie jest commitowany do kontroli źródła. Sekrety są wstrzykiwane w runtime z sejfu, a runtime nigdy nie loguje wartości sekretu.

26. Kontakt do zgłoszeń bezpieczeństwa

Odpowiedzialne zgłoszenia: security@profitroomhub.org (klucz PGP na żądanie). Potwierdzamy zgłoszenia w ciągu jednego dnia roboczego, dostarczamy harmonogram naprawy w ciągu 5 dni roboczych i wymieniamy odpowiedzialnych zgłaszających w changelogu (za zgodą).