IFC Viewer Online · Torna al blog BIM i IFC
Lliurament i ISO 19650 · 2026-11-13 · 7 min
Qui veu cada model: mantenir separades les dades dels proveïdors en un CDE de lliuraments
Un espai de lliuraments conté models de moltes empreses que no han de veure la feina de les altres. Cinc preguntes per fer a qualsevol CDE que rep models, i les proves que vam fer al nostre abans de donar-lo per llest.
Registre de lliuraments d'un projecte amb 16 entrades, el SHA-256 de cada fitxer i la cadena recalculada al navegador i trobada intacta
L'espai de lliuraments d'una constructora és un lloc curiós. L'enginyeria d'estructures, l'instal·lador i l'empresa de façanes hi lliuren tots, i cadascun, en un altre projecte, és competidor dels altres. Han de veure els requisits i la seva pròpia feina. No han de veure la dels altres.
La ISO 19650-5 estableix un enfocament de seguretat per gestionar la informació sensible dels actius construïts, tant si el projecte fa servir BIM com si no. [iso-19650-5] No cal aplicar tota la norma per fer cinc preguntes senzilles a un CDE.
L’essencial
- Què mostra un enllaç de proveïdor, i què no?
- Què pot fer cada rol de l'equip que rep, i què se li denega?
- Pot una empresa llegir mai les dades d'una altra?
- El fitxer que es va comprovar és el fitxer que es va lliurar?
- Si algú edita el registre després, es nota?
1. Què mostra un enllaç de proveïdor
Un enllaç de proveïdor porta un token per a un proveïdor. Tot sol no mostra res. Amb el projecte per al qual es va crear, mostra els requisits d'aquell projecte i els lliuraments d'aquell proveïdor, mai els d'un altre.
Ho diem clarament perquè primer ho vam fer malament: mentre construíem la pàgina de pujada, les nostres proves van detectar que el token sol llistava tots els projectes de l'empresa. Es va corregir abans de fusionar la pàgina, i ara una prova ho comprova a cada execució.
2. Què pot fer cada rol
Dins l'equip de la constructora hi ha sis rols, de propietari a convidat. Les nostres proves fan que cada rol intenti totes les escriptures i esperen exactament el que el rol permet. Alguns exemples del que es denega:
- Un revisor pot veure els lliuraments però no els pot acceptar ni retornar.
- Un convidat no pot veure els lliuraments de cap manera.
- Un lector no pot deixar un correu a la cua de sortida.
- Només els propietaris i els administradors poden canviar la biblioteca de regles de l'empresa.
Quan dues persones editen alhora la mateixa incidència o el mateix conjunt de regles, la segona rep la còpia actual i un conflicte, en lloc de sobreescriure la primera sense avisar.
3. Una empresa mai no llegeix una altra
Les nostres proves creen una segona empresa al mateix servidor i intenten llegir i escriure els lliuraments, les incidències i les regles de la primera amb els seus propis usuaris. Tots els intents es deneguen. La prova s'executa amb les altres, de manera que un canvi que la trenqui no passa desapercebut.
4. El fitxer comprovat és el fitxer lliurat
El navegador del proveïdor calcula el SHA-256 del fitxer i el registra abans de pujar-lo. L'executor de validació comprova aquesta empremta i la capçalera IFC abans d'obrir res: un fitxer que ha canviat pel camí, o que no és un IFC, es retorna abans de la validació. Qui decideix veu la mateixa empremta, i la seva decisió queda segellada amb ella.
Prova local de l'espai de treball al nostre propi servidor amb els models de prova de Hotel Vela (fitxers IFC reals), interfície en castellà. Encara no està obert.
5. Un registre que es nota si s'edita
Cada lliurament i cada decisió és una línia del registre, amb la data, l'autor i l'empremta, encadenada a la línia anterior. «Comprovar la cadena» recalcula cada hash al teu navegador; al nostre projecte de prova, les 16 entrades coincidien. Si algú edita una línia, la cadena es trenca en aquella línia. El UK BIM Framework descriu la revisió i l'acceptació com un pas de qui rep la informació; [uk-bim-part-c] aquest registre és l'evidència de cada acceptació.
Prova local de l'espai de treball al nostre propi servidor amb els models de prova de Hotel Vela (fitxers IFC reals), interfície en castellà. Encara no està obert.
Què surt de l'espai de treball
- Els webhooks se signen amb HMAC-SHA256, perquè el teu sistema pugui saber que vénen de nosaltres.
- Els correus van a una cua i hi esperen. Un contacte que no ho ha acceptat mai, o que s'ha donat de baixa, el rebutja la mateixa cua.
- Els enllaços de client només desen el hash del token i de la contrasenya, caduquen, es poden revocar i es bloquegen després de 10 intents fallits.
El que encara no està fet
- Funciona al nostre propi servidor en proves, encara no com a servei allotjat amb contracte.
- Encara no hi ha cap auditoria de seguretat externa.
Pregunta el mateix a qualsevol CDE
Aquestes cinc preguntes serveixen per a qualsevol eina, inclosa la nostra. Per a les preguntes que fa un departament d'informàtica sobre el visor gratuït (on van els fitxers, cookies, subencarregats), consulta la llista de comprovació de seguretat informàtica per a eines BIM. Per provar Recepció en un projecte real, parla amb nosaltres.
Qui veu cada model: mantenir separades les dades dels proveïdors en un CDE de lliuraments