Polityka bezpieczeństwa informacji

1. Zakres i odpowiedzialność

Polityka obejmuje wszystkie systemy, dane, osoby i dostawców zaangażowanych w świadczenie Platformy. Odpowiedzialność za bezpieczeństwo informacji ponosi zarząd spółki; nadzór nad zgodnością przetwarzania danych osobowych sprawuje Inspektor Ochrony Danych. Polityka jest przeglądana co najmniej raz w roku oraz po każdym istotnym incydencie lub zmianie architektury.

2. Zasady

• Najmniejsze uprawnienia — ludzie, usługi i agenci AI dostają wyłącznie dostęp niezbędny do zadania.
• Domyślna odmowa — zasób, do którego nie nadano dostępu, jest niedostępny; brak decyzji nie oznacza zgody.
• Obrona warstwowa — każda warstwa (brama, usługa, baza danych) egzekwuje dostęp samodzielnie, nie polegając na poprzedniej.
• Bezpieczeństwo w projekcie — wymagania bezpieczeństwa są częścią specyfikacji funkcji, a nie przeglądem po fakcie.
• Minimalizacja danych — zbieramy i przechowujemy tylko to, co potrzebne, przez określony czas.

3. Infrastruktura

• Usługi aplikacyjne, bazy danych PostgreSQL i pliki działają w chmurze Railway w regionie europe-west4 (Holandia, EOG). Strony publiczne i aplikacje webowe serwuje Vercel; ruch przechodzi przez Cloudflare (DNS, ochrona przed atakami DDoS).
• Platforma składa się z odseparowanych mikroserwisów. Z internetu dostępna jest wyłącznie brama API i powierzchnie publiczne; usługi wewnętrzne komunikują się siecią prywatną, uwierzytelniając każde wywołanie kluczem usługowym.
• Cała komunikacja z Platformą jest szyfrowana protokołem TLS (HTTPS); połączenia nieszyfrowane nie są obsługiwane.
• Środowisko testowe (UAT) jest oddzielone od produkcyjnego i nie zawiera danych produkcyjnych Klientów.

4. Izolacja danych Klientów

Każdy rekord Danych Klienta jest przypisany do Workspace. Izolację egzekwuje sama baza danych mechanizmem Row-Level Security (polityki na poziomie wiersza) we wszystkich usługach przechowujących dane najemców, niezależnie od logiki aplikacji. Każda zmiana w obszarze uprawnień przechodzi przegląd izolacji najemców, a testy automatyczne weryfikują, że dane jednego Workspace nie są widoczne w innym.

5. Tożsamość i kontrola dostępu

• Logowanie bez haseł: jednorazowy kod wysyłany e-mailem, klucze dostępu (passkey, WebAuthn/FIDO2) oraz opcjonalny drugi składnik (TOTP). Nie przechowujemy haseł użytkowników.
• Role: dostęp w Workspace wynika z roli (właściciel, administrator, członek, gość) i uprawnień do modułów; zasoby są domyślnie prywatne dla ich autora.
• Tokeny dostępu do API i serwera MCP są pokazywane jednorazowo, przechowywane wyłącznie w postaci skrótu, mogą mieć datę ważności i są odwoływalne w każdej chwili.
• Dostęp personelu: do danych produkcyjnych mają wyłącznie wyznaczone osoby, a konta administracyjne u dostawców infrastruktury wymagają uwierzytelniania wieloskładnikowego. Dostęp jest ograniczony do zakresu niezbędnego do utrzymania i wsparcia; dostęp jest odbierany niezwłocznie po zmianie roli lub zakończeniu współpracy.
• Sesje wygasają i są odnawiane w kontrolowany sposób; wylogowanie i usunięcie urządzenia unieważnia jego sesję.

6. Szyfrowanie i sekrety

• Transmisja: TLS na wszystkich połączeniach zewnętrznych.
• Tokeny integracji (OAuth), hasła skrzynek i inne sekrety Klientów są szyfrowane na poziomie aplikacji algorytmem AES-256-GCM; w sejfie sekretów automatyzacji każdy wpis ma własny klucz, opakowany kluczem głównym i związany z identyfikatorem Workspace, co uniemożliwia jego użycie w innym Workspace.
• Sekrety infrastruktury są przechowywane w zmiennych środowiskowych platformy chmurowej, nigdy w repozytorium kodu.
• Dane kart płatniczych nie trafiają do naszych systemów — obsługuje je Stripe (PCI DSS Level 1).

7. Bezpieczne wytwarzanie i zmiany

• Kod jest wersjonowany; zmiana trafia na produkcję wyłącznie przez zatwierdzone połączenie gałęzi (pull request), po przejściu bramki jakości: lint, kontrola typów, testy jednostkowe i integracyjne, testy bazodanowe polityk dostępu, build.
• Wydania przygotowuje wyznaczona rola, oddzielona od autorów zmian, po przeglądzie całości i styków między zmianami.
• Migracje baz danych są wersjonowane, niezmienne po wydaniu i rejestrowane.
• Zależności są aktualizowane, a znane podatności w nich ocenia procedura zarządzania podatnościami.

