Bezpieczeństwo

Wersja 1.2 · 04.10.2026

Ta strona opisuje, jak chronimy dane w Quanty. Podajemy wyłącznie to, co możemy pokazać w systemie. Nie posiadamy certyfikatów bezpieczeństwa i nie twierdzimy, że jesteśmy „zgodni z RODO”, bo zgodność zależy też od tego, jak używa systemu administrator danych. Poniżej jest opis środków, a nie deklaracja.

1. Gdzie działa Quanty

Aplikacja i baza danych działają w Amazon Web Services, w regionie eu-central-1 (Frankfurt, Niemcy), od 13.09.2026. Pliki klientów są przechowywane w tym samym regionie.

Wcześniej system działał na serwerze w Polsce. Informacja „serwery w Polsce” jest nieaktualna i została usunięta ze strony.

Dostęp do serwera odbywa się wyłącznie przez AWS Systems Manager Session Manager. Nie ma otwartego dostępu SSH.

Funkcje AI w aplikacji działają na Amazon Bedrock. Rozmowy w Sekretarce AI są obsługiwane w Amazon Web Services w UE: Amazon Transcribe, model Claude w Amazon Bedrock oraz Amazon Polly. Szczegóły i podstawy transferu opisuje strona /subprocessors.

2. Szyfrowanie

Ruch między przeglądarką a serwerem jest szyfrowany protokołem TLS.

Dane w bazie, pliki w magazynie obiektowym i kopie zapasowe są szyfrowane w spoczynku.

Tokeny dostępu do integracji i hasła do skrzynek pocztowych są przechowywane w postaci zaszyfrowanej i nie są pokazywane ponownie po wprowadzeniu.

Nie twierdzimy, że stosujemy szyfrowanie end-to-end. Dane muszą być odszyfrowane, aby system mógł je przetworzyć.

3. Rozdzielenie danych klientów

Każda organizacja ma własną przestrzeń danych. Rozdzielenie egzekwuje warstwa aplikacji przy każdym zapytaniu do bazy.

Identyfikator organizacji pochodzi z sesji zalogowanego użytkownika, a nie z parametrów żądania, więc nie da się sięgnąć po dane innej organizacji przez podmianę identyfikatora w adresie lub w treści żądania.

Rozdzielenie jest objęte testami automatycznymi uruchamianymi przed każdym wdrożeniem.

4. Logowanie i uwierzytelnianie

Logowanie obsługuje Amazon Cognito. Hasła są przechowywane wyłącznie w postaci skrótu.

Drugi składnik uwierzytelnienia jest wymagany dla kont administracyjnych i dla operacji wrażliwych, takich jak zmiana ustawień bezpieczeństwa czy usunięcie konta. Można go mieć w dwóch postaciach i można mieć obie naraz.

Aplikacja uwierzytelniająca (TOTP): jednorazowy kod ważny w wąskim oknie czasu. Zużyty kod nie może zostać użyty ponownie, a po serii błędnych prób składnik jest blokowany na czas karencji.

Wiadomość SMS: sześciocyfrowy kod wysyłany na numer telefonu, który użytkownik sam zarejestrował. Kod przechowujemy w postaci skrótu, wygasa po 5 minutach, działa jednorazowo, a wysyłki ogranicza karencja między kolejnymi kodami i dzienny limit. Numer pokazujemy wyłącznie w postaci zamaskowanej. Wiadomości wysyła AWS End User Messaging SMS w regionie eu-central-1 (Frankfurt).

Aplikacja uwierzytelniająca jest bezpieczniejsza od SMS-a i to ją zalecamy. Wiadomość SMS przechodzi przez sieć operatora komórkowego i jest podatna na przejęcie numeru (SIM swap) oraz na przechwycenie w sieci sygnalizacyjnej. SMS udostępniamy dlatego, że jest lepszy niż brak drugiego składnika, a nie dlatego, że dorównuje aplikacji.

Przy włączeniu drugiego składnika użytkownik otrzymuje kody zapasowe. Każdy działa jeden raz, przechowujemy je w postaci skrótu, a wygenerowanie nowego kompletu unieważnia poprzedni.

Jeśli ktoś straci telefon albo aplikację uwierzytelniającą, administrator platformy może odblokować zablokowany składnik, unieważnić sesje, wydać nowe kody zapasowe albo zresetować składnik, żeby dało się skonfigurować go od nowa. Robimy to dopiero po potwierdzeniu tożsamości kanałem innym niż konto, którego sprawa dotyczy. Każde takie działanie trafia do rejestru opisanego w sekcji 9, którego nie da się zmienić ani usunąć z poziomu aplikacji.

