# Plugin di cifratura del portale — proposta tecnica Documento di valutazione per DPO, Dirigente, DSGA e responsabili tecnici. Stato: anteprima, nessuna chiave reale e nessun documento reale. ## Risposta breve Sì, il portale può cifrare il PDF prima di inviarlo alla Drive condivisa e la segreteria può usare uno strumento compatibile per aprirlo. La chiave privata non deve mai essere presente nel portale, nel codice JavaScript, nella Drive o nel file XLS. Il portale deve conoscere soltanto la chiave pubblica della segreteria. Il modello corretto è: 1. il tutor chiude il PEI/PDP e i docenti completano le firme CIE; 2. il portale verifica il PDF definitivo e l’hash; 3. il modulo crittografico crea un pacchetto cifrato usando la chiave pubblica della segreteria; 4. il portale carica nella Drive condivisa soltanto il pacchetto cifrato; 5. la segreteria scarica il pacchetto, lo apre sulla postazione istituzionale, verifica hash e firme, stampa e procede con firme tradizionali, protocollo e conservazione; 6. la cartella Drive conserva il pacchetto cifrato; il PDF in chiaro non viene archiviato online dal portale. Docenti e tutor non devono vedere chiavi, password, cartelle o procedure di archivio. ## “Stesso plugin con la chiave”: come va inteso Non è necessario, e non è consigliabile, installare un’estensione nel browser dei docenti. L’estensione aggiungerebbe permessi, aggiornamenti e una superficie di attacco non necessaria. La soluzione più controllabile è: - nel portale: una libreria OpenPGP.js o equivalente, incorporata nel bundle dell’istituto e verificata, che usa solo la chiave pubblica; - nella segreteria: GnuPG/Kleopatra oppure un piccolo decryptor locale istituzionale che legge il formato OpenPGP e usa la chiave privata conservata sul PC; - nella Drive: solo file cifrati, con nome tecnico casuale. Se si vuole davvero lo stesso componente software sui due lati, si può realizzare un’applicazione locale della segreteria che usa OpenPGP.js anche per la decifratura. Deve però essere distribuita come pacchetto locale verificato, con chiave privata fuori dal browser pubblico. La parte web non deve mai ricevere la chiave privata. ## Confronto | Soluzione | Portale | Segreteria | Vantaggi | Rischi/limiti | |---|---|---|---|---| | OpenPGP.js + GnuPG/Kleopatra | libreria JavaScript | GnuPG/Kleopatra | formato interoperabile, gratuito, documentato, adatto a browser e desktop | gestione chiavi più articolata; va definito il formato e verificata la firma | | OpenPGP.js su entrambi i lati | stessa libreria e formato | decryptor locale basato sulla stessa libreria | esperienza uniforme e nessun componente commerciale | richiede sviluppo, pacchettizzazione, aggiornamenti e test locali | | age/rage | modulo JavaScript compatibile age | age o rage | formato moderno, chiavi semplici, niente password condivise | nel browser serve una libreria compatibile mantenuta e verificata; meno immediato per operatori non tecnici | | WebCrypto con formato proprietario | API del browser | decryptor sviluppato ad hoc | primitive disponibili nel browser | formato e gestione chiavi diventano responsabilità del progetto; da evitare senza revisione specialistica | | Estensione browser di cifratura | plugin con permessi sul sito/file | stesso plugin | automazione possibile | installazione, aggiornamenti, permessi e supply-chain aumentano il rischio | | Cryptomator/Drive cifrata | non cifra il file prima dell’invio da sola | app desktop | utile per cifrare il volume a riposo | non sostituisce la cifratura applicativa; gestione automatica meno trasparente | ### Raccomandazione Per una prima implementazione validabile: OpenPGP.js incorporato localmente, chiave pubblica della segreteria fissata nel backend/configurazione firmata, pacchetto OpenPGP cifrato e GnuPG/Kleopatra sulla postazione della segreteria. Per una seconda fase si può sostituire la console GnuPG con un decryptor locale con interfaccia semplice, mantenendo lo stesso formato. La scelta age è tecnicamente interessante e più minimale, ma va adottata solo quando è disponibile una libreria browser verificata, mantenuta e compatibile con il decryptor scelto. Il formato age definisce cifratura ibrida con una chiave di file unica per documento e destinatari pubblici; il punto delicato per questo progetto non è la crittografia di base, ma il modulo browser, la verifica del destinatario e il ciclo di vita della chiave. ## Chiavi e permessi ### Generazione La segreteria genera una coppia di chiavi su una postazione istituzionale protetta. La chiave pubblica viene registrata nel portale insieme al fingerprint. Il DPO/DSGA conserva una scheda di controllo con fingerprint, data, responsabile, algoritmo/formato e stato. ### Uso - il portale cifra soltanto con la chiave pubblica; - il sistema della Drive ha permesso di upload, ma non può decifrare; - la segreteria usa la chiave privata solo per aprire un pacchetto; - la chiave privata è protetta da passphrase e da cifratura completa del PC; - la chiave privata non viene sincronizzata in Drive, email, repository o backup cloud ordinario; - il backup della chiave privata è cifrato e custodito separatamente, con test periodico di ripristino; - una rotazione non deve rendere illeggibili i vecchi pacchetti: le vecchie chiavi restano custodite secondo la retention approvata. ### Drive condivisa La Drive condivisa deve essere separata dal resto dei documenti dell’istituto, senza link pubblici e senza condivisione esterna. L’identità tecnica del portale può avere Contributor per caricare pacchetti; la segreteria può avere Viewer per scaricarli; Manager resta a DSGA/IT o ad altro ruolo formalmente autorizzato. Il fatto che la segreteria scarichi il pacchetto non significa che Drive legga il PDP: senza chiave privata il contenuto resta cifrato. ## Controlli contro la compromissione del portale La cifratura nel browser protegge il deposito, ma non risolve da sola il rischio di un portale alterato: una pagina web malevola potrebbe leggere il PDF prima della cifratura. Per ridurre questo rischio: - bundle crittografico mantenuto nel repository istituzionale, non caricato da CDN non controllate; - dipendenza fissata a versione e hash verificati; - Content Security Policy restrittiva; - niente analytics, script pubblicitari o terze parti nella pagina operativa; - release approvate e pubblicate con hash; - controllo del fingerprint della chiave pubblica; - audit delle modifiche al codice e test di regressione; - eventualmente, nella versione più riservata, cifratura effettuata da un helper locale istituzionale invece che da codice web remoto. L’helper locale dà una garanzia più forte contro la manomissione del sito, ma richiede installazione e aggiornamento del programma sul PC della segreteria. Per i docenti rimane invisibile perché la loro attività è solo firma CIE e conferma del flusso. ## Verifica prima del rilascio - [ ] chiave pubblica e fingerprint approvati e pubblicati nel backend; - [ ] test di cifratura con PDF fittizio; - [ ] test di decifratura sulla postazione della segreteria; - [ ] modifica di un byte del pacchetto: la verifica deve fallire; - [ ] verifica che il pacchetto non contenga il PDF in chiaro; - [ ] verifica che la chiave privata non sia presente in rete, repository o browser; - [ ] prova di backup e ripristino della chiave; - [ ] test di rotazione senza perdita dei vecchi documenti; - [ ] test di permessi Drive con account docente, tutor, segreteria, DSGA e identità tecnica; - [ ] DPIA, designazioni, DPA/CDPA, retention e procedura di incidente approvati da DPO e Dirigente. ## Riferimenti tecnici - OpenPGP.js: https://github.com/openpgpjs/openpgpjs - OpenPGP.js: https://openpgpjs.org/ - GnuPG: https://gnupg.org/documentation/ - Specifica age: https://c2sp.org/age/ - Permessi Drive condivisi: https://support.google.com/drive/answer/7286514 Tutti questi strumenti sono gratuiti o open source; il costo zero riguarda le licenze. Restano costi organizzativi e tecnici per hosting, manutenzione, backup, gestione chiavi, test e responsabilità del trattamento.