SQL Server-Berechtigungstypen

Question

Mein Team ist kürzlich in ein formalisierteres System der SQL Server-Datenbanküberwachungs- und -bereitstellungssteuerelemente gewechselt, und als Ergebnis wurden mehrere Berechtigungen eingeschränkt.

Viele von uns sind mit der SQL Server-Sicherheit nicht vertraut und haben Szenarien kennengelernt, in denen wir nur eine Zugriffsbeschränkung für beispielsweise TRUNCATE TABLE in der Produktion bereitstellen.

Es ist nur ein Ärgernis in diesem Stadium, aber ich habe versucht, eine konsolidierte Liste zu finden (cheatsheet? Cabsheet? Referenzsuche?), Leicht gegen solche Funktionen zu überprüfen, so dass es nicht so einfach passiert, aber ich habe keine gefunden.

Ich weiß, dass der MSN-Artikel für jede Funktion diese auflistet, aber ich möchte nicht einzeln auf die spezifische Website für jede gebräuchliche und seltene Funktion nur zu überprüfen suchen, besonders wenn ich es mehr als tun muss Einmal, weil ich (zum Beispiel) vergessen habe.

Die nächstgelegene ich fand, waren Orte wie diese:

https://www.mssqltips.com/sqlservertip/1718/database-level-permissions-for-sql-server-2005-and-2008/

https://www.simple-talk.com/sql/database-administration/sql-server-security-cribsheet/

... aber sie waren unvollständig (konnte nicht in beide finden TRUNCATE) und ein wenig lang: Ich hoffe, es gibt irgendwo eine Tabelle, die einfach 'Aktion -> Aktionsname -> Berechtigungsname -> Server-/Tabellenebene -> Standardrolle' oder etwas zusammen an einer Stelle setzt.

Gibt es irgendwo eine solche Liste?

Answer 1

Leider ist mir kein Dokument bekannt, das jede Aktion in SQL Server mit den erforderlichen Berechtigungen zeigt. Solch eine Tabelle wäre unpraktisch, da es sehr viele mögliche Aktionen gibt und einige Aktionen mehrere Berechtigungen erfordern, einschließlich Szenarien, in denen sich die Berechtigungsanforderungen je nach Teilbereichen der Aktion ändern würden.

Für das Szenario, das Sie versuchen zu lösen, scheint es, als ob Sie Module (SPs) verwenden, um die Aktionen zu definieren, die den Benutzern ohne Administratorrechte erlaubt sind, richtig? In diesem Fall können Sie möglicherweise digital signierte Module verwenden, um beim Ausführen des SP die entsprechenden Berechtigungen zu erteilen, anstatt die Berechtigung direkt zuzuweisen. Zum Beispiel:

CREATE USER [low_priv_user] WITHOUT LOGIN 
go 

CREATE TABLE [dbo].[myTable](data int); 
go 

CREATE PROC [dbo].[sp_truncate_my_table] 
AS 
    TRUNCATE TABLE [dbo].[sp_truncate_my_table]; 
go 

GRANT EXECUTE ON [dbo].[sp_truncate_my_table] TO [low_priv_user] 
go 

-- Will fail due to permission 
EXECUTE ('EXEC [dbo].[sp_truncate_my_table];')AS USER = 'low_priv_user'; 
go 

-- Create a certificate to sign the SP, 
CREATE CERTIFICATE [signing_cert] 
    ENCRYPTION BY PASSWORD = '<you_could_use_masetr_key_instead_of_p@55w0rD5>' 
    WITH SUBJECT = 'demo - module signature'; 
go 
-- sign the SP 
ADD SIGNATURE TO [dbo].[sp_truncate_my_table] BY CERTIFICATE [signing_cert] 
    WITH PASSWORD = '<you_could_use_masetr_key_instead_of_p@55w0rD5>'; 
go 
-- destroy the private key 
ALTER CERTIFICATE [signing_cert] REMOVE PRIVATE KEY; 
go 

-- Create a user for the certificate & grant it all the permissions you would need for running teh SP 
CREATE USER [signing_cert] FROM CERTIFICATE [signing_cert]; 
go 
GRANT ALTER ON [myTable] TO [signing_cert]; 
go 

-- Permission check will be OK for the low privileged user 
-- You control what this user is allowed to do via SPs 
EXECUTE ('EXEC [dbo].[sp_truncate_my_table];')AS USER = 'low_priv_user'; 
go 

Wie Sie sehen können, habe ich ein Modul, das den Anrufer anrufen TRUNCATE auf einem Tisch, ohne Gewährung ALTER Erlaubnis direkt an den Benutzer ermöglicht.

Im Idealfall möchten Sie bei der Verwendung dieses Mechanismus dem Prinzip der geringsten Rechte folgen und nur die erforderlichen Berechtigungen und nichts anderes gewähren. Wenn Sie jedoch Schwierigkeiten haben, die benötigten Berechtigungen zu finden, können Sie eine Verknüpfung verwenden: GRANT CONTROL TO [signing_cert].

Offensichtlich hat eine solche Verknüpfung erhebliche Auswirkungen auf die Sicherheit, da Sie dem signierten Code buchstäblich die volle Kontrolle über Ihre Datenbank gewähren (einschließlich dynamischem SQL innerhalb dieser Module), aber wenn Sie sich dafür entscheiden, würde ich die folgenden Vorsichtsmaßnahmen empfehlen :

• den privaten Schlüssel zerstören, damit niemand es
• missbrauchen nicht dynamische SQL in Ihrer signierten Module (oder zumindest sicherstellen, dass unter SQL-Injection Sie sind nicht)
• verwenden Sie nach Möglichkeit vermeiden Geben Sie CONTROL Erlaubnis auf Modulen, wo Sie kann die minimalen Privilegien gewähren.
• Überwachen Sie alle Aktivitäten in Ihrer Datenbank.

Ich schließe auch eine Kopie der SQL Database Engine Permission Poster Verbindung ein, die nützlich sein kann.

Ich hoffe, diese Informationen helfen.