Przejdź do treści
Ala AI BOT

Bezpieczeństwo

Architektura, którą da się sprawdzić

Poniżej opisujemy mechanizmy, które są w kodzie: sposób przechowywania kluczy, podpisy webhooków, szyfrowanie sekretów, izolację sklepów i maskowanie nagrań.

Zobacz CSP dla sklepuDokumentacja techniczna

Najważniejsze fakty

  • Klucz tajny nigdy nie trafia do przeglądarki.
  • W bazie leży skrót klucza, nie klucz.
  • Webhooki są podpisane HMAC-SHA256 z tolerancją 5 minut.
  • Sekrety integracji są szyfrowane AES-256-GCM.
  • Role uprzywilejowane wymagają 2FA.
  • Nagrania maskują pola formularzy domyślnie.

Ta strona opisuje mechanizmy techniczne. Nie deklarujemy tu certyfikacji ani audytów, których nie przeszliśmy.

Architektura

Osiem warstw, które trzymają dane na miejscu

Każdy punkt odpowiada konkretnemu mechanizmowi w aplikacji — nie jest deklaracją intencji.

Klucze API sklepu

Sklep dostaje dwa klucze: publiczny do przeglądarki i tajny do wywołań serwerowych.

  • Klucz publiczny (pk_) jest widoczny w kodzie strony z założenia i nie daje dostępu do danych panelu.
  • Klucz tajny (sk_) uwierzytelnia wyłącznie wywołania backend-to-backend i nigdy nie trafia do przeglądarki.
  • W bazie przechowujemy skrót SHA-256 klucza, jego prefiks i cztery ostatnie znaki — surowej wartości nie da się odtworzyć.
  • Rotacja działa z zakładką czasową, więc wymiana klucza nie wymaga przestoju; stary klucz można też natychmiast unieważnić.

Podpisane webhooki wychodzące

Każde żądanie wychodzące jest podpisane, a odbiorca może je zweryfikować bez pytania nas o nic.

  • Nagłówek X-Ala-Signature ma postać t=<unix>,v1=<hex>, gdzie v1 to HMAC-SHA256 z sekretu endpointu nad ciągiem <t>.<body>.
  • Tolerancja znacznika czasu wynosi 5 minut, co odcina powtórzenia starych żądań.
  • Akceptujemy wyłącznie adresy https; adresy w sieciach prywatnych są odrzucane jako ochrona przed SSRF.
  • Po serii nieudanych dostarczeń endpoint jest automatycznie pauzowany, a zdarzenia trafiają do martwej kolejki.

Szyfrowanie danych dostępowych

Sekrety integracji i webhooków nie leżą w bazie w postaci jawnej.

  • Szyfrujemy je algorytmem AES-256-GCM; zapisujemy wektor inicjujący, tag uwierzytelniający i szyfrogram.
  • Klucz szyfrujący pochodzi ze zmiennej środowiskowej i nie jest przechowywany razem z danymi.
  • Sekrety i tokeny mają własną klasę w rejestrze danych — nie trafiają do logów ani do eksportów.

2FA dla ról uprzywilejowanych

Dostęp do ustawień, rozliczeń i danych osobowych wymaga drugiego składnika.

  • Konto z rolą uprzywilejowaną bez włączonego 2FA jest przekierowywane do konfiguracji, zanim zobaczy dane.
  • Uprawnienia są nadawane per moduł, a nie jednym przełącznikiem „administrator”.
  • Każda zmiana konfiguracji trafia do dziennika audytu razem z autorem i stanem przed zmianą.

Izolacja sklepów i przestrzeni

Nie istnieje zapytanie, które sięga po dane więcej niż jednej przestrzeni.

  • Każde zapytanie do danych jest zawężane identyfikatorem przestrzeni i sklepu.
  • Klucz API rozwiązuje się do dokładnie jednego sklepu — kluczem z innej przestrzeni nie odczytasz cudzych danych.
  • Sklep zawieszony lub zarchiwizowany przestaje przyjmować ruch z publicznego API.

Prywatność już przy zbieraniu danych

Filtry działają na wejściu, a nie dopiero w raportach.

  • Sygnał Do Not Track i Global Privacy Control wyłącza analitykę, nagrania, personalizację i marketing, gdy sklep wybrał tryb „respektuj”.
  • Adresy IP są skracane (IPv4 do /24, IPv6 do /64), a następnie haszowane z kluczem — surowy adres nie jest zapisywany.
  • Rejestr klas danych decyduje, co w ogóle wejdzie do bazy: sekrety i dane szczególnych kategorii są odrzucane przy przyjęciu zdarzenia.

