Zum Inhalt springen
CodamAI

Mandantentrennung im Fundament

Kunden bleiben voneinander getrennt – nicht durch einen nachträglich eingezogenen Filter, sondern durch getrennte Datenbanken. Wohin ein Zugriff geht, entscheiden das Modell und ein signierter Anmeldenachweis, nie eine Angabe des Clients.

Drei Ebenen je Modell

Für jedes Modell legen Sie im Hub fest, auf welcher Ebene seine Daten leben. Die Ebene beantwortet zwei Fragen auf einmal: In welcher Datenbank liegen die Daten, und wer sieht welche Datensätze?

  • System: Daten der ganzen Installation, die alle Mandanten teilen.
  • Mandant: Daten eines Kunden – der Standard.
  • Benutzer: Daten, die einer einzelnen Person gehören, etwa Entwürfe oder persönliche Einstellungen. Andere Personen desselben Kunden sehen sie nicht.

Eine Datenbank je Mandant

Eine Installation arbeitet entweder mit einer Datenbank für alles oder mit einer gemeinsamen System-Datenbank und einer eigenen Datenbank je Mandant. Im zweiten Fall liest und schreibt eine Anfrage nur in der Datenbank ihres Mandanten und in der System-Datenbank. Die Daten anderer Kunden liegen nicht auf ihrem Weg.

Dateien und Historie folgen derselben Trennung: Jeder Mandant hat ein eigenes Ablageverzeichnis und ein eigenes Revisionsprotokoll. Die Trennung nach Personen auf der Benutzerebene wirkt in beiden Betriebsarten.

Regeln ohne Ausnahme

Die Trennung beruht auf wenigen Regeln, die überall gelten:

  • Der Mandant stammt immer aus dem signierten Anmeldenachweis. Ein Feld in den Daten kann ihn nicht ändern.
  • Fehlt der Mandant, bricht der Zugriff ab. Mandantendaten landen nie stillschweigend in der gemeinsamen System-Datenbank.
  • Ein gesperrter oder abgelaufener Mandant erreicht keine Daten – das prüft Identity & Access vor jedem Zugriff.
  • Eine Mandanten-Datenbank entsteht nur mit ausdrücklicher Freigabe im Betrieb, und Data Management löscht nie eine Datenbank.

Kontrolliert wechseln

Manchmal muss jemand gezielt in einem anderen Mandanten arbeiten – eine Person, die zu zwei Firmen gehört, oder der Support. Ein Mandantenwechsel wirkt nur, wenn der Anmeldenachweis ihn deckt: als Mitglied des Ziels oder mit einer eigenen Berechtigung und dem Ziel in der Liste erlaubter Mandanten. Geprüft wird zweimal, in Identity & Access und noch einmal in der Datenhaltung. Ein gesperrter Mandant bleibt auch nach einem Wechsel gesperrt.

Soll der Support sehen, was eine bestimmte Person sieht, gibt es den Benutzerwechsel. Er braucht eine eigene Berechtigung und in der Grundeinstellung die Freigabe der betroffenen Person. Die Historie hält dann zusätzlich fest, wer tatsächlich gehandelt hat.

Wofür das im Alltag sorgt

Im Zweifel scheitert ein Zugriff sichtbar. Ein Fehler ist harmlos im Vergleich zu Daten, die im falschen Mandanten landen.

  • Mandantenfähigkeit muss nicht in jedem Projekt neu gebaut werden.
  • Ein Kunde lässt sich sperren, ohne dass Daten bewegt werden.
  • Die Trennung ist am Aufbau erkennbar, nicht nur an einzelnen Abfragen.

Passt CodamAI zu Ihrem Engineering Setup?

Der ehrlichste Weg dorthin ist ein technisches Gespräch: über Ihren Stack, Ihre Delivery und die Anforderungen, die Sie nachweisen müssen.