Ta strona opisuje, jak chronimy dane w Berlinetcie: co robimy dziś, a nie co planujemy. Piszemy konkretnie, bo czyta ją zwykle osoba, która ma ocenić nas jako dostawcę: administrator IT, inspektor ochrony danych albo audytor klienta. Jeżeli czegoś tu brakuje, zapytaj; odpowiemy równie konkretnie.
Podatność lub incydent zgłoś na kontakt@berlinetta.pl (sekcja 19).
1.Infrastruktura
- Berlinetta działa na serwerze dedykowanym w centrum danych na terytorium Polski (MEVSPACE, Warszawa), administrowanym wyłącznie przez ZELCODE LABS. Operator centrum danych zapewnia zasilanie, łącze i ochronę fizyczną; nie ma dostępu logicznego do systemu.
- Usługi (aplikacja, API, baza danych PostgreSQL, Redis, kolejka zdarzeń, magazyn sekretów) działają w odizolowanych kontenerach we wspólnej sieci wewnętrznej. Z Internetu dostępny jest wyłącznie serwer HTTPS; baza danych, Redis, kolejka i magazyn sekretów nie mają otwartych portów publicznych.
- Dostęp administracyjny do serwera odbywa się kluczem SSH; konta usługowe (np. do publikowania wydań agentów) mają uprawnienia ograniczone do swoich katalogów, bez dostępu do konfiguracji, bazy ani kontenerów.
2.Szyfrowanie transmisji
- Cała komunikacja z Berlinettą (strona, aplikacja, API, serwery aktualizacji agentów) odbywa się przez HTTPS z użyciem TLS 1.2 lub 1.3; starsze protokoły są wyłączone. Żądania HTTP są przekierowywane na HTTPS.
- Certyfikaty wystawia Let's Encrypt i odnawiają się automatycznie; każda organizacja dostaje własny adres w domenie berlinetta.pl objęty ważnym certyfikatem od pierwszej sekundy.
- Połączenia z systemami zewnętrznymi (marketplace, przewoźnicy, KSeF, model językowy) są szyfrowane TLS zgodnie z wymaganiami tych dostawców.
3.Ochrona danych w spoczynku
- Hasła użytkowników są przechowywane wyłącznie jako skróty bcrypt (koszt 12); nie da się z nich odtworzyć hasła. Kody zapasowe 2FA i klucze API są przechowywane jako skróty SHA-256. Tokeny i klucze integracji (np. tokeny Allegro, klucze API przewoźników) leżą w odrębnym, szyfrowanym magazynie sekretów (HashiCorp Vault), a nie w bazie aplikacji.
- Dostęp do bazy danych mają wyłącznie procesy aplikacji przez wewnętrzną sieć i dedykowane role bazodanowe o ograniczonych uprawnieniach. Rola używana przez panel obsługi nie ma dostępu do tabel z zamówieniami klientów.
- Dyski serwera nie są dziś szyfrowane na poziomie woluminu; ochronę danych w spoczynku zapewniają kontrola dostępu fizycznego operatora centrum danych, uprawnienia systemu operacyjnego i szyfrowanie sekretów opisane wyżej. Szyfrowanie woluminów i kopii zapasowych jest w planie rozwoju.
4.Hasła i sesje
- Każdy użytkownik ma własne konto i hasło. Konto założone przez administratora dostaje hasło tymczasowe, które trzeba zmienić przy pierwszym logowaniu; do tego czasu aplikacja nie pozwala pracować.
- Sesja jest ważna 24 godziny i może być odnawiana bez ponownego logowania przez maksymalnie 30 dni od zalogowania; potem wymagane jest ponowne podanie hasła. Zmiana hasła unieważnia wszystkie pozostałe sesje użytkownika. Administrator organizacji widzi aktywne sesje swoich użytkowników i może je zakończyć.
- Dezaktywacja konta użytkownika i zawieszenie organizacji działają od następnego żądania, nie od wygaśnięcia sesji.
5.Uwierzytelnianie dwuskładnikowe (2FA)
- Użytkownik może włączyć drugi składnik logowania: jednorazowe kody z aplikacji uwierzytelniającej (TOTP, np. Google Authenticator, Authy, 1Password) oraz zestaw kodów zapasowych do użycia w razie utraty telefonu. Zalecamy włączenie 2FA co najmniej administratorom organizacji.
- Między podaniem hasła a kodem logowanie jest wstrzymane maksymalnie 5 minut; do czasu podania poprawnego kodu nie powstaje żadna sesja ani token, którym dałoby się wykonać jakiekolwiek żądanie.
6.Autoryzacja integracji
- Tam, gdzie dostawca to umożliwia (np. Allegro), integrację autoryzuje sam klient, logując się u dostawcy i udzielając zgody (OAuth). Berlinetta prosi wyłącznie o zakres uprawnień potrzebny do funkcji integracji, nigdy o hasło do konta u dostawcy.
- Tokeny odnawiamy automatycznie z blokadą współbieżności, żeby dwa równoległe odświeżenia nie unieważniły sobie nawzajem dostępu. Odłączenie integracji w aplikacji usuwa nasze poświadczenia; zalecamy dodatkowo cofnięcie dostępu w ustawieniach dostawcy.
7.Zarządzanie sekretami
- Poświadczenia integracji klientów są przechowywane w HashiCorp Vault z dostępem ograniczonym do procesu API. Sekrety konfiguracyjne systemu nie znajdują się w kodzie źródłowym; repozytorium jest skanowane pod kątem przypadkowo zapisanych sekretów, a ujawniony sekret jest traktowany jako wymagający rotacji, nie tylko usunięcia.
8.Klucze API
- Klucz API ma zakres uprawnień wybrany przy tworzeniu (np. tylko odczyt zamówień) i nigdy nie daje więcej, niż może konto, które go wydało; odebranie uprawnień użytkownikowi zawęża też jego klucze. Wartość klucza jest pokazywana raz, przy utworzeniu, a w bazie zostaje wyłącznie skrót. Klucz można unieważnić w każdej chwili.
9.Role i uprawnienia
- Dostęp do funkcji opiera się na rolach (właściciel, administrator, pracownik, pakowacz) i granularnych uprawnieniach do 17 modułów aplikacji (podgląd, edycja, zarządzanie). Uprawnienia są sprawdzane po stronie serwera przy każdym żądaniu, nie tylko ukrywane w interfejsie; nowa trasa API bez zadeklarowanego uprawnienia nie przechodzi automatycznych testów.
- Uprawnienia są odczytywane ze świeżego stanu bazy przy każdym żądaniu, więc zmiana roli działa natychmiast, bez czekania na wygaśnięcie sesji.
10.Dzienniki zdarzeń
- Aplikacja zapisuje historię zmian zamówień, produktów, dokumentów i ustawień razem z informacją, kto i kiedy ich dokonał (użytkownik, reguła automatyczna, integracja). Logowania i sesje są rejestrowane z adresem IP i identyfikatorem przeglądarki. Doręczenia powiadomień zewnętrznych mają własny log.
- Dostęp pracowników ZELCODE LABS do organizacji klienta przez panel obsługi jest rejestrowany. Logi techniczne serwerów są rotowane; okresy przechowywania opisuje Polityka prywatności.
11.Monitoring
- Stan usług jest sprawdzany automatycznie (testy zdrowia kontenerów z automatycznym restartem, pomiar opóźnień i pamięci API). Błędy aplikacji i błędy zgłaszane przez przeglądarki użytkowników są zbierane co kilka minut i przeglądane; powtarzające się błędy trafiają do kolejki napraw.
- Nie korzystamy z zewnętrznych usług monitorowania błędów ani analityki, dzięki czemu dane o błędach (które mogą zawierać fragmenty adresów lub identyfikatorów) nie opuszczają naszej infrastruktury.
12.Kopie zapasowe
- Baza danych jest zrzucana w całości codziennie; przechowujemy 14 kopii dziennych i 8 tygodniowych. Dodatkowo co godzinę powstaje archiwum katalogu usługi (konfiguracja, pliki, dokumenty) z retencją 24 kopii godzinnych, 7 dziennych i 4 tygodniowych. Przed każdą zmianą struktury bazy wykonujemy osobny zrzut.
- Kopie są przechowywane lokalnie, na tej samej infrastrukturze, z dostępem ograniczonym do administratora. Replikacja szyfrowanych kopii do drugiej lokalizacji jest w planie rozwoju; do tego czasu odporność na utratę całego centrum danych jest ograniczona, o czym mówimy wprost.
- Kopie służą odtworzeniu usługi po awarii, nie są indywidualną usługą archiwizacji dla klienta (§ 18 Regulaminu). Dane usunięte przez klienta pozostają w kopiach do końca rotacji, najdłużej 90 dni.
13.Odtwarzanie po awarii
- Cel odtwarzania: w razie awarii serwera odtworzyć usługę z ostatniej kopii w ciągu godzin, z utratą danych nie większą niż od ostatniego zrzutu bazy (do 24 godzin). W praktyce większość incydentów (awaria kontenera, błąd wdrożenia) jest usuwana w minutach przez automatyczny restart albo cofnięcie wdrożenia, bez odtwarzania z kopii.
- Procedura odtworzenia bazy ze zrzutu jest używana regularnie przy pracach na środowisku testowym, więc nie jest teorią. Klienci w umowie Enterprise mogą uzgodnić krótsze cele odtwarzania i dodatkowe kopie (SLA Enterprise).
14.Aktualizacje
- System operacyjny serwera (Ubuntu LTS) i obrazy kontenerów są aktualizowane regularnie. Aplikacja jest wdrażana wielokrotnie w tygodniu małymi zmianami, każda przechodzi kontrolę typów, testy i bramkę bezpieczeństwa przed połączeniem z główną gałęzią; wdrożenie z błędem cofamy do poprzedniej wersji.
15.Zarządzanie podatnościami
- Utrzymujemy pisany model zagrożeń (wyciek między organizacjami, eskalacja uprawnień, sekrety, powierzchnia publiczna, wejścia użytkownika) i prowadzimy cykliczne wewnętrzne audyty bezpieczeństwa kodu; wyniki i naprawy są dokumentowane. Zależności są skanowane pod kątem znanych podatności.
- Dwie klasy błędów sprawdzają testy automatyczne przy każdej zmianie: każda nowa tabela z danymi organizacji musi mieć włączoną izolację na poziomie wierszy, a każda nowa trasa API musi deklarować wymagane uprawnienie. Bez tego zmiana nie zostanie wdrożona.
16.Separacja danych między firmami
- Wszystkie organizacje korzystają z jednej aplikacji i jednej bazy danych, dlatego izolacja jest egzekwowana w samej bazie: dla danych operacyjnych (zamówienia, produkty, oferty, magazyn, dokumenty, przesyłki, klienci, użytkownicy i inne) włączone są zabezpieczenia na poziomie wierszy (Row Level Security). Każde zapytanie wykonuje się w kontekście jednej organizacji, a zapytanie bez kontekstu nie zwraca cudzych danych.
- Drugą warstwą jest autoryzacja w aplikacji (role i uprawnienia) oraz osobne role bazodanowe dla aplikacji klienta i panelu obsługi. Izolację weryfikują testy generowane z definicji bazy, a jej stan (liczba tabel objętych RLS) jest mierzony na żywej bazie i dokumentowany.
- Pliki (zdjęcia produktów, załączniki, dokumenty) są przechowywane z identyfikatorem organizacji i serwowane wyłącznie po sprawdzeniu uprawnień.
17.Reakcja na incydenty
- Incydent bezpieczeństwa (podejrzenie nieuprawnionego dostępu, wyciek, przejęcie konta, ujawnienie sekretu) traktujemy priorytetowo: ograniczamy skutki (unieważnienie sesji i tokenów, rotacja sekretów, blokada źródła), ustalamy zakres na podstawie logów, usuwamy przyczynę i opisujemy wnioski.
- Klientów, których dane mogło dotknąć naruszenie, informujemy w ciągu 48 godzin od stwierdzenia (§ 14 Umowy powierzenia), podając zakres, skutki i podjęte środki. Obowiązki wobec organu nadzorczego i osób fizycznych wypełniamy zgodnie z RODO.
18.Dostęp pracowników ZELCODE LABS
- Dostęp do danych klientów mają wyłącznie osoby, które go potrzebują do utrzymania usługi lub obsługi zgłoszeń, przez imienne konta w panelu obsługi z listą dozwolonych adresów e-mail. Dostęp do organizacji klienta w celu diagnozy odbywa się w związku ze zgłoszeniem, jest rejestrowany i podlega obowiązkowi poufności. Klient może zażądać, żeby każdorazowo wymagał jego zgody.
- Nie testujemy funkcji na kontach klientów i nie kopiujemy ich danych do środowisk testowych bez uzgodnienia; środowiska testowe używają danych własnych albo zanonimizowanych.
19.Zgłaszanie podatności
- Jeżeli znalazłeś podatność w Berlinetcie, napisz na kontakt@berlinetta.pl. Opisz, czego dotyczy, jak ją odtworzyć i jaki może mieć skutek; przyjmujemy zgłoszenia po polsku i po angielsku. Potwierdzamy otrzymanie w ciągu 5 dni roboczych i informujemy o postępie naprawy.
- Prosimy o zasady odpowiedzialnego ujawniania, a w zamian zobowiązujemy się nie podejmować kroków prawnych wobec badaczy działających w dobrej wierze:
- nie uzyskuj dostępu do danych innych organizacji ani nie modyfikuj cudzych danych; do testów użyj własnego konta testowego (uruchomimy je na prośbę),
- nie wykonuj ataków odmowy usługi, nie wysyłaj spamu i nie testuj socjotechniką pracowników ani klientów,
- nie publikuj szczegółów podatności przed jej naprawieniem i uzgodnieniem terminu publikacji (proponujemy do 90 dni od zgłoszenia),
- zgłoś podatność niezwłocznie po jej znalezieniu i usuń dane, które mogłeś przy tym pobrać.
- Nie prowadzimy dziś programu nagród pieniężnych; za istotne zgłoszenia dziękujemy publicznie, jeżeli zgłaszający tego chce.
Usługodawca
ZELCODE LABS KRYSTIAN KAKITEK
NIP 6252509025, REGON 545716021
ul. Mielecka 12/18, 41-219 Sosnowiec, Polska
Pytania do tego dokumentu przyjmujemy pod adresem kontakt@berlinetta.pl.