Schaltausführungskontext innerhalb logon Trigger

Question

Ich habe eine Datenbank MyDB in einer Microsoft SQL Server 2008 Express-Instanz mit Authentifizierung im gemischten Modus genannt. Die Anwendung verwendet derzeit die Datenbank MyDB verbindet die Windows-Authentifizierung, des aktuellen Benutzers Windows-Anmeldeinformationen. Diese Anmeldung ist ein Mitglied der ‚öffentlichen‘ Serverrolle und hat einen Benutzer in der Datenbank MyDB abgebildet. Diese Datenbank Benutzer ein Mitglied der db_datareader und db_datawriter Datenbankrollen.

Was ich möchte, ist, dass, wenn die Anwendung eine Verbindung herstellt, es Berechtigungen in MyDB zu lesen und zu schreiben hat. Aber wenn ein andere Anwendung verbindet die gleiche Login verwenden, sollte es nur lesen darf.

Mein Gedanke war, dass ich ein Anmelde Trigger schaffen würde, die den Namen der Anwendung ein Teil der Verbindungszeichenfolge überprüfen würde, und auf der Grundlage, die entscheiden, ob die Ausführungskontext eingeschaltet werden soll. (Für das Protokoll, ich weiß, dass es in keiner Weise sicher auf den Namen der Anwendung der Verbindungszeichenfolge zu verlassen, und dass es sehr leicht zu umgehen. Der Zweck ist hier nicht um die Datenbank zu sichern, sondern um Benutzern zu helfen vermeiden Wechsel Daten, wenn sie eine andere Anwendung der Verbindung über, wie Microsoft Excel)

Ich habe ein neues Login namens ‚myapp_reader‘ an einen Benutzer in der MyDB Datenbank abgebildet erstellt, das Mitglied von db_datareader ist.

Ich habe dann versucht, eine Anmeldung Trigger mit dem folgende TSQL zu erstellen:

CREATE TRIGGER CheckUser
ON ALL SERVER
AFTER LOGON AS
BEGIN
IF APP_NAME() <> 'My Application Name'
    BEGIN
        EXECUTE AS LOGIN = 'myapp_reader' WITH NO REVERT
    END
END

Aber leider funktioniert es nicht. Wenn ich versuche, eine Verbindung bekomme ich folgende Fehlermeldung:

Fehler bei der Anmeldung für die Anmeldung 'MyComputer \ MyWindowsUsername' aufgrund Trigger-Ausführung.
Geänderte Datenbankkontext ‚Master‘.
Veränderte Spracheinstellung us_english. (Microsoft SQL Server, Fehler: 17892)

Und wenn ich in der errorlog aussehen heißt es:

Fehler: 15590, Schweregrad: 16, Status: 1.
Kann nur den ‚No Revert‘ oder ‚Cookie‘ Optionen mit der ‚Ausführen als‘ Erklärung auf der Ad-hoc-Ebene verwenden.
Fehler: 17892, Schweregrad: 20, Status: 1.
Fehler bei der Anmeldung für die Anmeldung ‚MyComputer \ MyWindowsUsername‘ aufgrund Trigger-Ausführung. [CLIENT: xxx.xxx.xxx.xxx]

Ist dieser Fehler meine ich nicht permanent den Ausführungskontext in der Anmelde Trigger ändern?

Answer 1

Ich glaube nicht, seine möglich, den Ausführungskontext für die gesamte Sitzung zu ändern. Sie könnten einen DML-Trigger für INSERT erstellen, UPDATE und DELETE für jede Tabelle / Ansicht in Ihrer Datenbank, die ein Rollback für eine bestimmte app_name tut (). Sie könnten eine Prozedur schreiben, die Schaffung all dieser Trigger zu automatisieren.

Alternativ, wenn Sie haben die Möglichkeit, über einen Verbindungsserver verbinden Anwendungen wie Excel, die dann könnte man den Ausführungskontext an dieser Stelle ändern. Und einen Anmelde Trigger erstellen, die Rollen, die Verbindung zurück, wenn Benutzer versuchen, über Excel oder andere Anwendungen direkt mit dem Server verbinden.

Answer 2

Unter der Annahme, dass Sie die Kontrolle über die Anwendung haben und es ändern können, dann Anwendungsrollen werden genau das tun, was Sie wollen. Siehe sp_setapprole in der Onlinedokumentation, um loszulegen.

Answer 3

Sie können dies nicht in der Art und Weise Sie wollen.

• Eine Benutzer-Verbindung hat die gleichen Anmeldeinformationen in ganz abgesehen von einigen spezifischen Tive AS mit EXECUTE.
• Sie haben erkannt, können Sie nicht auf APP_NAME verlassen () oder HOST_NAME (), wenn jemand anders Connects zu erkennen, was bedeutet, ein Rollback-Trigger pro Tabelle nicht dort verlassen
• Ihre App beruht auf direkten Tabellenschreibzugriff

Einige Optionen kann ich mich vorstellen ...

• Ihre App verwendet gespeicherte Prozeduren, haben Benutzer Zugriff nur lesen Sie in den Tabellen
• Verwenden Sie SET CONTEXT_INFO in Ihrer Anwendung einen "geheimen" Schlüssel für Rollback-Trigger
einstellen
• Ändern Sie Ihre Anwendung ein Dienstkonto / ist ein Windows-Dienst / etc und Proxies den Benutzernamen in (als eine Web-Seite tun würde)
verwenden
• ... oder einige Permutationen therof

Answer 4

Sie wirklich brauchen, um Ihre Meinung über Make-up, wie erste Anmeldeinformationen zu organisieren und zu verwalten.

Wenn Sie sp_setapprole verwenden, die Windows-Authentifizierung umgehen wird und für jeden Benutzer Zugriff durch diese App ermöglichen. Wenn das ist, was wirklich tun wollen Sie dann, wenn die App ein Server-Benutzerkonto für diese App erstellen und führen Sie es unter diesem Benutzer.

Wenn es eine Client-Anwendung dann einen Web-Service machen, die nur gelesen werden und bestimmte Daten, dass der App Bedarf senden und dass Web-Service unter dem neuen Konto ausgeführt. Dann in IIS7 können Sie eine ACL auf den Web-Service setzen sich so, dass es nach wie vor geschützt ist.

Auch wenn die App nicht sauber sein vertraut und wissen, was es tut verlangt dann, dass es überprüft werden, um Code hat, bevor es erlaubt ist, SQL Server zu berühren. Wenn es dann Ihre eigene App starten, sich zu vertrauen: -)