Lezione 10: Sicurezza di dati e modelli nel CDE (ISO 19650)

Introduzione e obiettivi

Nella lezione precedente abbiamo parlato dei fondamenti di cybersecurity: la triade CIA (Confidenzialità, Integrità, Disponibilità), le minacce più comuni e l'igiene digitale personale. Oggi facciamo un passo concreto e calato sul nostro mestiere: portiamo quei principi dentro l'ambiente in cui un tecnico della Green & Digital Construction vive ogni giorno, cioè il Common Data Environment (CDE), il contenitore condiviso di tutti i dati e i modelli di progetto.

Ti faccio subito un esempio. Immagina il cantiere che ci accompagna per tutto il modulo: la riqualificazione energetica di un edificio scolastico a Livorno. In un CDE moderno (ACCA usBIM, Autodesk Construction Cloud / Docs, Trimble Connect, Bentley ProjectWise) trovi il modello federato in formato IFC, gli abachi delle quantità, le tavole esecutive, il computo metrico, i verbali di cantiere, le foto dei sopralluoghi, i certificati dei materiali e perfino le letture dei sensori di consumo. Tutto in un solo posto. Comodissimo. Ma se "tutto è in un solo posto", anche il rischio si concentra in un solo posto. Chi entra dove non dovrebbe, può vedere, modificare o cancellare il lavoro di mesi.

In questa lezione impareremo a difendere quel cuore di dati. Vedremo:

• Che cos'è un CDE e perché concentra valore e rischio.
• La ISO 19650 e in particolare la parte 5 (security-minded): come si pensa la sicurezza fin dalla progettazione informativa.
• Il modello RBAC (Role-Based Access Control): assegnare permessi ai ruoli, non alle persone.
• Integrità e versioning dei modelli: chi modifica cosa, validazione e tracciabilità.
• La regola del backup 3-2-1, la cifratura e cosa significa davvero "sicurezza del cloud".

Il Common Data Environment e perché concentra il rischio

Il Common Data Environment (CDE), in italiano Ambiente di Condivisione Dati (ACDat), è la fonte unica di informazione condivisa per un progetto: l'unico posto da cui raccogliere, gestire e diffondere tutti i contenitori informativi (modelli, documenti, dati) attraverso un processo gestito. Non è semplicemente "una cartella su un disco di rete": è un processo + una tecnologia che governa chi mette dentro cosa, in che stato, con quali permessi e con quale storia delle versioni.

I quattro stati del CDE secondo ISO 19650

Il modello concettuale della ISO 19650 organizza il CDE in quattro stati attraverso cui i contenitori informativi transitano nel loro ciclo di vita:

Questo schema non è burocrazia: è già sicurezza. Separare il WIP dallo Shared evita che un disegno ancora "in bozza" venga preso per buono in cantiere; lo stato Published garantisce che ciò che si costruisce sia stato approvato; l'Archive è la nostra assicurazione contro la perdita di dati e contro le dispute legali.

Perché il CDE concentra il rischio

Tornando al nostro edificio scolastico: in un progetto tradizionale "a documenti sparsi" un attacco o un errore colpisce un file alla volta. In un CDE, invece, abbiamo un punto unico che riunisce:

• Valore economico: mesi di modellazione, computi, progettazione esecutiva. Rifare un modello federato può costare decine di migliaia di euro.
• Continuità operativa: se il CDE è offline o compromesso, il cantiere si ferma perché non ha accesso alle tavole ufficiali.
• Dati sensibili: dati personali dei lavoratori (presenze, formazione, sorveglianza sanitaria — GDPR), planimetrie di edifici critici (scuola, ospedale), informazioni su impianti di sicurezza.
• Accessi di terze parti: imprese, fornitori, consulenti, enti. Più "porte" ci sono, più grande è la superficie d'attacco.

Il CDE è quindi un classico esempio di concentrazione: massima efficienza operativa, ma anche massima esposizione. La buona notizia è che, proprio perché è un sistema gestito, possiamo proteggerlo in modo molto più sistematico di un mucchio di cartelle condivise. La sicurezza del CDE poggia su tre pilastri che vedremo nelle prossime sezioni: permessi (chi può fare cosa), integrità + versioning (la storia di chi ha modificato cosa) e backup + cifratura (poter ripristinare e mantenere riservato).

ISO 19650 e l'approccio security-minded (19650-5)

