Ist es jemals ratsam, für jeden Benutzer einer Anwendung ein eigenes Datenbankkonto zu verwenden?

Die Anwendungen, die ich bisher verwendet habe, sind serverbasiert und verwenden ein Datenbankkonto für viele Benutzer. Der Anwendungscode steuert, was der Benutzer tun kann, oder Einzelbenutzer.

Gibt es erfolgreiche komplexe Geschäftsanwendungen, für die jede Person ihr eigenes Datenbankkonto benötigt und auf die der Datenbankserver angewiesen ist, um Richtlinienregeln zu erzwingen, die festlegen, was jeder Benutzer darf und was nicht?

Ich denke an Anwendungen, bei denen mehrere Personen zu Informationen in einer Datenbank beitragen und auf Informationen zugreifen können, die von anderen Personen gespeichert wurden - z. B. Kollegen in einer Organisation, die alle auf Kundendatensätze zugreifen müssen.

Gibt es auch einen Namen für diese Art der Einrichtung?

Wenn Sie eine wirklich strenge Kontrolle auf Datenebene benötigen. Zum Beispiel umfangreiche Audits. Die Überwachung ist nicht besonders gut, wenn mehrere Benutzer dasselbe Konto verwenden. Wenn Sie Benutzer haben, die direkt auf die Datendatenbank zugreifen müssen.

Wenn die Sicherheit so streng ist, wird die Datenbank in der Regel nicht einmal direkt verfügbar gemacht. Sie haben einen Dienst und der Client muss Daten vom Dienst erhalten.

In einer Webanwendung wird die Datenbank (z. B. Port 1433) normalerweise nicht direkt verfügbar gemacht, sodass Sie über eine bestimmte Sicherheitsstufe verfügen. Auch wenn die Webanwendung direkt auf die Datenbank zugreift, haben die Benutzer immer noch keinen direkten Zugriff Zugriff auf die Datenbank.

Wenn sich Login und Passwort in der Client-Anwendung befinden, kann es gehackt werden. Bei einer Domain können Sie integrierte Sicherheit verwenden.

In der Datenbank können Sie ziemlich feine Kontrollen haben. Aber die Kontrolle auf Zeilenebene ist ein bisschen Arbeit. Eine Datenbank ist kein gutes Werkzeug für Geschäftsregeln. Geschäftsregeln und detaillierte Sicherheit werden normalerweise auf Anwendungsebene durchgesetzt.

Sie können einen gemischten Modus verwenden, in dem einige gespeicherte Prozeduren von Administratoren verwendet werden und Sie nachverfolgen möchten, welcher Administrator angemeldet ist. Außerdem können Sie Benutzern, die einen Bericht direkt erstellen, Lesezugriff gewähren.

Die Herausforderung hierbei ist, dass Ihr Datenbankzugriff von einer Abstraktion verwaltet wird. Anstatt sich als Benutzer zu verbinden, übernehmen sie im Wesentlichen die Identität einer allgemeinen Anwendungsrolle. Sie verlieren nicht nur die Sichtbarkeit der einzelnen Verbindungen, sondern auch die Genauigkeit der Definition verschiedener Zugriffsarten für alle Ihre einzelnen Benutzer.

Der Hauptgrund für die Verwendung dieses Ansatzes ist die Einfachheit. Viele Anwendungen sind so konzipiert, dass der Benutzer der Anwendung keine Kenntnisse über die Datenbank hat. Sie brauchen es wirklich nicht, besonders wenn die Anwendung ihre eigene interne Sicherheit verwaltet. Die meisten einzelnen Benutzer stellen niemals eine direkte Verbindung zur Datenbank her. Daher ist es nicht erforderlich, eine explizite Anmeldung für sie zu definieren.

Sie sollten nur in Betracht ziehen, die Datenbank Ihre Sicherheit verwalten zu lassen, wenn Benutzer eine direkte Verbindung zu Ihrer Datenbank herstellen. Dies bedeutet, dass sie Ihre Anwendung umgehen und die Sicherheit nicht mehr allein erzwingen können. Der Vorteil hierbei ist, dass Sie Ihre Sicherheit genauer definieren können. Der Nachteil ist der höhere Aufwand für die Verwaltung der Benutzer und ihrer Berechtigungen.

