Ich muss eines meiner "größeren" Datenbank-Projekte demnächst auf einem zentralen SQL-Server für mehrere konkurierende Unternehmen bereitstellen.
Bei der Suche nach der richtigen "Mehrmandanten-Lösung" habe ich nicht die nötige Praxiserfahrung.


Lösungsansatz eins, Mandantentabelle mit Mandanten-ID Beziehing in den "Nutzdaten-Tabellen", habe ich verworfen, weil er aus meiner Sicht zu unsicher ist.

In meiner Software kann ich noch sicherstellen, das Benutzer xy zu Mandant 1 gehört und kann die Mandanten-ID hart in den SQL-Abfragen übergeben.
SELECT * FROM Kundendaten WHERE ID_Mandant = 1 Kann ich irgendwie verhindern, das der User einen SQL-Editor nimmt, und sich die Daten von Mandant 2 klaut ?
SELECT * FROM Kundendaten WHERE ID_Mandant = 2 .


Mein zweiter Gedanke war, pro Kunden eine eigene Datenbank anzulegen, auf die nur er Zugriff hat.
Es können aber mal 30-40 Kunden werden ... Bedeutet das den sicheren Performance-Tot des SQL-Servers ?
Der Arme muss jetzt in 40 DB's die Statistiken aktualisieren, Indizies warten usw.


Variante drei ist mir entwicklungstechnisch zu "frickelig".
Ich könnte alle Tabellen mandantengebunden benennen und jeden SQL-Benutzer mit SQL-Server Rechten auf seine Tabellen beschränken.

markieren

Code:

Benutzer M1 hat nur Zugriff auf Tabelle Kundendaten_M1, Benutzer M2 nur auf Kundendaten_M2 usw.

Das wäre kein Problem. Sorgen habe ich nur mit den bestehenden 350 SP's, 80 Funktionen und etlichen Triggern in der DB. Ich müsste alles komplett durcharbeiten und die Mandaten-Kennung ( = SQL-Benutzer ) auslesen und mit dynamic-SQL neuen SQL-Code stricken, damit ich den kompletten SQL-Code nicht auch 40 mal anlegen und später auch noch 40 warten muss.
Zudem bin ich mir nicht sicher, ob die Performance bei dieser Variante nicht genauso in die Knie geht, wie bei der Variante mit den 40 Datenbanken.

Die Ideal-Lösung sollte folgende Kriterien erfüllen:
Die Datenbank muss mandanten-isoliert arbeiten, die Mehrbelastung des Servers durch das Mehrmandanten-Szenario sollte möglicht gering sein und der SQL-Code sollte grundlegend für alle Mandanten zentral wartbar sein.


Hatte jemand von euch mal ein ähnliches Problem, bzw. einen Lösungsansatz ?


Schöne Grüße,
Jens

Guten Morgen Jens,

den Zugriff (Datenschutz) kannst du auch mit nur einer Datenbank sicher gestalten. Du müsstest mit approles arbeiten, die interne Datenbanksicherheit (GRANT, REVOKE) ausreizen und konsequent auf Views setzen. Was mir wesentlich mehr Probleme bereiten würde, wäre ein griffiges Konzept für die Datensicherheit (backup, restore).

Grüße vom marabu

Hi Marabu,

die Zugriffskontrolle auf einzelne Datenbankobjekte, Tabellen und Spalten sowie die Kontrolle über einzelne DDL Statements via Grant/Revoke kenne ich.

Um das für meine Zwecke nutzen zu können, muss ich doch aber für jeden Mandanten eine eigene Tabelle erstellen, die nur er benutzen darf oder ?

Gibt es einen Trick, bei der ich die vorhandenen SP's, Trigger, UDF's und Views unverändert mandantenisoliert nutzen kann ?

Warum konsequent auf Views setzen ?
Gibt einen Weg, der es mit Hilfe von Views ermöglicht, die SP's usw. rolebezogen auf unterschiedliche Tabellen zu verteilen ?

Views bereiten mir im Hinblick aif die Performance Bauchschmerzen. Beim SQL Server 2005 Enterprise gibt es indizierte Sichten. Damit relativiert sich der Performancerinbruch durch Views. Beim SQL-Server 2000 sehe ich keine Möglichkeit, die Performance mit Views oben zu halten. Kennst du einen Weg ?

Zitat:

Was mir wesentlich mehr Probleme bereiten würde, wäre ein griffiges Konzept für die Datensicherheit (backup, restore).

Darüber habe ich mir auch schon den Kopf zerbrochen.
Derzeit tendiere ich zu folgender Variante:

- DB wird mehrmals täglich gesichert

Im Restorefall (ein Mandant hat versehentlich seine Daten gelöscht):
- DB unter anderem DB-Namen rücksüchern
- mandanteneigene Tabellen aus der Live-DB löschen
- DDL und Daten der mandanteneigenen DB-Objekte aus der 2. DB via DTS oder Script in die Live-DB schieben


Würde es doch nur einen "INSTEAD OF SELECT" Trigger geben ...

Es reicht, für jeden Mandanten eine VIEW zu erstellen, die fest auf der Tabelle nach dem Mandanten einschränkt. Der Benutzer bekomment dann keine Rechte auf der Tabelle sondern nur auf der View.

That's it.

alternativ kannst du auch stored functions/procedures nutzen welche den user der verbindung abfragen und dann nur noch die zugewiesenen datensätze liefern/verändern/einfügen.

auf die datenbank tabellen kann dann nicht zugegriffen werden - das solltest du über die datenbank berechtigungen sicherstellen.

Danke an euch drei.
Ich habe ein paar Tests gemacht und es scheint super zu funktonieren.

Zum Glück greift meine Applikation nicht direkt auf die Tabellen zu.
Ich werde jetzt die SP's und Views umbauen und den Zugriff auf die Tabellen sperren.


Schöne Grüße,
Jens