# Studio di rafforzamento sicurezza e privacy

**Portale Inclusione — IIS “Antonio Stradivari”**  
**Stato:** anteprima tecnica da sottoporre a DPO, Dirigente Scolastico, DSGA e segreteria  
**Data:** 15 settembre 2026

## 1. Sintesi esecutiva

Il PDP tratta dati personali di minori e informazioni relative alla salute o a
condizioni di fragilità. Non esiste una sicurezza “assoluta”; è però possibile
progettare un sistema nel quale il rischio principale — la circolazione di PDF
in chiaro e di password via email — venga fortemente ridotto.

La soluzione raccomandata per il progetto è:

1. accesso con identità istituzionale federata, verificata lato server;
2. autorizzazione per ruolo **e** per classe/PDP, sempre lato server;
3. codice casuale diverso per ogni PDP e ogni anno, senza usare numero
   progressivo, iniziali, classe o data di nascita;
4. tabella di corrispondenza nome-codice custodita separatamente, cifrata e
   visibile soltanto ai ruoli indispensabili;
5. PDF definitivo composto e congelato **prima** delle firme;
6. firme CIE/CieSign raccolte in sequenza senza rigenerare il PDF;
7. cifratura automatica del PDF già firmato con la chiave pubblica della
   segreteria, prima del deposito;
8. volume/cartella della segreteria cifrato a riposo, con permessi limitati e
   backup separato;
9. deposito istituzionale privato che riceve soltanto il cifrato, con chiave
   privata fuori dal portale e piano di recupero;
10. audit log minimizzato, append-only e senza diagnosi, contenuto del PDP,
   token o chiavi;
11. DPIA, prova pilota con dati fittizi e test di sicurezza prima di qualunque
    attivazione reale.

La pseudonimizzazione è quindi utile, ma non sostituisce la cifratura e non
trasforma il PDP in un dato anonimo: chi possiede la tabella o può ricondurre il
codice all’alunno tratta ancora dati personali.[^1][^2]

Il GDPR indica pseudonimizzazione e cifratura tra le misure da valutare in
funzione del rischio, insieme a riservatezza, integrità, disponibilità e
resilienza dei sistemi.[^11]

## 2. Perimetro e modello di minaccia

### 2.1 Dati e soggetti

Il sistema deve proteggere almeno:

- anagrafica dell’alunno, classe, anno scolastico e tipo di PDP;
- diagnosi o informazione diagnostica riportata dal tutor, senza modificarne il
  contenuto autorizzato;
- misure compensative, dispensative, strumenti e modalità di verifica per
  materia;
- identità e assegnazioni di tutor, docenti, referenti e segreteria;
- PDF definitivo, firme, hash, versioni, eventi e metadati di consegna.

Il modello di minaccia deve considerare sia incidenti sia attacchi:

| Minaccia | Esempio | Controllo prioritario |
|---|---|---|
| Errore umano | PDF inviato al destinatario sbagliato | niente email con allegati; consegna automatica a deposito privato |
| Accesso eccessivo | docente vede PDP di un’altra classe | RBAC + vincolo di classe/PDP verificato dal server |
| IDOR | cambio dell’ID nell’URL per leggere un altro fascicolo | identificativi opachi e autorizzazione a ogni richiesta |
| Account compromesso | credenziali Google rubate | sessioni brevi, revoca, MFA/step-up per ruoli sensibili, alert |
| Deposito compromesso | amministratore o servizio accede al Drive | il deposito riceve solo ciphertext cifrato con chiave pubblica |
| Dispositivo compromesso | PDF firmato resta nella cartella Download | istruzioni di cancellazione, endpoint gestiti, cifratura del dispositivo |
| XLS malevolo | formula, macro, file enorme o parser vulnerabile | allowlist, parsing come valori, limiti, scansione, niente macro |
| Insider | consultazione non necessaria della tabella nomi-codici | separazione, least privilege, audit e doppia autorizzazione |
| Perdita della chiave | segreteria non riesce ad aprire il deposito | backup cifrato, custodia separata, test di ripristino |
| Ransomware | cifrati anche backup e repository | versioning immutabile/offline e chiavi separate |
| Supply chain | CDN o libreria JavaScript alterata | dipendenze fissate e verificate, bundle interno, CSP |

