Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Anmeldungen aus dem SQL-Server als Sicht / View?
zurück: Daten im Hintergrund nachladen weiter: Gute Adresssuche / Alternativsuche / Neuerstellung Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Offen Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
stefaktiv
Im Profil kannst Du frei den Rang ändern


Verfasst am:
12. Sep 2013, 22:19
Rufname:

Anmeldungen aus dem SQL-Server als Sicht / View? - Anmeldungen aus dem SQL-Server als Sicht / View?

Nach oben
       Version: Office 2013

Hallo,

bzgl. des allgemeinen Umgebungsszenario meiner Datenbank folgender Link: Daten im Hintergrund nachladen

Bisher habe ich das Thema "Benutzer" noch nicht direkt mit Anmeldungen am SQL-Server abgebildet, sondern eine Tabelle mit Benutzern und ihren Rechten angelegt. Die Kennwörter sind natürlich verschlüsselt - bei der Datenbankanmeldung wird eine Dropdownliste der verfügbaren Nutzer angezeigt. Zusätzlich muss die Eingabe des Kennwortes erfolgen - der Hash wird mit dem in der Datenbank abgeglichen.

Die Rechte des Nutzers habe ich in der Form abgebildet, dass hinter dem Hauptmenü des Access-Frontend eine Sicht / ein View mit dem jeweiligen Datensatz liegt (ReadOnly). Die Ansicht der Menüs richtet sich nach diesen Berechtigungen. Das Hauptmenü bleibt immer im Hintergrund offen. Die Anbindung erfolgt mittels DAO-Einbindung als Tabelle über einen allgemein eingerichteten Datenbankbenutzer (nicht sa-Konto).

Diese Umsetzung ist natürlich hemdsärmlig und funktioniert nur deswegen, weil die Nutzergruppe überschaubar und zu 100% vertrauenswürdig ist. Da macht keiner was kaputt oder probiert rum, wie man die Sicherheit überwinden könnte.

Richtiger wäre aber sicherlich, wenn man das ganze mit Anmeldungen direkt am SQL-Server umsetzen würde.

Dazu wäre aber meine Frage, ob es auch möglich ist, eigene Rechte in diese Anmeldung mit einzubringen. Also z.B. haben Nutzer das Recht "Newsletterversand" und bekommen mit diesem Wert einen Reiter angezeigt, den andere Nutzer nicht sehen.

Es müsste jetzt natürlich die Möglichkeit geben, das auch beim SQL-Server entsprechend in der Anmeldung abzubilden. Hierzu habe ich in den "Erweiterten Eigenschaften" die Möglichkeit gefunden, eigene Werte zu definieren.

Kann man das auch von Access aus?

Und können diese Werte auch in Form einer View dargestellt werden?

Kann man irgendwie das Dropdownmenü vor der ersten Anmeldung darstellen, in dem dann nur die verfügbaren Nutzernamen angezeigt werden? Oder müssen die Nutzer immer bei der Anmeldung die vollständigen Nutzernamen eingeben?

Grüße

Stefan
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
16. Sep 2013, 07:54
Rufname:


AW: Anmeldungen aus dem SQL-Server als Sicht / View? - AW: Anmeldungen aus dem SQL-Server als Sicht / View?

Nach oben
       Version: Office 2013

Hallo Stefan,

wenn Du schon vom Thema Sicherheit sprichst, dann solltest Du als erstes das Dropdown-Menü mit den verfügbaren Nutzern abschaffen. Jeder Nutzer sollte seinen Usernamen und das Kennwort immer vollständig eingeben müssen. Wenn es etwa um das Thema Hacker geht, machst Du es einem Hacker sehr viel leichter, wenn er den Loginnamen bereits kennt und möglicherweise sogar ein paar Details zu der betreffenden Person, dann ist oft auch ein Kennwort leicht zu erraten.

Vielleicht hilft Dir das hier als Ansatz schon mal weiter: Sicherheit mit Stored Procedures

Hier wird gezeigt, wie Du erweiterte Eigenschaften als View anzeigen lassen kannst: fn_listextendedproperty (Transact-SQL)

Und allgemein noch mehr dazu hier: Verwenden von erweiterten Eigenschaften für Datenbankobjekte

Ich würde an Deiner Stelle allerdings besser hingehen und die Rechte über eigene Tabellen verwalten, dann hast Du ein einheitliches Konstrukt, in dem Du leicht Änderungen durchführen kannst. Bei den erweiterten Eigenschaften mußt Du ständig in die einzelnen Objekte hineinschauen, um deren Einstellung herauszufinden.

