Datenbankauthentifizierung für Intranet-Anwendungen

Question

Ich bin auf der Suche nach einer Best Practice für End-to-End-Authentifizierung für interne Web-Anwendungen auf der Datenbank-Ebene.

Das häufigste Szenario, das ich gesehen habe, ist die Verwendung eines einzelnen SQL-Kontos mit den Berechtigungen, die auf die Anforderungen der Anwendung festgelegt sind. Dieses Konto wird von allen Anwendungsaufrufen verwendet. Wenn dann Personen über Abfragetools Zugriff auf die Datenbank benötigen oder eine separate Gruppe mit dem Abfragezugriff erstellt wird, erhalten die Benutzer Zugriff auf diese Gruppe.

Das andere Szenario, das ich gesehen habe, ist die vollständige Windows-Authentifizierung Ende-zu-Ende verwenden. Daher werden die Benutzer selbst zu Gruppen hinzugefügt, die über alle Berechtigungen verfügen, sodass der Benutzer außerhalb der Parameter der Anwendung aktualisieren und ändern kann. Dies beinhaltet normalerweise, dass Benutzer an die entsprechenden gespeicherten Prozeduren gesichert werden, damit sie die Tabellen nicht direkt aktualisieren.

Das erste Szenario scheint relativ einfach zu warten, gibt aber Anlass zu Bedenken, wenn die Sicherheitslücke in der Anwendung besteht und die gesamte Datenbank kompromittiert wird.

Das zweite Szenario scheint sicherer zu sein, hat aber das gegenteilige Problem, zu viel Geschäftslogik in gespeicherten Prozeduren auf der Datenbank zu haben. Dies scheint die Verwendung einiger wirklich cooler Technologien wie Nhibernate und LINQ zu begrenzen. In der heutigen Zeit, in der Menschen Daten auf so viele unterschiedliche Arten verwenden können, sehen wir z.B. Mash-Ups usw. ist dies der beste Ansatz.

Answer 1

Dale - Das ist es genau. Wenn Sie diesen Benutzern Zugriff auf den zugrunde liegenden Datenspeicher gewähren möchten, tun Sie dies über Dienste. Und nach meiner Erfahrung sind es die erfahrenen Computerbenutzer, die aus Uni/College kommen und die Dinge am meisten beschädigen. Wie das Sprichwort sagt, wissen sie gerade genug, um gefährlich zu sein.

Wenn sie einen Teil ihres Jobs automatisieren möchten und sie das erforderliche Wissen anzeigen können, dann geben Sie ihrem Domänenkonto Zugriff auf das Backend. Auf diese Weise ist alles, was sie über ihre kleine VBA-Automatisierung tun, an ihr Konto gebunden und Sie wissen genau, auf wen Sie achten müssen, wenn die Daten abgespritzt werden.

Mein grundlegender Punkt ist, dass die Datenbank der sprichwörtliche Heilige Gral der Anwendung ist. Sie möchten so wenig Finger wie möglich in diesem bestimmten Kuchen.

Als Berater, wenn ich höre, dass jemand normale Benutzer in die Datenbank erlaubt hat, leuchten meine Augen, weil ich weiß, dass es ein großer Gehaltsscheck für mich wird, wenn ich gerufen werde, um es zu beheben.

Answer 2

Persönlich möchte ich normale Endbenutzer in der Datenbank nicht. Für eine Intranetanwendung (insbesondere eine, die in einer Domäne residiert) würde ich einen einzigen Account für den Anwendungszugriff auf die Datenbank bereitstellen, der nur die Rechte hat, die für die Funktion der Anwendung benötigt werden.

Der Zugriff auf die Anwendung würde dann über das Domänenkonto des Benutzers gesteuert (anonymen Zugriff in IIS usw. deaktivieren).

IF ein Benutzer braucht, und rechtfertigen kann, die direkten Zugriff auf die Datenbank, dann ihr Domänenkonto würde Zugriff auf die Datenbank gegeben werden, und sie können das DBMS melden Sie sich die entsprechenden Werkzeuge.

Answer 3

Ich war im vergangenen Jahr für die Entwicklung mehrerer interner Webanwendungen verantwortlich.

Unsere Lösung verwendete Windows-Authentifizierung (Active Directory oder LDAP).

Unser Ziel war lediglich eine einfache Anmeldung mit einer bestehenden Firmenkennung/Passwort zu ermöglichen. Wir wollten auch sicherstellen, dass die vorhandene Abteilung weiterhin für die Überprüfung und Verwaltung der Zugriffsberechtigungen verantwortlich ist.

Während ich das Argument bezüglich Nhibernate oder LINQ nicht beantworten kann, wenn Sie nicht eine spezielle Killer-Funktion haben, können diese Dinge implementieren, Active Directory oder LDAP sind einfach genug zu implementieren und zu pflegen, dass es einen Versuch wert ist.

Answer 4

Stephen - Es ist nett, normale Endbenutzer aus der Datenbank heraus zu halten, aber ich frage mich, ob es heutzutage so viele erfahrene Computerbenutzer gibt, die aus der Universität kommen, wenn dies der richtige Weg ist. Wenn jemand einen Teil seines Jobs automatisieren möchte, der ein VBA-Update auf eine Datenbank enthält, die ich ihm über die normale Anwendung erlaube, verlieren wir dadurch Gewinne, indem wir den Zugriff auf diese Weise einschränken.

Ich denke, der andere hier implizierte Pfad ist, Sie könnten die Anwendung über Dienste öffnen und dann diese Dienste über Gruppen sichern und die Benutzer weiterhin von der Datenbank getrennt halten.

Dann können Sie über die Delegierung Abteilungen erlauben, den Zugriff auf ihre eigenen Konten über die Gruppen gemäß Jonathan's Beitrag zu kontrollieren.

Answer 5

Ich stimme Stephen Wrighton. Domain-Sicherheit ist der Weg zu gehen. Wenn Sie Mashups und was-nicht-verwenden möchten, können Sie Teile der Datenbank über eine maschinenlesbare RESTful-Schnittstelle verfügbar machen. hat eine built in.