Hallo TS, mir ist nicht ganz klar, wie diese Rechteerhöhung funktionieren soll. Der DB-Server kann dem Web-Server keine "besonders berechtigte Connection" geben. Der Web-Server kann eine aufbauen, braucht dafür aber passende Credentials. Hier mit Wegwerf-Credentials und Einmal-Grants zu arbeiten dürfte den SQL Server in die Knie zwingen. Wenn Du dem Webserver nur Basis-Credentials geben willst, darfst Du keinen einzigen INSERT/UPDATE/DELETE mehr an den technischen User des Frontend granten, sondern nur noch SELECTS und das Recht, bestimmte Routinen auszuführen. Diese übernehmen dann alle Datenzugriffe und prüfen die Berechtigungen dazu. Im Extremfall musst Du sogar die SELECTs in Routinen legen. Du bekommst jetzt aber ein Problem: - ein SQL Server ist stateless, d.h. er kann nicht speichern, dass sich ein User X erfolgreich authentifiziert hat. Du musst also entweder bei jedem Zugriff User-ID und Passwort mitgeben, oder über eine Authentication Routine eine Session-ID erzeugen und die in einer Session-Table halten. Die Session-Prüfung baust Du in jeder einzelne Routine ein, die Du in den DB-Server legst. Lass das! - die Alternative wäre, dass deine externen User im SQL Server als User angelegt sind und die DB-Connection mit den Credentials dieser User aufgebaut wird. Das führt zu einer komplexen Userverwaltung, die bei Anlage eines neuen Users für das Web-Frontend auch einen DB-User anlegen muss. Nein!! Ich würde zu einer klareren Trennung der Zuständigkeiten raten. Es geht Dir vermutlich darum, zu verhindern, dass ein kompromittierter Webserver auf der DB herumtoben kann. Für so etwas trennt man die einfache 2-Tier Architektur (Server für HTML-Rendering und Logik / DB-Server) in eine 3-Tier Architektur auf (Web-Server / Application-Server / DB-Server). Der Web Server kümmert sich in diesem Modell um das HTML Rendering und ist auf fachlicher Ebene Durchlauferhitzer. Der Application Server enthält die Geschäftslogik und insbesondere auch die Rechtesteuerung. Rollenspezifische Rechte sind Geschäftslogik. Ein DB Server soll sich mMn generell nicht um userspezifische Rechte und Geschäftslogik kümmern, sondern nur um eine möglichst flotte Bereitstellung der Daten. Abfragen in Routinen zu kombinieren macht aus meiner Sicht nur Sinn, wenn man Tabellendaten auf eine Weise miteinander kombinieren muss, die mit SQL nicht darstellbar ist und eine Auswertung auf dem Web-/App-Server zuviele unnütze Daten aus dem SQL Server lesen müsste. Ein DB-Server darf auch noch technische Rechte bewachen (d.h. verhindern, dass die Application B die Tabellen der Application A umpflügt - dafür der technische User). Ein paar Ansätze zum Gebrauch: Wenn sich ein User am Webserver anmeldet, führt der Webserver das nicht selbst durch. Statt dessen beauftragt er den App-Server mit der Authentication und erhält eine Session-ID auf dem App-Server. Die kommt wie üblich in den Cookie für den Anwender, und damit braucht der WEB Server keine eigene Sessionverwaltung mehr. Und er muss auch keine DB-Credentials kennen. Der App-Server verwaltet User-Sessions, cached dort ggf. ermittelte Rollenrechte und spuckt jedesmal Gift und Schwefel, wenn der Webserver mit der Session des Users X eine Operation durchführen will, die für X nicht erlaubt ist. Die weitere Vorgehensweise ist dann noch, zwischen Web-Server und App-Server eine Firewall zu platzieren, so dass der Application-Server vom Browser des Users aus netzwerktechnisch überhaupt nicht erreichbar ist. Der Netzwerkteil, in dem der Webserver steht, wird dann DMZ genannt (Ja. Genau. Demilitarisierte Zone). Vorteil des Ganzen ist auch, dass es besser skaliert. Wenn deine Application Logik aufwändig ist und der App-Server zu dampfen beginnt, ersetzt Du ihn durch einen Cluster. Wenn die Application Logik eher dürftig ist, man aber dafür auf dem Webserver in der DMZ Popcorn rösten kann, dann clusterst Du den. Wenn Du der Meinung bist, deine Application Logik statt in PHP besser/performanter in Java oder C# darstellen zu können, dann ersetzt Du die Appserver-Scripte durch Services in Java, C# oder C++. _Rolf_ -- sumpsi - posui - clusi