Gruß

Christian
stefaktiv
Im Profil kannst Du frei den Rang ändern


Verfasst am:
17. Sep 2013, 21:16
Rufname:

AW: Anmeldungen aus dem SQL-Server als Sicht / View? - AW: Anmeldungen aus dem SQL-Server als Sicht / View?

Nach oben
       Version: Office 2013

Hallo Christian,

Danke schon einmal für die Antwort und die sehr ausführlichen Links. Deinen Text in dem anderen Zusammenhang muss ich mir mal in Ruhe zu Gemüte führen... ist doch recht lang.

Als technischen Hintergrund vielleicht noch, dass der Zugriff auf die Datenbank nur über das VPN innerhalb des Intranets zugelassen ist. Nach außen hin ist da die Hardwarefirewall des Routers und dann noch die Softwarefirewall des Servers dazwischen.

Da die Nutzer sich untereinander alle kennen und die Anmeldung einfach nur Vor- und Zuname ist, wäre es eher eine hypothetische Sicherheitsvorkehrung, wenn man den kompletten Nutzernamen eintippen lässt.

Man müsste halt einen Dummy-User einrichten, der nur diese eine Tabelle mit den Benutzernamen anzeigen darf. Diese Tabelle ist mit der Datenbank verknüpft. Alle restlichen Rechte zieht er dann nach der Anmeldung nach.

Wenn ich mir die Lösung von Microsoft so durchlese, dann ist das aber wohl eher nicht so gedacht, dass man die Nutzerrechte als Erweiterte Eigenschaften verwaltet. Wobei mich wundert, dass man Rechte nicht standardmäßig im SQL-Server definieren, verwalten und darauf zugreifen kann. Eigentlich braucht man das doch immer bei der Arbeit mit einer komplexeren Datenbank mit vielen Nutzern, oder?

Grüße

Stefan
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
17. Sep 2013, 23:41
Rufname:

AW: Anmeldungen aus dem SQL-Server als Sicht / View? - AW: Anmeldungen aus dem SQL-Server als Sicht / View?

Nach oben
       Version: Office 2013

Hallo,

das mußt Du letztlich selbst wissen, ist halt so Standard, Benutzernamen niemals in einer Dropdown-Liste beim Login anzuzeigen.

Wer sagt, daß man Rechte nicht standardmäßig verwalten kann? Du kannst zu jedem Objekt die Rechte einzeln definieren, je nach Einstellung sogar bis runter auf Datensatzebene (was aber nur für sehr spezielle Anwendungen sinnvoll ist).

Wenn man vollen Zugriff auf die Loginverwaltung hat (nur für Systemadmins auf SQL Server möglich), kann man z.B. jedem Benutzer einen SQL Server Login verpassen oder in dem alternativen und sichereren Modell einfach den Windows Login verwenden, dann brauchst Du nicht einmal einen Anmeldebildschirm, die Windows-Anmeldung des Users ist dann bereits der Sicherheitsschlüssel.

Gruß

Christian
stefaktiv
Im Profil kannst Du frei den Rang ändern


Verfasst am:
20. Sep 2013, 09:50
Rufname:

AW: Anmeldungen aus dem SQL-Server als Sicht / View? - AW: Anmeldungen aus dem SQL-Server als Sicht / View?

Nach oben
       Version: Office 2013

Also das mit der Windowsanmeldung hab ich mir auch überlegt - es scheitert aber daran, dass die Nutzer mit ganz unterschiedlichen Rechnerkonstellationen auf die Datenbank zugreifen.

Dazu muss man sagen, dass immer zwischen 2 bis 3 Hauptamtlichen Mitarbeitern die Datenbank hauptsächlich nutzen. Bei Computerproblemen ggf. aber auch mit wechselnden PCs. Eine Active Directory o.ä. gibt es nicht.

Hinzu kommen dann noch vielleicht 6 ehrenamtliche Mitarbeiter, die eben über VPN auf die Datenbank zugreifen, deren PCs aber ganz unterschiedlich sind.

Die grundsätzliche Fragestellung der Rechteverwaltung ist auch weniger die Beschränkung des Zugriffs auf einzelne Tabellen, sondern vielmehr die Funktionen meiner Access-Datenbank selbst.

Es gibt z.B. das Benutzerrecht "Newsletterversand", das steuert, ob ein Benutzer den Reiter "Newsletterversand" angezeigt bekommt. Bisher gibt es eben in der Tabelle "Benutzer" auf dem Server ein Feld mit Bool-Wert für den Newsletterversand.

