Bezpieczeństwo DarhimLabs

Bezpieczeństwo DarhimLabs jest projektowane jako część produktu, a nie dodatkowa warstwa po wdrożeniu. Platforma obsługuje rozmowy klientów, konfiguracje agentów AI, dokumenty bazy wiedzy, webhooki, klucze API, transkrypcje Voice i dane compliance, dlatego każdy moduł musi mieć kontrolę dostępu, audyt, retencję, izolację tenantów i bezpieczne domyślne ustawienia. Ten dokument opisuje architekturę, proces reagowania na incydenty, program zgłaszania podatności i sposób prowadzenia testów bezpieczeństwa.

1. Model bezpieczeństwa

DarhimLabs stosuje model obrony warstwowej: zabezpieczenia na edge, aplikacji, bazie danych, storage, warstwie AI, integracjach i procesach operacyjnych. Każda warstwa zakłada, że inna może zawieść, dlatego krytyczne kontrole są powielane. Przykładowo: autoryzacja jest sprawdzana w aplikacji, ale dane workspace’ów są dodatkowo izolowane przez Row-Level Security w PostgreSQL. Mutacje są walidowane po stronie API, a ich wynik trafia do audit logu.

Zasada minimalnych uprawnień dotyczy zarówno użytkowników klientów, jak i zespołu DarhimLabs. Role w workspace’ach ograniczają dostęp do modułów, a działania administracyjne wymagają kont o wyższym poziomie zaufania. Dostęp produkcyjny po stronie DarhimLabs wymaga MFA, jest rejestrowany, okresowo przeglądany i dostępny wyłącznie osobom, które potrzebują go do obsługi incydentu, utrzymania systemu, migracji lub zgłoszenia wsparcia.

Bezpieczeństwo obejmuje również AI. Modele językowe są traktowane jak komponenty wysokiego ryzyka, ponieważ mogą generować treści, wykonywać narzędzia, klasyfikować dane i korzystać z dokumentów RAG. Dlatego DarhimLabs stosuje prompt-injection checks, polityki zatwierdzeń, ograniczenia domen, maskowanie PII, kosztowe limity wykonania i rejestrację tool calls. Wrażliwe akcje, takie jak płatności lub zmiany danych w CRM, mogą wymagać Approval Inbox.

2. Architektura bezpieczeństwa

Architektura DarhimLabs jest podzielona na warstwy. Na brzegu ruch przechodzi przez ochronę DNS, CDN, WAF i mechanizmy anty-DDoS. Warstwa aplikacyjna Next.js odpowiada za routing, sesję, walidację wejścia, CSP, nagłówki bezpieczeństwa i API. Warstwa danych korzysta z Supabase Postgres z RLS, storage, auth i realtime. Warstwa szyfrowania i sekretów obejmuje KMS, vault, rotację kluczy i ograniczenie dostępu do tokenów integracji. Monitoring zbiera logi aplikacyjne, błędy, zdarzenia bezpieczeństwa, health checks i alerty compliance.

Każda warstwa ma odrębne mechanizmy kontroli. Edge blokuje ruch automatyczny, reguły WAF i anomalie. Aplikacja waliduje Zod schema, sprawdza workspace context i rate limit. Baza danych egzekwuje izolację tenantów przez polityki RLS, indeksy i foreign keys. Monitoring pozwala wykrywać regresje, błędy CSP, nadużycia API, nietypowe logowania oraz próby omijania limitów.

Diagram jest uproszczeniem. Wdrożenie produkcyjne obejmuje też kolejki, webhook retries, storage plików, integracje OAuth, API v2, system powiadomień push i workerów asynchronicznych. Dla każdego komponentu stosujemy osobne sekrety, rate limits, walidację wejścia, logowanie błędów i ograniczony zakres danych w payloadach.

3. Dane, szyfrowanie i kontrola dostępu

Dane w tranzycie są chronione przez TLS 1.3. Dane w spoczynku korzystają z zabezpieczeń dostawców infrastruktury oraz dodatkowych mechanizmów aplikacyjnych dla sekretów i tokenów. Klucze API, tokeny OAuth, sekrety webhooków i credentials integracji nie są traktowane jak zwykłe pola tekstowe. Dostęp do nich jest ograniczony, a operacje administracyjne są rejestrowane.

