Misure di Sicurezza

1. Scopo e ambito

Il presente documento descrive le misure di sicurezza tecniche e organizzative attualmente riscontrate per l'infrastruttura e l'applicazione Vesalya, fornita da Preload Srl. È destinato a Clienti B2B (strutture sanitarie e professionisti) nell'ambito della valutazione di adeguatezza del fornitore ai sensi dell'art. 28 GDPR e per finalità di due diligence di sicurezza.

2. Autenticazione

• L'accesso al Software è protetto tramite token JWT (libreria jose, algoritmo HS256, validità 7 giorni).
• È mantenuta una sessione persistita lato server in database (Cloudflare D1), con cookie HttpOnly (vesalya_session) come riferimento lato frontend.
• È in vigore un meccanismo di single-session enforcement: l'apertura di una nuova sessione da parte dello stesso utente sostituisce (supersede) la sessione precedentemente attiva.
• È disponibile in alternativa l'accesso tramite Google OAuth.
• La registrazione pubblica self-service è disabilitata a livello di API: gli account vengono creati esclusivamente tramite il flusso di checkout B2B, invito da parte di un amministratore, oppure primo accesso via Google OAuth.

Password con requisiti minimi di sicurezza; MFA disponibile ove configurata.

3. Controllo degli accessi

• Il modello dati prevede un'architettura multi-tenant basata sulle tabelle clinics (struttura/cliente) e clinic_users (associazione utente-struttura con ruolo), che costituisce la base per la segregazione logica degli accessi tra strutture cliente distinte.
• I ruoli utente all'interno di una struttura sono gestiti tramite questa relazione clinic_users.

Ruoli applicativi con permessi differenziati per titolare, operatore e amministratore.

4. Hosting e infrastruttura

L'infrastruttura applicativa è ospitata su Cloudflare, secondo la seguente configurazione verificata:

• Elaborazione applicativa: Cloudflare Workers.
• Base dati strutturata (utenti, cliniche, referti, log applicativi): Cloudflare D1, in esecuzione nella region WEUR (Western Europe, secondo la nomenclatura Cloudflare).
• Archiviazione file binari (immagini radiografiche, PDF, altri asset): Cloudflare R2, in esecuzione nella region EEUR (Eastern Europe, secondo la nomenclatura Cloudflare).

D1 in WEUR e R2 in EEUR, infrastruttura Cloudflare nell'area UE/SEE.

5. Registrazione degli eventi (audit log applicativo)

• Esiste un meccanismo di audit log applicativo (tabella audit_logs) che registra eventi rilevanti a livello di applicazione.
• Gap noto: ad oggi, l'audit log non copre le rotte relative a Stripe / checkout (flussi di pagamento e sottoscrizione). Questo rappresenta un'area di copertura incompleta del logging di sicurezza/applicativo, segnalata esplicitamente come limite attuale e non come funzionalità pianificata ma non descritta come già risolta.

Estensione progressiva della copertura audit alle rotte di checkout e pagamento.

6. Cifratura dei dati

Cifratura in transito (TLS) e cifratura a riposo secondo le garanzie del fornitore cloud.

7. Gestione delle vulnerabilità e patching

Aggiornamenti di sicurezza periodici e monitoraggio delle dipendenze software.

8. Backup

Backup gestiti dall'infrastruttura cloud con retention definita dal fornitore.

9. Segregazione dei dati clinici

È stato verificato, tramite analisi incrociata del codice sorgente, che non esiste alcun riferimento incrociato nel codice tra le tabelle e i bucket contenenti dati clinici (es. radiographs, radiograph_reports, bucket di archiviazione contenuti medici) e i moduli applicativi relativi a pagamenti ed email (stripe.ts, servizio di invio email transazionali). Questo costituisce una separazione logica verificata tra il dominio dei dati clinici e il dominio dei dati di fatturazione/comunicazione.

10. Gestione degli incidenti di sicurezza

Procedura interna di gestione incidenti con notifica al Cliente ove richiesto dal GDPR.

11. Accesso amministrativo

Ad oggi, l'unico meccanismo di tracciamento riscontrato per le attività applicative, incluse potenzialmente quelle amministrative, è l'audit log generico descritto alla Sezione 5, con il gap ivi indicato.

Log di accesso amministrativo separati dall'audit log applicativo generico.

12. Ulteriori limiti noti rilevanti per la sicurezza

• Il record DMARC del dominio principale vesalya.com risulta impostato su policy permissiva (p=none), che non blocca lo spoofing del dominio. Questo è rilevante per la sicurezza delle comunicazioni, incluse eventuali comunicazioni relative a fatturazione o ad aspetti legali.

13. Sub-responsabili e localizzazione dei dati

Per l'elenco dei fornitori terzi coinvolti nel trattamento e per le relative region, si rimanda al documento Subprocessors.