Hallo TS, mir ist nicht ganz klar, wie diese Rechteerhöhung funktionieren soll. Der DB-Server kann dem Web-Server keine "besonders berechtigte Connection" geben. Der Web-Server kann eine aufbauen, braucht dafür aber passende Credentials. Hier mit Wegwerf-Credentials und Einmal-Grants zu arbeiten dürfte den SQL Server in die Knie zwingen. Wenn Du dem Webserver nur Basis-Credentials geben willst, darfst Du keinen einzigen INSERT/UPDATE/DELETE mehr an den technischen User des Frontend granten, sondern nur noch SELECTS und das Recht, bestimmte Routinen auszuführen. Diese übernehmen dann alle Datenzugriffe und prüfen die Berechtigungen dazu. Im Extremfall musst Du sogar die SELECTs in Routinen legen. Du bekommst jetzt aber ein Problem: - ein SQL Server ist stateless, d.h. er kann nicht speichern, dass sich ein User X erfolgreich authentifiziert hat. Du musst also entweder bei jedem Zugriff User-ID und Passwort mitgeben, oder über eine Authentication Routine eine Session-ID erzeugen und die in einer Session-Table halten. Die Session-Prüfung baust Du in jeder einzelne Routine ein, die Du in den DB-Server legst. Lass das! - die Alternative wäre, dass deine externen User im SQL Server als User angelegt sind und die DB-Connection mit den Credentials dieser User aufgebaut wird. Das führt zu einer komplexen Userverwaltung, die bei Anlage eines neuen Users für das Web-Frontend auch einen DB-User anlegen muss. Nein!! Ich würde zu einer klareren Trennung der Zuständigkeiten raten. Es geht Dir vermutlich darum, zu verhindern, dass ein kompromittierter Webserver auf der DB herumtoben kann. Für so etwas trennt man die einfache 2-Tier Architektur (Server für HTML-Rendering und Logik / DB-Server) in eine 3-Tier Architektur auf (Web-Server / Application-Server / DB-Server). Der Web Server kümmert sich in diesem Modell um das HTML Rendering und ist auf fachlicher Ebene Durchlauferhitzer. Der Application Server enthält die Geschäftslogik und insbesondere auch die Rechtesteuerung. Rollenspezifische Rechte sind Geschäftslogik. Ein DB Server soll sich mMn generell nicht um userspezifische Rechte und Geschäftslogik kümmern, sondern nur um eine möglichst flotte Bereitstellung der Daten. Abfragen in Routinen zu kombinieren macht aus meiner Sicht nur Sinn, wenn man Tabellendaten auf eine Weise miteinander kombinieren muss, die mit SQL nicht darstellbar ist und eine Auswertung auf dem Web-/App-Server zuviele unnütze Daten aus dem SQL Server lesen müsste. Ein DB-Server darf auch noch technische Rechte bewachen (d.h. verhindern, dass die Application B die Tabellen der Application A umpflügt - dafür der technische User). Wenn sich ein User am Webserver anmeldet, führt der Webserver das nicht selbst durch. Statt dessen beauftragt er den App-Server mit der Authentication und erhält eine Session-ID auf dem App-Server. Die kommt wie üblich in den Cookie für den Anwender, und damit braucht der WEB Server keine eigene Sessionverwaltung mehr. Und er muss auch keine DB-Credentials kennen. Die weitere Vorgehensweise ist dann noch, zwischen Web-Server und App-Server eine Firewall zu platzieren, so dass der Application-Server vom Browser des Users aus netzwerktechnisch überhaupt nicht erreichbar ist. Der Netzwerkteil, in dem der Webserver steht, wird dann DMZ genannt (Ja. Genau. Demilitarisierte Zone). Vorteil des Ganzen ist auch, dass es besser skaliert. Wenn deine Application Logik aufwändig ist und der App-Server zu dampfen beginnt, ersetzt Du ihn durch einen Cluster. Wenn die Application Logik eher dürftig ist, man aber dafür auf dem Webserver in der DMZ Popcorn rösten kann, dann clusterst Du den. Wenn Du der Meinung bist, deine Application Logik statt in PHP besser/performanter in Java oder C# darstellen zu können, dann ersetzt Du die Appserver-Scripte durch Services in Java, C# oder C++. _Rolf_ -- sumpsi - posui - clusi