La disponibilità è importante, ma per questi documenti la priorità è:
**riservatezza**, **integrità**, **autenticità** e poi disponibilità. La cifratura
non risolve un account autorizzato ma compromesso, né un PDF alterato prima
della firma: occorrono anche autorizzazioni, firme e audit.

## 3. Pseudonimizzazione: proposta e limiti

### 3.1 Codice casuale annuale

È consigliabile introdurre un `pdp_code` casuale, ad esempio un UUID v4 o un
token casuale equivalente di almeno 128 bit. Il codice deve essere:

- non sequenziale e non prevedibile;
- privo di nome, iniziali, classe, anno, data di nascita o codice fiscale;
- generato dal backend con un generatore casuale crittograficamente sicuro;
- nuovo a ogni annualità o nuova versione logica, salvo una necessità
  documentata di collegamento storico;
- usato in URL, nomi tecnici dei file, log e riferimenti interni.

Un numero progressivo (`00017`) è meglio del nome soltanto contro la lettura
casuale, ma è facilmente enumerabile. Un codice derivato dal nome con SHA-256
non è sufficiente: nomi e classi hanno bassa entropia e possono essere
indovinati con dizionari. Se occorre un token deterministico, va valutato con il
DPO e realizzato con keyed hashing/HMAC e segreto separato; per questo portale è
più semplice e sicuro usare token casuali. La scelta va comunque riesaminata
contro il modello di attacco concreto, come raccomanda ENISA per le tecniche di
pseudonimizzazione.[^12]

### 3.2 Separazione della tabella di corrispondenza

L’import XLS non deve diventare l’archivio definitivo. Il backend deve dividere
il contenuto in due domini logici e, preferibilmente, in due chiavi o due
contenitori distinti:

**Registro operativo**

- `pdp_code`;
- anno e classe necessari all’assegnazione;
- tipo PDP, stato, versione, tutor e docenti in forma di identificativo;
- scadenze, firme e hash.

**Vault di re-identificazione**

- `pdp_code`;
- nome/cognome dell’alunno e identificativo scolastico;
- classe completa, anno e ogni dato necessario alla stampa o alla segreteria.

Il vault deve essere cifrato, non esportabile dai ruoli ordinari, accessibile
solo per operazioni motivate (per esempio generazione della stampa in
segreteria) e protetto da audit. Un export del primo foglio con nomi, tutor,
classi e password non deve essere conservato come file operativo.

Il codice riduce l’esposizione accidentale nei log e nei riferimenti tecnici,
ma diagnosi, testo libero, classe e combinazione di misure possono comunque
rendere riconoscibile l’alunno. L’EDPB chiarisce che i dati pseudonimizzati
restano dati personali quando sono ricollegabili con informazioni aggiuntive e
che proprio tali informazioni devono essere protette e separate.[^1]

### 3.3 Quando si ricostruisce il nome

Il nome completo va reinserito nell’artefatto finale **prima** della firma:

1. il tutor compila le sole aree autorizzate;
2. il sistema produce il PDF nominativo definitivo;
3. il tutor e i docenti verificano la versione congelata;
4. i docenti firmano in sequenza con CIE/CieSign;
5. il sistema verifica le firme, calcola l’hash e cifra il PDF;
6. la segreteria apre il cifrato, verifica hash e firme e procede agli atti.

Non si deve decrittare o sostituire il nome dopo la firma: cambiare il PDF dopo
una firma modifica il documento firmato e può invalidare la verifica. La
pseudonimizzazione va quindi applicata ai dati di lavoro e ai metadati, non con
una sostituzione tardiva del testo già firmato.

## 4. Importazione annuale XLS/XLSX

Lo schema già predisposto nella demo è una buona base, ma in produzione va
trattato come un vero ingresso dati privilegiato.

### 4.1 Struttura

- primo foglio `PDP_IMPORT`: alunno, classe, anno opzionale, tipo PDP, tutor,
  email tutor opzionale;