Nagrania sesji z maskowaniem

Nagranie pokazuje zachowanie, nie treść wpisywaną przez klienta.

  • Wszystkie pola formularzy są maskowane domyślnie; hasła, dane płatnicze i ramki iframe są blokowane całkowicie.
  • Sklep może dodać własne selektory do zablokowania albo włączyć maskowanie całego tekstu na stronie.
  • Moduł nagrań ładuje się wyłącznie przy zgodzie na analitykę i nagrania.

Retencja i usuwanie danych

Dane znikają automatycznie, a nie na wniosek złożony w odpowiednim momencie.

  • Obowiązuje surowsza z dwóch wartości: ustawienie przestrzeni albo limit planu.
  • Zdarzenia, nagrania, rozmowy i dziennik audytu mają osobne okresy przechowywania.
  • Cykliczne zadanie usuwa lub anonimizuje dane, a jego przebieg trafia do dziennika audytu.

Dane

Co zapisujemy, a czego nie zapiszemy nigdy

Klasyfikacja danych działa na wejściu: zanim zdarzenie trafi do bazy, rejestr decyduje, które właściwości zostaną odrzucone.

Zapisujemy

  • Zdarzenia zachowania: odsłony, kliknięcia, przewinięcia, czas aktywny.
  • Zdarzenia ecommerce przekazane przez sklep lub zmapowane z warstwy danych.
  • Identyfikatory pseudonimowe: anonimowy identyfikator przeglądarki i identyfikator klienta przekazany przez sklep.
  • Treść rozmów z asystentką i decyzje reguł, które je wywołały.
  • Zamówienia i zwroty potwierdzone przez backend sklepu.
  • Techniczny kontekst sesji: język, rozmiar okna, strefa czasowa, typ urządzenia.

Nie zapisujemy

  • Haseł, tokenów, kluczy API i nagłówków autoryzacyjnych.
  • Numerów PESEL, IBAN, numerów kart i innych danych szczególnych kategorii.
  • Wartości wpisywanych w formularzach podczas nagrywania sesji.
  • Surowych adresów IP.
  • Danych osobowych w zdarzeniach, jeśli sklep nie włączył ich jawnie dla danego schematu.

Retencja

  • Okres przechowywania zdarzeń i nagrań wynika z planu oraz ustawień przestrzeni.
  • Rozmowy i dziennik audytu mają własne, dłuższe minimum.
  • Nagrania dodatkowo wygasają automatycznie po stronie bazy danych.
  • Realizacja żądań RODO jest rejestrowana i potwierdzana linkiem e-mail.
Złóż żądanie dotyczące swoich danych

Integracja

CSP dla sklepu

Jeśli Twój sklep ma Content Security Policy, dopisz poniższe dyrektywy. Bez nich przeglądarka zablokuje skrypt i wywołania API asystentki.

  • Skrypt ładujemy asynchronicznie — jego niedostępność nie blokuje renderowania sklepu.
  • Jeśli używasz nonce, przekaż go w atrybucie skryptu: loader ustawi ten sam nonce na skryptach, które sam dołącza.
  • Dyrektywa img-src jest potrzebna tylko wtedy, gdy asystentka ma ustawiony awatar.
  • Nie wymagamy 'unsafe-inline' ani 'unsafe-eval' po stronie sklepu.
Instalacja standardowa
script-src 'self' https://www.alabot.app;
style-src 'self' https://www.alabot.app;
connect-src 'self' https://www.alabot.app;
img-src 'self' data: https://res.cloudinary.com;

Przy proxy first-party skrypt i API są serwowane z Twojej domeny, więc polityka nie musi wymieniać zewnętrznego hosta.

Instalacja przez proxy first-party
script-src 'self';
connect-src 'self';
style-src 'self';
img-src 'self' data: https://res.cloudinary.com;

Dokumenty

Reszta papierów w jednym miejscu

Polityka prywatności, regulamin i informacja RODO obowiązują od 18 września 2026 — dane rejestrowe usługodawcy znajdziesz w każdym z tych dokumentów.

Porozmawiaj o wdrożeniu