Dati sensibili nel registro scolastico

Questa lezione appartiene al Modulo 18 — Sicurezza di base.

Cos’è un dato sensibile nel Registro

Un dato sensibile è un’informazione che, se esposta o conservata nel posto sbagliato, può causare un problema reale: identificare una persona, rivelare un comportamento, o violare la privacy di uno studente.

Nel Registro del laboratorio scolastico, i dati sensibili non sono ovvi come in un’app bancaria. Ma esistono.

Dati che richiedono attenzione:

Dato	Dove compare	Rischio
Nome dello studente	prestito.assegnatario	Associato a un guasto o a uno storico prestiti
Storico prestiti	archivioPrestiti	Rivela abitudini o frequenza d’uso di uno studente
Motivo del guasto	segnalazioneGuasto.descrizione	Può contenere testo libero con nomi o accuse
ID studente	comando.studenteId	Se prevedibile, può essere enumerato

Dati che non sono sensibili nel contesto scolastico:

• Nome e categoria dello strumento (sono dati pubblici del laboratorio)
• Stato dello strumento (disponibile, guasto, in manutenzione)
• Numero di prestiti aperti in totale

Perché il Registro scolastico deve prestare attenzione

Il Registro gestisce dati di studenti minorenni. In Italia, il trattamento di dati personali di minori è regolato dal GDPR (Regolamento UE 2016/679) e dal Codice della Privacy italiano. Anche un progetto scolastico, se conserva nomi associati a comportamenti, rientra in questo contesto.

Tre principi pratici da applicare subito:

1. Minimizzazione: salva solo ciò che serve. Se non hai bisogno del cognome completo, non salvarlo.
2. Separazione: i dati personali non devono mescolarsi con i log tecnici.
3. Accesso minimo: non tutti devono poter leggere tutti i dati.

Cosa non fare — esempi concreti

Problema 1: loggare dati personali in console

// ❌ MAI fare così
console.log("Prestito aperto per:", comando.assegnatario, "strumento:", strumento.nome);

// ✅ Logga solo l'ID e l'evento
console.log("Prestito aperto. strumentoId:", strumento.id);

In un’aula, la console del browser è visibile. Loggare nomi espone dati personali a chiunque sia seduto vicino.

Problema 2: salvare il testo libero del guasto senza controllo

// ❌ Testo libero non validato può contenere nomi o accuse
const segnalazione = {
  strumentoId: comando.strumentoId,
  descrizione: comando.descrizione  // "Rotto da Mario Rossi"
};

// ✅ Valida lunghezza e caratteri; avvisa che il campo è tecnico
function validaDescrizioneGuasto(testo) {
  const pulito = testo.trim();
  if (pulito.length < 5) throw new Error("DESCRIZIONE_TROPPO_CORTA");
  if (pulito.length > 200) throw new Error("DESCRIZIONE_TROPPO_LUNGA");
  return pulito;
}

Problema 3: esporre l’intera lista prestiti con dati personali

// ❌ Espone tutti i dati di tutti gli studenti
function tuttiIPrestiti() {
  return archivioPrestiti.leggiTutti();
}

// ✅ Filtra solo ciò che serve per lo scopo
function prestitiAperti() {
  return archivioPrestiti.leggiTutti()
    .filter(p => !p.chiusoIl)
    .map(p => ({ strumentoId: p.strumentoId, apertoIl: p.apertoIl }));
    // l'assegnatario non serve per mostrare "quali strumenti sono in prestito"
}

Dove stanno le responsabilità

Presentation   →  non mostrare mai dati personali non necessari all'UI
Application    →  validare e ridurre i dati prima di passarli al dominio
Domain         →  non deve conoscere nomi, solo ID e stati
Infrastructure →  non loggare dati personali; salvare solo ciò che serve

La regola più importante: il dominio non deve mai contenere nomi. Il dominio lavora con ID, stati e regole. I nomi degli studenti appartengono al livello di Presentation (dove vengono mostrati) e Infrastructure (dove vengono salvati), non al dominio.

Procedura guidata

1. Apri il progetto e cerca tutte le occorrenze di assegnatario, nomePersona, descrizione, console.log.
2. Per ogni occorrenza: questo dato deve davvero stare qui? Deve essere salvato? Deve essere mostrato?
3. Identifica se stai loggando dati personali in console — rimuovi o anonimizza.
4. Verifica che il motivo del guasto venga validato in lunghezza.
5. Controlla che la lista prestiti non esponga più dati del necessario.
6. Scrivi una nota nel README: “Dati personali gestiti: assegnatario (salvato in localStorage, non loggato).”

Attività in classe

Lavora su una scheda breve:

## Dati sensibili nel registro scolastico

Contesto:

File o documenti coinvolti:

Dati personali trovati nel progetto:

Dove vengono salvati:

Cosa ho cambiato o verificato:

Limite rimasto (es. "il motivo del guasto non è ancora validato"):

