IFC Viewer Online · Zurück zum BIM- & IFC-Blog
Übergabe & ISO 19650 · 2026-11-13 · 7 Min.
Wer sieht welches Modell: Lieferantendaten in einer Liefer-CDE getrennt halten
Ein Lieferbereich enthält Modelle vieler Unternehmen, die die Arbeit der anderen nicht sehen dürfen. Fünf Fragen an jede CDE, die Modelle empfängt, und die Tests, die wir an unserer durchgeführt haben, bevor wir sie fertig nannten.
Lieferprotokoll eines Projekts mit 16 Einträgen, dem SHA-256 jeder Datei und der im Browser neu berechneten, intakten Kette
Der Lieferbereich eines Bauunternehmens ist ein eigenartiger Ort. Der Tragwerksplaner, der TGA-Installateur und die Fassadenfirma liefern alle hinein, und auf einem anderen Projekt ist jeder der Konkurrent des anderen. Sie müssen die Anforderungen und ihre eigene Arbeit sehen. Die der anderen dürfen sie nicht sehen.
ISO 19650-5 legt einen sicherheitsbewussten Ansatz für das Management sensibler Informationen über Bauwerke fest, unabhängig davon, ob das Projekt BIM nutzt. [iso-19650-5] Man muss nicht die ganze Norm anwenden, um einer gemeinsamen Datenumgebung (CDE) fünf einfache Fragen zu stellen.
Das Wichtigste
- Was zeigt ein Lieferantenlink, und was nicht?
- Was darf jede Rolle im empfangenden Team, und was wird verweigert?
- Kann ein Unternehmen jemals die Daten eines anderen lesen?
- Ist die geprüfte Datei die gelieferte Datei?
- Wenn jemand den Eintrag nachträglich bearbeitet, fällt es auf?
1. Was ein Lieferantenlink zeigt
Ein Lieferantenlink trägt ein Token für einen Lieferanten. Allein zeigt er nichts. Zusammen mit dem Projekt, für das er erstellt wurde, zeigt er die Anforderungen dieses Projekts und die Lieferungen dieses Lieferanten, nie die eines anderen.
Wir sagen das offen, weil wir es zuerst falsch gemacht haben: Beim Bau der Upload-Seite fanden unsere Tests heraus, dass das Token allein alle Projekte des Unternehmens auflistete. Das wurde behoben, bevor die Seite zusammengeführt wurde, und ein Test prüft es jetzt bei jedem Lauf.
2. Was jede Rolle darf
Im Team des Bauunternehmens gibt es sechs Rollen, vom Eigentümer bis zum Gast. Unsere Tests lassen jede Rolle jeden Schreibvorgang versuchen und erwarten genau das, was die Rolle erlaubt. Einige Beispiele für Verweigertes:
- Ein Prüfer kann Lieferungen sehen, aber nicht annehmen oder zurückweisen.
- Ein Gast sieht überhaupt keine Lieferungen.
- Ein Betrachter kann keine E-Mail in die ausgehende Warteschlange stellen.
- Nur Eigentümer und Admins können die Regelbibliothek des Unternehmens ändern.
Wenn zwei Personen gleichzeitig dasselbe Issue oder Regelwerk bearbeiten, erhält die zweite die aktuelle Fassung und einen Konflikt, statt die erste stillschweigend zu überschreiben.
3. Ein Unternehmen liest nie ein anderes
Unsere Tests legen ein zweites Unternehmen auf demselben Server an und versuchen, mit dessen eigenen Benutzern die Lieferungen, Issues und Regeln des ersten zu lesen und zu schreiben. Jeder Versuch wird verweigert. Der Test läuft mit den anderen, sodass eine Änderung, die ihn bricht, nicht unbemerkt bleibt.
4. Die geprüfte Datei ist die gelieferte Datei
Der Browser des Lieferanten berechnet den SHA-256 der Datei und registriert ihn vor dem Hochladen. Der Validierungsdienst prüft diesen Fingerabdruck und den IFC-Header, bevor er irgendetwas öffnet: Eine Datei, die sich unterwegs verändert hat, oder eine, die keine IFC-Datei ist, wird vor der Validierung zurückgewiesen. Wer entscheidet, sieht denselben Fingerabdruck, und die Entscheidung wird damit versiegelt.
Lokaler Test des Arbeitsbereichs auf unserem eigenen Server mit den Testmodellen von Hotel Vela (echte IFC-Dateien), spanische Oberfläche. Noch nicht geöffnet.
5. Ein Eintrag, der Bearbeitungen zeigt
Jede Lieferung und jede Entscheidung ist eine Zeile im Protokoll, mit Datum, Autor und Fingerabdruck, verkettet mit der vorherigen Zeile. „Kette prüfen“ berechnet jeden Hash in Ihrem Browser neu; in unserem Testprojekt stimmten 16 Einträge überein. Bearbeitet jemand eine Zeile, bricht die Kette an dieser Zeile. Das UK BIM Framework beschreibt Prüfung und Annahme als Schritt der Partei, die die Informationen empfängt; [uk-bim-part-c] dieses Protokoll ist der Nachweis jeder Annahme.
Lokaler Test des Arbeitsbereichs auf unserem eigenen Server mit den Testmodellen von Hotel Vela (echte IFC-Dateien), spanische Oberfläche. Noch nicht geöffnet.
Was den Arbeitsbereich verlässt
- Webhooks werden mit HMAC-SHA256 signiert, sodass Ihr System erkennen kann, dass sie von uns kommen.
- E-Mails gehen in eine Warteschlange und warten dort. Ein Kontakt, der nie eingewilligt oder sich abgemeldet hat, wird von der Warteschlange selbst abgelehnt.
- Kundenlinks speichern nur den Hash des Tokens und des Passworts, laufen ab, können widerrufen werden und sperren sich nach 10 Fehlversuchen.
Was noch nicht fertig ist
- Es läuft in Tests auf unserem eigenen Server, noch nicht als gehosteter Dienst mit Vertrag.
- Es gibt noch kein externes Sicherheitsaudit.
Stellen Sie jeder CDE dieselben Fragen
Diese fünf Fragen funktionieren für jedes Werkzeug, unseres eingeschlossen. Für die Fragen, die eine IT-Abteilung zum kostenlosen Viewer stellt (wohin Dateien gehen, Cookies, Unterauftragsverarbeiter), siehe die IT-Sicherheits-Checkliste für BIM-Werkzeuge. Um Reception an einem echten Projekt zu testen, sprechen Sie mit uns.
Wer sieht welches Modell: Lieferantendaten in einer Liefer-CDE getrennt halten