Freigeben über

EXECUTE AS-Klausel (Transact-SQL)

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

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' }

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 SELFEXECUTE 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\NetworkServiceoder 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\NetworkServiceoder 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, UPDATEund DELETE.
  • 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ügtEXECUTE.

  • 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 die Sales Datenbank.

  • CompanyDomain\SqlUser1 ist Mitglied SQLUsers und hat daher Zugriff auf die Sales 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 ASdem 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

Zugehöriger Inhalt