Datenbankrechte SQLServer mit sp_setapprole

[dbfreak]

Hallo alle zusammen,

Ich finde theoretisch die Anwendung von Applikationsrollen sehr gut. Der Anwender könnte so die Plausibilität der Applikation nicht durch direkte Datenbankzugriffe (z.B. über ODBC) umgehen. Allerdings habe ich keine Idee, wann ich diese Rolle mit sp_setapprole zuweisen könnte, da die DB-Verbindung ja automatisch aufgebaut und beendet wird. Es erolgt ja kein explizites Open/Close.

Beispiel:

    
        Dim con As DbConnection = New SqlConnection(globfunction.constr)
        Dim dt As New DataTable
        Dim da As DbDataAdapter = New SqlDataAdapter
        Dim sqlstring As String
        Dim cmd As DbCommand = New SqlCommand
sqlstring = "select [MenueName],[Projekt_Kunde] from TKonfigMenue "

            cmd.CommandText = sqlstring
            da.SelectCommand = cmd
            da.Fill(dt)

Sehe ich das richtig, oder gibt es eine Möglichkeit eine Rollenzuweisung dazwischen zu schieben oder dem Connect-Objekt zuzuweisen? Als Alternative sehe ich sonst eine Grant/Revoke einer Datenbankrolle zur Laufzeit durch einen "hinterlegten Admin".

[dbfreak]

Hallo alle zusammen,

mit soviel Antwort hatte ich gar nicht gerechnet. War meine Frage zu einfach oder gibt es wirklich keine Meinung dazu? Vielleicht sollte ich diese Frage auch unter dem Forum ->Datenbank stellen. Bitte, wenn jemand einen Tip hat, dann lasst es mich wissen.

[tinof]

Also ich arbeite mit Datenbankrollen, was aber grundsätzlich auch zu deiner Frage passt.

Ich verstehe nicht, warum du die Rollen zur Laufzeit zuordnen willst/mußt.

Bei uns sind alle Benutzer 'ihren' entsprechenden Datenbankrollen auf dem Server zugeordnet. Diese Zuordnung geschieht über ein separates Frontend, auf das nur die Admins Zugriff haben. Jedenfalls ist sie statisch.
Wenn sich einer anmeldet, dann ist sofort klar, was er darf und was nicht.

In dem Moment, wo jeder Nutzer beim Anmelden am Server bereits soviel Rechte hat, dass der seine eigene Rollenzugehörigkeit selber ändern kann (so verstehe ich deine Frage), kann er im Prinzip schon das ganze System aushebeln.

Grüße
Tno

[dbfreak]

Hallo tinof,

vielen Dank erstmal für Deine Antwort.
1. hast Du grundsätzlich recht.
Ich möchte lediglich verhindern, dass ein Nutzer an der Applikation vorbei versucht, Daten zu ändern. Damit würde er Plausibilitäten der Anwendung außer Kraft setzen. Da seine Anmeldeinformationen für die SQL-DB ja transparent sind, würde das gehen. In Oracle kannst Du das ausbremsen. Da werden (definierte) Befehle z.B. nur ausgeführt, wenn Sie von einer zugelassenen Applikation kommen. Du weißt doch, mit Microsoft (Access, Excel und Co) steht die Welt offen.
Wenn ich die zweite Variante wähle - sprich Grant bei Anmeldung und Revoke bei Abmeldung - würde ich einen Systemuser (den nur ich bzw. ein Admin mit Anmeldeinformation kennt) in der Applikation verschlüsseln. Ähnlich funktionieren letztendlich auch die Applikationsrollen des SQLservers. Da wird das Passwort auch hart in der Applikation hinterlegt. Das ist eigentlich auch nicht wirklich schick.

[tinof]

In Oracle kannst Du das ausbremsen. Da werden (definierte) Befehle z.B. nur ausgeführt, wenn Sie von einer zugelassenen Applikation kommen.

Achso, wenn ich mich 'einfach so' anmelde, dann darf ich vielleicht nur gerade mal ein SELECT.

Wenn ich aber mit der gleichen Anmeldung aus der Applikation heraus komme, dann hab' ich 'vollzugriff'.

Anwendungsrollen funktionieren in beiden Authentifizierungsmodi, werden über sp_setapprole aktiviert und benötigen ein Kennwort

Hm, ich lese das so, dass du einfach in der laufenden Session (irgendwannd) sp_setapprole() ausführst und dich dadurch authentifizierst. So wie beim Login an einem unbekannten System. Klappt die Anmeldung, arbeitest du fortan mit den approle- Rechten.
Beim Logout muss da auch nichts zurückgesetzt werden.

Soweit die Theorie...

Gute Idee, hab' ich auch noch nicht so gründlich durchforstet, deshalb kann ich auch keine Lösungsvorschläge bringen.

Viel Erfolg!
Tino

[dbfreak]

Ja, so habe ich mir das gedacht. Eine weitere Variante (aber letztendlich gleicher Weg), ist die Anmeldung des Users nur zur Laufzeit der Applikation zu aktivieren und mit dem Schließen diese wieder zu deaktivieren.

So oder so, man muss in der Applikation oder an einem sehr versteckten Ort ein Passwort für einen authorisierten User vorhalten.