- secondo foglio `DOCENTI_MATERIE_CLASSI`: docente, materia, classe, ruolo ed
  email opzionali;
- nessuna password, diagnosi, contenuto del PDP o chiave nel file;
- eventuale segreto iniziale generato dal server, mostrato una sola volta solo
  se proprio necessario, e mai scritto nel foglio.

Per gli account locali residuali, le password devono essere casuali, lunghe e
memorizzate solo con hashing adattivo (preferibilmente Argon2id), mai cifrate in
modo reversibile o conservate in chiaro.[^3] La soluzione preferita resta
comunque l’identità istituzionale federata, senza password locali per i docenti.

### 4.2 Controlli obbligatori

Il backend deve:

- accettare solo estensioni e formati necessari; in produzione escludere file
  con macro salvo eccezione motivata;
- verificare firma del formato, MIME reale, dimensione, numero di righe e
  numero massimo di fogli;
- usare una libreria fissata a versione verificata e aggiornata;
- leggere formule come valori e rifiutare formule, link esterni, oggetti,
  macro, fogli nascosti inattesi e contenuti attivi;
- validare intestazioni, codici classe, duplicati, tutor esistenti e coerenza
  docente-materia-classe;
- impedire che una riga del file sovrascriva un PDP senza conferma e audit;
- creare un riepilogo di scarti/anomalie senza riproporre i nomi nei messaggi
  visibili a ruoli non autorizzati;
- usare nomi file generati dal sistema, non quelli forniti dall’utente;
- mantenere il file originale soltanto per il tempo tecnico necessario, poi
  eliminarlo secondo una regola approvata;
- inviare l’evento di import nel registro: attore, timestamp, esito, conteggi,
  hash del file e identificativo del lotto, non il contenuto.

Questi controlli seguono le buone pratiche OWASP: allowlist, validazione del
tipo reale, limiti di dimensione, autorizzazione dell’uploader, deposito fuori
dalla web root e analisi antimalware quando disponibile.[^4]

Il foglio dei referenti è quindi un **input di assegnazione**, non un contenitore
di segreti. Dopo l’import, i referenti devono poter correggere le assegnazioni
docente-materia-classe tramite una schermata autenticata, con storico delle
modifiche e senza modificare retroattivamente le firme già raccolte.

## 5. Identità, sessioni e autorizzazioni

### 5.1 Autenticazione

Per i docenti si può mantenere l’identità Google istituzionale nella prima fase,
oppure integrare un IdP scolastico compatibile con OIDC/SAML. Il token deve
essere verificato dal backend: firma, issuer, audience, scadenza, dominio o
gruppo istituzionale e stato dell’utente. Il solo controllo JavaScript della
demo non è un controllo di sicurezza.

SPID/CIE può essere valutato per una futura autenticazione forte o per ruoli
esterni, ma non è necessario per i genitori se restano in segreteria. Per le
operazioni ad alto impatto — apertura del vault, export nominativo, rotazione o
recupero della chiave, amministrazione dei ruoli — è opportuno un secondo
fattore o un’autenticazione step-up. Le linee guida NIST distinguono inoltre la
resistenza al phishing e alla riproduzione dell’autenticazione: una password o
un codice copiabile non offre la stessa garanzia di un autenticatore
crittografico legato al dominio e alla sessione.[^5]

### 5.2 Autorizzazione per oggetto

Il modello deve essere deny-by-default e combinare:

- **RBAC:** referente, tutor, docente, coordinatore, segreteria, dirigente,
  amministratore tecnico;
- **ABAC:** classe, anno scolastico, PDP assegnato, materia, stato del
  workflow, eventuale sostituzione autorizzata;
- **controllo per campo:** diagnosi e testo generale solo tutor/ruoli definiti;
  matrici di misure solo docente della materia assegnata; firma e invio solo
  tutor dopo tutte le spunte; apertura e stampa solo segreteria/dirigente
  secondo autorizzazione approvata.

