Mandantentrennung in CDMS
Wie CDMS Kunden voneinander trennt: eine Datenbank pro Mandant, woher der Mandant einer Anfrage kommt, wie er gewechselt wird und welche Regeln nie gebrochen werden.
Themen dieser Fachlichkeit
- 1.SINGLE und MULTI
Die zwei Betriebsarten der Datenhaltung: eine Datenbank für alle oder eine pro Mandant. Was sich dadurch ändert.
- 2.Woher der Mandant einer Anfrage kommt
Der Mandant steht im Token. Hier steht, wie er gelesen wird und was ohne Mandant passiert.
- 3.Welche Datenbank? Das Persistenzziel
Die Entscheidung, ob ein Zugriff in der System-DB oder in der Mandanten-DB landet, als vollständige Entscheidungstabelle. Ohne Rückfall auf die System-DB.
- 4.Mandantenwechsel per Header
Wie eine berechtigte Person mit dem Header
tenantfür einen anderen Mandanten arbeitet und warum ein Wechsel ohne Rolle still ignoriert wird. - 5.Benutzerwechsel per Header
Wie eine berechtigte Person im Namen einer anderen Person arbeitet, mit den eigenen Rollen oder mit denen der Zielperson, und welche Prüfungen davor stehen.
- 6.Wird der Mandant bedient?
Vor jedem Zugriff fragt die Filterkette bei CIAS nach, ob der Mandant aktiv ist. Hier steht die Sicht von CDMS; die Einzelheiten stehen bei CIAS.
- 7.Datenbanken, Pools, Migration
Jeder Mandant hat eine eigene Datenbank mit eigenem Verbindungspool. Wann sie angelegt und wie ihr Schema migriert wird.
- 8.Regeln, die nie gebrochen werden
Die Sicherheitsinvarianten der Mandantentrennung: kein Rückfall auf die System-DB, getrennte Typmengen, nur drei Stellen dürfen einen Mandanten setzen.