Bezpieczeństwo Systemu SerwisRun

Ten dokument opisuje w przystępny sposób, jak system SerwisRun chroni Twoje dane — od momentu logowania, przez codzienną pracę, aż po przechowywanie plików w chmurze.

1 Logowanie i dostęp do systemu

Jak działa logowanie?

Po wpisaniu loginu i hasła system generuje cyfrowy identyfikator sesji (tzw. token JWT), który działa jak jednorazowa przepustka. Ta przepustka:

• Wygasa automatycznie po 8 godzinach — nawet jeśli ktoś ją przechwyci, po tym czasie staje się bezużyteczna
• Jest podpisana cyfrowo — nie da się jej podrobić ani zmodyfikować
• Zawiera tylko minimum informacji — Twoje ID, email i rolę (nie zawiera hasła ani innych wrażliwych danych)

Porównanie: To ten sam mechanizm, jakiego używają banki internetowe i systemy takie jak Google Workspace czy Microsoft 365.

Logowanie biometryczne (odcisk palca / Face ID)

System obsługuje WebAuthn/FIDO2 — międzynarodowy standard logowania biometrycznego:

• Odciskiem palca (czytnik w laptopie lub telefonie)
• Rozpoznawaniem twarzy (Face ID na iPhone, Windows Hello)
• Kluczem bezpieczeństwa USB (np. YubiKey)

Porównanie: To ten sam standard, jakiego używają Google, Apple, Microsoft i banki (np. ING, mBank). Jest uznawany za najbezpieczniejszą dostępną metodę logowania — odporna na phishing i kradzież haseł.

Strona logowania systemu SerwisRun z przyciskiem „Zaloguj biometrycznie" (WebAuthn/FIDO2).

Ochrona przed atakami na logowanie

2 Szyfrowanie komunikacji (transmisja danych)

Co to oznacza w praktyce?

Każda informacja przesyłana między Twoim komputerem/telefonem a serwerem jest szyfrowana protokołem HTTPS (TLS 1.2+). Oznacza to, że:

• Nikt podsłuchujący sieć (np. w kawiarni z Wi-Fi) nie odczyta Twoich danych
• Dane nie mogą zostać zmodyfikowane w trakcie przesyłania
• Przeglądarka potwierdza tożsamość serwera (ikona kłódki w pasku adresu)

Dodatkowe nagłówki bezpieczeństwa

Kontrola dostępu między domenami (CORS)

System akceptuje żądania wyłącznie z autoryzowanych domen (np. app.serwis.cloud). Żadna inna strona internetowa nie może komunikować się z API systemu.

3 Ochrona danych w bazie danych

Ochrona przed włamaniem do bazy (SQL Injection)

SQL Injection to najczęstszy atak na bazy danych. System SerwisRun jest w 100% odporny na ten atak:

• Wszystkie zapytania do bazy używają parametryzowanych zapytań
• Kolumny sortowania są walidowane przez whitelistę
• Wyszukiwanie tekstowe używa bezpiecznego mechanizmu ILIKE z parametrami

Szyfrowanie połączenia z bazą

• Połączenie z bazą szyfrowane SSL
• Weryfikacja certyfikatu CA
• Pool połączeń: max 20 z timeout'em 30s na zapytanie

Przechowywanie haseł

1. Hasło przetwarzane algorytmem bcrypt (10 rund solenia)
2. Wynik to losowy ciąg znaków — nie da się odtworzyć hasła
3. Nawet administrator systemu nie ma dostępu do haseł

Porównanie: Bcrypt to ten sam algorytm, jakiego używają Dropbox, GitHub i Slack. 10 rund solenia oznacza, że próba złamania hasła metodą brute-force zajęłaby dziesiątki lat.

4 Kto widzi jakie dane? (System uprawnień)

Role i uprawnienia (RBAC)

Administrator
    └── widzi i może wszystko

Sub-admin oddziału
    └── pełny dostęp, ale tylko w swoim oddziale

Technik / Pracownik
    └── dostęp tylko do przypisanych modułów

Konto demo
    └── ograniczony podgląd, max 50 rekordów

Izolacja danych między oddziałami

Jeśli firma ma wiele oddziałów, każdy oddział widzi tylko swoje dane. Filtrowanie odbywa się na poziomie bazy danych.

Porównanie: To mechanizm multi-tenant isolation znany z systemów takich jak Salesforce czy HubSpot.

Moduł zarządzania uprawnieniami ról — konfiguracja poziomu dostępu do każdego modułu systemu.

5 Przesyłanie plików na OneDrive

Porównanie: Mechanizm OAuth2 + MSAL to ten sam sposób, w jaki Microsoft Teams i SharePoint komunikują się z OneDrive.

6 Śledzenie zmian (Dziennik audytu)

Porównanie: Dziennik audytu na tym poziomie to wymóg RODO i ISO 27001.

Dziennik audytu — rejestr wszystkich operacji w systemie z informacjami kto, kiedy i co zmienił.

7 Szyfrowanie sekretów integracji w bazie

Po co to robimy?

System przechowuje dane logowania do integracji zewnętrznych (Google Calendar, Gmail, OneDrive, KSeF, IPfon, SMSAPI, Anthropic Claude). Aby zminimalizować skutki potencjalnego wycieku bazy danych, każdy taki sekret jest zaszyfrowany na poziomie aplikacji przed zapisaniem — nawet bezpośredni dostęp do bazy nie wystarczy do ich odczytania.

Jak to działa?

Porównanie: AES-256-GCM to ten sam algorytm, którego używają WhatsApp (Signal Protocol), Google (Cloud KMS) i Apple (iCloud Keychain). Klucze trzymane oddzielnie od danych = nawet wykradzenie zrzutu bazy nie ujawni sekretów.

Procedura rotacji klucza

Jeśli zaistnieje podejrzenie wycieku INTEGRATION_SECRET_KEY, można go bezpiecznie zmienić bez utraty danych:

1. Wygenerowanie nowego klucza i zapisanie w trybie „rotacja" (stary klucz nadal działa do odszyfrowania)
2. Skrypt ponownie zaszyfrowuje wszystkie sekrety w bazie nowym kluczem
3. Po zakończeniu — usunięcie starego klucza ze środowiska

Pełna procedura w dokumentacji wewnętrznej docs/SECURITY.md.

8 Izolacja środowisk DEV / DEMO / PROD

System jest wdrożony w trzech rozdzielnych środowiskach, każde z osobnym kontem Railway, osobną bazą danych i osobnymi sekretami:

Migracje, które wstrzykują dane testowe (147, 148, 261), same się pomijają jeśli flaga DEMO_MODE nie jest ustawiona na true. Dzięki temu produkcja nigdy nie zostanie zanieczyszczona danymi demo, nawet w razie pomyłki przy wdrażaniu.

Dla klienta: Twoje dane są w środowisku PROD. Nikt z testerów ani prezenterów nie ma do nich dostępu. Środowisko DEMO ma własny zestaw fikcyjnych danych firm i klientów.

9 Ochrona przed typowymi atakami

10 Podsumowanie — Jaki to poziom ochrony?

System SerwisRun stosuje zabezpieczenia na poziomie porównywalnym z bankowością elektroniczną i systemami klasy enterprise.