Ogni endpoint deve verificare l’autorizzazione sull’oggetto richiesto, non solo
la presenza di una sessione valida. Questo previene l’IDOR e impedisce che un
utente modifichi un PDP cambiando un parametro nell’URL. Le regole OWASP
raccomandano che i controlli di autorizzazione siano applicati lato server o in
un gateway/serverless affidabile, non nel solo client.[^6]

Non inserire nomi, diagnosi, token o PDF in URL, localStorage, sessionStorage,
console, analytics o messaggi di errore. La demo usa dati fittizi e mantiene
alcuni dati nel browser per simulare il flusso; ciò va rimosso o sostituito con
sessioni server-side prima della produzione.

## 6. Cifratura automatica e deposito

### 6.1 Scelta raccomandata a costo licenza zero

Dopo l’ultima firma, il browser o un componente di backend fidato deve creare
un pacchetto di **cifratura ibrida autenticata**:

- il PDF viene cifrato con una chiave simmetrica casuale;
- la chiave del documento viene protetta per la chiave pubblica della
  segreteria;
- il deposito riceve ciphertext, metadati minimi e hash, mai il PDF in chiaro;
- la chiave privata resta fuori dal portale, idealmente su dispositivo dedicato
  della segreteria o in un vault istituzionale;
- la chiave privata ha backup cifrato, custodia separata, inventario, rotazione
  e procedura di revoca/recupero.

`age`/`rage` è un’opzione open source adatta a un flusso a destinatari pubblici:
il mittente usa la chiave pubblica e non deve conoscere né trasmettere una
password. WebCrypto può essere usato come primitiva del browser, ma non si deve
scrivere una crittografia proprietaria: libreria, formato, gestione errori,
pinning della chiave e test devono essere sottoposti a revisione tecnica.

Il ciclo di vita della chiave — generazione, inventario, uso, backup, rotazione,
revoca e recupero — deve essere documentato prima del pilota; la gestione delle
chiavi è una componente del controllo, non un dettaglio da lasciare al singolo
computer della segreteria.[^13]

La chiave pubblica deve essere fissata nel backend/configurazione firmata e
mostrata nella console amministrativa con fingerprint verificabile. Se un
attaccante sostituisce la chiave pubblica, può ricevere i documenti al posto
della segreteria; questo è un rischio distinto dalla cifratura del file.

### 6.2 Cartella già cifrata

Un deposito Nextcloud, Drive Condiviso o SFTP istituzionale può essere usato
come archivio dei pacchetti cifrati. La cifratura server-side del deposito è
comunque utile per backup e dischi, ma non equivale alla cifratura end-to-end:
un amministratore o un servizio che controlla il server può, a seconda della
configurazione, operare sul contenuto in chiaro. La documentazione Nextcloud
segnala anche che la sua E2EE dipende dal client e non offre lo stesso flusso in
ogni interfaccia web.[^7][^8]

Perciò la decisione tecnica consigliata è:

> deposito istituzionale privato + cifratura applicativa prima del deposito.

Il deposito può essere già cifrato “a monte” come seconda barriera, ma il
portale non deve caricare un PDF in chiaro contando sul fatto che la cartella lo
protegga automaticamente. Il docente non compie alcuna operazione manuale:
vede soltanto “consegna protetta completata”.

Il volume della segreteria può usare LUKS su Linux, BitLocker su Windows quando
incluso, FileVault su macOS o Cryptomator per un contenitore
portabile/multipiattaforma. Il servizio di deposito deve avere permessi minimi;
la chiave privata, la chiave di ripristino e i backup devono essere custoditi
separatamente. Il deposito e i backup devono contenere soltanto pacchetti
cifrati. È una scelta a costo di licenza zero se si riutilizza
un’infrastruttura già disponibile, ma richiede comunque approvazione,
manutenzione, test di ripristino e regole di conservazione.

### 6.3 Drive condivisa e delega operativa

