Oświadczenie o bezpieczeństwie

To oświadczenie opisuje środki techniczne i organizacyjne chroniące usługę RavSolutions i przechowywane w niej dane. Napisano je tak, aby dało się je sprawdzić: wymienia środki faktycznie wdrożone, a sekcja 15 równie otwarcie mówi, czego nie posiadamy.

Nie jest to gwarancja i nie tworzy zobowiązania co do poziomu usług; warunki umowne określa Regulamin. Tam, gdzie ten sam środek pojawia się także w informacji RODO lub w informacji o przetwarzaniu danych, ma on w istocie znaczyć to samo.

Oświadczenie obejmuje usługę, którą prowadzimy. Za bezpieczeństwo kont, urządzeń i haseł wewnątrz własnego obszaru roboczego odpowiada abonent; żaden z opisanych tu środków nie ochroni obszaru roboczego, którego dane logowania zostały udostępnione lub użyte ponownie w innym miejscu.

Usługa składa się z trzech front-endów — strony internetowej, aplikacji i portalu klienta — jednego API, bazy danych PostgreSQL, instancji Redis oraz magazynu obiektowego. Front-endy komunikują się z API wyłącznie przez HTTPS.

Wszystko poza magazynem obiektowym działa za reverse proxy na infrastrukturze RackForest Zrt. w regionie Hungary (EU). Baza danych i Redis podłączone są wyłącznie do sieci wewnętrznej i nie publikują żadnego portu, więc żadne z nich nie jest osiągalne z internetu; komunikować się z nimi może tylko API.

Przesłane pliki nie są przechowywane na serwerach aplikacji, lecz w magazynie obiektowym Cloudflare R2 skonfigurowanym dla regionu European Union. Bucket jest prywatny: nie ma publicznego dostępu ani własnej domeny przed nim, a każdy plik udostępniany jest przez link podpisywany przez API.

Sekrety — dane logowania do bazy danych, klucze podpisujące, klucze API dostawców — dostarczane są przez środowisko przy wdrożeniu i nigdy nie trafiają do repozytorium kodu źródłowego.

Cały ruch do strony internetowej, aplikacji, portalu i API obsługiwany jest przez HTTPS. Certyfikaty wystawia i odnawia automatycznie Let's Encrypt, a zwykłe żądania HTTP są przekierowywane na HTTPS.

Reverse proxy wysyła nagłówek HTTP Strict Transport Security z max-age wynoszącym rok, obejmujący subdomeny i z preload, więc przeglądarka, która raz odwiedziła witrynę, nie wróci do połączenia nieszyfrowanego.

Odpowiedzi zawierają X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, politykę referrera strict-origin-when-cross-origin oraz politykę uprawnień odmawiającą dostępu do kamery, mikrofonu i geolokalizacji. Nagłówki identyfikujące serwer i framework są usuwane. API przyjmuje żądania cross-origin wyłącznie z origin aplikacji i portalu.

Strona internetowa, aplikacja i portal serwowane są z polityką Content Security Policy. Skrypty mogą być wczytywane wyłącznie z samej usługi, a w aplikacji dodatkowo z Google Identity Services na potrzeby logowania przez Google; strona internetowa i portal nie dopuszczają żadnego skryptu zewnętrznego. Osadzanie w ramce, treści wtyczek i zmiana bazowego adresu dokumentu są odrzucane, a API odpowiada polityką, która nie zezwala na nic.

Hasło musi mieć co najmniej osiem znaków oraz zawierać wielką literę, małą literę i cyfrę. Hasła przechowywane są wyłącznie jako kryptograficzny skrót z solą wytworzony przez mechanizm haszowania haseł ASP.NET Core Identity; nigdy nie są przechowywane w postaci możliwej do odczytania i nie możemy odzyskać zapomnianego hasła, a jedynie je zresetować.

Po dziesięciu nieudanych próbach logowania konto zostaje zablokowane na piętnaście minut. Licznik prowadzony jest dla konta, a nie dla wywołującego, więc próba rozłożona na wiele adresów zostaje zatrzymana, mimo że każdy adres z osobna pozostaje poniżej limitu na wywołującego.

Dostępne jest logowanie kontem Google. Token tożsamości wystawiony przez Google jest weryfikowany u Google, zanim powstanie jakakolwiek sesja, a my nigdy nie otrzymujemy hasła Google.

Rejestracja powoduje wysłanie wiadomości potwierdzającej na podany adres, a adres zostaje oznaczony jako potwierdzony po użyciu zawartego w niej linku. Zapomniane hasło resetuje się jednorazowym linkiem wysłanym na zarejestrowany adres; udany reset usuwa też istniejącą blokadę konta, ponieważ blokada jest typową przyczyną resetu.

Tokeny dostępu to JSON Web Tokens ważne przez piętnaście minut. Przy każdym żądaniu sprawdzany jest wystawca, odbiorca, podpis i data wygaśnięcia, bez żadnej tolerancji zegara.