Meine Frage wäre aber, ob man genau diesen Wert auch in der Anmeldung unter "Erweiterte Eigenschaften" hinterlegen kann. Falls ja - wie genau schreibe und lese ich diese Wert mit Access. Einigermaßen schnell sollte das auch gehen - bisher werden die Rechte im Hintergrund beim Laden der Datenbank mit dem Hauptmenü mitgeladen.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
20. Sep 2013, 11:00
Rufname:

AW: Anmeldungen aus dem SQL-Server als Sicht / View? - AW: Anmeldungen aus dem SQL-Server als Sicht / View?

Nach oben
       Version: Office 2013

Hallo Stefan,

ohne Domäne scheidet die Windows-Anmeldung grundsätzlich aus. Das funktioniert nur, wenn die Anmeldung per Domäne geregelgt wird (und daher ist der verwendete Rechner in dem Fall auch völlig egal, da ein Domänenaccount auf jedem Rechner der Domäne verwendet werden kann).

Heißt: Du müßtest in dem Fall mit den SQL Server Logins arbeiten, also für jeden Benutzer Deiner Datenbank einen Login anlegen und diesem entsprechende Rechte auf die Datenbankobjekte vergeben. Oder besser: Man legt Datenbankrollen an und weist die Rechte den Datenbankrollen zu, dann werden die Benutzer zu den gewünschten Datenbankrollen verlinkt. Das sollte natürlich in einem vernünftigen Rahmen geschehen, man würde also nicht gerade ein granulares Recht wie "Darf Newsletter versenden" als ganze Rolle definieren, da es auf SQL Server Ebene eher darum geht, welche Datenbankobjekte wie genutzt werden dürfen. Beispiel für eine Rolle wäre, wenn User direkt per Excel Reporte aus der Datenbank ziehen können sollen, dann würde man eine Rolle für Excel-Reporte anlegen, die dann alle Objekte verbietet, an die ein Excel-User nicht gelangen soll, etwa grundsätzlich alle Tabellen und von den Views nur die, die im Schema z.B. "Excel" sind und auch diese nur als Read-Only.

Geht es um die granularen Rechte, mache ich persönlich das so, daß ich eine Tabelle von Objekten und -typen verwalte, die eine Rechteeinstellung erfordern. Beispiele wären Typ "Formular" und Objekt "frmKunden". Dazu eine Tabelle von möglichen Rechten wie etwa "Lesen", "Schreiben". Dann wieder eine Tabelle, die Rechtegruppen definiert (damit man die Rechte nicht einzeln je User zuweisen muß) und die Zuordnungstabellen zwischen Usern, Gruppen und Rechten.

Wenn nun etwa ein Newsletter verschickt werden soll, dann ist das eine Aufgabe für eine Stored Procedure. Die Stored Procedure kann anhand des SQL Server Logins testen, um welchen User es sich handelt und dann anhand der oben beschriebenen Rechte- und Objekte-Tabellen feststellen, ob der Login-User in einer Gruppe enthalten ist, die das Recht hat, Newsletter zu versenden, da wäre das Objekt der Name der SP, die den Newsletterversand vornimmt und das Recht "Execute". Hat der User das Recht "Execute" auf diese SP, kann diese nun fortfahren und die Daten zusammenstellen und (je nach Konfiguration) entweder gleich selbst über SQL Server Maildienste verschicken oder, wenn das besser das Frontend machen soll, den erstellten Newsletter zurückschicken und dem Frontend den Versand überlassen. Hat der User nicht das Recht, wird ein Fehlerwert in der Return-Variablen zurückgeschickt, den das Frontend auswerten kann und so feststellen kann, daß der Newsletter aufgrund von mangelnden Rechten nicht verschickt werden konnte, was das Frontend dann dem User melden kann.
So liegt die Logik immer komplett auf dem Server und das Frontend schickt nur eine Anforderung und gibt das Ergebnis zurück.

