Re: Benutzerkonzept
From: Olaf Pietsch (olaf_pietsch_at_online.ms)
Date: 02/28/04
- Next message: Philipp Stiefel: "(2003-10-28) Infos fuer Newsgroup-Neulinge"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 28 Feb 2004 17:11:35 +0100
Hallo Andi,
In 220701c3fc4f$bd56bca0$a401280a@phx.gbl, Andi typed:
> Ich habe ein ADP-FE und ein SQL-Server-BE. Jetzt muss ich
> mir überlegen, wie die FE-User auf das BE zugreifen. Ich
> habe gedacht, dass ich das FE auf alle Stationen verteile
> und dann über eine Application Role auf das BE zugreife.
nein, lass das sein, wie es schon Christa geschrieben hat, das ist nichts
für ACCESS.
> Alternativ könnte ich die integrierte Sicherheit
> verwenden, doch dann müsste ich bei jeder Benutzer-
> Mutation auf BE die Rechte anpassen. Das sagt mir
> eigentlich nicht wirklich zu. Meine Fragen: Wie habt Ihr
> das gelöst? Was habt Ihr für Erfahrungen mit erstgenannter
> Version gemacht? Krieg ich da unter Umständen Locking und
> ähnliche Probleme oder läuft das problemlos?
Integrierte Sicherheit ist nach meiner Erfahrung am einfachsten zu
handhaben, denn dann hat man auf Anwendungsebene nicht mit einer
Passwortverwaltung zu tun (Ich habe schon Anwendungen gesehen, da standen
die Passworte unverschlüsselt in einer Tabelle und jeder hatte Berechtigung
auf diese Tabelle). Zusätzlich zu den Berechtigungen der DB-Objekte (SELECT,
INSERT, EXECUTE usw.) wird in der Datenbank des SQL-Servers hinterlegt, wer
darf was innerhalb der Anwendung machen. Alle User die eine Anwendung nutzen
sollen, werden in einer NT-Gruppe, z. B. einer universal group erfasst.
Diese Gruppe wird in die Datenbankrolle der Anwendung eingetragen. Somit
braucht man nur noch die User in die NT-Gruppe einzutragen. Innerhalb der
Anwendungs-DB muss ggf. hinterlegt werden, welcher User hat welches Recht.
Einen User kann man mit z. B. anhand seines Logins mit suser_sname() im
SQL-Server identifizieren.
Aber es gibt aus meiner Sicht einiges zu bedenken. Man kann auf die DB des
SQL-Server von ganz unterschiedlichen Clients zugreifen, im schlimmsten Fall
ein Bügeleisen mit ODBC-Anschluß ;-). Somit muss bei jedem Zugriff der
SQL-Server entscheiden können, ob die Berechtigung besteht und ob die
Geschäftregel (Plausis) eingehalten sind. Eine alleinige Prüfung im Client
ist nicht ausreichend.
Deshalb sollte der User keine Berechtigung auf die eigentlichen Tabellen
erhalten. Der User greift nur per View, SP oder UDF auf die Daten zu, d. h.
nur auf diese Objekte hat die Berechtigung, und es werden ggf. Trigger
eingesetzt. In dieser Zugriffsschicht erfolgen die Prüfungen der
Geschäftsregeln und der Berechtigungen innerhalb der Anwendung.
Greift nun ein fremder Client auf die Datenbank zu, kann er nicht direkt auf
die Tabellen zugreifen, sondern muss die o. g. Objekte für den Datenzugriff
nutzen, somit kann er sich nicht unberechtigten Zugriff verschaffen.
Helge hat aber ein weiteres Problem in diesen Umfeld angesprochen. Den
Client, den Du für die Anwendung mit den notwendigen Benutzerfühungen
erstellst, wird die Geschäftsregeln berücksichtigen, darf nun auch nicht
direkt auf die Tabellen zugreifen. Damit der Client in der Lage ist, in
einem Formular die entsprechende Punkte zu deaktiveren oder aktivieren usw.,
muss er eine Information vom Server erhalten können, was der angemeldete
User machen darf. Dies kann man mit Hilfe einer SP, View oder UDF im Server
realisieren, z. B. indem der Server mittels Bits über die Rechte informiert.
(Dies sollte so gestaltet sein, dass es für nicht eingeweihte nicht
verständlich ist.) Der Client kann damit vollständig aus der Schicht der
Geschäftsregeln der Datenbank des SQL-Server gesteuert werden. Damit kann
der Client auch noch abprüfen, ob seine Version in der Lage ist, mit der
Datenbank zusammen zuarbeiten, d. h. ob eine neue Client Version installiert
werden muss.
Man kann es sich aber auch einfacher machen: Jeder darf direkt auf die
Tabellen der Datenbank zugreifen und alle Prüfungen laufen im Client ab.
Wenn Du das 100%-ig sicherstellen kanst, dass niemand mit einem anderen
Client als Deinem Client auf die Datenbank zugreifen kannst, dann kannst Du
es so machen. Wir können das bei uns im Unternehmen nicht sicherstellen und
betreiben diesen Aufwand.
Gruß Olaf
- Next message: Philipp Stiefel: "(2003-10-28) Infos fuer Newsgroup-Neulinge"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
