Paszport to obietnica.
Tak jej dotrzymujemy.

Funkcje serwerowe aplikacji działają we Frankfurcie (fra1), obok głównego magazynu danych — zarządzanego klastra Postgres w AWS eu-central-1 (Frankfurt). Tam przechowywane są treści klientów, rekordy tenantów i ścieżki audytu. Funkcje AI przesyłają tekst, na którym pracują, do Gemini API firmy Google, które przetwarza go w USA.

Zasoby statyczne i publiczne strony paszportów są serwowane z globalnej sieci brzegowej, z lokalizacji najbliższej czytelnikowi; buforowane są tam wyłącznie publiczne, niewrażliwe zasoby (logo, teksty marketingowe, HTML stron resolvera). Uwierzytelnione odpowiedzi API z zasady omijają pamięć podręczną.

Własne domeny tenantów (na przykład dpp.brand.com) są obsługiwane przez tę samą platformę. Nie utrzymujemy żadnej rezerwy, która przeniosłaby przechowywane dane poza UE.

Wszystkie połączenia z resolverem, panelem tenanta i API są zakańczane na TLS 1.2 lub wyższym. HSTS jest wymuszany z max-age wynoszącym dwa lata i ustawionym preload. Strony są serwowane z X-Frame-Options SAMEORIGIN i Referrer-Policy strict-origin-when-cross-origin; Content-Security-Policy działa w trybie report-only.

W spoczynku woluminy pamięci Postgres są szyfrowane przez dostawcę algorytmem AES-256. Dane uwierzytelniające integracji (Akeneo, Centra, Shopify, inriver, Delogue, własne tokeny REST) znajdują się w zaszyfrowanym sejfie osobnym dla każdego tenanta; klucz szyfrowania jest przechowywany poza bazą danych. Klucze API LLM dostarczane przez tenantów (BYOK) są szyfrowane w ten sam sposób.

Logowanie obsługuje magic link przez e-mail i Google. Sesje są przechowywane w plikach cookie Secure, SameSite=Lax ograniczonych do naszej domeny.

Każda tabela z treściami klientów jest chroniona przez Row-Level Security bazy danych. Użytkownik tenanta nigdy nie może odczytać danych należących do innego tenanta — ograniczenie jest egzekwowane w warstwie bazy danych, a nie tylko w kodzie aplikacji. Dostęp pracowników jest osobno ograniczany przez tabelę staff_users i wymaga podania powodu operacyjnego zapisywanego w dzienniku audytu.

Role w tenancie to admin, editor i viewer — admin zarządza członkami i wszystkim poniżej, editor pracuje nad paszportami i danymi, ale nie może zmieniać, kto ma dostęp, viewer czyta. Obok nich istnieją role dla publicznego paszportu przeznaczone dla organów i innych podmiotów (economic-operator, distributor, refurbisher, recycler, market-surveillance, competent-authority). Działanie w imieniu użytkownika przez pracowników jest możliwe wyłącznie w podpisanym, audytowanym procesie.

Sekrety aplikacji znajdują się wyłącznie w zaszyfrowanych zmiennych środowiskowych platformy. Żaden sekret nie trafia do systemu kontroli wersji, żaden nie jest logowany, a klucze API wklejone do czatu są traktowane jako skompromitowane i natychmiast rotowane.

Gdy tenant integruje się z systemem zewnętrznym, dane uwierzytelniające są przechowywane osobno dla każdego tenanta w opisanym wyżej zaszyfrowanym sejfie. Rotacje, wygaśnięcia i zmiany zakresu są widoczne w panelu Integracje; błędy dostępu są zapisywane w ścieżce audytu tenanta.

Główna baza danych jest stale archiwizowana z możliwością odtworzenia do dowolnego punktu w czasie w ruchomym oknie. Codzienne zaszyfrowane migawki są przechowywane według harmonogramu odpowiedniego do planu tenanta; długoterminowe przechowywanie jest dostępne na życzenie dla kategorii regulowanych.

Dla klientów, którzy wymagają niezależnego hosta kopii zapasowej (zgodnie z EN 18221 §4.5), prowadzimy równoległy zapis do odseparowanej warstwy przechowywania, dzięki czemu paszport pozostaje dostępny nawet wtedy, gdy główna aplikacja jest niedostępna. Specyfikacja dostawcy hosta kopii zapasowej jest dostępna dla potencjalnych klientów w ramach NDA.

Bieżący stan infrastruktury — dostępność, incydenty i planowane prace serwisowe — jest publikowany pod adresem status.dppagent.com. Opisy minionych incydentów zawierają to, co się stało, co zmieniliśmy i co wykryliśmy za następnym razem.

Przyjmujemy zgłoszenia w ramach odpowiedzialnego ujawniania pod adresem security@dppagent.com. Zgłoszenia są wstępnie oceniane w ciągu jednego dnia roboczego i usuwane według harmonogramu zależnego od wagi. Badacze działający w dobrej wierze są chronieni przed działaniami prawnymi, na życzenie wymieniani z nazwiska i nie muszą podpisywać NDA, aby dokonać zgłoszenia.

W przypadku potwierdzonych incydentów wpływających na klientów stosujemy udokumentowaną procedurę reagowania: najpierw ograniczenie skutków, powiadomienie właściciela tenanta w terminie określonym w umowie, raport po incydencie opublikowany na stronie statusu oraz usunięcie przyczyny źródłowej śledzone aż do zamknięcia.

Runtime DPP Agent i jego wyniki są zbudowane zgodnie z pakietem norm CEN/CENELEC JTC 24 (EN 18216 dostęp, EN 18219 identyfikatory, EN 18221 cykl życia i ciągłość, EN 18223 struktura i interoperacyjność), profilem referencyjnym CIRPASS-2 oraz wymogami na poziomie pól z ESPR (rozporządzenie 2024/1781) i rozporządzenia UE w sprawie baterii (2023/1542). Dane paszportu są zgodne z GS1 Digital Link z identyfikatorami zastosowań GTIN, partii, CPV i numeru seryjnego.

Jako administrator / podmiot przetwarzający działający w UE podlegamy RODO i na życzenie oferujemy standardową umowę powierzenia przetwarzania danych. Przepływy danych klientów są udokumentowane na naszej liście podmiotów podprzetwarzających, która w przypadku istotnych zmian jest aktualizowana z 30-dniowym wyprzedzeniem.

Obecnie nie posiadamy certyfikacji SOC 2 ani ISO 27001. Gdy uzyskamy certyfikację, opublikujemy tutaj raport i zakres audytu. Klienci Enterprise mogą poprosić o aktualny pakiet przeglądu bezpieczeństwa, podsumowanie testów penetracyjnych i listę kontroli wewnętrznych w ramach NDA.