Kontrola dostępu działa na kilku poziomach: sesja użytkownika, rola w workspace, uprawnienia modułowe, autoryzacja endpointu i RLS w bazie danych. Dzięki temu nawet poprawnie uwierzytelniony użytkownik nie powinien odczytać danych innego workspace’u. Dla planów Enterprise dostępne są dodatkowe mechanizmy: SSO/SAML, SCIM, wymuszenie MFA, ograniczenia IP, eksport audit logów i polityki retencji per kategoria danych.

Backupy są tworzone regularnie, a procedury odtworzeniowe są testowane okresowo. Dane usuwane na żądanie nie są aktywnie używane, a backupy rotują zgodnie z harmonogramem retencji. Szczegółowe zasady zwrotu i usuwania danych opisuje DPA, a prawa osób opisuje przewodnik RODO.

4. AI, compliance i izolacja tenantów

DarhimLabs wykorzystuje modele językowe do generowania odpowiedzi, klasyfikacji intencji, tworzenia draftów, RAG, benchmarków jakości i automatyzacji. Dane klientów nie są używane do trenowania modeli DarhimLabs ani modeli dostawców LLM w domyślnej konfiguracji. Wywołania AI są ograniczane do danych potrzebnych dla konkretnej operacji, a payloady mogą być redagowane przez mechanizmy PII masking.

Izolacja tenantów dotyczy także RAG. Dokumenty, chunki, embeddings i cytowania są przypisane do workspace’u oraz źródła. Zapytania testowe i produkcyjne nie powinny mieszać źródeł między klientami. Dodatkowe kontrole obejmują citation coverage, freshness, quality score, alerty regresji i możliwość wyłączenia demo data poza trybem demo.

Moduły AI Agents i Bot Builder mają polityki zatwierdzeń dla działań wysokiego ryzyka. Bot może sugerować akcję, ale wykonanie może wymagać człowieka, zwłaszcza przy płatnościach, zmianach danych CRM, wysyłce SMS, rezerwacjach, escalations lub działaniach w systemach zewnętrznych. Każde wywołanie narzędzia zapisuje parametry, wynik, czas i koszt tam, gdzie jest to potrzebne do audytu.

• Prompt injection checks ograniczają wykonywanie instrukcji pochodzących z niezaufanych źródeł.
• Approval Inbox pozwala zatrzymać akcję AI przed wykonaniem w systemie zewnętrznym.
• Quality Lab wykrywa regresje jakości, halucynacje i spadek citation coverage.
• Model routing może rozdzielać zadania według jakości, kosztu, latency i wymogów compliance.

5. Cykl życia incydentu

Incident response w DarhimLabs ma pięć etapów: detection, triage, containment, eradication, recovery i post-mortem. Detection oznacza wykrycie sygnału przez monitoring, alert bezpieczeństwa, zgłoszenie klienta, raport badacza lub logi dostawcy. Triage określa zakres, severity, potencjalne dane, dotknięte moduły i właściciela incydentu. Containment ogranicza wpływ, na przykład przez wyłączenie klucza, blokadę integracji, rollback albo regułę WAF.

Eradication usuwa przyczynę, czyli poprawia kod, konfigurację, sekret, regułę RLS, zależność lub proces. Recovery przywraca pełne działanie i monitoruje, czy incydent nie wraca. Post-mortem dokumentuje oś czasu, przyczynę źródłową, wpływ na dane, komunikację, działania naprawcze i zadania prewencyjne. Dla poważnych zdarzeń przygotowujemy RCA dostępne dla klientów Enterprise, jeżeli incydent dotyczył ich danych.

Jeśli incydent stanowi naruszenie ochrony danych osobowych, uruchamiamy procedurę RODO: IODO ocenia ryzyko, a DarhimLabs informuje Administratora bez zbędnej zwłoki. Jeżeli DarhimLabs jest Administratorem i naruszenie wymaga zgłoszenia do PUODO, stosujemy termin 72 godzin od stwierdzenia naruszenia zgodnie z art. 33 RODO. Szczegóły są spójne z DPA i RODO.

6. Bug bounty program

DarhimLabs przyjmuje zgłoszenia podatności od badaczy bezpieczeństwa i klientów. Program bug bounty obejmuje publiczne powierzchnie produkcyjne, w szczególności app.darhimlabs.pl, api.darhimlabs.pl, widget klienta, endpointy API v1/v2, mechanizmy auth, izolację tenantów, webhooki, widget embed i panel dashboard. Najwyższy priorytet mają podatności pozwalające na nieautoryzowany dostęp do danych, obejście RLS, eskalację uprawnień, przejęcie konta, wyciek sekretów lub wykonanie akcji w cudzym workspace.

