Rebutta
← Strona główna

Bezpieczeństwo

Wersja 2.0 z 6 sierpnia 2026. Dokument przygotowany do przeglądu przez kancelarię.

Ta strona jest odpowiedzią na ankietę bezpieczeństwa, którą dział IT albo zakupów przysyła przed podpisaniem umowy. Opisuje stan faktyczny, łącznie z tym, czego nie mamy. Jeżeli czegoś tu brakuje, napisz na kontakt@rebutta.app - odpowiemy konkretnie, a nie ogólnikiem.

---

1. Rozdział danych między Klientami

To jest najważniejszy mechanizm w całym systemie i dlatego stoi pierwszy.

Każda tabela zawierająca dane Klienta ma kolumnę z identyfikatorem firmy. Warstwa dostępu do bazy odrzuca zapytanie, które tej kolumny nie używa: nie jest to konwencja, której programista może zapomnieć, tylko blokada, o którą rozbija się pominięty warunek. Zapytanie, które świadomie ma iść ponad firmami (migracja, statystyka właściciela produktu), musi to zadeklarować w kodzie.

Skuteczność sprawdza osobny zestaw testów, który z konta jednej firmy próbuje sięgnąć po dane drugiej każdą ścieżką dostępną z zewnątrz: rozmowy, transkrypty, playbook, materiały, leady, integracje, zespół. Test jest częścią zestawu uruchamianego przed każdym wdrożeniem.

---

2. Szyfrowanie

GdzieJak
W transporciewyłącznie TLS. Aplikacja nie działa po HTTP; przeglądarka i tak nie udostępniłaby mikrofonu
W spoczynkuszyfrowanie po stronie dostawcy hostingu (Railway), obejmuje bazę i kopie zapasowe
Hasławyłącznie skróty bcrypt, koszt 12. Hasła w postaci jawnej nie są nigdzie zapisywane ani logowane
Tokeny do CRM KlientaAES-256-GCM, kluczem trzymanym poza bazą. Zrzut bazy nie daje dostępu do CRM-u Klienta
Zaproszenia do zespołuw bazie leży wyłącznie skrót SHA-256 tokenu. Wyciek tabeli nie pozwala wejść na konto

Token CRM nigdy nie wraca do przeglądarki. Panel pokazuje wyłącznie cztery ostatnie znaki.

---

3. Uwierzytelnianie i dostęp

---

4. Dane, których nie ma

Najskuteczniejsze zabezpieczenie danych to ich nieprzechowywanie:

---

5. Podprocesorzy i lokalizacja danych

Pełna lista z zakresem danych i podstawą transferu: rebutta.app/podprocesorzy.html.

Baza danych i aplikacja stoją w regionie europejskim. Do modeli językowych i transkrypcji w Stanach Zjednoczonych trafia treść rozmowy i playbook, na podstawie standardowych klauzul umownych. Dostawcy ci nie trenują modeli na przekazanych danych.

Klient, dla którego przetwarzanie poza EOG jest niedopuszczalne, powinien to zgłosić przed zawarciem umowy. Dziś nie mamy wariantu wyłącznie europejskiego i mówimy to wprost, zamiast obiecywać go w ankiecie.

---

6. Kopie zapasowe i ciągłość

Kopie zapasowe bazy wykonuje dostawca hostingu, z tym samym ograniczeniem dostępu co dane produkcyjne. Odtworzenie jest testowane przy okazji migracji i zmian schematu.

Nie udzielamy gwarancji dostępności (SLA). Usługa stoi na jednej instancji i zależy od dostawców zewnętrznych; obietnica dostępności, której nie da się pokryć architekturą, byłaby obietnicą pustą. Zamiast tego Regulamin przewiduje proporcjonalne obniżenie opłaty przy przerwie dłuższej niż 48 godzin z naszej winy.

---

7. Rozwój i wdrożenia

---

8. Naruszenia

Naruszenie ochrony danych zgłaszamy Klientowi bez zbędnej zwłoki, nie później niż w ciągu 48 godzin od stwierdzenia, na adres e-mail przypisany do konta, wraz z opisem zakresu, możliwych skutków i podjętych działań. Szczegóły w umowie powierzenia.

Podatności prosimy zgłaszać na kontakt@rebutta.app. Nie ścigamy osób, które zgłaszają je w dobrej wierze, nie wykorzystują ich poza zakresem koniecznym do wykazania problemu i nie ujawniają ich publicznie przed naprawą.

---

9. Czego nie mamy

Uczciwie, bo dział IT i tak to sprawdzi:

Jeżeli któraś z tych pozycji jest dla Was warunkiem koniecznym, powiedzcie o tym przed podpisaniem umowy, a nie po.