Wenn Sie diese Art von Zugriff benötigen, möchten Sie die rollenbasierte Zugriffssteuerung verwenden . Sie sollten Rollen basierend auf den Berechtigungen definieren, die in Ihrer Datenbank benötigt werden, und dann einzelne Benutzer unter diesen Rollen gruppieren. Dies gibt Ihnen eine bessere Überwachung und Kontrolle über Ihr Sicherheitsmodell, das bei der Verwaltung des direkten Zugriffs schnell außer Kontrolle geraten kann.

Hierfür gibt es einen hybriden Ansatz. Wenn Sie möchten, dass Ihre Sicherheit teilweise von der Datenbank geändert wird, können Sie mehrere Anwendungsbenutzer erstellen, die jeweils durch ihre Rolle definiert sind, und diesen Benutzern basierend auf der Rolle, die sie erfüllen, explizit Zugriff gewähren. Dies bedeutet, dass Sie die Datenbank-Engine für einige Ihrer Sicherheitsmodelle nutzen können, die Anwendung jedoch noch verwaltet werden muss. Dies erhöht die Komplexität des Anwendungsbenutzermodells, gibt Ihnen jedoch eine genauere Übersicht über die verschiedenen verwendeten Anmeldungen.

Sie sollten so bald wie möglich mit der Durchsetzung der Sicherheit auf höchstem Niveau beginnen. Rollen helfen in dieser Hinsicht - es ist kein Albtraum, Menschen Zugang zu mehreren Tischen auf einmal zu verschaffen.

Der einzelne Account für alle ist eine gute Quelle für Fragen hier und anderswo - "Datensatz x wurde gelöscht, wie finde ich heraus, wer es getan hat?" - Die Antwort lautet, Sie können nicht - ohne individuelle Konten und Prüfung .

Mit "Auditing" meine ich, dass es zwar sehr gut ist, einen Account für alle zu haben, aber nicht bedeutet, dass Sie echte Sicherheit haben. Wenn beispielsweise ein Datensatz in der HR-Tabelle gelöscht wird, können Sie nur sagen, dass jemand mit Zugriff auf die HR-Tabelle dies getan hat - das sind x Personen.

Sie benötigen Trigger in Ihrem System, die Aktionen protokollieren, um auf die jeweilige Ebene zu gelangen, die die Aktion X ausgeführt hat (es sei denn, Sie verfügen über ein RDBMS wie Oracle, bei dem dies automatisch erfolgen kann).

In jedem Fall sollten Sie Ihre Sicherheit so schnell wie möglich so detailliert wie möglich gestalten. Geben Sie den Benutzern nur dann Zugriff auf Tabellen, wenn Sie dies wissen müssen. Fügen Sie außerdem immer Zeitstempel für Aktionen in Tabellen ein - die Leute geben ihre IDs häufig an andere weiter -, wenn Sie sagen können: "Jimmy, Sie waren um 17:49 Uhr der einzige im Büro ..." - auch hier ist es nicht schlampig Ein weiterer Pfeil in deinem Köcher.

Vielleicht könnten Sie, wenn Sie uns Ihr RDBMS geben, einen Rat einholen, der spezifischer / relevant für Ihre Situation ist?

Ja ist es. Das Herstellen einer Verbindung zu einer Datenbank von einer Anwendung aus als ein einziger leistungsfähiger Benutzer verstößt gegen das Prinzip der geringsten Berechtigungen . Dies ist die Hauptursache für die meisten SQL Injection-Angriffe.

Dies geschieht normalerweise aus Unwissenheit, der Einfachheit halber oder manchmal aus Gründen der Leistung.

Datenbanken sind oft langlebig und werden von mehreren Anwendungen gleichzeitig und im Laufe der Zeit verwendet. Sie können Ressourcen sparen, indem Sie die Zugriffssteuerung in der Datenbank zentralisieren und nicht über mehrere Anwendungen hinweg.

Sie möchten einen Datenbankserver auswählen, der Zeilensicherheit, Spaltensicherheit und Identitätswechsel / Proxy-Authentifizierung unterstützt (unterstützt echte Datenbankbenutzer + Verbindungspooling).

Es wäre auch sicherer für "Plugin" -basierte Anwendungen wie Wordpress, bei denen SQL-Injections aufgrund ungeübter Plugin-Autoren schwer zu vermeiden sind. Jedes Plugin erhält anstelle der gesamten Anwendung ein DB-Login.