La ISO 19650 è la famiglia di norme internazionali che definisce la gestione informativa con il BIM lungo tutto il ciclo di vita di un'opera. In Italia si affianca alla UNI 11337. È la norma che dà un linguaggio comune a progettisti, imprese e committenti: stabilisce ruoli, processi e il modo di organizzare le informazioni. Le parti principali che incontrerai sono:

Cosa significa "security-minded"

La ISO 19650-5 introduce un concetto semplice ma potente: la sicurezza non è un'aggiunta finale, è una mentalità che attraversa l'intero processo informativo, fin dall'inizio. Tradotto in pratica per il nostro cantiere significa chiedersi, prima ancora di aprire il software:

• Quali informazioni sono sensibili? La pianta di una scuola con le vie di fuga, la posizione degli impianti antincendio, i dati dei minori che la frequentano: non tutto va trattato allo stesso modo.
• Chi ha davvero bisogno di vederle? Principio del need to know: si dà accesso solo a chi serve, solo a ciò che serve.
• Cosa succederebbe se queste informazioni finissero nelle mani sbagliate, o se venissero perse o alterate?

Sensitivity, triage e Built Asset Security Manager

La 19650-5 propone un processo di triage di sensibilità: si valuta se il progetto (o parti di esso) richiede misure di sicurezza particolari. Per la maggior parte degli edifici "ordinari" il triage porterà a misure standard; per asset sensibili (infrastrutture critiche, edifici governativi, sanità, sicurezza) servono misure rafforzate. La norma prevede figure dedicate, come il Built Asset Security Manager (BASM), e documenti come il Built Asset Security Information Requirements e il Built Asset Security Management Plan.

Non devi imparare a memoria gli acronimi. Ciò che conta, come tecnico, è il riflesso mentale: prima di condividere un dato o un modello, chiediti sempre "questo è sensibile? chi deve vederlo?". È esattamente lo stesso ragionamento che applicheremo costruendo la matrice dei permessi.

Accessi e permessi: il modello RBAC

Veniamo al cuore pratico della sicurezza del CDE: i permessi. Il principio guida è quello del privilegio minimo (least privilege): ogni persona deve poter fare solo ciò che serve al suo ruolo, niente di più. Il modello standard per realizzarlo si chiama RBAC — Role-Based Access Control, controllo degli accessi basato sui ruoli.

L'idea chiave: permessi al ruolo, non alla persona

L'errore classico è assegnare i permessi una persona alla volta ("dai accesso a Mario, a Giulia, a quella ditta..."). È ingestibile e pericoloso: quando Mario cambia mansione o l'impresa finisce il lavoro, nessuno si ricorda di togliere gli accessi. Con RBAC invece:

1. Si definiscono i ruoli del progetto (BIM Manager, BIM Coordinator, Progettista, Impresa, Committente, Consulente esterno...).
2. A ogni ruolo si associa un set di permessi su cartelle e azioni.
3. Le persone vengono semplicemente assegnate a un ruolo.

Quando arriva un nuovo progettista, lo metti nel ruolo "Progettista" ed eredita tutti i permessi giusti in un clic. Quando l'impresa finisce, disattivi le persone di quel ruolo. Pulito, tracciabile, scalabile.

Le azioni tipiche di un CDE

I permessi in un CDE come usBIM o Autodesk Docs si esprimono tipicamente come combinazioni di queste azioni su una cartella o un contenitore:

• Visualizzare (View): aprire e consultare, senza modificare.
• Scaricare (Download): portarsi il file in locale (occhio: chi scarica, "esce" dal CDE col dato).
• Caricare / Modificare (Upload/Edit): aggiungere nuove versioni, modificare contenuti.
• Eliminare (Delete): rimuovere file o cartelle. Permesso da concedere con grande parsimonia.
• Approvare / Cambiare stato (Approve): autorizzare il passaggio da Shared a Published.
• Gestire i permessi (Manage): amministrare il progetto e gli accessi altrui. Solo a pochissimi.

Esempio di matrice ruoli × permessi

Vediamo una matrice di esempio sul nostro cantiere scolastico. Le colonne sono le cartelle/stati del CDE, le righe sono i ruoli. La leggenda: V = Visualizza, D = Download, M = Modifica/Carica, X = Elimina, A = Approva, — = nessun accesso.

