Eigentümerschaft, Gerätefreigabe & mandantenspezifische API
Ein System, das die Computer von Kunden verwaltet, muss zwei gegensätzliche Fragen zugleich beantworten: Wie verhindert man, dass verschiedene Mandanten einander sehen, und ermöglicht dabei gleichzeitig weiterhin die Gerätefreigabe zwischen Nutzern, ohne die Eigentümerschaft zu verlieren. So haben wir beides gelöst.
Mandantenisolierung — das Fundament
Jedes Gerät (DEVICE) ist an einen einzigen Workspace gebunden, und jede Abfrage im System — Auflisten, Verbinden, Löschen und sogar der WebSocket — wird nach diesem Workspace gefiltert. Wir haben das nicht nur im Code, sondern live gegen die Datenbank verifiziert: 0 von 12 Geräten ohne Zuordnung, und mandantenübergreifender Zugriff ist schlicht unmöglich. Selbst das Gerätepasswort ist mit dem Schlüssel des Workspace verschlüsselt, sodass ein Gerät, das einem Mandanten gehört, nicht mit dem Schlüssel eines anderen Mandanten entschlüsselt werden kann.
Nutzerspezifische Eigentümerschaft
Innerhalb derselben Organisation ist jeder Nutzer ein separater Mandant: Das Gerät gehört demjenigen, der es verbunden hat (owner_id), und ist standardmäßig für ihn privat. Das ist die Trennung, die fehlte, als jedes Teammitglied alles sehen konnte — jetzt bleibt ein nicht freigegebenes Gerät allein bei seinem Eigentümer.
Freigabe — explizit und gerätebezogen
Die Freigabe ist eine bewusste Handlung: Der Eigentümer wählt einen Nutzer in der Organisation und gibt ein einzelnes Gerät für ihn frei (device_grants) oder alle seine Geräte (account_grants), wobei er zwischen voller Steuerung und Nur-Ansicht wählt. Das freigegebene Gerät ist für beide zugänglich und verhält sich identisch — bis auf eine Sache:
Das Dashboard hat einen Bereich „🔗 Geteilte Geräte" mit zwei Reitern — was ich freigegeben habe und was mit mir geteilt wurde — sodass die Zugriffsverwaltung klar und bequem ist. Die Kryptografie hat sich nicht geändert: Der Worker entschlüsselt weiterhin mit dem Workspace-Schlüssel, und die Grant-Zeile ist die Berechtigung. Es gibt keinen Schlüsselaustausch und keine Rotation — dasselbe Vertrauensmodell, nur gerätebezogen statt organisationsbezogen fokussiert.
Mandantenspezifische API und MCP
Jeder Mandant kann seinen eigenen API-Schlüssel ausstellen (drk_…), der programmatischen Zugriff mit genau demselben Umfang gewährt, den er im Dashboard hat — nicht mehr. Der Schlüssel ist per Definition mandantenisoliert. Er treibt sowohl REST (/api/v1/*) als auch einen gehosteten MCP-Server an (/api/mcp), sodass Sie einen KI-Agenten (wie Claude) anbinden und ihm Werkzeuge geben können: Geräte auflisten, sehen, was freigegeben ist, und ein einmaliges Verbindungstoken erhalten. Alles steht hinter derselben Berechtigung — ein Agent kann kein Gerät sehen, das Sie nicht sehen können.
3D-Verbindungskarte
Und schließlich eine Ansicht im FROG-Stil: alle Ihre Geräte und Server als Knoten um ein Zentrum („wir"), umhüllt von einem durchscheinenden Schutzschild, mit ein- und ausgehenden Pfeilen, die den Verkehr zeigen, einem Überwachungspuls, der sich über die gesamte Konnektivität wiederholt, und einer Farbkodierung nach der Gesundheit jedes Geräts. Kundenzentriert: Jeder Mandant sieht nur seine eigenen Verbindungen. Das ist keine Dekoration — es ist eine Möglichkeit, auf einen Blick zu erfassen, was verbunden ist, was geschützt ist und was Aufmerksamkeit braucht.