Misure tecniche e organizzative di sicurezza

Allegato B all'Accordo sul trattamento dei dati — art. 32 Reg. (UE) 2016/679 · Versione 1.1 · 05/10/2026

Principio: questo documento descrive misure realmente in essere. Le voci segnalate come (rischio accettato) o (in roadmap) sono dichiarate come tali, senza promesse non veritiere.

1. Cifratura e protezione in transito e a riposo

In transito: HTTPS/TLS su tutto il traffico; HSTS (max-age 1 anno, includeSubDomains, preload); upgrade-insecure-requests.
A riposo: database (Cloud Firestore) e archivio file cifrati a riposo dal provider (Google) per impostazione predefinita.
Segreti: chiavi e segreti di integrazione gestiti lato server, mai esposti nel client né leggibili tra clienti diversi.
Chiavi del box dei varchi, del ponte RT e dell'API dei documenti: generate dal Servizio, mostrate una sola volta e conservate solo come impronta SHA-256; il club può renderle inutilizzabili dalle Impostazioni (revoca della chiave API; nuova chiave per box e ponte, che invalida subito la precedente).

2. Riservatezza — controllo degli accessi e isolamento dei tenant

Autenticazione: Firebase Authentication per il personale; portali pubblici con sessione anonima a sola scrittura controllata; app socio e portale istruttori con credenziali proprie verificate dal server (password solo come hash) e sessione firmata.
App socio: un solo dispositivo autorizzato per socio (la sessione è legata al dispositivo); attivazione con password temporanea valida 72 ore, mostrata una sola volta all'operatore; finché non viene cambiata il server rifiuta ogni operazione diversa dal cambio password, così il personale non conosce la password definitiva.
Autorizzazione (RBAC): ruoli applicativi (supremo, direzionale, segreteria, manutentore, istruttore) con permessi differenziati; le operazioni sensibili (decisione sulle deroghe di sconto, revoca dei link ai documenti, chiavi) sono riservate alla direzione; le aperture manuali dei varchi sono consentite a direzione e reception e sempre registrate.
Isolamento multi-tenant: ogni cliente opera su uno spazio dati separato; l'accesso è consentito solo agli utenti attivi del medesimo cliente, imposto dalle Security Rules lato server e verificato da test di isolamento automatici.
Amministrazione di piattaforma: legata a un claim crittografico sull'identità, non a un indirizzo e-mail.
Minimizzazione nei registri: nei passaggi ai varchi si salva l'identificativo della persona, non il nome in chiaro; il portale istruttori riceve solo nome e cognome dei prenotati.

3. Integrità e protezione da abusi

App Check (reCAPTCHA v3) attivo in produzione; nell'app socio è caricato solo nella schermata di accesso.
Funzioni server: le operazioni sensibili verificano l'identità del chiamante (token Firebase + ruolo, o sessione firmata) oppure App Check per i flussi pubblici; non si fidano del solo "Origin".
Scritture pubbliche (form, disdette, prenotazioni, prove) via funzioni server con validazione del cliente, whitelist dei campi, limiti di frequenza e scrittura con account di servizio.
Registri scritti solo dal server: registro di autocontrollo della piscina (con catena di impronte SHA-256 degli eventi di ogni giorno e ora del server), prese visione dell'informativa collaboratori (testo integrale, impronta, ora del server, IP, browser), riepiloghi degli invii, passaggi ai varchi.
Varchi: QR personali monouso firmati, rigenerati ogni 40 secondi, verificati e "consumati" dal server (un QR già usato non apre); il box del club conserva un registro tecnico di 2 giorni con i codici solo in forma ridotta.
Documenti fiscali: la pagina personale del documento è raggiungibile solo con link firmato (HMAC) legato a club e documento, valido 24 mesi e revocabile dalla direzione; i documenti si emettono solo a pagamento acquisito; dopo l'emissione il piano rate è bloccato anche nelle Security Rules (l'importo non si modifica, le rate non si riducono, il blocco non si rimuove, il piano non si cancella).
Webhook verso i sistemi del club: firmati con HMAC-SHA256; controlli anti-SSRF sull'indirizzo (solo HTTPS, niente credenziali nell'URL, niente indirizzi IP o nomi di rete interni), nessun reindirizzamento seguito.
Deroghe sugli sconti: lo sconto proposto dal desk resta in sospeso e la decisione (approvazione o rifiuto, con eventuale rata integrativa) è eseguita dal server su richiesta della direzione; le regole impediscono al client di modificarla.
Documenti riservati (es. preventivi con dati di minori) accessibili con token firmato (HMAC) con scadenza, non con ID indovinabili.
Intestazioni di sicurezza: CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Permitted-Cross-Domain-Policies.