Leggiamola insieme. Il progettista impianti può fare tutto sul proprio WIP, ma sul WIP architettonico può solo guardare: non deve poter toccare il modello di un'altra disciplina. L'impresa vede i dati condivisi per coordinarsi, ma lavora soprattutto sul Published (ciò che è ufficiale per il cantiere) e non ha accesso ai WIP: non c'è motivo che veda bozze non verificate. Il committente vede solo ciò che è pubblicato e l'archivio. Il consulente esterno ha l'accesso più ristretto e solo per la durata del suo incarico. Nessuno, a parte il BIM Manager, può approvare il passaggio a Published.

Integrità dei modelli e versioning

I permessi dicono chi può fare cosa. L'integrità risponde a una domanda diversa e altrettanto importante: "il modello che ho davanti è davvero quello giusto, completo e non alterato?". Su un progetto edile l'integrità è denaro e sicurezza: se in cantiere si costruisce su una tavola sbagliata o manomessa, i danni sono concreti (rifacimenti, contestazioni, rischi per le persone).

I rischi per l'integrità

• Sovrascrittura accidentale: qualcuno carica una versione vecchia sopra quella aggiornata. È l'incidente più comune.
• Modifica non autorizzata: qualcuno cambia quote, materiali o quantità senza che il responsabile lo sappia.
• Manomissione dolosa: in casi rari, alterazione volontaria di un computo o di una tavola (frode, sabotaggio).
• Corruzione del file: trasferimenti interrotti, file IFC danneggiati, conversioni che perdono dati.
• Disallineamento tra modelli: l'impianto è aggiornato ma la struttura no, e nessuno se ne accorge.

Il versioning: la "macchina del tempo" del CDE

Il versioning (controllo di versione) è la difesa principale per l'integrità: ogni volta che un contenitore viene caricato, il CDE conserva la versione precedente e registra chi ha fatto la modifica, quando e (idealmente) perché. Si crea così una storia tracciabile e si può sempre tornare indietro.

Le revisioni in ambito ISO 19650 seguono una codifica per stato e versione. Un esempio di evoluzione di una tavola architettonica:

Contenitore: SCU-BNT-XX-ZZ-M3-A-0001  (modello architettonico)

Storia delle versioni nel CDE
-----------------------------------------------------------------
Rev.   Stato        Autore         Data         Nota
S1     WIP          M. Rossi       12/01/2026   bozza piano terra
S2     WIP          M. Rossi       18/01/2026   aggiunte aperture
S3     Shared       M. Rossi       22/01/2026   condiviso x coordinamento
S4     Shared       M. Rossi       05/02/2026   recepiti clash impianti
P1     Published    BIM Manager    10/02/2026   APPROVATA per cantiere
P2     Published    BIM Manager    14/03/2026   variante locale aula 3
-----------------------------------------------------------------

Prefisso stato:  S = Work in progress/Shared (sospeso)
                 P = Published (pubblicato/approvato)
Ogni versione resta recuperabile: nulla viene mai perso davvero.

Grazie a questa storia, se qualcuno il 15 marzo si accorge che la variante "aula 3" era sbagliata, il BIM Manager può ripristinare la P1 in pochi secondi e capire esattamente chi ha caricato cosa. Senza versioning, quella stessa situazione significherebbe ricostruire a mano il lavoro, sperando di ricordarsi com'era.

Validazione e controllo: difese complementari

Oltre al versioning, l'integrità si protegge con:

• Validazione automatica all'ingresso: il CDE controlla naming, formato, completezza del contenitore prima di accettarlo.
• Workflow di approvazione: il passaggio a Published richiede l'azione di un ruolo autorizzato (vedi RBAC). Nessuno pubblica "di nascosto".
• Audit log (registro attività): il CDE registra ogni accesso e ogni azione. È la nostra "telecamera di sorveglianza" sui dati.
• Checksum / hash: un'impronta digitale del file. Se anche un solo bit cambia, l'hash cambia: ci accorgiamo subito di una corruzione o manomissione.

Un esempio numerico utile: lo stesso file IFC calcolato due volte produce sempre lo stesso hash; se cambia anche una virgola, l'hash è completamente diverso.

modello_v1.ifc   SHA-256 = 9f2a...e71c   (originale firmato dal coordinatore)
modello_v1.ifc   SHA-256 = 9f2a...e71c   (ricalcolato a distanza di mesi: IDENTICO → integro)
modello_v1.ifc   SHA-256 = c40b...18ad   (1 byte modificato → DIVERSO → allarme!)

Backup 3-2-1, cifratura e cloud

