Bezpieczeństwo i zgodność

Uwierzytelnianie

• Tokeny dostępu to krótkotrwałe JWT (15 minut) weryfikowane w bramie API; tokeny odświeżania żyją 30 dni bezczynności i maksymalnie 90 dni, są wymieniane przy każdym użyciu i przechowywane w pliku cookie HttpOnly, Secure, SameSite. Ponowne użycie wymienionego tokenu odświeżania unieważnia cały łańcuch.
• Klucze podpisujące są zmieniane co 90 dni z okresem nakładania się; klucze publiczne są publikowane pod /.well-known/jwks.json.
• Uprawnienia nie są zapisane w tokenach: są odczytywane przy każdym żądaniu, więc zmiana roli działa natychmiast, a każdą sesję można centralnie unieważnić.
• Uwierzytelnianie dwuskładnikowe (TOTP) może być opcjonalne, wymagane dla Właścicieli i Administratorów albo wymagane dla wszystkich. Logowanie jednokrotne przez Google Workspace i Apple jest dostępne w każdym planie. SAML 2.0, klucze dostępu (passkeys) i provisioning SCIM są planowane i na razie niedostępne.
• Klucze API są pokazywane raz, przechowywane jako skrót SHA-256, mają zakresy z zamkniętego katalogu, są ograniczone uprawnieniami właściciela i można je natychmiast odwołać. Zobacz Uwierzytelnianie.
• Logowanie ma limity per IP i per e-mail; dziesięć nieudanych prób blokuje konto na 30 minut; nieudane próby z jednego adresu IP są liczone i zapisywane, ale domyślnie nie blokują tego adresu. Każde logowanie, nieudana próba, odświeżenie, zmiana uprawnień i działanie administracyjne trafia do dziennika audytu.

Izolacja najemców

Każdy wiersz w każdej usłudze zawiera konto, do którego należy, a każde zapytanie jest automatycznie filtrowane według niego; wyłączenie filtra wymaga jawnego wywołania z listy dozwolonych, używanego tylko przez międzynajemcowe operacje personelu i objętego testami. Role przypisane do stron dodają filtr strony. Żądanie zasobu innego konta zwraca 404, nigdy 403, aby nie dało się wyliczać identyfikatorów. Każdy endpoint zapisu używa ścisłej listy dozwolonych pól. Test dostępu między kontami jest obowiązkowy dla każdego nowego endpointu.

Nagłówek X-Account-Id w każdym żądaniu jest sprawdzany względem tokenu, więc błąd klienta lub odtworzony token nigdy nie może po cichu odczytać danych innego najemcy.

Szyfrowanie

TLS 1.2 lub nowszy do każdego publicznego endpointu, wzajemny TLS między usługami, TLS do każdego magazynu danych, szyfrowane woluminy w spoczynku oraz szyfrowanie kopertowe wrażliwych pól dla każdego konta. Publiczne certyfikaty są wystawiane i odnawiane automatycznie; certyfikaty wewnętrzne są krótkotrwałe.

Sekrety

Wszystkie sekrety, w tym Twoje klucze dostawców BYOK i sekrety webhooków, znajdują się w dedykowanym menedżerze sekretów, zaszyfrowane, ograniczone do poszczególnych usług i objęte audytem. Nic nie trafia do systemu kontroli wersji (co wymusza skanowanie przed każdym commitem) ani do obrazów kontenerów (sprawdzane w CI). Deweloperzy domyślnie nie mają dostępu do sekretów produkcyjnych; dostęp awaryjny wymaga dwóch zatwierdzeń, jest krótkotrwały i logowany na kanał, którego nie da się wyciszyć.

Webhooki

Dostarczenia wychodzące są podpisywane HMAC-SHA256 ze znacznika czasu i surowej treści, zawierają nonce i identyfikator zdarzenia, są odrzucane poza pięciominutowym oknem i ponawiane z wydłużanymi odstępami aż do kolejki martwych wiadomości. Sekrety są zmieniane z oknem nakładania się i można je natychmiast odwołać. Przychodzące webhooki dostawców są weryfikowane według schematu danego dostawcy, zanim cokolwiek zostanie przetworzone. Szczegóły: Webhooki.

Limity żądań

Cztery warstwy: ochrona przed DDoS i botami w sieci brzegowej, limity per IP w reverse proxy, kubełki tokenów per konto i per tożsamość w bramie API oraz limity domenowe wewnątrz usług. Limity są opisane w przeglądzie API.

Audyt

Każda zmiana jest zapisywana w dzienniku audytu, który pozwala tylko dopisywać wpisy i jest połączony łańcuchem skrótów, z dwiema klasami przechowywania: zdarzenia ogólne i zdarzenia zgodności (wnioski osób, których dane dotyczą, naruszenia, podmioty przetwarzające i wpisy KYC). Klasa jest przypisywana w chwili zapisu; nikt nie może edytować ani usuwać dziennika, a automatyczne czyszczenie według klas jeszcze nie działa. Właściciele i Administratorzy mogą go filtrować i eksportować. Hasła, tokeny i klucze nigdy nie są logowane; warstwa logowania redaguje znane wrażliwe klucze.

Ochrona danych

• Wnioski osób, których dane dotyczą, w ramach RODO, UK GDPR, CCPA i LGPD (dostęp, eksport, usunięcie) są przyjmowane i śledzone w konsoli zgodności wraz z terminami. Usunięcie wykonują pracownicy RolChat, a wniosek jest zamykany dopiero po ich potwierdzeniu; automatycznego usuwania we wszystkich modułach jeszcze nie ma.
• Lokalizacja danych: dane są przechowywane w UE. Region nie jest wybierany według kraju przy rejestracji; ustawienie regionu w ustawieniach konta jest tylko zapisywane i na razie nie przenosi danych.
• Przechowywanie zależy od planu: 1, 2 lub 3 lata. Usunięta rozmowa lub kontakt jest ukryta do końca tego okresu; usunięcie konta to wniosek z 30 dniami na anulowanie, po których pracownicy usuwają dane; konto nieopłacone jest przechowywane 90 dni, a potem dane są usuwane. Automatyczne czyszczenie egzekwujące te terminy jest wdrażane.
• Umowa powierzenia przetwarzania danych, lista podmiotów przetwarzających, polityka prywatności i polityka plików cookie są opublikowane na rolchat.com; umowę powierzenia akceptuje się przy rejestracji.
• Powiadomienie o naruszeniu w ciągu 72 godzin, zgodnie z art. 33 RODO.

Zarządzanie podatnościami

Zależności są stale monitorowane; pliki blokad są commitowane; obrazy bazowe są przypięte skrótem (digest); akcje CI są przypięte do commita. Od bety co roku planowany jest zewnętrzny test penetracyjny obejmujący API, widżet i strony publiczne oraz wewnętrzny scenariusz założonego włamania. Prywatny program bug bounty ruszy wraz z wersją ogólnodostępną. Problemy bezpieczeństwa zgłaszaj na security@rolchat.com.

Dostępność usługi

Platforma działa na wielu węzłach z automatycznym przełączaniem awaryjnym dla usług bezstanowych i zarządzaną replikacją baz danych. Docelowe wskaźniki dostępności dla poszczególnych planów są określone w Twojej umowie.

Reagowanie na incydenty

Procedury dla każdej usługi, rotacja dyżurów, zewnętrzny system powiadamiania, który działa, gdy nasza własna infrastruktura nie działa, oraz obowiązki powiadamiania klientów wbudowane w proces.