EXECUTE AS-Klausel (Transact-SQL)
Gilt für: SQL Server
Azure SQL-Datenbank
Azure SQL verwaltete Instanz
In SQL Server können Sie den Ausführungskontext der folgenden benutzerdefinierten Module definieren: Funktionen (außer Inline-Tabellenwertfunktionen), Prozeduren, Warteschlangen und Trigger.
Durch Angeben des Kontexts, in dem das Modul ausgeführt wird, können Sie steuern, mit welchem Benutzerkonto Datenbank-Engine Berechtigungen für Objekte, auf die im Modul verwiesen wird, überprüft. Dies bietet zusätzliche Flexibilität und Kontrolle bei der Verwaltung von Berechtigungen für die Objektkette, die zwischen benutzerdefinierten Modulen und den Objekten vorhanden ist, auf die von diesen Modulen verwiesen wird. Berechtigungen müssen nur Benutzern für das Modul selbst erteilt werden, ohne dass ihnen explizite Berechtigungen für die Objekte, auf die verwiesen wird, erteilt werden müssen. Nur das Benutzerkonto, unter dem das Modul ausgeführt wird, benötigt Berechtigungen für die Objekte, auf die das Modul zugreift.
Transact-SQL-Syntaxkonventionen
Syntax
In diesem Abschnitt wird die SQL Server-Syntax für EXECUTE AS
.
Funktionen (außer Inlinetabellenwertfunktionen), gespeicherte Prozeduren und DML-Trigger:
{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | 'user_name' }
DDL-Trigger mit Datenbankbereich:
{ EXEC | EXECUTE } AS { CALLER | SELF | 'user_name' }
DDL-Trigger mit Serverbereich und Anmeldetriggern:
{ EXEC | EXECUTE } AS { CALLER | SELF | 'login_name' }
Warteschlangen:
{ EXEC | EXECUTE } AS { SELF | OWNER | 'user_name' }
Hinweis
Informationen zum Anzeigen der Transact-SQL-Syntax für SQL Server 2014 (12.x) und früher finden Sie unter Dokumentation zu früheren Versionen.
Argumente
CALLER
Gibt an, dass die Anweisungen innerhalb des Moduls im Kontext des Aufrufers des Moduls ausgeführt werden. Der Benutzer, der das Modul ausführt, benötigt die entsprechenden Berechtigungen nicht nur für das Modul selbst, sondern auch für alle Datenbankobjekte, auf die das Modul verweist.
CALLER
ist die Standardeinstellung für alle Module außer Warteschlangen und ist identisch mit sql Server 2005 (9.x)-Verhalten.
CALLER
kann in einer CREATE QUEUE
oder ALTER QUEUE
anweisung nicht angegeben werden.
SELF
EXECUTE AS SELF
EXECUTE AS <user_name>
entspricht , wobei der angegebene Benutzer die Person ist, die das Modul erstellt oder ändert. Die tatsächliche Benutzer-ID der Person, die die Module erstellt oder ändert, wird in der execute_as_principal_id
Spalte in der sys.sql_modules
Ansicht oder sys.service_queues
Katalog gespeichert.
SELF
ist die Standardeinstellung für Warteschlangen.
Hinweis
Um die Benutzer-ID der execute_as_principal_id
Spalte in der sys.service_queues
Katalogansicht zu ändern, müssen Sie die EXECUTE AS
Einstellung in der ALTER QUEUE
Anweisung explizit angeben.
OWNER
Gibt an, dass die Anweisungen innerhalb des Moduls im Kontext des aktuellen Besitzers des Moduls ausgeführt werden. Wenn das Modul keinen angegebenen Besitzer hat, wird der Besitzer des Schemas des Moduls verwendet. OWNER
kann für DDL- oder Anmeldetrigger nicht angegeben werden.
Wichtig
OWNER
muss einem Singleton-Konto zugeordnet werden und kann keine Rolle oder Gruppe sein.
'user_name'
Gibt an, dass die Anweisungen innerhalb des Moduls im Kontext des in user_name angegebenen Kontexts ausgeführt werden. Berechtigungen für alle Objekte innerhalb des Moduls werden gegen user_name geprüft. user_name können für DDL-Trigger mit Serverbereichs- oder Anmeldetriggern nicht angegeben werden. Verwenden Sie stattdessen login_name.
user_name muss in der aktuellen Datenbank vorhanden und ein Singleton-Konto sein. user_name kann keine Gruppe, Rolle, Zertifikat, Schlüssel oder integriertes Konto sein, zNT AUTHORITY\LocalService
. B. , NT AUTHORITY\NetworkService
oder NT AUTHORITY\LocalSystem
.
Die Benutzer-ID des Ausführungskontexts wird in Metadaten gespeichert und kann in der Spalte in der execute_as_principal_id
sys.sql_modules
Ansicht oder sys.assembly_modules
Katalogansicht angezeigt werden.
"login_name"
Gibt an, dass die Anweisungen innerhalb des Moduls im Kontext des in login_name angegebenen SQL Server-Anmeldenamens ausgeführt werden. Berechtigungen für alle Objekte innerhalb des Moduls werden gegen login_name geprüft. login_name kann nur für DDL-Trigger im Serverbereich oder für LOGON-Trigger angegeben werden.
login_name kann keine Gruppe, Rolle, Zertifikat, Schlüssel oder integriertes Konto sein, zNT AUTHORITY\LocalService
. B. , NT AUTHORITY\NetworkService
oder NT AUTHORITY\LocalSystem
.
Hinweise
Wie Datenbank-Engine Berechtigungen für Objekte auswertet, auf die im Modul verwiesen wird, hängt von der Besitzkette ab, die zwischen den aufrufenden Objekten und den Objekten vorhanden ist, auf die verwiesen wird. In früheren Versionen von SQL Server war die Besitzverkettung die einzig verfügbare Methode, um zu vermeiden, dass dem aufrufenden Benutzer der Zugriff für alle Objekte, auf die verwiesen wird, erteilt werden muss.
Für die Besitzverkettung gelten die folgenden Einschränkungen:
- Gilt nur für DML-Anweisungen:
SELECT
, ,INSERT
,UPDATE
undDELETE
. - Die Besitzer der aufrufenden Objekte und der aufgerufenen Objekte, müssen identisch sein.
- Gilt nicht für dynamische Abfragen innerhalb des Moduls.
Die folgenden Aktionen werden immer angewendet, unabhängig vom Ausführungskontext, der im Modul angegeben ist:
Wenn das Modul ausgeführt wird, überprüft die Datenbank-Engine zunächst, ob der Benutzer, der das Modul ausführt, über die Berechtigung für das Modul verfügt
EXECUTE
.Besitzverkettungsregeln werden weiterhin angewendet. Das heißt, wenn die Besitzer der aufrufenden und der aufgerufenen Objekte identisch sind, werden keine Berechtigungen der zugrunde liegenden Objekte überprüft.
Wenn ein Benutzer ein Modul ausführt, das für die Ausführung in einem anderen Kontext angegeben wurde als CALLER
, wird die Berechtigung des Benutzers zum Ausführen des Moduls überprüft, aber zusätzliche Berechtigungsprüfungen für Objekte, auf die vom Modul zugegriffen wird, werden für das in der EXECUTE AS
Klausel angegebene Benutzerkonto ausgeführt. Der Benutzer, der das Modul ausführt, nimmt die Identität des angegebenen Benutzers an.
Der in der EXECUTE AS
Klausel des Moduls angegebene Kontext ist nur für die Dauer der Modulausführung gültig. Der Kontext des Aufrufers wird wiederhergestellt, wenn die Ausführung des Moduls abgeschlossen ist.
Angeben eines Benutzer- oder Anmeldenamens
Ein datenbankbenutzer oder serveranmeldung, der in der EXECUTE AS
Klausel eines Moduls angegeben ist, kann erst gelöscht werden, wenn das Modul so geändert wird, dass es unter einem anderen Kontext ausgeführt wird.
Der in EXECUTE AS
der Klausel angegebene Benutzer- oder Anmeldename muss als Prinzipal vorhanden sys.database_principals
sein sys.server_principals
, oder andernfalls schlägt der Erstellungs- oder Änderungsmodulvorgang fehl. Darüber hinaus benötigt der Benutzer, der das Modul erstellt oder ändert, IMPERSONATE-Berechtigungen für den Prinzipal.
Wenn der Benutzer über eine Windows-Gruppenmitgliedschaft impliziten Zugriff auf die Datenbank oder Instanz von SQL Server hat, wird der in der EXECUTE AS
Klausel angegebene Benutzer implizit erstellt, wenn das Modul erstellt wird, wenn eine der folgenden Anforderungen vorhanden ist:
- Der angegebene Benutzer oder Anmeldename ist ein Mitglied der festen Serverrolle sysadmin.
- Der Benutzer, der das Modul erstellt, hat die Berechtigung zum Erstellen von Prinzipalen.
Wenn keine dieser Anforderungen erfüllt ist, wird für den Vorgang zum Erstellen des Moduls ein Fehler gemeldet.
Wichtig
Wenn der SQL Server -Dienst (MSSQLSERVER) als lokales Konto (lokaler Dienst oder lokales Benutzerkonto) ausgeführt wird, verfügt er nicht über Berechtigungen zum Abrufen der Gruppenmitgliedschaften eines Windows-Domänenkontos, das in der EXECUTE AS
Klausel angegeben ist. Deshalb wird die Ausführung des Moduls fehlschlagen.
Stellen Sie sich z. B. folgende Bedingungen vor:
CompanyDomain\SQLUsers
die Gruppe hat Zugriff auf dieSales
Datenbank.CompanyDomain\SqlUser1
ist MitgliedSQLUsers
und hat daher Zugriff auf dieSales
Datenbank.Der Benutzer, der das Modul erstellt oder ändert, hat Berechtigungen zum Erstellen von Prinzipalen.
Wenn die folgende CREATE PROCEDURE
-Anweisung ausgeführt wird, wird CompanyDomain\SqlUser1
implizit als Datenbankprinzipal in der Sales
-Datenbank erstellt.
USE Sales;
GO
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT USER_NAME();
GO
Use EXECUTE AS CALLER stand-alone statement
Verwenden Sie die EXECUTE AS CALLER
eigenständige Anweisung in einem Modul, um den Ausführungskontext auf den Aufrufer des Moduls festzulegen.
Angenommen, die folgende gespeicherte Prozedur wird von SqlUser2
aufgerufen.
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'SqlUser1'
AS
SELECT USER_NAME(); -- Shows execution context is set to SqlUser1.
EXECUTE AS CALLER;
SELECT USER_NAME(); -- Shows execution context is set to SqlUser2, the caller of the module.
REVERT;
SELECT USER_NAME(); -- Shows execution context is set to SqlUser1.
GO
Verwenden von EXECUTE AS zum Definieren von benutzerdefinierten Berechtigungssätzen
Die Angabe eines Ausführungskontexts für ein Modul kann nützlich sein, wenn Sie benutzerdefinierte Berechtigungssätze definieren möchten. Beispielsweise verfügen einige Aktionen, z TRUNCATE TABLE
. B. nicht über zulässige Berechtigungen. Indem Sie die TRUNCATE TABLE
Anweisung in ein Modul integrieren und angeben, dass das Modul als Benutzer ausgeführt wird, der über Berechtigungen zum Ändern der Tabelle verfügt, können Sie die Berechtigungen erweitern, um die Tabelle auf den Benutzer zu kürzen, dem Sie Berechtigungen für das Modul erteilen EXECUTE
.
Verwenden Sie die Katalogsicht sys.sql_modules (Transact-SQL), um die Definition des Moduls mit dem angegebenen Ausführungskontext anzuzeigen.
Best Practice
Geben Sie einen Anmeldenamen oder einen Benutzer an, der die mindestens erforderlichen Privilegien zum Ausführen der im Modul definierten Vorgänge aufweist. Geben Sie beispielsweise kein Datenbankbesitzerkonto an, es sei denn, diese Berechtigungen sind erforderlich.
Berechtigungen
Um ein mit EXECUTE AS
dem Modul angegebenes Modul auszuführen, muss der Aufrufer über Berechtigungen für das Modul verfügen EXECUTE
.
Um ein mit AS angegebenes EXECUTE
CLR-Modul auszuführen, das auf Ressourcen in einer anderen Datenbank oder einem anderen Server zugreift, muss die Zieldatenbank oder der Server dem Authentifikator der Datenbank vertrauen, aus der das Modul stammt (die Quelldatenbank).
Um die EXECUTE AS
Klausel beim Erstellen oder Ändern eines Moduls anzugeben, müssen Sie über Berechtigungen für den angegebenen Prinzipal und auch über Berechtigungen zum Erstellen des Moduls verfügen IMPERSONATE
. Sie können immer Ihre eigene Identität annehmen. Wenn kein Ausführungskontext angegeben oder EXECUTE AS CALLER
angegeben wird, IMPERSONATE
sind keine Berechtigungen erforderlich.
Um eine login_name oder user_name anzugeben, die über eine Windows-Gruppenmitgliedschaft impliziten Zugriff auf die Datenbank hat, müssen CONTROL
Sie über Berechtigungen für die Datenbank verfügen.
Beispiele
Im folgenden Beispiel wird eine gespeicherte Prozedur in der AdventureWorks2022-Datenbank erstellt und der Ausführungskontext dem OWNER
zugewiesen.
CREATE PROCEDURE HumanResources.uspEmployeesInDepartment @DeptValue INT
WITH EXECUTE AS OWNER
AS
SET NOCOUNT ON;
SELECT e.BusinessEntityID,
c.LastName,
c.FirstName,
e.JobTitle
FROM Person.Person AS c
INNER JOIN HumanResources.Employee AS e
ON c.BusinessEntityID = e.BusinessEntityID
INNER JOIN HumanResources.EmployeeDepartmentHistory AS edh
ON e.BusinessEntityID = edh.BusinessEntityID
WHERE edh.DepartmentID = @DeptValue
ORDER BY c.LastName,
c.FirstName;
GO
-- Execute the stored procedure by specifying department 5.
EXECUTE HumanResources.uspEmployeesInDepartment 5;
GO