Se il deposito è una Drive condivisa, usare una Drive separata e gestita
dall’istituto, con accesso generale disattivato e condivisioni esterne vietate.
L’account tecnico del portale riceve il minimo ruolo necessario per caricare
pacchetti cifrati (di norma Contributor); la segreteria riceve Viewer e
scarica il cifrato per la verifica locale; Manager e amministratore sono
limitati a DSGA, IT e ruoli formalmente autorizzati. La chiave privata non deve
essere memorizzata nella Drive condivisa. Il fatto che un account possa vedere
il nome tecnico o scaricare il pacchetto non gli consente di leggere il PDP
senza la chiave privata.

La configurazione deve essere accompagnata da designazione degli autorizzati,
accordo di trattamento Google Workspace aggiornato, eventuali accordi ex art.
28 GDPR con altri fornitori, DPIA, audit, retention e procedura di incidente.
La delega del Dirigente attribuisce responsabilità operative interne; non
trasforma il fornitore cloud in titolare e non sostituisce la verifica del DPO.

### 6.4 Metadati e file temporanei

Anche il nome del file può rivelare troppo. Nel deposito usare un nome generato
come `pdp_<pdp_code>_<versione>.enc`, con directory non indicizzabile e accesso
solo tramite handler autenticato. Il mapping nome-codice resta nel vault.

Il PDF in chiaro può esistere temporaneamente nel browser del firmatario e nel
componente che genera il documento: non è realistico promettere il contrario.
Occorre minimizzare questa finestra, non usare cache applicative, impedire
download non necessari, cancellare Blob/temporary file quando possibile,
abilitare cifratura completa dei dispositivi gestiti e definire una procedura
per i download richiesti da CieSign.

## 7. Firme CIE/CieSign e integrità del documento

La firma deve essere apposta sul PDF definitivo nominativo e congelato. La
sequenza sicura è:

1. il tutor chiude le modifiche;
2. il portale verifica che ogni docente assegnato abbia spuntato il proprio
   completamento;
3. viene creato un identificativo di versione e un hash del PDF;
4. ogni docente scarica quella versione, firma con CieSign e ricarica il file;
5. il backend verifica che il PDF non contenga modifiche non autorizzate e che
   la firma sia presente/valida secondo il formato approvato;
6. il tutor passa al docente successivo;
7. dopo l’ultima verifica, il sistema cifra il PDF firmato e lo consegna.

Il portale non deve rigenerare o “abbellire” il PDF tra una firma e l’altra.
Eventuali correzioni riaprono una nuova versione e richiedono una nuova raccolta
firme. La qualificazione giuridica della firma CIE (FEA, firma digitale o altro)
e la sua sufficienza per il PDP devono essere validate da DPO, DS e consulente
documentale: la disponibilità gratuita del software non determina da sola il
valore giuridico. Per la parte operativa si deve mantenere il riferimento al
software e alle istruzioni ufficiali CIE, non a una procedura inventata dal
portale.[^14]

### 7.1 Annullamento e ripartenza controllata

Il tutor deve poter correggere un errore senza alterare un PDF già firmato. Sono
quindi previste due azioni distinte:

- **Annulla firme e riapri**: annulla la raccolta in corso, conserva l’evento di
  annullamento nell’audit, azzera firme e dichiarazioni della versione aperta e
  crea una nuova fase di compilazione;
- **Elimina documento e ricomincia**: azione eccezionale, riservata al tutor o
  all’amministratore delegato, con doppia conferma e digitazione di `ELIMINA`.

In produzione il secondo comando non deve cancellare fisicamente e senza traccia
un documento soggetto a conservazione o a obblighi probatori. Deve applicare una
procedura autorizzata di rettifica/scarto, registrare motivo, attore, timestamp e
versione interessata e impedire che una versione firmata venga sovrascritta. La
demo usa il browser locale e, per rendere visibile il comportamento, elimina solo
la bozza fittizia del tipo di piano corrente.

## 8. Audit, monitoraggio e gestione incidenti

Il registro deve essere append-only o comunque protetto da alterazioni, con
backup separato. Ogni evento contiene solo ciò che serve:

- identificativo tecnico dell’attore;
- `pdp_code`, non nome o diagnosi;
- timestamp UTC sincronizzato;
- azione, versione, esito e motivo sintetico;
- hash del file o del pacchetto, non contenuto;
- eventuale identificativo della chiave e del lotto di import.