Sesje wygasają, a ich unieważnienie jest natychmiastowe po wylogowaniu i po zmianie hasła.

5. Dostęp naszego personelu

Nasz personel nie ma stałego dostępu do danych klientów.

Dostęp wsparcia jest przyznawany na czas określony, domyślnie na 7 dni i najwyżej na 30 dni. Po tym czasie wygasa automatycznie.

Klient widzi aktywny dostęp wsparcia w panelu organizacji i może go odwołać w każdej chwili.

Każda osoba z dostępem ma pisemne upoważnienie i zobowiązanie do poufności. Prowadzimy rejestr osób upoważnionych.

6. Kopie zapasowe

Baza danych działa na Amazon RDS z automatycznymi kopiami zapasowymi. Kopie są szyfrowane i pozostają w tym samym regionie UE.

Udokumentowanego testu odtworzenia z kopii jeszcze nie przeprowadziliśmy. Planujemy go i opublikujemy wynik w materiałach dla klientów, zamiast twierdzić, że test już się odbył.

7. Przechowywanie i usuwanie danych

Usunięcie konta przenosi je do stanu archiwalnego na 180 dni, aby dało się je przywrócić po pomyłce, a następnie dane są trwale usuwane.

Kopia robocza wiadomości pobranej z połączonej skrzynki jest usuwana po 14 dniach.

Sekretarka AI nie nagrywa dźwięku rozmów. Tekstowy zapis rozmowy przechowujemy w Quanty przez okres ustawiony przez organizację, domyślnie 30 dni.

Dane z połączeń można usunąć pojedynczo z poziomu aplikacji.

Po zakończeniu umowy dane usuwamy z systemów produkcyjnych, a z kopii zapasowych w cyklu ich nadpisywania, nie dłuższym niż 90 dni.

8. Integracje i webhooki

Wiadomości przychodzące z systemów zewnętrznych, w tym zdarzenia płatności i zdarzenia po rozmowie telefonicznej, są podpisane, a podpis weryfikujemy przed przetworzeniem. Wiadomość bez poprawnego podpisu jest odrzucana.

Poczta wychodząca i przychodząca przechodzi przez Amazon SES w regionie UE.

9. Rejestrowanie działań

Działania administratorów platformy są zapisywane w osobnym rejestrze: kto, co i kiedy zrobił.

W rejestrze znajdują się także działania odzyskiwania dostępu do konta: odblokowanie drugiego składnika, unieważnienie sesji, wydanie nowych kodów zapasowych i reset składnika.

Zdarzenia logowania i zmiany uprawnień są rejestrowane. Rejestry przechowujemy do 12 miesięcy, dłużej tylko wtedy, gdy dotyczą badanego incydentu.

Rozszerzenie rejestru o zdarzenia dotyczące danych z połączeń, wraz z eksportem dla inspektora ochrony danych klienta, jest w planie.

10. Rozwój oprogramowania

Zmiany w kodzie przechodzą przez przegląd i zestaw testów automatycznych uruchamianych przed wdrożeniem.

Środowisko produkcyjne i testowe są rozdzielone i mają osobne bazy danych oraz osobne dane dostępowe.

Sekrety przechowujemy poza repozytorium kodu.

11. Czego nie twierdzimy

Nie posiadamy certyfikatów ISO 27001, ISO 27701, ISO 42001 ani SOC 2 i nie posiadamy certyfikacji z art. 42 RODO. Certyfikaty posiadają nasi dostawcy infrastruktury; nie są to nasze certyfikaty.

Nie jesteśmy „zgodni z HIPAA” i nie podpisujemy BAA. To prawo amerykańskie, nieistotne dla polskich placówek.

Nie twierdzimy, że dane nigdy nie opuszczają Unii Europejskiej. Przypadki, w których je opuszczają, opisujemy w polityce prywatności i na stronie /subprocessors.

Nie twierdzimy, że nie przechowujemy transkrypcji ani nagrań. Transkrypcje są przechowywane domyślnie przez 30 dni.

12. Zgłaszanie podatności

Jeśli znalazłeś podatność, napisz na dawid@pluscode.io z opisem, krokami odtworzenia i wpływem. Potwierdzamy zgłoszenie w ciągu 3 dni roboczych i informujemy o postępach.

Prosimy o nieujawnianie podatności publicznie, zanim ją naprawimy, o niepobieranie i nieusuwanie cudzych danych oraz o niewykonywanie testów obciążeniowych i ataków odmowy usługi.

Nie prowadzimy programu nagród. Za zgłoszenia dziękujemy i, za zgodą zgłaszającego, wymieniamy je w podziękowaniach.

Ta sama informacja jest dostępna maszynowo pod adresem /.well-known/security.txt.