Arriviamo alla terza gamba dello sgabello: la disponibilità. Per quanto bene tu configuri permessi e versioning, devi sempre poter ripristinare i dati se succede il peggio: ransomware, cancellazione, guasto hardware, errore del provider, alluvione (a Livorno l'abbiamo vista). La risposta standard, semplice da ricordare, è la regola 3-2-1.

La regola 3-2-1

Una versione moderna è la 3-2-1-1-0: aggiunge 1 copia offline/immutabile (non raggiungibile dal ransomware, perché scollegata o non sovrascrivibile) e 0 errori verificati (i backup vanno testati ripristinandoli, non solo creati). Quest'ultimo punto è cruciale e spesso trascurato: un backup che non hai mai provato a ripristinare non è un backup, è una speranza.

Cifratura: at rest e in transit

La cifratura rende i dati illeggibili a chi non ha la chiave. Per il CDE e i backup ci interessano due momenti:

• Cifratura a riposo (at rest): i file sono cifrati quando sono archiviati sul disco/cloud. Se qualcuno ruba il disco o accede allo storage, vede solo dati illeggibili. Standard tipico: AES-256.
• Cifratura in transito (in transit): i dati sono cifrati mentre viaggiano in rete tra il tuo PC e il CDE. È ciò che fa il protocollo HTTPS / TLS (il lucchetto del browser). Senza, chi intercetta la rete Wi-Fi di cantiere potrebbe leggere quello che carichi.

Un esempio concreto: scarichi una copia del modello su una chiavetta USB per portarla in cantiere e la perdi. Se la chiavetta era cifrata (es. BitLocker, VeraCrypt), chi la trova vede solo numeri casuali. Se non lo era, ha in mano le planimetrie complete della scuola.

"Sicurezza del cloud": modello di responsabilità condivisa

Quando usiamo un CDE cloud (Autodesk, ACCA, Trimble...) molti pensano "ci pensa il fornitore". Vero solo a metà. Vale il modello di responsabilità condivisa:

• Il fornitore protegge l'infrastruttura: datacenter, server, cifratura dello storage, ridondanza, disponibilità del servizio.
• Tu sei responsabile di: password e MFA, gestione dei permessi (la matrice RBAC!), chi inviti nel progetto, cosa scarichi e dove lo metti, backup aggiuntivi dei tuoi dati critici.

In altre parole: il cloud serio è molto sicuro a livello di infrastruttura, ma la maggior parte delle violazioni reali nasce da configurazioni sbagliate e credenziali deboli — che sono esattamente la nostra parte di responsabilità. La sicurezza del CDE, quindi, dipende soprattutto da noi.

Laboratorio: matrice dei permessi

Ora si lavora. In questo laboratorio metti insieme tutto ciò che abbiamo visto e produci due deliverable concreti che entreranno nel tuo project work integrato: la matrice dei permessi RBAC e la policy di backup del nostro caso.

Parte A — Impostare il CDE demo

Usate uno di questi ambienti gratuiti / in versione di prova:

• ACCA usBIM (piano free / di prova): create un progetto, una struttura di cartelle e provate la gestione utenti e permessi.
• Autodesk Docs / Construction Cloud (trial 30 giorni): create un progetto, definite cartelle e i livelli di permesso per cartella.

Create una struttura di cartelle che rispecchi i quattro stati ISO 19650, ad esempio:

Progetto: Riqualificazione Scuola "Livorno-Centro"
├── 1_WIP (Lavorazione)
│     ├── ARC  (architettonico)
│     ├── STR  (strutture)
│     └── MEP  (impianti)
├── 2_SHARED (Condiviso / coordinamento)
├── 3_PUBLISHED (Pubblicato / cantiere)
└── 4_ARCHIVE (Archivio)

Parte B — Progettare la matrice RBAC

Compilate una tabella come questa, definendo per ogni ruolo i permessi su ogni cartella. Usate la leggenda V / D / M / X / A / — vista prima. Partite da questo modello e adattatelo al vostro team:

Mentre compilate, rispondete a queste domande di controllo (sono il filo del privilegio minimo):

• Chi ha davvero bisogno del permesso Elimina? (Suggerimento: quasi nessuno.)
• Chi può approvare il passaggio a Published? Deve essere un numero molto ristretto.
• L'impresa deve vedere i WIP? Perché sì o perché no?
• Il consulente esterno: per quanto tempo manterrà l'accesso e chi lo revocherà?

Parte C — Scrivere la policy di backup

Redigete una policy di backup di una pagina che risponda almeno a questi punti, applicando la regola 3-2-1:

1. Cosa si salva (modello federato, abachi, tavole published, documenti, audit log).
2. Dove sono le 3 copie e su quali 2 supporti, e quale è la copia offsite.
3. Ogni quanto (frequenza): es. giornaliera incrementale, settimanale completa.
4. Quanto a lungo si conservano (retention): es. ultime 30 versioni giornaliere + archivio annuale.
5. Cifratura: at rest (AES-256) e in transit (TLS).
6. Test di ripristino: quando e come si verifica che il backup funzioni davvero (almeno trimestrale).
7. Responsabile: chi è incaricato di eseguire e verificare i backup.

POLICY DI BACKUP — Progetto "Riqualificazione Scuola Livorno-Centro"

OGGETTO: modello federato IFC, abachi quantità, tavole Published,
         computo metrico, documenti contrattuali, audit log del CDE.

REGOLA 3-2-1
- Copia 1 (primaria): CDE cloud del progetto (Autodesk Docs / usBIM).
- Copia 2 (locale):  NAS dello studio (RAID), in sede.
- Copia 3 (offsite): servizio cloud di backup dedicato, datacenter UE.
  + Copia immutabile settimanale (object lock) -> anti-ransomware.

FREQUENZA
- Incrementale automatico: giornaliero (notte).
- Completo: settimanale (domenica).
- Immutabile: settimanale, conservazione 90 giorni.

RETENTION
- Giornalieri: ultimi 30. Settimanali: ultimi 12. Mensili: ultimi 12.
- Versioni Published: conservate per tutta la vita dell'opera (Archive).

CIFRATURA
- At rest:  AES-256 su NAS e su cloud di backup.
- In transit: TLS 1.2+ per ogni trasferimento.

TEST DI RIPRISTINO
- Ripristino di prova di un contenitore: TRIMESTRALE, verbalizzato.
- Esito registrato (0 errori) prima di considerare valido il backup.

RESPONSABILE
- BIM Manager (esecuzione/supervisione) + IT studio (infrastruttura).
- Revisione della policy: semestrale.

Mini-test di autoverifica

Sezione A: domande a risposta multipla

1. Cosa indica la sigla CDE in ambito BIM?
   a) Computer Design Engine   b) Common Data Environment   c) Cantiere Digitale Edile   d) Cloud Data Encryption
