SQL Server-Sicherheit über TSQL

Question

Ich möchte ein Transact-Sql-Skript erstellen, das bestimmte Personen daran hindert, bestimmte Befehle für alle Datenbanken auszuführen:

drop database, drop table or preferbly drop *

delete

update

Ist dies möglich? Der Benutzer wird bereits Zugang zum Server haben.

Hinweis: Ich versuche nicht, ein Sicherheitsmodell für einen Server zu entwickeln oder einen bösartigen Angriff zu verhindern. Es handelt sich um einen bestehenden Server, auf dem Personen über verschiedene Windows-Gruppen, denen sie angehören, eine Reihe von Zugriffsrechten haben können. Ich möchte nur wissen, ob es einen schnellen Schutz gibt, um zu verhindern, dass jemand versehentlich einen Befehl auf dem falschen Server ausführt.

Answer 1

( caveat (dies gilt für jede Datenbank; mir ist nichts Serverweites bekannt, da die Datenbank die wichtigste eigenständige Einheit ist)

Vermutlich ist Ihr Benutzer nicht der Eigentümer des Schemas (oder der dbo)? In diesem Fall sollte er ohnehin keinen Zugriff auf irgendetwas haben, es sei denn, Sie gewähren ihn. Also nicht GRANT den Zugang, den sie nicht brauchen, REVOKE jeden von Ihnen fälschlicherweise gewährten Zugang und DENY alles, was sie auf keinen Fall tun sollen.

Siehe auch MSDN .

Answer 2

Die einzige mir bekannte Möglichkeit, bestimmte Rechte zuverlässig einzuschränken, ist die Verwendung gespeicherter Verfahren. Sehr sicher, aber nicht dynamisch.

Gespeicherte Verfahren bieten erhebliche Vorteile, wenn es um die Sicherheit geht. Durch Verwendung einer gespeicherten Prozedur, können Sie Berechtigungen für bestimmte Benutzer gewähren, um Zugriff auf Daten gewähren, was den immensen Codierung, die Sie in Ihren Client-Anwendungen vornehmen Client-Anwendungen. Dies ist eine der der besten Möglichkeiten, den Zugriff auf Ihre Daten.

http://www.wwwcoder.com/main/parentid/191/site/4004/68/default.aspx

Answer 3

Wenn Sie mit SQL Server 2005 oder 2008 arbeiten, ist die beste Antwort eine, die bereits gegeben wurde, nämlich DDL-Trigger. Ein richtig geschriebener DDL-Trigger hält selbst jemanden mit Systemadministratorrechten davon ab, DDL-Operationen durchzuführen. Ein Systemadministrator kann einen Trigger für die Durchführung von Arbeiten deaktivieren, oder der Trigger kann so geschrieben werden, dass er bestimmten Personen die Durchführung von Arbeiten erlaubt, so dass Sie immer noch die Möglichkeit haben, Änderungen nach Bedarf vorzunehmen.

Wenn Sie mit SQL Server 2000 (oder niedriger) arbeiten, bleibt Ihnen nur die Möglichkeit, die Sicherheitsberechtigungen für jede Anmeldung/jeden Benutzer zu überprüfen. Letztlich ist dies auch bei SQL Server 2005 oder 2008 erforderlich, aber in den früheren Versionen gibt es keine Abkürzung.

Answer 4

Sie können nicht wirklich überprüfen, ob Sie Drop-Befehle sehen, weil jemand etwas wie folgt tun könnte

Stellen Sie sich vor, es gäbe exec anstelle von print

print ( convert(varchar(50), 0x64726F7020646174616261736520616263))

Sie könnten ihnen nur Lesezugriff gewähren und den Ausführenden nur Zugang zu gespeicherten Prozessen geben

Sie können auch DDL-Trigger verwenden http://msdn.microsoft.com/en-us/library/ms190989.aspx

Hier ein Beispiel

CREATE TRIGGER safety 
ON DATABASE 
FOR DROP_TABLE, ALTER_TABLE 
AS 
   PRINT 'You are not allowed to drop or alter tables!' 
   ROLLBACK
;

Answer 5

Cindi - schauen Sie sich den DENY-Berechtigungsbefehl an, um eine fein abgestufte Kontrolle über die Fähigkeiten Ihrer Benutzer zu erhalten.

Ich muss aber auch eine tiefer gehende Frage stellen. Warum sollten diese Menschen SQL-Befehlszeilenzugriff auf Ihre Datenbanken haben? Das heißt, wenn sie nicht einmal in der Lage sein sollten, Datensätze zu löschen oder zu aktualisieren, welchen Grund könnten sie dann haben, überhaupt Zugang zu einer SQL-Befehlszeile zu erhalten?

Ich glaube nicht, dass Sie wissen müssen, wie man Berechtigungen verweigert. Sie müssen Ihre gesamte Datenzugriffsstrategie überdenken, um zu vermeiden, dass diese Personen überhaupt ein Konto erhalten. Es klingt, als müssten Sie den Zugriff auf die Daten ausschließlich über eine Front-End-Anwendung regeln.

Update: Das einzige Szenario, bei dem ich mir vorstellen kann, dass dies Sinn macht, ist, wenn Sie einige Leute haben, die nur Berichte erstellen. In diesem Fall sollten Sie ein Konto mit einem pauschalen DENY-Status erstellen und dann die Berechtigung nur für Select und für bestimmte gespeicherte Prozeduren (nur die, die für Berichte nützliche Daten abrufen) gewähren.