Registrare almeno login riusciti/falliti, fallimenti di autorizzazione, letture
del vault, import/export, modifiche assegnazioni, congelamento, firme,
cifratura, consegna, apertura della segreteria, rotazione chiavi, backup e
ripristino. Gli errori mostrati all’utente devono essere generici e non
contenere dati sensibili.

Il log non deve diventare un secondo archivio del PDP. OWASP indica come eventi
utili, tra gli altri, autenticazioni, errori di autorizzazione, import/export,
upload, operazioni sulle chiavi e modifiche di configurazione, precisando che i
log devono essere protetti e minimizzati.[^9]

Prima dell’esercizio occorre una procedura per: rilevazione, contenimento,
revoca sessioni, sospensione del deposito, rotazione chiavi, valutazione del
data breach, comunicazioni al DPO e ripristino. Il personale deve sapere che un
PDF scaricato per CieSign non va inoltrato, copiato su cloud personale o
conservato oltre il necessario.

## 9. Confronto di soluzioni a costo di licenza zero

| Soluzione | Privacy | Automazione invisibile | Punti deboli | Valutazione |
|---|---|---|---|---|
| Drive/Nextcloud + PDF cifrato prima del deposito | alta se il deposito vede solo cifrati | alta | richiede backend e gestione chiavi | **raccomandata** |
| Nextcloud E2EE del client | buona, se configurata correttamente | media; dipende dal client e dal flusso | browser/recupero chiavi, complessità operativa | alternativa da pilota |
| age/rage + SFTP/WebDAV | alta | alta lato server | meno interfaccia amministrativa; chiave privata da custodire bene | ottima per il servizio tecnico |
| 7-Zip AES-256 | discreta | bassa | password, errori umani, scambio separato | solo fallback/transizione |
| PDF cifrato allegato a email | bassa | media | destinatari errati, metadati, copie e password | da eliminare |

7-Zip documenta la cifratura AES-256 del formato 7z, ma questo non elimina i
rischi organizzativi di password condivise, copie locali e perdita del segreto;
per questo rimane un fallback e non il flusso principale.[^15]

Il costo “0 €” è riferito alle licenze software, non all’hosting, alla
manutenzione, ai backup, alla gestione delle chiavi, alle verifiche di
sicurezza o alla responsabilità organizzativa. Se l’istituto possiede già
Nextcloud o Workspace for Education, il costo incrementale può essere nullo,
ma il DPO deve approvare ruoli, ubicazione, responsabili/sub-responsabili,
retention e configurazione.

## 10. Rafforzamenti alla demo e limiti attuali

La demo deve restare un ambiente di validazione con dati fittizi. Mostra già
le fasi, il caricamento dell’elenco, il CdC modificabile, il passaggio annuale,
la firma simulata e la consegna cifrata simulata. Prima della produzione vanno
però sostituiti o completati:

- autenticazione solo client-side → verifica server-side dei token e delle
  sessioni;
- localStorage/sessionStorage → database e sessione server-side, senza token o
  PDP in chiaro nel browser oltre il necessario;
- roster importato nel browser → import transazionale sul backend con audit;
- CDN SheetJS → dipendenza bundlata, fissata, verificata e aggiornata;
- “cifratura simulata” → libreria/servizio reale, fingerprint della chiave,
  test di decrittazione e procedura di recupero;
- ruolo visibile nella UI → autorizzazione effettiva a ogni endpoint e campo;
- log demo → audit immutabile senza contenuto sensibile;
- link pubblico del front-end → nessun dato personale e nessuna API con
  permessi incorporati nel codice.

La verifica di sicurezza del web service va impostata su OWASP ASVS, che offre
requisiti verificabili per autenticazione, sessione, controllo accessi,
validazione, logging e protezione dei dati.[^10]

## 11. Piano di attuazione

### Gate 0 — decisione organizzativa

Prima del codice reale, DPO e dirigente devono approvare: titolare e ruoli,
base giuridica, DPIA, registro dei trattamenti, categorie di utenti, tempi di
conservazione, modalità di stampa, firma del DS, firma fisica dei genitori,
protocollo e conservazione.