4. Disponibilità, resilienza e ripristino

Backup: Firestore con Point-in-Time Recovery (7 giorni) + backup pianificati giornalieri (ritenzione 7 gg) e settimanali (ritenzione 14 settimane).
Ripristino: procedura di restore su database isolato, con validazione prima del ripristino in produzione.
Localizzazione dati: database in UE (multi-regione europea eur3).
Continuità rilasci: feature flag per cliente e rollback immediato senza nuovo deploy.
Monitoraggio: processi notturni con segnale di vita controllato; allarmi tecnici interni con soli identificativi.

5. Minimizzazione e limitazione della conservazione

IA: dati inviati ai modelli limitati al necessario; per il coach alimentare senza nome né contatti; nessun addestramento sui dati inviati via API; tetti d'uso lato server.
Conservazione: tempi definiti nella Politica di conservazione (doc. 10), con cancellazione notturna per categoria; i tetti promessi agli interessati (coach alimentare 24 mesi, prove nuoto 180 giorni) si applicano sempre; contatori anti-abuso cancellati dopo 24 ore; registro errori cancellato dopo 90 giorni.
Registro degli errori tecnici: registra tipo, messaggio, punto del codice e pagina senza parametri; il testo è ripulito automaticamente da e-mail, numeri di telefono e altri numeri lunghi, codici fiscali, token e chiavi.
Uscita dalle app: all'uscita l'app socio cancella sessione, copia dei dati e palinsesto memorizzati; il portale istruttori cancella sessione e copia offline.

6. Tracciabilità e accountability

Registro attività (audit log) per cliente: azioni rilevanti con autore, momento e dettaglio.
Aperture manuali dei varchi registrate con operatore e motivo; invii dei documenti registrati sul documento (canale, data, esito).
Registro dei rilasci e delle accettazioni dei documenti contrattuali (identità, ora del server, impronta dei documenti).
Test automatici prima dei rilasci su soldi (rate, incassi, emissione), regole di sicurezza e isolamento, accessi ai varchi e documenti fiscali.
Controllo notturno del codice: un agente di IA analizza ogni notte il codice sorgente e i risultati dei test, senza credenziali né accesso ai dati; le correzioni sono proposte solo in bozza e applicate soltanto dopo revisione umana.

7. Misure organizzative

Accesso ai sistemi limitato al personale autorizzato, con obbligo di riservatezza.
Credenziali amministrative e segreti separati dal codice.
Separazione degli ambienti di sviluppo e produzione; nuove funzioni provate prima su un cliente dimostrativo.
Accesso remoto al box e al ponte presso il club solo per installazione, aggiornamento e assistenza (DPA art. 4-bis).
Procedura di gestione delle violazioni (doc. 09) e di assistenza al Titolare.
Selezione dei sub-responsabili con garanzie adeguate (doc. 05).

8. Limiti noti / rischi accettati (trasparenza)

CSP con unsafe-inline in script-src: necessario per gli script inline delle pagine attuali. unsafe-eval è stato rimosso (stile compilato in fase di build). Mitigato da App Check, escaping dell'output e altre direttive restrittive. (rischio accettato, documentato)
Staging condiviso con l'infrastruttura di produzione: le prove avvengono su un cliente dimostrativo separato; un ambiente di staging isolato è in roadmap. (in roadmap)
Apparati presso il club (box, ponte RT, registratore, rete): la sicurezza fisica e di rete è a cura del club (DPA art. 4-bis).
Trasferimenti extra-UE verso alcuni fornitori USA con SCC/DPF (doc. 05). (garanzie in essere; da mantenere aggiornate)

9. Revisione

Le misure sono riviste periodicamente e in occasione di cambiamenti significativi dell'architettura o a seguito di incidenti. Ultima revisione: 05/10/2026.

Privacy · Cookie · Condizioni · DPA · Sub-responsabili · Misure di sicurezza · Conservazione · SLA · Intelligenza artificiale · ↩ Torna indietro