Im Fall von Frontendobjekten wie Formularen oder Buttons oder sonstigen Controls kann das Frontend eine SP aufrufen, die anhand des Login-Users feststellt, welche Objekte des Frontends für diesen User auf welche Rechte eingestellt sind und speichert das Ergebnis z.B. in einer Collection eines Datenklassenmoduls. Nun kann zum Beispiel in "Form_Open" eines Formulars auf diese Datenklasse zugegriffen werden und nachgesehen werden, ob der User das Recht hat, dieses Formular zu öffnen oder ob er Daten schreiben oder lesen können soll und kann das Formular entweder nicht öffnen ("Cancel=True" in Form_Open) oder entsprechend vorbereiten, also etwa AllowAdditions abschalten usw.
Danach kann das Formular die Collection der Objekte weiter durchlaufen und anhand der Objektnamen herausfinden, welche Controls zum Beispiel auf Disabled oder unsichtbar gestellt werden müssen und so das Formular komplett vorbereiten, passend zu den Userrechten.

Das praktische an SQL Server Logins ist, daß man damit auch SQL Server User erstellen kann, die nicht das Recht haben, sich anzumelden. Das sind also quasi "Backend-User", die sich aber nie, auch nicht am SQL Server Management Studio o.ä., am SQL Server anmelden können. Über diese User kann man die Rechteverwaltung regeln, d.h., hier kann man etwa einen User anlegen, der alle Rechte auf der Datenbank hat (diese aber theoretisch nie nutzen kann, weil er sich ja nicht anmelden kann, also keine Gefahr "von außen"). Der User, der sich mit seinem normalen Login anmeldet, bekommt nur die "Public"-Rolle zugewiesen und hat damit sozusagen nur Gast-Zugang. Die SP, die man aufruft, kann aber nun mit Ausführungsrechten dieses Spezial-Users ausgeführt werden, so daß ein normaler Login-User zwar diese SP ausführen kann, selbst aber keine Rechte an den weiteren Objekten wie etwa den Tabellen hat, dagegen die ausgeführte SP aber durch den Spezial-User die Möglichkeit hat, mit den Objekten arbeiten zu können, auf die der Login-User selbst keine Rechte hat.
Schade ist lediglich, daß Access hier nicht mitspielt, wenn man gebundene Formulare verwendet, da Access in dem Fall immer mit direkten Änderungsbefehlen auf die Tabellen zugreifen möchte, was mit dem Sicherheitsmodell nicht so recht funktioniert. Ist 'ne ziemliche Fummelei, da einen Weg dazwischen zu finden, sozusagen "halb-sauber".

Mit ungebundenen Formularen ist es kein Problem, da man hier das Speichern/Ändern/Löschen für jedes Formular über eine entsprechende SP regelt und dann wieder das o.g. Sicherheitsmodell verwenden kann - dafür hat man allerdings auch einen deutlich höheren Programmieraufwand, da viele Automatismen von Access nicht mehr verwendbar sind. Auf der anderen Seite hat es den weiteren Vorteil, daß die ungebundenen Formulare keine 100%-Verbindung zum Backend mehr erfordern, da nur auf Anforderung Daten hin und her gehen, also kein Problem für Laptop-Benutzer, vom Meetingraum aus ins Büro zu gehen und zwischendurch kein Netzwerk gehabt zu haben, was bei einem gebundenen Formular zu Problemen führt.

Frage wäre natürlich auch, warum Ihr eigentlich keine Domäne aufsetzt, in einer Unternehmensumgebung würde ich das mal als Minimal-Sicherheitsmodell ansehen.

Gruß

Christian
stefaktiv
Im Profil kannst Du frei den Rang ändern


Verfasst am:
20. Sep 2013, 20:00
Rufname:


AW: Anmeldungen aus dem SQL-Server als Sicht / View? - AW: Anmeldungen aus dem SQL-Server als Sicht / View?

Nach oben
       Version: Office 2013

Hallo Christian,

Danke erst mal für die ausführliche Antwort. Da kann ich mir glaube ich schon einige Anregungen rausziehen. Die Tabelle mit den Nutzerrechten hab ich an sich ja schon - nur muss man tatsächlich bei jedem Nutzer jedes Recht einzeln eintragen. Eine Art Gruppenfunktion gibt es nicht - aufgrund der sehr geringen Benutzerzahl ist das aber auch nicht das größte Problem.

Das mit der Domäne geht aus den beschriebenen Gründen nicht, weil die ehrenamtlichen Mitarbeiter ja das Frontend auf ihren Privatrechnern haben. Zudem ist es natürlich auch eine Kostenfrage - so ein Windows Server ist ja nicht gerade billig und irgendwas mit Linux zu machen ist viel zu aufwendig. An sich mache ich die ganze Arbeit auch halb ehrenamtlich - also da ist so ein Projekt einfach nicht drin.