### Gate 1 — MVP tecnico privato

- backend istituzionale con API `anagrafica-api` e service account minimo;
- OIDC verificato dal server;
- RBAC/ABAC e test IDOR;
- vault separato e codici casuali annuali;
- import XLS validato e senza password;
- generazione PDF, hash, versionamento e audit;
- cifratura con chiave pubblica e deposito privato;
- backup cifrati e prova di ripristino.

### Gate 2 — pilota controllato

Una o due classi, dati reali solo dopo autorizzazione, firme in ambiente di
prova, nessun genitore nel portale, segreteria coinvolta nell’apertura e nella
stampa. Testare anche cambio docente, cambio classe, riapertura, sostituzione,
PDP senza modifiche, firma interrotta, duplicati XLS e perdita di rete.

### Gate 3 — messa in esercizio

Rilasciare solo con checklist firmata, backup verificato, chiavi inventariate,
contatti incident response, formazione breve e revisione periodica annuale.

## 12. Criteri di non-rilascio

Il sistema non deve entrare in esercizio se una delle seguenti risposte è “no”:

- ogni richiesta al backend verifica ruolo, classe, PDP e stato?
- il deposito conserva esclusivamente ciphertext?
- la chiave privata non è nel repository, nel browser o nel Drive?
- esiste un recupero testato della chiave senza creare una copia incontrollata?
- il nome-codice è separato e accessibile solo ai ruoli necessari?
- l’import rifiuta macro, formule non ammesse, duplicati e file anomali?
- il PDF viene congelato prima della prima firma e non viene rigenerato dopo?
- gli audit log escludono nomi, diagnosi, token, password e contenuto?
- sono definiti retention, cancellazione, backup e gestione del data breach?
- DPO e dirigente hanno validato DPIA, firma, deposito e flusso con la
  segreteria?

## Conclusione

La tabella cifrata nome→codice è una misura utile per ridurre la circolazione
dei nominativi, soprattutto in URL, log, assegnazioni e file tecnici. Non va
però inserita nello stesso XLS insieme ai dati operativi e non deve essere
considerata anonimizzazione. La combinazione più equilibrata, gratuita sul
fronte licenze e invisibile ai docenti è: **codice casuale annuale + vault
separato + autorizzazione per oggetto + PDF congelato e firmato + cifratura con
chiave pubblica prima del deposito + backup e audit minimizzati**.

Questa è una proposta tecnica per la validazione del DPO e del dirigente, non
una certificazione di conformità né una decisione giuridica sulla validità
della firma.

## Fonti tecniche

[^1]: [EDPB, Guidelines 01/2025 on Pseudonymisation](https://www.edpb.europa.eu/system/files/2025-01/edpb_guidelines_202501_pseudonymisation_en.pdf).
[^2]: [Garante per la protezione dei dati personali, Pseudonimizzazione](https://www.garanteprivacy.it/temi/pseudonimizzazione).
[^3]: [OWASP, Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html).
[^4]: [OWASP, File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html).
[^5]: [NIST SP 800-63B, Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html).
[^6]: [OWASP, Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html).
[^7]: [Nextcloud, End-to-End Encryption user manual](https://docs.nextcloud.com/server/latest/user_manual/en/files/using_e2ee.html).
[^8]: [Nextcloud, Server-side encryption configuration](https://docs.nextcloud.com/server/stable/admin_manual/configuration_files/encryption_configuration.html).
[^9]: [OWASP, Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html).
[^10]: [OWASP Application Security Verification Standard](https://owasp.org/projects/asvs/).
[^11]: [EUR-Lex, Regolamento (UE) 2016/679, articolo 32](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679).
[^12]: [ENISA, Pseudonymisation techniques and best practices](https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices).
[^13]: [NIST SP 800-57, Recommendation for Key Management](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final).
[^14]: [CIE, Firma elettronica con CieSign](https://www.cartaidentita.interno.gov.it/pa-e-imprese/firma-elettronica-cie-ciesign/).
[^15]: [7-Zip, Technical information](https://www.7-zip.org/7z.html).