2. Quali sono i quattro stati del CDE secondo la ISO 19650?
   a) Bozza, Finale, Stampa, Cestino   b) WIP, Shared, Published, Archive   c) Privato, Pubblico, Cifrato, Backup   d) Locale, Cloud, Offsite, Online
3. Di cosa si occupa in particolare la ISO 19650-5?
   a) Della fase di esercizio   b) Dell'approccio security-minded   c) Dei formati dei file   d) Del computo metrico
4. Nel modello RBAC, i permessi vengono assegnati prima di tutto:
   a) Alle singole persone   b) Ai file   c) Ai ruoli   d) Ai computer
5. Il principio del "privilegio minimo" (least privilege) significa:
   a) Dare a tutti i permessi di amministratore   b) Concedere solo i permessi necessari al ruolo   c) Togliere tutti i permessi   d) Assegnare i permessi a caso
6. A cosa serve principalmente il versioning in un CDE?
   a) A cifrare i file   b) A velocizzare i download   c) A conservare la storia delle versioni e poter tornare indietro   d) A eliminare i duplicati
7. La regola di backup 3-2-1 prevede:
   a) 3 copie, 2 supporti, 1 offsite   b) 3 password, 2 utenti, 1 admin   c) 3 giorni, 2 settimane, 1 mese   d) 3 cartelle, 2 cloud, 1 disco
8. Nel modello di responsabilità condivisa del cloud, di cosa è responsabile l'utente (e non il fornitore)?
   a) Della cifratura dei datacenter   b) Della ridondanza dei server   c) Della gestione di password, MFA e permessi   d) Della manutenzione hardware

Sezione B: domande a risposta aperta

9. (2 punti) Spiega con parole tue perché il Common Data Environment, pur aumentando l'efficienza, "concentra il rischio". Fai un esempio sul cantiere.
10. (2 punti) Un consulente esterno ha terminato il suo incarico sul progetto due mesi fa, ma ha ancora accesso al CDE. Quale principio è stato violato e quali due misure pratiche avrebbero evitato il problema?

Riepilogo della lezione

Ottimo lavoro! Hai imparato a difendere il cuore dei dati BIM: il Common Data Environment. Ecco i punti chiave da portare con te.