Il passaporto è una promessa.
Ecco come la manteniamo.

Le funzioni server dell'applicazione girano a Francoforte (fra1), accanto al datastore principale, un cluster Postgres gestito in AWS eu-central-1 (Francoforte). Lì sono conservati i contenuti dei clienti, i record dei tenant e gli audit trail. Le funzioni AI inviano il testo su cui lavorano alla Gemini API di Google, che lo elabora negli Stati Uniti.

Le risorse statiche e le pagine pubbliche dei passaporti sono servite da una rete edge globale, dal nodo più vicino al lettore; solo le risorse pubbliche e non sensibili (loghi, testi di marketing, HTML delle pagine del resolver) vi vengono memorizzate nella cache. Per policy, le risposte API autenticate non passano dalla cache.

I domini personalizzati dei tenant (ad esempio dpp.brand.com) sono serviti dalla stessa piattaforma. Non manteniamo alcuno standby che sposterebbe i dati conservati fuori dall'UE.

Tutte le connessioni al resolver, all'amministrazione del tenant e all'API terminano su TLS 1.2 o superiore. HSTS è imposto con un max-age di due anni e preload attivo. Le pagine sono servite con X-Frame-Options SAMEORIGIN e Referrer-Policy strict-origin-when-cross-origin; una Content-Security-Policy è attiva in modalità report-only.

A riposo, i volumi di archiviazione Postgres sono cifrati con AES-256 dal fornitore. Le credenziali delle integrazioni (Akeneo, Centra, Shopify, inriver, Delogue, token REST personalizzati) risiedono in un vault cifrato per tenant; la chiave di cifratura è conservata fuori dal database. Le chiavi API LLM fornite dai tenant (BYOK) sono cifrate allo stesso modo.

L'accesso avviene tramite magic link via email e Google. Le sessioni sono conservate in cookie Secure, SameSite=Lax, limitati al nostro dominio.

Ogni tabella che contiene contenuti dei clienti è protetta dalla Row-Level Security del database. Un utente di un tenant non può mai leggere dati di un altro tenant: il vincolo è applicato a livello di database, non solo nel codice applicativo. L'accesso del personale è delimitato separatamente tramite una tabella staff_users e richiede un motivo operativo registrato nell'audit log.

I ruoli all'interno di un tenant sono admin, editor e viewer: un admin gestisce i membri e tutto ciò che sta sotto, un editor lavora su passaporti e dati ma non può cambiare chi ha accesso, un viewer legge. Accanto a questi ci sono i ruoli rivolti alle autorità per il passaporto pubblico (economic-operator, distributor, refurbisher, recycler, market-surveillance, competent-authority). L'impersonificazione da parte del personale è possibile solo tramite un flusso firmato e sottoposto ad audit.

I segreti dell'applicazione risiedono esclusivamente in variabili d'ambiente cifrate della piattaforma. Nessun segreto viene inserito nel controllo di versione, nessun segreto viene registrato nei log, e le chiavi API incollate in una chat sono considerate compromesse e ruotate immediatamente.

Quando un tenant si integra con un sistema esterno, la credenziale è conservata per tenant nel vault cifrato descritto sopra. Rotazioni, scadenze e modifiche dell'ambito sono mostrate nel pannello Integrazioni; gli accessi non riusciti sono registrati nell'audit trail del tenant.

Il database principale è sottoposto a backup continuo con ripristino point-in-time su una finestra mobile. Gli snapshot giornalieri cifrati sono conservati secondo un calendario adeguato al piano del tenant; la conservazione a lungo termine è disponibile su richiesta per le categorie regolamentate.

Per i clienti che richiedono un host di backup indipendente (secondo la EN 18221 §4.5), gestiamo un percorso di scrittura parallela verso un livello di archiviazione separato, così il passaporto resta risolvibile anche se l'applicazione principale non è disponibile. La specifica del fornitore dell'host di backup è disponibile per i potenziali clienti sotto NDA.

Lo stato dell'infrastruttura in tempo reale (uptime, incidenti e manutenzioni programmate) è pubblicato su status.dppagent.com. Gli incidenti passati riportano che cosa è successo, che cosa abbiamo cambiato e che cosa abbiamo rilevato la volta successiva.

Accettiamo segnalazioni di divulgazione responsabile all'indirizzo security@dppagent.com. Le segnalazioni vengono valutate entro un giorno lavorativo e risolte secondo un calendario basato sulla gravità. I ricercatori in buona fede sono tutelati da azioni legali, citati su richiesta e non devono firmare un NDA per inviare una segnalazione.

Per gli incidenti confermati con impatto sui clienti seguiamo un runbook documentato di risposta agli incidenti: prima il contenimento, poi la notifica al titolare del tenant entro la finestra definita dal contratto, un resoconto post-incidente pubblicato sulla pagina di stato e la correzione della causa principale seguita fino alla chiusura.

Il runtime di DPP Agent e ciò che produce sono costruiti secondo la serie di norme CEN/CENELEC JTC 24 (EN 18216 accesso, EN 18219 identificativi, EN 18221 ciclo di vita e continuità, EN 18223 struttura e interoperabilità), il profilo di riferimento CIRPASS-2 e i requisiti a livello di campo dell'ESPR (regolamento 2024/1781) e del regolamento UE sulle batterie (2023/1542). I dati dei passaporti sono conformi a GS1 Digital Link con gli application identifier per GTIN, lotto, CPV e numero di serie.

In qualità di titolare / responsabile del trattamento che opera dall'UE, siamo soggetti al GDPR e offriamo su richiesta un accordo standard sul trattamento dei dati (DPA). I flussi dei dati dei clienti sono documentati nel nostro elenco dei sub-responsabili, che viene modificato con 30 giorni di preavviso in caso di cambiamenti sostanziali.

Attualmente non disponiamo di una certificazione SOC 2 o ISO 27001. Quando otterremo una certificazione pubblicheremo qui il rapporto e l'ambito dell'audit. I clienti enterprise possono richiedere sotto NDA il pacchetto aggiornato di revisione della sicurezza, la sintesi del penetration test e la checklist dei controlli interni.