Token odświeżania to sześćdziesiąt cztery bajty z kryptograficznego generatora liczb losowych. Baza danych przechowuje wyłącznie jego skrót SHA-256, więc samego tokenu nie da się odczytać z kopii bazy danych.

Każde odświeżenie rotuje token: poprzedni zostaje unieważniony, a nowy wystawiony. Tokeny odświeżania wygasają po trzydziestu dniach, a wylogowanie unieważnia token natychmiast.

Odświeżenie zostaje odrzucone, jeśli użytkownik został dezaktywowany lub obszar roboczy oznaczony jako nieaktywny, więc odebranie komuś dostępu staje się skuteczne najpóźniej z chwilą wygaśnięcia jego bieżącego tokenu dostępu.

Każdy użytkownik ma rolę w obszarze roboczym, a punkty końcowe ją sprawdzają. Funkcje zależne od planu dodatkowo chronią własne polityki autoryzacji, więc funkcja spoza wykupionego planu jest odrzucana przez API, a nie jedynie ukryta w interfejsie.

Obszary robocze rozdzielone są na poziomie danych: każdy zapis zawiera identyfikator obszaru roboczego, do którego należy, a każde zapytanie ograniczone jest do obszaru roboczego wywołującego. Zapis należący do innego obszaru roboczego nie jest ukrywany w wyniku — nigdy do niego nie trafia.

Obszar roboczy pobierany jest z oświadczenia (claim) w podpisanym tokenie dostępu i rozstrzygany po stronie serwera. Identyfikator obszaru roboczego przekazany przez klienta nie jest traktowany jako wiarygodny do niczego.

Połączenia czasu rzeczywistego korzystają z tego samego uwierzytelniania co reszta API; połączenie bez ważnego tokenu jest odrzucane, rozmiar przychodzącej wiadomości jest ograniczony, a szczegółowe informacje o błędach zwracane są wyłącznie w środowisku deweloperskim.

Klient otrzymuje link zawierający losowo wygenerowany token przypisany do jednego zlecenia i opatrzony datą wygaśnięcia. Token otwiera to jedno zlecenie i nic więcej w obszarze roboczym.

Przed wyświetleniem zlecenia odwiedzający musi potwierdzić adres e-mail lub numer telefonu zapisany dla danego klienta. Udane potwierdzenie tworzy dowód ważny przez dwanaście godzin, podpisany HMAC kluczem wyprowadzonym z sekretu podpisującego serwera, lecz kryptograficznie od niego niezależnym, i weryfikowany w czasie stałym.

Próby potwierdzenia są ograniczane liczbowo per wywołujący, a celowo nie per token: ograniczanie per token pozwoliłoby każdemu zablokować klientowi dostęp do własnego zlecenia po prostu przez wyczerpanie jego limitu.

Przesyłanie ograniczone jest do ustalonej listy typów plików — JPEG, PNG, WebP, PDF, DOCX, XLSX i zwykły tekst — oraz do maksymalnego rozmiaru zależnego od wykupionego planu. Obrazy są przed zapisaniem ponownie kodowane na serwerze.

Pliki dostarczane są przez krótkotrwałe podpisane linki generowane przez API. Ponieważ sam bucket jest prywatny, wygasły lub zmodyfikowany link nie daje absolutnie żadnego dostępu.

Przesyłanie i pobieranie mają odrębne limity liczby żądań per wywołujący, więc wyciekniętego linku ani rozbieganego klienta nie da się wykorzystać do nieograniczonego drenowania przestrzeni lub przepustowości.

Przechowywane pliki są szyfrowane w spoczynku przez dostawcę magazynu.

API stosuje limity liczby żądań dzielone per wywołujący — według obszaru roboczego i użytkownika z tokenu, jeśli taki istnieje, a w pozostałych przypadkach według adresu klienta. Logowanie, logowanie przez Google, reset hasła i potwierdzenie w portalu ograniczone są do dziesięciu prób na minutę; rejestracja do pięciu.

Ograniczniki odczytują rzeczywisty adres wywołującego z nagłówków przekazywanych przez proxy, a ustawiać je może wyłącznie samo proxy, któremu ufamy. Bez takiej konfiguracji każde żądanie wydawałoby się pochodzić od proxy i wszyscy dzieliliby jeden limit, co zamieniłoby ochronę w awarię.

Reverse proxy stosuje dodatkowy ogólny limit liczby żądań przed aplikacją, więc ruch jest ograniczany, zanim w ogóle dotrze do API.

Dane przychodzące są walidowane na serwerze, zanim trafią do logiki domenowej, a błędy zwracane są jako ustrukturyzowane komunikaty: do klienta nie trafiają ślady stosu, komunikaty bazy danych ani ścieżki wewnętrzne.

Baza danych i Redis znajdują się wyłącznie w sieci wewnętrznej i przyjmują połączenia tylko od API; żadne z nich nie jest wystawione do internetu.

Magazyn obiektowy szyfruje przechowywane pliki w spoczynku, a bucket nie jest publicznie odczytywalny.