Poza zakresem są środowiska prywatne dev/staging, systemy osób trzecich niezależne od DarhimLabs, ataki DDoS, social engineering, spam, fizyczne ataki na pracowników, masowe skanowanie bez ograniczeń, raporty bez wpływu bezpieczeństwa i znane problemy w bibliotekach, jeżeli nie da się ich wykorzystać w DarhimLabs. Badacz musi działać odpowiedzialnie: nie pobierać masowo danych, nie modyfikować cudzych rekordów, nie utrudniać działania usługi i nie ujawniać podatności publicznie przed zakończeniem procesu.

Nagrody są oceniane według wpływu, jakości raportu, reprodukowalności i zakresu. Orientacyjny zakres to od 100 USD za niski wpływ do 10 000 USD za krytyczne podatności umożliwiające dostęp do danych wielu tenantów. Wypłata wymaga raportu zawierającego kroki reprodukcji, dowód wpływu, minimalny payload i rekomendację naprawy. DarhimLabs stosuje safe harbor dla badań prowadzonych zgodnie z zasadami programu.

7. Testy penetracyjne

DarhimLabs prowadzi zewnętrzne testy penetracyjne co najmniej raz w roku oraz po istotnych zmianach architektury, takich jak nowy model auth, nowe API, publiczny widget, zmiana izolacji tenantów albo wdrożenie funkcji wysokiego ryzyka. Zakres obejmuje OWASP Top 10, OWASP API Security Top 10, kontrolę tenant isolation, SSRF, XSS, CSRF, IDOR, błędy autoryzacji, bezpieczeństwo webhooków i konfigurację nagłówków.

Preferujemy niezależnych dostawców z doświadczeniem w aplikacjach SaaS, API i cloud security, na przykład Securitum lub równoważnych vendorów. Testy obejmują środowisko kontrolowane, przygotowany zakres, konto testowe, ograniczenia czasowe i kanał awaryjny. Wyniki trafiają do rejestru ryzyk, a naprawy są priorytetyzowane według CVSS, wpływu na klientów i możliwości nadużycia.

Executive summary testów penetracyjnych może być udostępnione klientom Enterprise po NDA. Pełny raport techniczny, zawierający szczegóły podatności, payloady i konfigurację systemów, udostępniamy tylko w ograniczonym zakresie, jeżeli jest to uzasadnione audytem klienta i nie zwiększa ryzyka dla innych klientów. Status działań naprawczych jest dokumentowany w systemie zarządzania ryzykiem.

• Testy roczne obejmują aplikację, API, dashboard, auth i widget.
• Testy po dużych zmianach obejmują moduł, którego dotyczy zmiana architektury.
• Krytyczne i wysokie podatności mają priorytet hotfix lub release blokujący.
• Podsumowania audytów są dostępne dla Enterprise po NDA.

8. Vulnerability disclosure

Podatności bezpieczeństwa należy zgłaszać na adres security@darhimlabs.pl. W temacie wpisz „Security disclosure” oraz krótki opis wpływu. W raporcie umieść kroki reprodukcji, adres URL, payload, oczekiwany i rzeczywisty wynik, zrzuty ekranu lub logi, ocenę wpływu oraz informację, czy podatność mogła dotknąć danych osobowych. Nie wysyłaj haseł, pełnych tokenów, danych kart płatniczych ani danych osób trzecich.

Potwierdzamy otrzymanie raportu w ciągu 24 godzin roboczych dla zgłoszeń o potencjalnie wysokim wpływie. Następnie wykonujemy triage, klasyfikację severity i komunikujemy plan naprawy. Oczekujemy odpowiedzialnego ujawnienia przez 90 dni lub do czasu uzgodnionego przez strony. Jeżeli podatność jest krytyczna i aktywnie wykorzystywana, możemy poprosić o dłuższe embargo do czasu ochrony klientów.

DarhimLabs może wnioskować o CVE dla kluczowych podatności w komponentach publicznych lub bibliotekach, jeżeli spełniają kryteria ekosystemu. Dla podatności w samej aplikacji SaaS priorytetem jest szybka naprawa, komunikacja z klientami i ograniczenie ryzyka, a nie publiczny rozgłos. Badacze działający w dobrej wierze są objęci safe harbor i nie będą ścigani za testy zgodne z zasadami programu.

Dodatkowe informacje o zgodności, transferach i przetwarzaniu danych znajdują się w DPA, Polityce prywatnościoraz SLA. Status działania platformy publikujemy na stronie /status.