IFC Viewer Online · Torna al blog BIM e IFC
Consegna e ISO 19650 · 2026-11-13 · 7 min
Chi vede quale modello: tenere separati i dati dei fornitori in un CDE di consegna
Uno spazio di consegna contiene modelli di molte aziende che non devono vedere il lavoro delle altre. Cinque domande da fare a qualsiasi CDE che riceve modelli, e i test che abbiamo eseguito sul nostro prima di considerarlo pronto.
Registro delle consegne di un progetto con 16 voci, lo SHA-256 di ogni file e la catena ricalcolata nel browser e risultata integra
Lo spazio di consegna di un'impresa è un posto strano. L'ingegnere strutturista, l'installatore impiantistico e l'azienda delle facciate consegnano tutti lì, e ognuno, su un altro progetto, è concorrente dell'altro. Devono vedere i requisiti e il proprio lavoro. Non devono vedere quello degli altri.
La ISO 19650-5 definisce un approccio orientato alla sicurezza per gestire le informazioni sensibili sui beni costruiti, che il progetto usi il BIM o no. [iso-19650-5] Non serve applicare l'intera norma per fare a un CDE cinque domande semplici.
In sintesi
- Cosa mostra un link fornitore, e cosa no?
- Cosa può fare ogni ruolo del team ricevente, e cosa viene rifiutato?
- Un'azienda può mai leggere i dati di un'altra?
- Il file controllato è il file consegnato?
- Se qualcuno modifica il registro in seguito, si vede?
1. Cosa mostra un link fornitore
Un link fornitore contiene un token per un solo fornitore. Da solo non mostra nulla. Con il progetto per cui è stato creato, mostra i requisiti di quel progetto e le consegne di quel fornitore, mai quelle di un altro.
Lo diciamo apertamente perché la prima volta abbiamo sbagliato: durante la costruzione della pagina di caricamento, i nostri test hanno scoperto che il solo token elencava tutti i progetti dell'azienda. È stato corretto prima del merge della pagina, e ora un test lo verifica a ogni esecuzione.
2. Cosa può fare ogni ruolo
Nel team dell'impresa ci sono sei ruoli, da proprietario a ospite. I nostri test fanno tentare a ogni ruolo ogni scrittura e si aspettano esattamente ciò che il ruolo consente. Alcuni esempi di ciò che viene rifiutato:
- Un revisore può vedere le consegne ma non accettarle né respingerle.
- Un ospite non può vedere le consegne.
- Un lettore non può mettere un'email nella coda di uscita.
- Solo proprietari e amministratori possono modificare la libreria di regole aziendale.
Quando due persone modificano contemporaneamente la stessa segnalazione o lo stesso set di regole, la seconda riceve la copia attuale e un conflitto, invece di sovrascrivere in silenzio la prima.
3. Un'azienda non legge mai un'altra
I nostri test creano una seconda azienda sullo stesso server e tentano, con i suoi utenti, di leggere e scrivere consegne, segnalazioni e regole della prima. Ogni tentativo viene rifiutato. Il test gira insieme agli altri, quindi una modifica che lo rompe non passa inosservata.
4. Il file controllato è il file consegnato
Il browser del fornitore calcola lo SHA-256 del file e lo registra prima del caricamento. Il runner di validazione verifica quell'impronta e l'intestazione IFC prima di aprire qualsiasi cosa: un file cambiato lungo il percorso, o che non è un IFC, viene respinto prima della validazione. Chi decide vede la stessa impronta, e la sua decisione viene sigillata con essa.
Test locale dello spazio di lavoro sul nostro server con i modelli di prova di Hotel Vela (file IFC reali), interfaccia in spagnolo. Non ancora aperto.
5. Un registro che rivela le modifiche
Ogni consegna e ogni decisione è una riga del registro, con data, autore e impronta, concatenata alla riga precedente. «Verifica la catena» ricalcola ogni hash nel tuo browser; nel nostro progetto di prova, 16 voci corrispondevano. Se qualcuno modifica una riga, la catena si spezza in quella riga. Lo UK BIM Framework descrive revisione e accettazione come un passaggio di chi riceve le informazioni; [uk-bim-part-c] questo registro è la prova di ogni accettazione.
Test locale dello spazio di lavoro sul nostro server con i modelli di prova di Hotel Vela (file IFC reali), interfaccia in spagnolo. Non ancora aperto.
Cosa esce dallo spazio di lavoro
- I webhook sono firmati con HMAC-SHA256, così il tuo sistema sa che provengono da noi.
- Le email vanno in una coda e restano lì. Un contatto che non ha mai acconsentito, o che si è disiscritto, viene rifiutato dalla coda stessa.
- I link per il committente salvano solo l'hash del token e della password, scadono, si possono revocare e si bloccano dopo 10 tentativi falliti.
Cosa non è ancora fatto
- Gira sul nostro server nei test, non ancora come servizio ospitato con contratto.
- Non c'è ancora un audit di sicurezza esterno.
Fai le stesse domande a qualsiasi CDE
Queste cinque domande valgono per qualsiasi strumento, il nostro compreso. Per le domande che un reparto IT fa sul visualizzatore gratuito (dove vanno i file, cookie, sub-responsabili), vedi la checklist di sicurezza IT per strumenti BIM. Per provare Ricezione su un progetto reale, parliamone.
Chi vede quale modello: tenere separati i dati dei fornitori in un CDE di consegna