Kopie zapasowe wykonywane są regularnie, a ich odtwarzanie testowane. Dane usunięte po zakończeniu subskrypcji znikają z kopii zapasowych wraz z ich wygasaniem w normalnym cyklu rotacji, a do tego czasu nie są wykorzystywane w żadnym innym celu.

Aplikacja zapisuje logi serwera, a każdy obszar roboczy ma historię aktywności odnotowującą, który użytkownik co i kiedy zmienił. Historia jest widoczna dla abonenta w aplikacji.

Logi serwera, aplikacji i bezpieczeństwa przechowywane są przez 90 dni, chyba że dany zapis jest przechowywany dłużej na potrzeby trwającego postępowania w sprawie bezpieczeństwa.

Logi służą prowadzeniu usługi i badaniu incydentów. Nie logujemy haseł, tokenów sesji ani danych kart płatniczych.

Dostęp do systemów produkcyjnych i danych produkcyjnych ograniczony jest do personelu, który potrzebuje go do prowadzenia usługi lub wsparcia, według zasady najmniejszych uprawnień i pod zobowiązaniem do zachowania poufności trwającym po zakończeniu współpracy.

Zależności zewnętrzne mają przypięte wersje i są zarządzane centralnie, więc wersję zmienia się w jednym miejscu; aktualizacje bezpieczeństwa platformy i jej zależności wdrażamy w miarę ich udostępniania.

Zmiany schematu bazy danych wprowadzane są jako wersjonowane migracje przy starcie usługi, więc schemat na produkcji zawsze odpowiada uruchomionemu na niej kodowi.

Dostawcy przetwarzający dane w naszym imieniu — hosting, magazyn obiektowy, dostarczanie poczty, płatności i fakturowanie — wymienieni są wraz z rolą i regionem w sekcji 5 informacji RODO i sekcji 8 informacji o przetwarzaniu danych.

O nowym dostawcy informujemy co najmniej 30 dni przed rozpoczęciem przez niego przetwarzania, aby abonent zgłaszający sprzeciw miał czas zareagować.

Prowadzimy wewnętrzny rejestr naruszeń ochrony danych osobowych i stosujemy procedurę obejmującą wykrycie, ocenę, ograniczenie skutków i zgłoszenie.

Gdy naruszenie może powodować ryzyko naruszenia praw i wolności osób fizycznych, zgłaszamy je właściwemu organowi nadzorczemu bez zbędnej zwłoki, a w miarę możliwości w ciągu 72 godzin od stwierdzenia (art. 33 RODO); gdy ryzyko jest wysokie, informujemy również prostym językiem osoby, których dotyczy (art. 34 RODO).

Gdy działamy jako podmiot przetwarzający, zawiadamiamy abonenta występującego w roli administratora bez zbędnej zwłoki po stwierdzeniu naruszenia i wspieramy go w wykonaniu jego własnych obowiązków zgłoszeniowych.

Żadnej usługi internetowej nie da się uczynić całkowicie bezpieczną. Ta strona opisuje środki, a nie gwarancje, a Regulamin nie zawiera zobowiązania co do dostępności ani poziomu usług.

Nie posiadamy certyfikacji ISO/IEC 27001 ani raportu SOC 2, a usługa nie została poddana niezależnym testom penetracyjnym. Gdyby cokolwiek z tego się zmieniło, zostanie to podane właśnie w tej sekcji.

Uwierzytelnianie dwuskładnikowe dla kont użytkowników nie jest jeszcze dostępne. Bezpieczeństwo konta opiera się zatem na sile hasła, blokadzie konta i opisanych wyżej limitach liczby żądań — dlatego prosimy o hasło nieużywane nigdzie indziej.

Usługa działa w jednym regionie, bez przełączania awaryjnego między regionami, a jeśli ten region zawiedzie, usługa jest niedostępna do czasu jego powrotu. Podajemy to, ponieważ oświadczenie o bezpieczeństwie wymieniające wyłącznie mocne strony nie nadaje się do podjęcia decyzji.

Jeśli znajdziesz podatność, napisz na info@ravsolutions.eu, podając opis, kroki potrzebne do jej odtworzenia oraz adres, którego dotyczy. Potwierdzimy otrzymanie zgłoszenia i poinformujemy, jak zamierzamy je obsłużyć.

Daj nam rozsądną możliwość naprawienia problemu, zanim ujawnisz go publicznie. Podczas testów nie uzyskuj dostępu do cudzych danych, nie zmieniaj ich ani nie usuwaj, nie pogarszaj działania usługi dla innych i nie stosuj socjotechniki wobec naszych pracowników ani dostawców.

Nie prowadzimy płatnego programu bug bounty. Nie podejmiemy działań przeciwko zgłaszającemu, który działa w dobrej wierze i w powyższych granicach.

To oświadczenie utrzymujemy w zgodzie z usługą. Numer wersji i data wejścia w życie na górze strony wskazują, który tekst obowiązuje, a wcześniejsze wersje udostępniamy na żądanie.

Gdy zmienia się opisany tu środek, zmienia się wraz z nim ta strona. Pytania o treść można kierować na info@ravsolutions.eu.