Verwenden der Sysadmin-Rolle mit EXECUTE AS


7

Nach meinem Verständnis kann ich die EXECUTE AS OWNERKlausel als Teil einer von mir erstellten Prozedur verwenden, um den Hauptteil dieser Prozedur als einen anderen Benutzer auszuführen. Mein Ziel ist es, einen Befehl auszuführen, der die sysadminRolle ( DBCC TRACEON(1224)) erfordert . Diese Prozedur soll von einem nicht privilegierten Benutzer aufgerufen werden.

Ich habe das folgende Skript unter dem saBenutzer ausgeführt:

SELECT USER_NAME(), USER_ID(), IsSysAdmin = IS_SRVROLEMEMBER('sysadmin')
-- dbo  1   1

IF EXISTS(SELECT * FROM sys.procedures WHERE name = 'MyProc')
    DROP PROCEDURE MyProc

GO
CREATE PROCEDURE MyProc
WITH EXECUTE AS OWNER
AS 
    SELECT USER_NAME(), USER_ID(), IsSysAdmin = IS_SRVROLEMEMBER('sysadmin');
-- dbo  1   0

    DBCC TRACEON(1224)
--Msg 2571, Level 14, State 3, Procedure MyProc, Line 7
--User 'dbo' does not have permission to run DBCC TRACEON.

RETURN
GO

EXEC MyProc

Die Ausgabe erfolgt in Kommentaren inline. Es stellt sich heraus, dass ich außerhalb des Verfahrens eine sysadminMitgliedschaft zu haben scheine , aber nicht innerhalb des Verfahrens.

Die Prozedur gehört dem dboBenutzer. Ich verstehe, dass es nicht möglich ist, die sysadminRolle einem Datenbankbenutzer zuzuweisen (zumindest bietet die GUI diese Möglichkeit nicht). Ich sehe also nicht ein, wie ich jemals einen Datenbankbenutzer dazu bringen könnte, eine Serverrolle zu übernehmen.

Ich habe auch versucht, EXECUTE AS 'sa'was dazu führt Cannot execute as the user 'sa', because it does not exist or you do not have permission.. In der Dokumentation heißt es, dass ich nur einen Benutzernamen angeben kann, keinen Anmeldenamen. Ich verstehe also, warum das nicht funktioniert hat.

Wie kann ich meine Prozedur mit sysadminRollenmitgliedschaft ausführen ?

Antworten:


5

Es kann getan werden, aber es wird allgemein als ziemlich gefährlich angesehen. Auf einer sehr einfachen Ebene setzen Sie das trustworthyFlag in der Datenbank, und wenn Sie es execute asauf dem SP verwenden, kann es den Sicherheitszugriff der Server-Ebene nutzen.

Wegen der Gefährlichkeit möchte ich hier nicht ins Detail gehen. Allerdings habe ich hier darüber mit spezifischen Anweisungen gebloggt, wie es geht.

Alles, was gesagt wird, stellen Sie sicher, dass Sie es unbedingt NEEDso machen. Sie öffnen eine große Sicherheitslücke. Wenn Sie sich dazu entschließen, legen Sie Ihren SP in einer eigenen Datenbank ab und gewähren Sie nur Benutzern eine Verbindung und führen Sie den Zugriff auf den SP aus.


Ihr Artikel beschreibt eine Möglichkeit, die Prozedur in einer neuen Datenbank zu speichern. Das würde funktionieren. Ist es immer noch "gefährlich", das zu tun? Es scheint , dass mit einer separaten Datenbank , die die Konfiguration richtig hinzubekommen ist nicht , dass beteiligt.
usr

1
Das Einfügen des SP in eine neue Datenbank ist sicherlich am wenigsten gefährlich. Die Gefahr besteht hier wirklich darin, dass irgendwann irgendwann jemand etwas durcheinander bringt und jemandem db_owner dieser Datenbank gewährt. Das würde ihnen effektiv Systemadministrator geben, wenn sie wissen, wie es geht. Ich denke (noch nicht getestet), dass Sie es sogar mit CREATE PROCEDUREBerechtigungen tun und sich als solche ausgeben können. Es ist momentan nicht so sehr das Risiko, sondern das Risiko, nachdem alle vergessen haben, warum Sie überhaupt eine separate Datenbank erstellt haben.
Kenneth Fisher

6

Mein Ziel ist es, einen Befehl auszuführen, der die Sysadmin-Rolle erfordert (DBCC TRACEON (1224)).

Sie schlagen eine Lücke in Ihrer Sicherheit, indem Sie einem nicht privilegierten Benutzer erlauben, als Systemadministratorrolle ausgeführt zu werden.

Wenn Sie versuchen, ein 1224Traceflag festzulegen, das die Sperreneskalation basierend auf der Anzahl der Sperren deaktiviert, können Sie dies auf Tabellenebene mithilfe von tunALTER TABLE

Beispiel: Unten wird die Eskalation der Sperre auf Partitionsebene für eine partitionierte Tabelle aktiviert. Wenn die Tabelle nicht partitioniert ist, wird die Sperreneskalation auf der Ebene TABLE festgelegt.

ALTER TABLE dbo.T1 SET (LOCK_ESCALATION = AUTO); - Gültige Optionen sind AUTO, TABLE und DISABLE

Jetzt können Sie einem unvorhergesehenen Benutzer nur die Rechte zum Ändern der Tabelle erteilen.

HTH


Dies ist ein guter Trick für dieses spezielle Trace-Flag, aber nicht für Trace-Flags im Allgemeinen. Wenn Sie verhindern möchten, dass der Benutzer andere Aktivitäten zum Ändern von Tabellen ausführt, können Sie einen DDL-Trigger verwenden, der ALTER_TABLEgenau erfasst und überprüft, was er tut, bevor er dies zulässt (genauer gesagt, bevor er nicht zurückgesetzt wird).
Aaron Bertrand

Dies ist eine praktikable Lösung für mich, da es riskant erscheint, Sicherheitsrechte zu implementieren. Ich werde das wahrscheinlich benutzen. Vielen Dank! Trotzdem akzeptiere ich die Antwort, die den Sicherheitsteil dieser Frage am besten beantwortet.
usr

@AaronBertrand stimmte zu, dass dies nur für dieses Trace-Flag gilt, 1224 da dieses Trace-Flag auf Tabellenebene ausgeführt wird. Ich habe diese Antwort als Blick auf die Trace-Flag-Definition geschrieben. Sie kann alternativ mit Alter Table aktiviert werden .
Kin Shah

0

Das Erstellen eines SQL Server-Agent-Jobs (im Besitz eines Sysadmin-Mitglieds) reicht aus, obwohl mir klar ist, dass dies keine sehr hübsche Lösung ist.

Der Benutzer kann den Job (ansynchron) mit msdb.dbo.sp_start_job starten. Das synchrone Ausführen eines Agent-Jobs erfordert jedoch einige weitere Codezeilen, wenn dies erforderlich ist. Außerdem muss der SQL Server-Agent-Dienst natürlich ausgeführt werden.


Ich fordere, dass das Ablaufverfolgungsflag in der aktuellen Sitzung für eine bestimmte Verbindung gesetzt wird. Ich möchte es nicht global aktivieren.
usr

Entschuldigung, ich wusste nicht, dass es sitzungsspezifisch ist.
Daniel Hutmacher
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.