Leggere insieme agli altri documenti del Centro Legale e all’ordine sottoscritto. In caso di versioni bilingui, la versione italiana prevale per i rapporti regolati dalla legge italiana, salvo diverso accordo.
1. Modello di sicurezza
ISOPILOT adotta un modello security-by-design e risk-based. Le misure effettive dipendono dalla configurazione, dall’hosting e dal Piano. La sicurezza è condivisa: UESE protegge piattaforma e componenti sotto il proprio controllo; il Cliente protegge dispositivi, reti, utenti, dati, configurazioni e procedure interne.
2. Identità, autenticazione e autorizzazione
Sono previsti ruoli separati, password hashate, recupero controllato, 2FA TOTP tramite QR code, sessioni protette e revoca utenti. Il principio del minimo privilegio deve essere applicato dal Cliente. Gli accessi amministrativi e impersonati sono tracciati.
3. Segregazione multi-tenant e storage
Record e file sono associati a company_id e project_id, con controlli backend per impedire accessi trasversali. Gli allegati sono archiviati in percorsi privati e serviti solo dopo autorizzazione. Validazioni controllano nome, estensione, MIME, dimensione e hash; sistemi antimalware possono dipendere dall’infrastruttura.
4. Cifratura e segreti
Le connessioni pubbliche devono utilizzare HTTPS/TLS. Chiavi API, password SMTP e segreti sono conservati lato server e, ove previsto, cifrati con chiave applicativa. Non vengono mostrati nuovamente in chiaro. La gestione sicura di APP_KEY, backup e variabili ambiente è responsabilità dell’amministratore dell’hosting.
5. Audit log e monitoraggio
La piattaforma registra eventi quali accessi, creazioni, modifiche, approvazioni, impostazioni, impersonazioni e operazioni rilevanti. I log devono essere protetti da accessi impropri e conservati per periodo proporzionato. Il monitoraggio dell’infrastruttura e gli alert dipendono dal servizio di hosting adottato.
6. Backup, ripristino e continuità
La strategia deve includere backup cifrati o protetti, rotazione, copie separate e test di ripristino. Frequenza, RPO e RTO non sono impliciti e devono essere definiti nell’offerta/SLA. Il Cliente deve mantenere copie dei documenti pubblicati e procedure di continuità per attività critiche.
7. Sviluppo, patch e vulnerabilità
Il ciclo di manutenzione comprende controllo sintattico, aggiornamenti dipendenze, validazione input, gestione errori e revisione di configurazioni. Prima della produzione sono raccomandati hardening, vulnerability assessment e penetration test indipendente. Le segnalazioni responsabili possono essere inviate a UESE con dettagli tecnici e senza sfruttamento ulteriore.
8. Gestione degli incidenti
Gli incidenti sono classificati, contenuti, analizzati e documentati. UESE coordina comunicazioni a clienti e autorità secondo ruolo e legge. Il Cliente deve fornire contatti reperibili, preservare log locali e collaborare senza divulgazioni premature.
9. Obblighi del Cliente
- abilitare 2FA e password uniche;
- gestire tempestivamente ingressi, cambi ruolo e cessazioni;
- limitare dati caricati e verificare autorizzazioni;
- proteggere endpoint, browser, reti e email;
- non condividere chiavi o credenziali;
- esportare e conservare copie dei documenti critici;
- segnalare anomalie senza ritardo.
10. Limiti e verifica indipendente
La presente pagina descrive un quadro di controllo e non costituisce certificazione di sicurezza né impegno SLA. Le misure devono essere verificate nell’ambiente di produzione. Certificazioni, audit o report indipendenti sono dichiarati solo se effettivamente disponibili.
11. Evidenze pubbliche di affidabilità
Il gestore può rendere disponibili certificazioni, attestazioni e relativi documenti nel Trust Center. La presenza di tali evidenze integra, ma non sostituisce, la valutazione del Cliente sul servizio, sul perimetro contrattuale e sulle misure applicabili alla propria configurazione.