Bezpieczeństwo

AdActa powstała z myślą o pracy z dokumentami prawnymi — dlatego bezpieczeństwo traktujemy jako fundament produktu, a nie dodatek marketingowy. Poniżej opisujemy środki, które realnie wdrożyliśmy w aplikacji i w procesie rozwoju. Nie wykazujemy certyfikatów ani atestów (np. SOC 2, ISO 27001), których nie posiadamy pomimo, że spełniamy kluczowe dla bezpieczeństwa wymagania definiowane w tych standardach.

Szczegóły przetwarzania danych osobowych znajdziesz w Polityce prywatności, a zasady korzystania z Usługi — w Warunkach użytkowania.

§1. Ochrona konta i dostępu

• Komunikacja z AdActa jest szyfrowana (HTTPS/TLS).
• Logowanie z możliwością użycia passkey (WebAuthn), tam gdzie funkcja jest dostępna w koncie.
• Dwuskładnikowe uwierzytelnianie (2FA) oraz dodatkowe potwierdzenie (step-up) przy wrażliwych operacjach administracyjnych — zgodnie z praktykami ochrony dostępu wymaganymi m.in. przez NIS2 i art. 32 RODO.
• Kontrola dostępu do zasobów w ramach konta oraz izolacja danych użytkowników w modelu aplikacji.

§2. Dokumenty, uploady i dane w produkcie

• Walidacja i utwardzanie ścieżek uploadu plików — ograniczenie ryzyka złośliwych lub nieoczekiwanych treści w materiałach wgrywanych do Usługi.
• Rejestrowanie zdarzeń istotnych dla bezpieczeństwa w centralnym rejestrze (SecurityEvent), z możliwością przeglądu po stronie administracyjnej.
• Gotowość do asynchronicznego eksportu zdarzeń bezpieczeństwa do zewnętrznych systemów monitoringu (most SIEM / log-drain) — gdy konfiguracja na to pozwala.

§3. Utwardzanie aplikacji i odporność na nadużycia

• Ograniczanie częstotliwości żądań (rate limiting) w kluczowych punktach — ochrona przed nadużyciami i atakami typu brute-force / flood.
• Ochrona wrażliwych endpointów statusu i diagnostyki przed nieuprawnionym dostępem.
• Nagłówki bezpieczeństwa przeglądarki, w tym Content Security Policy, wdrażane stopniowo (obecnie z naciskiem na telemetrię i bezpieczne zaostrzanie polityki).
• Regularne skanery bezpieczeństwa w ciągłej integracji (CI) — m.in. analiza zależności i typowe kontrole łańcucha dostaw oprogramowania.

§4. Audyty bezpieczeństwa i zarządzanie lukami

• Przeprowadzamy okresowe (kwartalne) audyty bezpieczeństwa AdActa. Problemy wykryte w danym audycie traktujemy jako zadania do naprawy w kolejnych cyklach rozwoju — z priorytetem wynikającym z ryzyka.
• Przy każdym wydaniu (co tydzień) sprawdzamy rejestry luk bezpieczeństwa (m.in. w procesie CI / przed wdrożeniem), w tym skanowanie zależności i typowe kontrole łańcucha dostaw.
• Każda wykryta luka jest automatycznie kwalifikowana jako priorytet do rozwiązania przed następnym wydaniem AdActa, w uzasadnionych przypadkach wdrożenie poprawki jest realizowane niezwłocznie tj. poza planem kolejnego wydania AdActa.
• W ten sposób staramy się niezwłocznie reagować na informacje bezpieczeństwa publikowane przez m.in. bazę OSV (Open Source Vulnerabilities), Ruby Advisory Database (m.in. poprzez bundler-audit), GitHub Advisory Database oraz komunikaty powiązane z identyfikatorami CVE — a także na ustalenia z wewnętrznych skanerów kodu (np. Brakeman).
• Ze względów bezpieczeństwa zastrzegamy sobie prawo do nieujawniania wszystkich zabezpieczeń jakie wykorzystujemy w AdActa do ochrony prywatności Użytkownika, informacji wrażliwych w dokumentach Użytkownika i ochrony wszelkich komponentów AdActa. W uzasadnionych przypadkach, możemy na prośbę Użytkownika dostarczyć dodatkową dokumentację w tym zakresie.
• Analiza luk bezpieczeństwa stanowi integralną część procesu CI/CD w AdActa, dzięki czemu jest procesem automatycznym i obligatoryjnym dla każdego wydania AdActa.

§5. Sztuczna inteligencja z myślą o poufności

• Domyślne kierowanie wybranych wywołań LLM do zaufanego routingu (w tym preferencja dostawców w UE tam, gdzie przewiduje to konfiguracja produktu).
• Retencja i redakcja payloadów związanych z wywołaniami LLM — ograniczenie przechowywania treści zgodnie z zasadą minimalizacji danych (RODO) oraz dobrymi praktykami governance logów AI.
• Treści ze spraw nie służą do trenowania globalnych modeli zewnętrznych dostawców — szczegóły w Polityce prywatności.

§6. Monitoring, kopie zapasowe i gotowość operacyjna

• Centralny rejestr incydentów i zdarzeń bezpieczeństwa jako podstawa obsługi zdarzeń (NIS2 / DORA / RODO art. 32).
• Procedury backupu i odtwarzania oraz runbook operacyjny bezpieczeństwa — utrzymywane w dokumentacji wewnętrznej i rozwijane wraz z infrastrukturą.
• Parametry ciągłości działania zależą od architektury chmurowej i umów z dostawcami (hosting, baza, poczta, płatności, AI). Publicznie nie obiecujemy konkretnego SLA ani „monitoringu 24/7”, jeśli nie wynika to z osobnej umowy z Państwem.

§7. Zgodność regulacyjna — mechanizmy kontrolne

Budujemy techniczne i organizacyjne mechanizmy kontrolne mapowane na obowiązki z obszaru m.in. NIS2, RODO (w tym art. 32), AI Act oraz DORA (odporność ICT). To nie zastępuje zewnętrznego audytu ani certyfikatu — stanowi natomiast konkretny, weryfikowalny zestaw zabezpieczeń w produkcie i procesie rozwoju.

§8. Zgłaszanie podatności

Jeśli chcą Państwo zgłosić podatność lub incydent bezpieczeństwa, prosimy o wiadomość na contact@adacta.digital z tematem zawierającym „security”. Opisz problem bez exploita na produkcji; rozpatrujemy zgłoszenia w uzasadnionym terminie. Nie prowadzimy publicznego programu bug bounty — nagrody są wyłączone, o ile nie uzgodniono inaczej na piśmie.