IFC Viewer Online · Voltar ao blog de BIM e IFC
Entrega e ISO 19650 · 2026-11-13 · 7 min
Quem vê qual modelo: como manter separados os dados dos fornecedores num CDE de entregas
Um workspace de entregas guarda modelos de muitas empresas que não podem ver o trabalho umas das outras. Cinco perguntas para fazer a qualquer CDE que recebe modelos, e os testes que fizemos no nosso antes de considerá-lo pronto.
Histórico de entregas de um projeto com 16 entradas, o SHA-256 de cada arquivo e a cadeia recalculada no navegador e encontrada intacta
O workspace de entregas de uma construtora é um lugar curioso. O engenheiro de estruturas, o instalador de sistemas prediais e a empresa de fachadas entregam todos nele, e cada um, em outro projeto, é concorrente do outro. Eles precisam ver os requisitos e o próprio trabalho. Não podem ver o dos outros.
A ISO 19650-5 estabelece uma abordagem com foco em segurança para gerir informação sensível sobre ativos construídos, use o projeto BIM ou não. [iso-19650-5] Você não precisa aplicar a norma inteira para fazer cinco perguntas simples a um CDE.
O essencial
- O que um link de fornecedor mostra, e o que não mostra?
- O que cada função na equipe que recebe pode fazer, e o que é recusado?
- Uma empresa consegue, em algum caso, ler os dados de outra?
- O arquivo verificado é o arquivo entregue?
- Se alguém edita o registro depois, isso aparece?
1. O que um link de fornecedor mostra
Um link de fornecedor leva um token de um único fornecedor. Sozinho, não mostra nada. Com o projeto para o qual foi criado, mostra os requisitos desse projeto e as entregas daquele fornecedor, nunca as de outro.
Dizemos isso com franqueza porque erramos primeiro: enquanto construíamos a página de envio, nossos testes descobriram que só o token listava todos os projetos da empresa. Foi corrigido antes de a página ser integrada, e agora um teste verifica isso a cada execução.
2. O que cada função pode fazer
Dentro da equipe da construtora há seis funções, de proprietário a convidado. Nossos testes fazem cada função tentar cada operação de escrita e esperam exatamente o que a função permite. Alguns exemplos do que é recusado:
- Um revisor pode ver as entregas, mas não pode aceitá-las nem devolvê-las.
- Um convidado não vê entrega nenhuma.
- Um leitor não pode colocar um e-mail na fila de saída.
- Só proprietários e administradores podem alterar a biblioteca de regras da empresa.
Quando duas pessoas editam a mesma pendência ou o mesmo conjunto de regras ao mesmo tempo, a segunda recebe a cópia atual e um conflito, em vez de sobrescrever a primeira sem aviso.
3. Uma empresa nunca lê outra
Nossos testes criam uma segunda empresa no mesmo servidor e tentam ler e escrever as entregas, pendências e regras da primeira com os próprios usuários. Todas as tentativas são recusadas. O teste roda junto com os outros, então uma mudança que o quebre não passa despercebida.
4. O arquivo verificado é o arquivo entregue
O navegador do fornecedor calcula o SHA-256 do arquivo e o registra antes do envio. O executor da validação confere essa impressão digital e o cabeçalho IFC antes de abrir qualquer coisa: um arquivo que mudou no caminho, ou que não é IFC, é devolvido antes da validação. Quem decide vê a mesma impressão digital, e a decisão fica selada com ela.
Teste local do workspace no nosso próprio servidor com os modelos de teste do Hotel Vela (arquivos IFC reais), interface em espanhol. Ainda não disponível.
5. Um registro que mostra se foi editado
Cada entrega e cada decisão é uma linha no histórico, com a data, o autor e a impressão digital, encadeada à linha anterior. “Verificar a cadeia” recalcula cada hash no seu navegador; no nosso projeto de teste, as 16 entradas conferiram. Se alguém edita uma linha, a cadeia quebra nessa linha. O UK BIM Framework descreve a revisão e a aceitação como uma etapa da parte que recebe a informação; [uk-bim-part-c] este histórico é a evidência de cada aceitação.
Teste local do workspace no nosso próprio servidor com os modelos de teste do Hotel Vela (arquivos IFC reais), interface em espanhol. Ainda não disponível.
O que sai do workspace
- Os webhooks são assinados com HMAC-SHA256, para que o seu sistema saiba que vieram de nós.
- Os e-mails vão para uma fila e esperam lá. Um contato que nunca consentiu, ou que cancelou a inscrição, é recusado pela própria fila.
- Os links de cliente guardam apenas o hash do token e da senha, expiram, podem ser revogados e bloqueiam após 10 tentativas falhas.
O que ainda não está feito
- Roda no nosso próprio servidor em testes, ainda não como serviço hospedado com contrato.
- Ainda não há auditoria de segurança externa.
Pergunte o mesmo a qualquer CDE
Essas cinco perguntas valem para qualquer ferramenta, incluindo a nossa. Para as perguntas que um departamento de TI faz sobre o visualizador gratuito (para onde vão os arquivos, cookies, subprocessadores), veja a checklist de segurança de TI para ferramentas BIM. Para testar o Recepção num projeto real, fale com a gente.
Quem vê qual modelo: como manter separados os dados dos fornecedores num CDE de entregas