Se lavori in gruppo, una persona fa l’analisi e una persona verifica che le modifiche non abbiano rotto il comportamento esistente.

Spiegazione guidata per studiare

Il Registro del laboratorio scolastico tratta dati personali di studenti. Anche se il progetto è scolastico, i principi del GDPR si applicano: minimizzare i dati raccolti, non mescolarli con i log tecnici, e non esporli inutilmente.

Per dati sensibili nel registro scolastico, il punto centrale è questo: il dato personale (nome dello studente, storico prestiti, motivo del guasto) non deve mai attraversare più livelli del sistema del necessario. Il dominio non ha bisogno di sapere chi è lo studente — ha bisogno solo di sapere che un prestito è aperto.

Il rischio tipico è loggare console.log("Prestito aperto per:", nomeStudente) perché “è solo un progetto scolastico”. Questo espone dati visibili a tutti in aula e crea abitudini sbagliate. Per evitarlo, applica la regola: logga eventi, non persone.

Passo per passo nel progetto

1. Cerca console.log in tutto il progetto. Rimuovi quelli che contengono nomi o dati personali.
2. Cerca assegnatario o nomePersona. Verifica che non vengano passati al dominio.
3. Aggiungi validazione al campo motivo del guasto (lunghezza minima e massima).
4. Verifica che la funzione che lista i prestiti non esponga dati non necessari.
5. Scrivi una riga nel README che descriva quali dati personali vengono salvati e dove.

Esempio da leggere lentamente

Questo esempio serve a ragionare, non a incollare codice senza capire:

// Domain: conosce solo ID e stati — mai nomi
function apriPrestito(strumentoId, apertoIl) {
  return { strumentoId, apertoIl, chiusoIl: null };
}

// Application: aggiunge l'assegnatario al momento del salvataggio
function registraPrestito({ archivioStrumenti, archivioPrestiti }, comando) {
  const strumento = archivioStrumenti.trovaPerId(comando.strumentoId);
  if (!strumento) throw new Error("STRUMENTO_NON_TROVATO");
  if (strumento.stato !== "disponibile") throw new Error("STRUMENTO_NON_DISPONIBILE");

  const prestito = apriPrestito(strumento.id, new Date().toISOString());
  // L'assegnatario viene aggiunto solo al momento del salvataggio
  archivioPrestiti.salva({ ...prestito, assegnatario: comando.assegnatario });
  archivioStrumenti.salva({ ...strumento, stato: "in_prestito" });

  // Non logghiamo il nome — solo l'evento
  console.log("Prestito registrato. strumentoId:", strumento.id);
}

Nota: apriPrestito nel dominio non conosce l’assegnatario. Il caso d’uso lo aggiunge solo quando salva. Questo è il confine corretto.

Prova di comprensione

Prima di chiudere la lezione, rispondi per iscritto a queste domande:

• Quali dati del Registro consideri sensibili? Perché?
• Il dominio del tuo progetto conosce nomi di studenti? Dovrebbe?
• Dove vengono loggati dati nel tuo progetto? C’è qualcosa da rimuovere?
• Qual è la differenza tra “dato necessario” e “dato comodo”?

Errori da evitare

• loggare nomi di studenti in console.log — è visibile a tutta l’aula;
• passare l’assegnatario al dominio — il dominio non deve conoscerlo;
• non validare il campo “motivo del guasto” — testo libero non controllato è un rischio;
• salvare più dati di quelli necessari perché “tanto è un progetto scolastico”;
• esporre l’intera lista prestiti con nomi quando serve solo sapere quali strumenti sono occupati.

Prodotto da consegnare

Può essere:

• una modifica che rimuove console.log con dati personali;
• una funzione validaDescrizioneGuasto aggiunta al dominio;
• una versione di prestitiAperti che non espone l’assegnatario inutilmente;
• una riga nel README che descrive i dati personali trattati.

Deve essere chiaro dove si vede il lavoro e quale problema risolve.

Checklist di chiusura

Prima di chiudere la lezione, controlla:

• Nessun console.log contiene nomi di studenti o dati personali
• Il dominio non conosce nomi — lavora solo con ID e stati
• Il campo “motivo del guasto” ha validazione di lunghezza
• La lista prestiti non espone dati personali non necessari
• Il README descrive quali dati personali vengono salvati e dove

Domande per la revisione

• Quale dato personale hai trovato nel progetto che non ti aspettavi?
• Dove stava? Era nel livello giusto?
• Che cosa hai cambiato o deciso di non cambiare, e perché?
• Come verificheresti che un futuro sviluppatore non reintroduca il problema?

Risultato atteso

Alla fine lo studente deve saper dire:

Ho trovato questi dati personali nel Registro: [elenco].
Il dato [X] stava nel livello [Y], che non è corretto perché [motivo].
Ho modificato [Z] per ridurre l'esposizione.
Il dominio ora non conosce nomi di studenti.

Se questa spiegazione non è possibile, la lezione non è ancora davvero conclusa.