Bei den Funktionen selbst ist es mir immer das liebste, dass der Benutzer Dinge gar nicht sieht, die er eh nicht darf. Sonst füllt er lieb gemeint einen Newsletter aus und bekommt dann den Hinweis, dass er den gar nicht verschicken kann.

Worüber ich bei deiner Aufzählung gestolpert bin, ist der Begriff "Collection eines Datenklassenmoduls". Obwohl ich jetzt doch schon ne Zeit lang mit Access programmiere sagt mir das gar nichts. Aber es klingt interessant - da muss ich mich mal einlesen. Ich hab nämlich durchaus das Problem mit der Parameterübergabe an Unterformulare. Im Gegensatz zu normalen Formularen gibt es da ja keine gute Möglichkeit zur Parameterübergabe mit OpenArgs. Zumal mir die Lösungen mit OpenArgs auch nicht so toll gefallen. Bis dato habe ich halt viele Variablen mit "Public" deklariert. Ne bessere Lösung wäre da herzlich willkommen.

Zu den Stored Procedures muss ich sagen, dass ich das Thema jetzt mehrere Jahre vor mir hergeschoben habe und lieber neue Funktionen in die Datenbank eingebaut habe. Es ging immer und vor allem konnte das Büro des Jugendverbandes so schnell besser arbeiten. Aber jetzt merke ich doch deutlich die Grenzen in punkto Performance.

Die ersten Formulare hab ich schon umgestellt - wenn ich die komplette Datenbank umarbeiten muss, dann wird das eine Schweinearbeit. Aber zumindest von Seiten der Geschwindigkeit scheint es sich auszuzahlen...

Grüße

Stefan
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Diese Seite Freunden empfehlen

Seite 1 von 1
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Microsoft Access und MS SQL Server: Access 2010 und SQLServer 2012 6 scheuersim 234 05. März 2014, 11:49
scheuersim Access 2010 und SQLServer 2012
Keine neuen Beiträge Microsoft Access und MS SQL Server: Unterabfrage auf eine SQL-Server Tabelle 0 Mike_d 311 10. Sep 2013, 16:34
Mike_d Unterabfrage auf eine SQL-Server Tabelle
Keine neuen Beiträge Microsoft Access und MS SQL Server: Filtermöglichkeit von view bei der Einbindung? 1 peeka 295 02. Sep 2013, 21:52
MAPWARE Filtermöglichkeit von view bei der Einbindung?
Keine neuen Beiträge Microsoft Access und MS SQL Server: Updatefähiges View 3 RoKz 422 24. Jul 2013, 11:27
Bitsqueezer Updatefähiges View
Keine neuen Beiträge Microsoft Access und MS SQL Server: Problem mit View 0 trekking 297 26. März 2013, 22:32
trekking Problem mit View
Keine neuen Beiträge Microsoft Access und MS SQL Server: Diagramm wird in anderer Sortierung angezeigt als View 1 hneuse 305 14. Jan 2013, 18:48
mikael Diagramm wird in anderer Sortierung angezeigt als View
Keine neuen Beiträge Microsoft Access und andere Datenbank-Server: lokale Access Datenbank mit SQL-Server synchronisieren 1 CaIngca 2621 21. Aug 2011, 20:17
Gast lokale Access Datenbank mit SQL-Server synchronisieren
Keine neuen Beiträge Microsoft Access und MS SQL Server: linked Server zu ms-acc 2000 aus sql-server 2005 express 12 Teodor 3435 13. Apr 2010, 08:48
Teodor linked Server zu ms-acc 2000 aus sql-server 2005 express
Keine neuen Beiträge Microsoft Access und MS SQL Server: Bug in View?? 5 Homer J. Simpson 1392 07. Dez 2009, 17:21
Stephan T. Bug in View??
Keine neuen Beiträge Microsoft Access und MS SQL Server: MS SQL View: wie zwei Felder aneinander hängen? 1 Gast 2715 01. Okt 2009, 13:01
Bitsqueezer MS SQL View: wie zwei Felder aneinander hängen?
Keine neuen Beiträge Microsoft Access und MS SQL Server: Arbeiten mit .seek Eigenschaft auf SQL-Server 2 Demiurge 2213 01. Jul 2008, 15:52
Demiurge Arbeiten mit .seek Eigenschaft auf SQL-Server
Keine neuen Beiträge Microsoft Access und MS SQL Server: von mdb auf View (SQL-Server) zugreifen 5 StefanWW 3634 20. Feb 2008, 14:47
--Gast-- von mdb auf View (SQL-Server) zugreifen
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: Access Tabellen