Zeilenebenen-Sicherheit mit Entity Framework

Question

Ich habe versucht zu prüfen, wie Row Level Security mit dem Entity Framework implementiert werden könnte. Die Idee ist, eine datenbankunabhängige Mittel zu haben, die Methoden anbieten, um die Zeilen, die von dem ObjectContext kommen, einzuschränken.

Einige meiner anfänglichen Ideen beinhalteten die Modifizierung der Teilklassen, die mit dem EDMGEN-Tool erstellt wurden und die eine begrenzte Unterstützung geboten haben. Benutzer können diese Lösung dennoch umgehen, indem sie ihre eigenen eSQL-Anweisungen und ein QueryObject verwenden.

Ich habe nach einer umfassenden Lösung gesucht, die über den Datenbankanbietern existieren würde, so dass es agnostisch bleiben würde.

Answer 1

Sicher können Sie es tun. Wichtig ist, den direkten Zugriff auf den Objektkontext zu blockieren (indem verhindert wird, dass Benutzer ihre eigene ObjectQuery erstellen), und stattdessen dem Client ein engeres Gateway zu geben, über das er auf Entitäten zugreifen und ihn mutieren kann. Wir machen es mit der Entity Repository pattern. Sie können eine example implementation of this pattern for the entity framework in this blog post finden. Auch hier blockiert der Schlüssel den Zugriff auf den Objektkontext. Beachten Sie, dass die Objektkontextklasse partiell ist. Sie sollten also in der Lage sein, "unautorisierte" Instantiierungsmethoden zu verhindern, nämlich außerhalb Ihrer Repository-Assembly.

Allerdings gibt es Feinheiten zu beachten. Wenn Sie die Sicherheit auf Zeilenebene für einen bestimmten Entitätstyp über das Repository-Muster implementieren, müssen Sie andere Mittel in Betracht ziehen, mit denen ein Client auf dieselben Entitäten zugreifen kann. Zum Beispiel über Navigationsbeziehungen. Möglicherweise müssen Sie einige dieser Beziehungen privat machen, was Sie in Ihrem Modell tun können. Sie haben auch die Option specifying a custom query oder gespeicherte Prozedur zum Laden/Speichern von Entitäten. Gespeicherte Prozeduren sind in der Regel DB-Server-spezifisch, SQL kann jedoch generisch geschrieben werden.

Obwohl ich nicht einverstanden bin, dass dies nicht mit dem Entity Framework getan werden kann, stimme ich den Kommentaren "tun Sie es auf dem DB-Server" insofern zu, als Sie defense in depth implementieren sollten.

Answer 2

Der Ort, an dem Sie Sicherheit hinzufügen, hängt wirklich davon ab, gegen wen Sie sich schützen möchten.

Wenn Sie beispielsweise eine Website sichern, reicht das Hinzufügen der Filterung auf Kontextebene aus, da sich die "Benutzer" in diesem Fall auf der Website befinden. Sie haben keine andere Wahl, als durch Ihren Kontext zu gehen, da Sie die Anwendung vollständig gegen den Kontext schreiben würden.

In Ihrem Fall klingt es wie die "Benutzer", gegen die Sie sich schützen, sind Entwickler. Das ist ein bisschen schwieriger. Wenn die Entwickler keinen Zugriff auf Änderungen an der Datenbank selbst haben, müssen Sie die Sicherheit auf Datenbankebene setzen. Keine Menge von eSQL-Zugriff wird in der Lage sein, die Datenbank mit "Nein" zu umgehen.

Answer 3

Was Sie versuchen zu erreichen, ist definitionsgemäß nicht möglich.

Wenn die Sicherheit nicht explizit von der zugrunde liegenden Datenbankanwendung (SQL Server, Oracle, was auch immer) behandelt wird, dann werden die Standardtools wie SQL Management Studio direkt vorbei.

Das Beste, was Sie tun können, ist die Durchsetzung der Sicherheit auf Zeilenebene durch Benutzer der Anwendung NUR, wenn diese Benutzer keinen Zugriff auf die Datenbank über einen anderen Mechanismus haben.

Answer 4

Diesen Artikel finden könnte nützlich:

http://msdn.microsoft.com/en-us/magazine/ff898427.aspx

„Table Zugang zum Ohne Entity Framework Verweigern eine Meuterei Verursachung“

Answer 5

ich einen Weg, es zu tun gefunden Postgres und eine Erweiterung namens Veil. Es funktioniert tatsächlich (entwickelt für) mit Views für alle Operationen (wählen, aktualisieren, löschen, einfügen) und überprüfen Berechtigungen in WHERE Klauseln. Aber Veil fügt nur die Mathematik hinzu, um Berechtigungsinformationen effizient im Speicher zu verwalten, anstatt sie jedes Mal abzufragen. Wenn Sie sich also direkt mit DBMS verbinden, haben Sie mit Veil nur Zugriff auf Zeilenebene für Sie.

Ich modifiziere meinen Stil mit Schleier in mancher Hinsicht, zum Beispiel begann ich Triggers anstelle von Views für die Anwendung von Berechtigungen Einschränkungen zu verwenden.

Ich empfehle Ihnen, diese Lösung zu studieren und versuchen, ihre Logik hier anzuwenden.

d. H .: Sie machen eine select * from table Abfrage und Sie erhalten genau das, was Sie vorhaben (Zeilenebene sprechen).