IFC Viewer Online · Volver al blog BIM e IFC
Entrega e ISO 19650 · 2026-11-13 · 7 min
Quién ve cada modelo: separar los datos de los proveedores en un CDE de entregas
Un espacio de entregas guarda modelos de muchas empresas que no deben ver el trabajo de las demás. Cinco preguntas que hacer a cualquier CDE que recibe modelos, y las pruebas que pasamos al nuestro antes de darlo por listo.
Registro de entregas de un proyecto con 16 entradas, el SHA-256 de cada archivo y la cadena recalculada en el navegador y comprobada intacta
El espacio de entregas de una constructora es un sitio curioso. La ingeniería de estructuras, el instalador de MEP y la empresa de fachadas entregan todos en él, y cada uno es, en otro proyecto, competidor del otro. Deben ver los requisitos y su propio trabajo. No deben ver el de los demás.
La ISO 19650-5 establece un enfoque de gestión de la información sensible de los activos construidos orientado a la seguridad, se use o no BIM en el proyecto. [iso-19650-5] No hace falta aplicar toda la norma para hacerle a un CDE cinco preguntas sencillas.
Lo esencial
- ¿Qué muestra un enlace de proveedor y qué no?
- ¿Qué puede hacer cada rol del equipo que recibe y qué se le deniega?
- ¿Puede una empresa leer alguna vez los datos de otra?
- ¿El archivo comprobado es el archivo entregado?
- Si alguien edita el registro después, ¿se nota?
1. Qué muestra un enlace de proveedor
Un enlace de proveedor lleva un token para un solo proveedor. Por sí solo no muestra nada. Con el proyecto para el que se creó, muestra los requisitos de ese proyecto y las entregas de ese proveedor, nunca las de otro.
Lo decimos claramente porque al principio lo hicimos mal: mientras construíamos la página de subida, nuestras pruebas detectaron que el token por sí solo listaba todos los proyectos de la empresa. Se corrigió antes de fusionar la página, y ahora una prueba lo comprueba en cada ejecución.
2. Qué puede hacer cada rol
Dentro del equipo de la constructora hay seis roles, de propietario a invitado. Nuestras pruebas hacen que cada rol intente cada escritura y esperan exactamente lo que el rol permite. Algunos ejemplos de lo que se deniega:
- Un revisor puede ver las entregas, pero no aceptarlas ni devolverlas.
- Un invitado no puede ver las entregas en absoluto.
- Un lector no puede dejar un correo en la cola de salida.
- Solo propietarios y administradores pueden cambiar la biblioteca de reglas de la empresa.
Cuando dos personas editan a la vez la misma incidencia o el mismo conjunto de reglas, la segunda recibe la copia actual y un conflicto, en lugar de sobrescribir en silencio a la primera.
3. Una empresa nunca lee los datos de otra
Nuestras pruebas crean una segunda empresa en el mismo servidor e intentan leer y escribir las entregas, incidencias y reglas de la primera con sus propios usuarios. Se deniegan todos los intentos. La prueba se ejecuta con las demás, así que un cambio que la rompa no pasa desapercibido.
4. El archivo comprobado es el archivo entregado
El navegador del proveedor calcula el SHA-256 del archivo y lo registra antes de subirlo. El proceso de validación comprueba esa huella y la cabecera IFC antes de abrir nada: un archivo que cambió por el camino, o uno que no es un IFC, se devuelve antes de validarlo. Quien decide ve la misma huella, y su decisión queda sellada con ella.
Prueba local del espacio de trabajo en nuestro propio servidor con los modelos de prueba de Hotel Vela (archivos IFC reales), interfaz en español. Aún no está abierto.
5. Un registro que delata cualquier edición
Cada entrega y cada decisión es una línea del registro, con la fecha, el autor y la huella, encadenada a la línea anterior. «Comprobar la cadena» recalcula todos los hashes en tu navegador; en nuestro proyecto de prueba coincidieron las 16 entradas. Si alguien edita una línea, la cadena se rompe en esa línea. El UK BIM Framework describe la revisión y aceptación como un paso de la parte que recibe la información; [uk-bim-part-c] este registro es la prueba de cada aceptación.
Prueba local del espacio de trabajo en nuestro propio servidor con los modelos de prueba de Hotel Vela (archivos IFC reales), interfaz en español. Aún no está abierto.
Lo que sale del espacio de trabajo
- Los webhooks van firmados con HMAC-SHA256, para que tu sistema sepa que vienen de nosotros.
- Los correos van a una cola y esperan allí. Un contacto que nunca dio su consentimiento, o que se dio de baja, lo rechaza la propia cola.
- Los enlaces de cliente guardan solo el hash del token y de la contraseña, caducan, se pueden revocar y se bloquean tras 10 intentos fallidos.
Lo que aún no está hecho
- Funciona en nuestro propio servidor en pruebas, todavía no como servicio alojado con contrato.
- Aún no hay una auditoría de seguridad externa.
Pregunta lo mismo a cualquier CDE
Estas cinco preguntas sirven para cualquier herramienta, la nuestra incluida. Para las preguntas que hace un departamento de TI sobre el visor gratuito (adónde van los archivos, cookies, subencargados), consulta la lista de seguridad TI para herramientas BIM. Para probar Recepción en un proyecto real, habla con nosotros.
Quién ve cada modelo: separar los datos de los proveedores en un CDE de entregas