4
Zugriff auf OLAP-Cube (MS SQL Server 2005) unterbinden
Hallo,
ich hoffe mir kann jemand auf die Sprünge helfen. Ich muss vorab sagen, dass ich kein DB-Pro bin sondern aus einer ganz anderen Schiene komme. Sollten also wichtig Informationen fehlen, dann bitte nochmal nachfragen.
Kollegen von mir betreiben einen OLAP-Cube auf einem MS SQL Server. Neben dem DB-Server gibt es einen Web-Server, der für unsere User entsprechende Berichte zur Verfügung stellt. Die Nutzer melden sich dort an der Web-Oberfläche an. Die Berichte werden in Echtzeit vom DB-Server bereitgestellt (so weit ich das verstanden habe). Die User haben also auch Rechte auf der Datenbank, damit die Berichte erzeugt werden können.
Das Problem ist jetzt folgendes:
Die User können den Cube auch am Web-Server vorbei abfragen. Sie können ihn z.B. per Excel als Pivot-Tabelle importieren und sich dann eigene Berichte basteln. Dies ist nicht erwünscht.
Das Problem liegt jetzt bei mir mit der Bitte den Zugriff auf den DB-Server netzwerktechnisch von den Clients aus zu unterbinden. Das ist kein größeres Problem, aber ich kann mir einfach nicht vorstellen, dass es keine andere Möglichkeit gibt! Es muss doch möglich sein, das ganze SQL Server intern zu lösen, oder???
Gruß
Fritz0609
ich hoffe mir kann jemand auf die Sprünge helfen. Ich muss vorab sagen, dass ich kein DB-Pro bin sondern aus einer ganz anderen Schiene komme. Sollten also wichtig Informationen fehlen, dann bitte nochmal nachfragen.
Kollegen von mir betreiben einen OLAP-Cube auf einem MS SQL Server. Neben dem DB-Server gibt es einen Web-Server, der für unsere User entsprechende Berichte zur Verfügung stellt. Die Nutzer melden sich dort an der Web-Oberfläche an. Die Berichte werden in Echtzeit vom DB-Server bereitgestellt (so weit ich das verstanden habe). Die User haben also auch Rechte auf der Datenbank, damit die Berichte erzeugt werden können.
Das Problem ist jetzt folgendes:
Die User können den Cube auch am Web-Server vorbei abfragen. Sie können ihn z.B. per Excel als Pivot-Tabelle importieren und sich dann eigene Berichte basteln. Dies ist nicht erwünscht.
Das Problem liegt jetzt bei mir mit der Bitte den Zugriff auf den DB-Server netzwerktechnisch von den Clients aus zu unterbinden. Das ist kein größeres Problem, aber ich kann mir einfach nicht vorstellen, dass es keine andere Möglichkeit gibt! Es muss doch möglich sein, das ganze SQL Server intern zu lösen, oder???
Gruß
Fritz0609
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 75111
Url: https://administrator.de/contentid/75111
Printed on: April 24, 2024 at 06:04 o'clock
4 Comments
Latest comment
so wie ich das verstanden habe willst du den clients nur einen Einblick in bestimmte bereiche (Daten) deiner DB geben. Würde dir spontan vorschlagen "Visionen" zu erstellen. Dies sind die Abfragen die der User (je nach Zugriffsrecht) sieht und nur diese kann er verwenden.
Moin Fritz0609,
da geht gedanklich etwas durcheinander, glaube ich.
Der Webserver ist (lässt man/frau die unnötigen Schnörkel weg) eine Applikation.
Dieser hat sicher auch einen Prozessuser, das heißt eine UserID/Passwort, welches die Endbenutzer nicht kennen müssen oder dürfen.
Mit dieser UserID darf sich die Applikation 1) an der DB authentifizieren und 2) alles das tun, wofür dieser User Rechte hat.
Letzteres war und ist ein manueller Akt, jemand muss diese Rechte für diesen Application-User vergeben haben. --> mit dem DB-Admin schimpfen, wenn das zu viele Rechte sind.
Wenn diese Daten in Grids präsentiert werden, die per Copy & Paste markiert/kopiert werden können oder gar den Export ins XLS erlauben--> mit den Appz-Entwicklern schimpfen.
Dann muss das weiter eingeschränkt werden.
Wenn sich User DIREKT mit der DB verbinden (können) und das aber eben nicht sein soll: -> allen Usern (außer Admistrativen Usern und Application-Usern) das Recht zum Connect wegnehmen.
Wenn die Application-EndUser die Daten nur sehen dürfen und auch kopieren, aber nienichtaufkeinenFall ändern/bearbeiten/manipulieren:
-> Daten nur als Grafik anbieten oder im PDF-Format mit Wasserzeichen.
Grüße
Biber
da geht gedanklich etwas durcheinander, glaube ich.
Der Webserver ist (lässt man/frau die unnötigen Schnörkel weg) eine Applikation.
Dieser hat sicher auch einen Prozessuser, das heißt eine UserID/Passwort, welches die Endbenutzer nicht kennen müssen oder dürfen.
Mit dieser UserID darf sich die Applikation 1) an der DB authentifizieren und 2) alles das tun, wofür dieser User Rechte hat.
Letzteres war und ist ein manueller Akt, jemand muss diese Rechte für diesen Application-User vergeben haben. --> mit dem DB-Admin schimpfen, wenn das zu viele Rechte sind.
Wenn diese Daten in Grids präsentiert werden, die per Copy & Paste markiert/kopiert werden können oder gar den Export ins XLS erlauben--> mit den Appz-Entwicklern schimpfen.
Dann muss das weiter eingeschränkt werden.
Wenn sich User DIREKT mit der DB verbinden (können) und das aber eben nicht sein soll: -> allen Usern (außer Admistrativen Usern und Application-Usern) das Recht zum Connect wegnehmen.
Wenn die Application-EndUser die Daten nur sehen dürfen und auch kopieren, aber nienichtaufkeinenFall ändern/bearbeiten/manipulieren:
-> Daten nur als Grafik anbieten oder im PDF-Format mit Wasserzeichen.
Grüße
Biber
Erstmal vielen Dank für die schnellen Antworten. Leider komme ich dennoch noch nicht weiter
Ich glaube mein Problem liegt hier:
Bei uns ist es so, dass sich nicht der Web-Server an der DB authentifiziert sondern der Web-Server nur die ADS-Account-Informationen an die DB weitergibt. In der DB hat der ADS Benutzer die entsprechenden Rechte, damit er sich die Daten auf dem Web-Server anschauen kann. Der User soll die Daten aber auch wirklich nur über diesen Weg anschauen dürfen und nicht sich mit Excel zur DB connecten können.
Fritz0609
Ich glaube mein Problem liegt hier:
Der Webserver ist (lässt man/frau die
unnötigen Schnörkel weg) eine
Applikation.
Dieser hat sicher auch einen Prozessuser,
das heißt eine UserID/Passwort, welches
die Endbenutzer nicht kennen müssen oder
dürfen.
Mit dieser UserID darf sich die Applikation
1) an der DB authentifizieren und 2) alles
das tun, wofür dieser User Rechte hat.
Letzteres war und ist ein manueller Akt,
jemand muss diese Rechte für diesen
Application-User vergeben haben. --> mit
dem DB-Admin schimpfen, wenn das zu viele
Rechte sind.
unnötigen Schnörkel weg) eine
Applikation.
Dieser hat sicher auch einen Prozessuser,
das heißt eine UserID/Passwort, welches
die Endbenutzer nicht kennen müssen oder
dürfen.
Mit dieser UserID darf sich die Applikation
1) an der DB authentifizieren und 2) alles
das tun, wofür dieser User Rechte hat.
Letzteres war und ist ein manueller Akt,
jemand muss diese Rechte für diesen
Application-User vergeben haben. --> mit
dem DB-Admin schimpfen, wenn das zu viele
Rechte sind.
Bei uns ist es so, dass sich nicht der Web-Server an der DB authentifiziert sondern der Web-Server nur die ADS-Account-Informationen an die DB weitergibt. In der DB hat der ADS Benutzer die entsprechenden Rechte, damit er sich die Daten auf dem Web-Server anschauen kann. Der User soll die Daten aber auch wirklich nur über diesen Weg anschauen dürfen und nicht sich mit Excel zur DB connecten können.
Fritz0609
Moin Fritz0609,
tja.
Sieh es positiv: wir haben die Ursache lokalisiert.
Und Du kannst in Deiner Firma Potentiale und Verbesserungsmöglichkeiten aufzeigen.
Nein, Schadenfreude beiseite: Wenn die UserInnen "Einzel"-Rechte auf der Datenbank bzw einzelnen Views / Zeilen/Spalten selbst haben müssen oder sollen... okay.
Aber das Recht, sich mit der Datenbank zu connecten --- das brauchen sie nicht.
Nimm es ihnen weg, dann müssen sie über den Webserver. und der bekommt eine ConnectionID/einen ProzessUser.
Alles andere ist doch Augenwischerei - wenn sich jede/r Tabellen-seh-berechtigte UserIn mit einem beliebigen Tool/einem beliebigen Client gegen die DB connecten kann, dann werden natürlich die Daten kopiert, die gesehen werden können.
Und zwar gar nicht, um die meistbietend zu versteigern, sondern weil JEDER die Daten, auf die ein flüchtiger Blick erlaubt war, "sicherheitshalber" als lokale Kopie abspeichert (so genanntes "Schäuble-Syndrom").
Grüße
Biber
tja.
Sieh es positiv: wir haben die Ursache lokalisiert.
Und Du kannst in Deiner Firma Potentiale und Verbesserungsmöglichkeiten aufzeigen.
Nein, Schadenfreude beiseite: Wenn die UserInnen "Einzel"-Rechte auf der Datenbank bzw einzelnen Views / Zeilen/Spalten selbst haben müssen oder sollen... okay.
Aber das Recht, sich mit der Datenbank zu connecten --- das brauchen sie nicht.
Nimm es ihnen weg, dann müssen sie über den Webserver. und der bekommt eine ConnectionID/einen ProzessUser.
Alles andere ist doch Augenwischerei - wenn sich jede/r Tabellen-seh-berechtigte UserIn mit einem beliebigen Tool/einem beliebigen Client gegen die DB connecten kann, dann werden natürlich die Daten kopiert, die gesehen werden können.
Und zwar gar nicht, um die meistbietend zu versteigern, sondern weil JEDER die Daten, auf die ein flüchtiger Blick erlaubt war, "sicherheitshalber" als lokale Kopie abspeichert (so genanntes "Schäuble-Syndrom").
Grüße
Biber
