Nasze bezpieczeństwo

Wszystkie transmisje danych są szyfrowane TLS (co najmniej TLS 1.2, najlepiej TLS 1.3) między przeglądarką, aplikacją, bazą danych a silnikiem transkrypcji. HSTS jest aktywny na wszystkich publicznych punktach końcowych; żądania HTTP są przekierowywane na HTTPS, a zestawy szyfrów są skonfigurowane zgodnie z profilem "Modern" firmy Mozilla.

Dane są szyfrowane w spoczynku: kopie zapasowe są zabezpieczone AES-256, a woluminy bazy danych są w pełni szyfrowane na poziomie dysku. Hasła są przechowywane wyłącznie z użyciem bcrypt (cost ≥ 10). Klucze API są przechowywane w postaci skrótu i wyświetlane jawnie tylko raz, podczas tworzenia.

Dostęp administracyjny do systemów produkcyjnych odbywa się wyłącznie przez SSH z uwierzytelnianiem kluczem asymetrycznym – logowanie hasłem jest wyłączone. Wszystkie konta pracowników w konsolach platformy i chmury są chronione uwierzytelnianiem dwuskładnikowym opartym na TOTP.

• Kontrola dostępu oparta na rolach (RBAC) zgodnie z zasadą minimalnych uprawnień
• Kwartalny przegląd wszystkich uprawnień dostępu
• Pełny dziennik audytu wszystkich dostępów administracyjnych (kto, kiedy, co, skąd)
• W normalnej eksploatacji pracownicy Aliru nie mają dostępu do odczytu treści transkrypcji
• Po stronie klienta: opcjonalne 2FA TOTP, kody zapasowe, osobny dziennik audytu dla każdego konta

Każda przestrzeń robocza (wewnętrznie "Directory") jest logicznie oddzielona od wszystkich innych za pomocą identyfikatora UUID. Każde zapytanie do bazy danych sprawdza kontekst Directory bieżącego żądania – dostęp do odczytu między najemcami jest technicznie niemożliwy, ponieważ warstwa aplikacji nigdy nie dopuszcza niesprawdzonego zapytania do bazy danych. Kopie zapasowe, dzienniki audytu i pamięci podręczne podlegają tej samej separacji.

• Codzienne zautomatyzowane kopie zapasowe; kroczące przechowywanie przez 14 dni
• Kopie zapasowe szyfrowane (AES-256) i przechowywane na osobnym sprzęcie w drugim centrum danych
• Udokumentowane testy odtwarzania co pół roku
• RTO (Recovery Time Objective): 4 godziny w przypadku całkowitej awarii
• RPO (Recovery Point Objective): maksymalnie 24 godziny utraty danych
• Strona statusu pod deepscript.com/status z sondowaniem co minutę i 90-dniową historią incydentów

Stosujemy udokumentowany proces reagowania na incydenty z jasną ścieżką eskalacji: wykrycie → ograniczenie → analiza → usunięcie → powiadomienie klienta → analiza powdrożeniowa.

• Powiadamianie klientów o naruszeniach danych w ciągu 24 godzin od ich stwierdzenia
• Treść powiadomienia: charakter naruszenia, kategorie i przybliżona liczba dotkniętych danych, podjęte środki, osoba kontaktowa
• Zgłoszenie do organu nadzorczego zgodnie z art. 33 RODO (termin 72 godzin) spoczywa na administratorze – zapewniamy wsparcie wszystkimi niezbędnymi informacjami
• Analiza powdrożeniowa każdego incydentu wraz z analizą przyczyn źródłowych i środkami zapobiegającymi powtórzeniu

Co roku zlecamy niezależnemu zewnętrznemu dostawcy zabezpieczeń przeprowadzenie testu penetracyjnego aplikacji webowej oraz publicznego API REST. Wyniki są priorytetyzowane według wagi ryzyka; krytyczne ustalenia są usuwane w ciągu 14 dni. Podsumowanie dla kierownictwa udostępniamy klientom biznesowym na życzenie, na podstawie umowy o poufności (NDA).

Wewnętrznie co kwartał przeprowadzamy weryfikację skuteczności środków TOM – aktualna wersja jest udokumentowana w załączniku 1 do umowy powierzenia przetwarzania danych (DPA).

• Obowiązkowy przegląd kodu dla wszystkich zmian w kodzie produkcyjnym
• Skanowanie zależności przy każdej kompilacji (pnpm audit) – brak znanych krytycznych podatności CVE w produkcji
• Zautomatyzowane CI ze sprawdzaniem typów, testami jednostkowymi i testami E2E przed każdym wdrożeniem
• Ścisłe oddzielenie środowisk programistycznego, testowego i produkcyjnego – brak rzeczywistych danych w systemach nieprodukcyjnych
• Sekrety w konfiguracjach produkcyjnych za pomocą szyfrowanych zmiennych środowiskowych; brak sekretów w repozytorium kodu

Nasz silnik zamiany mowy na tekst należy do kategorii "ograniczonego ryzyka" rozporządzenia UE w sprawie AI (rozporządzenie (UE) 2024/1689). Nie zachodzi identyfikacja biometryczna, scoring społeczny ani zautomatyzowane podejmowanie decyzji wywołujące skutki prawne. Szczegóły zawiera oświadczenie o zgodności AI (załącznik 4 do DPA).

• Zobowiązanie wszystkich pracowników do zachowania poufności zgodnie z art. 28 ust. 3 lit. b RODO
• Obowiązkowe coroczne szkolenie z ochrony danych i bezpieczeństwa informacji
• Szkolenie wdrożeniowe dla każdego nowego pracownika z dostępem do systemów produkcyjnych
• Proces offboardingu z natychmiastowym cofnięciem wszystkich dostępów po zakończeniu zatrudnienia