[SQL-Server 2008] Benutzerverwaltung aus Anwendungssicht versus Datenbanksicht



  • Ist-Zustand
    Wegen einigen Problemen mit der derzeitigen *hüstel* "Datenbank" Access, werden wir auf den SQL-Server umsteigen. Nun stelle ich mir aber schon einige Fragen, zu denen ich bislang nur recht einseitige Informationen gefunden habe. z.B. wie man am Besten die bisherige Benutzerverwaltung übernimmt, und gleichzeitig aber diese auch auf Datenbankseite berücksichtigen kann...

    Alles was ich in Büchern gefunden habe betrachtet aber entweder nur die DB-Sicherheit oder die Anwendungssicherheit, nicht aber ob man dies gut kombinieren kann, und wenn wie.

    Aus Anwendungssicht gibt es bei uns Benutzer die über Benutzergruppen (Rollen) zu Rechten zugeordnet sind. Bislang liegt dabei jegliche Logik in der Anwendung, z.B. das wenn man bestimmten Datensätze anlegt, auch andere Datensätze angelegt werden müssen. Ebenso wurde bislang damit gelebt, das man die Datenbank mit Access direkt manipulieren konnte. Zum letzten Punkt hatte ich zwar schon seit ich in der Firma tätig bin, meine Kritik geäußert, aber erst mit steigenden Kundenanforderungen wurde dieses Thema nun richtig relevant.

    Soll-Zustand
    Die Umstellung auf den SQL-Server als solches ist für mich nicht das Problem, wohl aber, wie man am besten vorgeht sobald es um Sicherheitsaspekte geht (Ich weiß grob über Login- und Datenbankbenutzer sowie das Rechtesystem vom SQL Server bescheid, nicht aber wie man dies am besten mit der Anwendung kombiniert).

    Grundsätzlich existieren schon folgende groben Vorstellungen:
    a) Die grundlegenden datenorientierten Aktionen (CRUD) sollen mit STPs abgebildet werden (auch weil diese von Kunden, schon wegen einer Anbindung an ein Fremdsystem, angefragt wurden sind).
    b) Die Zugriffe auf die STPs/Tabellen/Sichten etc. soll gesichert sein.
    c) Die angemeldeten Benutzer soll man abfragen können (Wobei gewisse Verzögerungen bei der Abmeldung akzeptiert werden).
    d) Die Anwendungsrechte könnten zumindest in kleinen Teilen auch für die STPs relevant sein.

    Ich weiß aus meiner letzten Firma noch, das sich dort die Anwendung über einen festen Loginbenutzer an der Datenbank angemeldet hatte, dieser Login aber selbst nur sehr eingeschränkte Rechte bekam, wie z.B. den Zugriff auf eine Login-STP. Letzteres hört sich für mich durchaus sinnvoll an, weil man damit vermutlich eine Kombination zwischen den Datenbank-Benutzern und den Anwendungsbenutzern realisieren könnte.

    Ist dies ein üblicher Weg, bzw. gibt es Lektüre wo solche Möglichkeiten oder Alternativen beschrieben sind (Also wie man am sinnvollsten die Benutzerverwaltung der Anwendung und das Rechtesystem der Datenbank kombinieren kann, ohne blind nur den Standpunkt des Anwendungsentwicklers versus des DBAs zu betrachten)?

    Wie genau ist die Abfragemöglichkeit der angemeldeten Benutzer bei der Datenbank?

    Zusätzlich würde mich mal interessieren, wie die Verbindung des Loginbenutzers und der Datenbank geregelt wird, im Zusammenhang mit Datensicherung und Wiederherstellung? (Sprich: Was ist wenn man eine DB ankoppelt, an einer Instanz, die von dem Login nichts weiß - wie kann man dann diese Verbindung herstellen?).



  • Wie sieht denn die Client-Applikation aus? Bleibt die weiterhin MS Access? Quasi Access als MSSQL-Frontend? Das spielt hier auch eine Rolle.

    MfG SideWinder



  • SideWinder schrieb:

    Wie sieht denn die Client-Applikation aus? Bleibt die weiterhin MS Access?

    Die Clientanwendung ist nicht auf Basis von Access (Derzeit ein C++ Builder Programm, hier könnte aber auf langer Sicht wegen einer Webschnittstelle etwas anderes hinzukommen bzw. langfristig ganz ersetzten).


Anmelden zum Antworten