8. Bezpieczeństwo funkcji AI

• Agent AI działa z uprawnieniami Użytkownika, w którego imieniu działa — nigdy szerszymi.
• Wywołania modeli językowych kierujemy przez bramkę modeli, która wybiera dostawcę i rejestruje użycie; korzystamy wyłącznie z dostawców wymienionych w Polityce prywatności.
• Akcje nieodwracalne lub zewnętrzne (wysyłka, publikacja, płatność) wymagają potwierdzenia człowieka lub reguły zatwierdzania.
• Treści pochodzące z zewnątrz (e-maile, strony, dokumenty) są traktowane jako dane, a nie polecenia dla agenta.

9. Monitorowanie i dzienniki

Usługi raportują do własnego systemu obserwowalności: żądania, błędy, zdarzenia bezpieczeństwa i działania. Zdarzenia bezpieczeństwa (m.in. nieudane logowania, odmowy dostępu, błędy uwierzytelniania usług) są rejestrowane i przeglądane; automatyczne wykrywanie anomalii rozbudowujemy. Dzienniki żądań przechowujemy 30 dni, zdarzenia bezpieczeństwa i działań 90 dni; dzienniki nie zawierają treści sekretów ani tokenów.

10. Zarządzanie podatnościami i testy

Prowadzimy program testów penetracyjnych w kampaniach obejmujących perymetr i tożsamość, izolację najemców i eskalację uprawnień, powierzchnię agentową (MCP), dane i pliki, płatności i limity oraz powierzchnię publiczną. Każda podatność jest rejestrowana, oceniana według CVSS i usuwana w terminach:

Każda usunięta podatność zostawia test regresji, który nie pozwala jej wrócić.

11. Zgłaszanie podatności

Jeśli odkryjesz podatność, napisz na support@signaltoinsight.com z tematem zaczynającym się od „[SECURITY]" — opisz ją i sposób odtworzenia. Potwierdzamy otrzymanie w ciągu 3 dni roboczych i informujemy o postępie. Adres jest też podany w pliku security.txt.

Nie podejmiemy kroków prawnych wobec osoby, która działa w dobrej wierze: testuje wyłącznie na własnym koncie, nie narusza prywatności innych, nie zakłóca działania usługi, nie wynosi danych ponad niezbędne minimum i daje nam rozsądny czas na usunięcie podatności przed jej ujawnieniem.

12. Incydenty i naruszenia ochrony danych

Stosujemy wewnętrzną procedurę obsługi incydentów: wykrycie, ocena, ograniczenie, usunięcie przyczyny, odtworzenie i analiza po zdarzeniu. W razie naruszenia ochrony danych osobowych:

• zawiadamiamy Klientów, których dane dotyczą, bez zbędnej zwłoki — nie później niż w ciągu 48 godzin od stwierdzenia naruszenia;
• jako administrator zgłaszamy naruszenie Prezesowi UODO w ciągu 72 godzin, jeżeli może ono powodować ryzyko naruszenia praw lub wolności osób, a przy wysokim ryzyku zawiadamiamy także osoby, których dane dotyczą;
• powiadamiamy dostawców platform, z którymi Platforma jest zintegrowana (np. Google, Microsoft, Meta, TikTok, LinkedIn), w terminach i trybie określonych w ich warunkach dla deweloperów, jeżeli naruszenie obejmuje dane uzyskane przez ich interfejsy.

Kontakt w sprawie incydentu: support@signaltoinsight.com, w sprawach danych osobowych: iod@signaltoinsight.com.

13. Ciągłość działania

Usługi są wdrażane jako kontenery odtwarzalne z kodu i konfiguracji; każda może zostać ponownie uruchomiona lub przywrócona do poprzedniej wersji. Bazy danych działają w zarządzanej infrastrukturze dostawcy. Formalny plan kopii zapasowych i odtwarzania po awarii — z publikowanymi celami punktu i czasu odtworzenia (RPO/RTO) — jest w trakcie wdrażania; jego parametry opublikujemy w tej Polityce po uruchomieniu.

14. Dostawcy

Dostawców oceniamy pod kątem bezpieczeństwa przed rozpoczęciem współpracy, zawieramy z nimi umowy powierzenia i przekazujemy im wyłącznie dane niezbędne do ich zadania. Lista podprzetwarzających znajduje się w Polityce prywatności.

15. Ludzie

Osoby z dostępem do danych są zobowiązane do zachowania poufności, znają tę Politykę i procedury z nią związane, a ich dostęp jest przeglądany i odbierany po zakończeniu współpracy. Z informacjami postępujemy zgodnie z Polityką klasyfikacji danych.