EXECUTE AS, klauzula (Transact-SQL)

Dotyczy:SQL Server Azure SQL Database Azure SQL Managed Instance

W programie SQL Server można zdefiniować kontekst wykonywania następujących modułów zdefiniowanych przez użytkownika: funkcje (z wyjątkiem wbudowanych funkcji wartości tabeli), procedury, kolejki i wyzwalacze.

Określając kontekst, w którym moduł jest wykonywany, możesz kontrolować, które konto użytkownika jest używane przez aparat bazy danych do sprawdzania poprawności uprawnień do obiektów, do których odwołuje się moduł. Zapewnia to dodatkową elastyczność i kontrolę nad zarządzaniem uprawnieniami w łańcuchu obiektów, które istnieją między modułami zdefiniowanymi przez użytkownika i obiektami, do których odwołuje się te moduły. Uprawnienia muszą być przyznawane użytkownikom tylko w samym module bez konieczności udzielania im jawnych uprawnień do przywołynych obiektów. Tylko użytkownik uruchomiony przez moduł musi mieć uprawnienia do obiektów, do których uzyskuje dostęp moduł.

Transact-SQL konwencje składni

W tej sekcji opisano składnię programu SQL Server dla programu EXECUTE AS.

Funkcje (z wyjątkiem wbudowanych funkcji wartości tabeli), procedury składowane i wyzwalacze DML:

{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | 'user_name' }

Wyzwalacze DDL z zakresem bazy danych:

{ EXEC | EXECUTE } AS { CALLER | SELF | 'user_name' }

Wyzwalacze DDL z wyzwalaczami zakresu serwera i logowania:

{ EXEC | EXECUTE } AS { CALLER | SELF | 'login_name' }

Kolejek:

{ EXEC | EXECUTE } AS { SELF | OWNER | 'user_name' }

W tej sekcji opisano składnię usługi Azure SQL Database dla programu EXECUTE AS.

Funkcje (z wyjątkiem wbudowanych funkcji wartości tabeli), procedury składowane i wyzwalacze DML:

{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | 'user_name' }

Wyzwalacze DDL z zakresem bazy danych:

{ EXEC | EXECUTE } AS { CALLER | SELF | 'user_name' }

Arguments

OBIEKT WYWOŁUJĄCY

Określa instrukcje wewnątrz modułu są wykonywane w kontekście obiektu wywołującego modułu. Użytkownik wykonujący moduł musi mieć odpowiednie uprawnienia nie tylko w samym module, ale także na wszystkich obiektach bazy danych, do których odwołuje się moduł.

CALLER jest wartością domyślną dla wszystkich modułów z wyjątkiem kolejek i jest taka sama jak zachowanie programu SQL Server 2005 (9.x).

CALLER Nie można określić w instrukcji CREATE QUEUE or ALTER QUEUE .

SELF

EXECUTE AS SELF jest odpowiednikiem EXECUTE AS <user_name>elementu , gdzie określony użytkownik jest osobą tworzącą lub zmieniającą moduł. Rzeczywisty identyfikator użytkownika osoby tworzącej lub modyfikujące moduły jest przechowywany w execute_as_principal_id kolumnie w sys.sql_modules widoku katalogu lub .sys.service_queues

SELF jest wartością domyślną dla kolejek.

Uwaga / Notatka

Aby zmienić identyfikator execute_as_principal_id użytkownika kolumny w sys.service_queues widoku wykazu, należy jawnie określić EXECUTE AS ustawienie w instrukcji ALTER QUEUE .

WŁAŚCICIEL

Określa, że instrukcje wewnątrz modułu są wykonywane w kontekście bieżącego właściciela modułu. Jeśli moduł nie ma określonego właściciela, zostanie użyty właściciel schematu modułu. OWNER Nie można określić dla wyzwalaczy DDL lub logowania.

Ważne

OWNER musi być mapowanie na pojedyncze konto i nie może być rolą ani grupą.

"user_name"

Określa instrukcje wewnątrz modułu wykonywane w kontekście użytkownika określonego w user_name. Uprawnienia do wszystkich obiektów w module są weryfikowane pod kątem user_name. user_name nie można określić dla wyzwalaczy DDL z wyzwalaczami zakresu serwera lub logowania. Zamiast tego użyj login_name .

user_name musi istnieć w bieżącej bazie danych i musi być pojedynczym kontem. user_name nie może być kontem grupy, roli, certyfikatu, klucza lub wbudowanego konta, takiego jak NT AUTHORITY\LocalService, NT AUTHORITY\NetworkServicelub NT AUTHORITY\LocalSystem.

Identyfikator użytkownika kontekstu wykonywania jest przechowywany w metadanych i można go wyświetlić w execute_as_principal_id kolumnie w sys.sql_modules widoku katalogu lub sys.assembly_modules .

"login_name"

Określa instrukcje wewnątrz modułu wykonywane w kontekście logowania programu SQL Server określonego w login_name. Uprawnienia do wszystkich obiektów w module są weryfikowane względem login_name. login_name można określić tylko dla wyzwalaczy DDL z wyzwalaczami zakresu serwera lub logowania.

login_name nie może być kontem grupy, roli, certyfikatu, klucza lub wbudowanego konta, takiego jak NT AUTHORITY\LocalService, NT AUTHORITY\NetworkServicelub NT AUTHORITY\LocalSystem.

Uwagi

Sposób, w jaki aparat bazy danych ocenia uprawnienia do obiektów, do których odwołuje się moduł, zależy od łańcucha własności, który istnieje między wywoływanie obiektów a obiektami, do których odwołuje się odwołanie. We wcześniejszych wersjach programu SQL Server łańcuch własności był jedyną dostępną metodą, aby uniknąć konieczności udzielenia użytkownikowi wywołującego dostępu do wszystkich przywoływałych obiektów.

Łańcuch własności ma następujące ograniczenia:

Dotyczy tylko instrukcji DML: SELECT, INSERT, UPDATEi DELETE.
Właściciele wywołań i wywoływane obiekty muszą być takie same.
Nie dotyczy zapytań dynamicznych wewnątrz modułu.

Niezależnie od kontekstu wykonywania określonego w module, zawsze mają zastosowanie następujące akcje:

Po wykonaniu modułu aparat bazy danych najpierw sprawdza, czy użytkownik wykonujący moduł ma EXECUTE uprawnienia do modułu.
Reguły tworzenia łańcucha własności nadal mają zastosowanie. Oznacza to, że jeśli właściciele wywołań i wywoływanych obiektów są takie same, żadne uprawnienia nie są sprawdzane na obiektach bazowych.

Gdy użytkownik wykonuje moduł, który został określony do uruchomienia w kontekście innym niż CALLER, uprawnienie użytkownika do wykonania modułu jest sprawdzane, ale dodatkowe uprawnienia kontroli obiektów, do których uzyskuje dostęp moduł, są wykonywane względem konta użytkownika określonego w klauzuli EXECUTE AS . Użytkownik wykonujący moduł jest w efekcie personifikujący określonego użytkownika.

Kontekst określony w EXECUTE AS klauzuli modułu jest ważny tylko przez czas trwania wykonywania modułu. Kontekst jest przywracany do obiektu wywołującego po zakończeniu wykonywania modułu.

Nie można usunąć nazwy logowania użytkownika bazy danych lub serwera określonego w EXECUTE AS klauzuli modułu, dopóki moduł nie zostanie zmodyfikowany do wykonania w innym kontekście.

Nazwa użytkownika lub nazwy logowania określona w EXECUTE AS klauzuli musi istnieć odpowiednio jako podmiot zabezpieczeń lub sys.database_principalssys.server_principals, albo operacja tworzenia lub zmiany modułu kończy się niepowodzeniem. Ponadto użytkownik, który tworzy lub zmienia moduł, musi mieć uprawnienia IMPERSONATE dla podmiotu zabezpieczeń.

Jeśli użytkownik ma niejawny dostęp do bazy danych lub wystąpienia programu SQL Server za pośrednictwem członkostwa w grupie systemu Windows, użytkownik określony w EXECUTE AS klauzuli jest niejawnie tworzony podczas tworzenia modułu, gdy istnieje jedno z następujących wymagań:

Określony użytkownik lub identyfikator logowania jest członkiem stałej roli serwera sysadmin .
Użytkownik tworzący moduł ma uprawnienia do tworzenia podmiotów zabezpieczeń.

Jeśli żadne z tych wymagań nie zostanie spełnione, operacja tworzenia modułu zakończy się niepowodzeniem.

Ważne

Jeśli usługa PROGRAMU SQL Server (MSSQLSERVER) jest uruchomiona jako konto lokalne (usługa lokalna lub konto użytkownika lokalnego), nie będzie mieć uprawnień do uzyskania członkostwa w grupie konta domeny systemu Windows określonego w klauzuli EXECUTE AS . Spowoduje to niepowodzenie wykonywania modułu.

Załóżmy na przykład następujące warunki:

CompanyDomain\SQLUsers grupa ma dostęp do Sales bazy danych.
CompanyDomain\SqlUser1 jest członkiem programu i w związku z SQLUsers tym Sales ma dostęp do bazy danych.
Użytkownik, który tworzy lub zmienia moduł, ma uprawnienia do tworzenia podmiotów zabezpieczeń.

Po uruchomieniu następującej CREATE PROCEDURE instrukcji element CompanyDomain\SqlUser1 jest niejawnie tworzony jako jednostka bazy danych w Sales bazie danych.

USE Sales;
GO

CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT USER_NAME();
GO

Używanie instrukcji autonomicznej EXECUTE AS CALLER

Użyj autonomicznej EXECUTE AS CALLER instrukcji wewnątrz modułu, aby ustawić kontekst wykonywania na obiekt wywołujący modułu.

Załóżmy, że następująca procedura składowana jest wywoływana przez SqlUser2element .

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

Definiowanie niestandardowych zestawów uprawnień przy użyciu funkcji EXECUTE AS

Określenie kontekstu wykonywania dla modułu może być przydatne, gdy chcesz zdefiniować niestandardowe zestawy uprawnień. Na przykład niektóre akcje, takie jak TRUNCATE TABLE nie mają uprawnień możliwych do udzielenia. Dołączając instrukcję TRUNCATE TABLE w module i określając, że ten moduł jest wykonywany jako użytkownik, który ma uprawnienia do zmiany tabeli, możesz rozszerzyć uprawnienia, aby obcinać tabelę użytkownikowi, któremu udzielasz EXECUTE uprawnień do modułu.

Aby wyświetlić definicję modułu z określonym kontekstem wykonywania, użyj widoku katalogu sys.sql_modules .

Najlepsze rozwiązanie

Określ identyfikator logowania lub użytkownika, który ma najmniejsze uprawnienia wymagane do wykonania operacji zdefiniowanych w module. Na przykład nie należy określać konta właściciela bazy danych, chyba że te uprawnienia są wymagane.

Permissions

Aby wykonać moduł określony za pomocą EXECUTE ASpolecenia , obiekt wywołujący musi mieć EXECUTE uprawnienia do modułu.

Aby wykonać moduł CLR określony z EXECUTE AS tym, który uzyskuje dostęp do zasobów w innej bazie danych lub serwerze, docelowa baza danych lub serwer musi ufać wystawcy uwierzytelnienia bazy danych, z której pochodzi moduł (źródłowa baza danych).

Aby określić klauzulę EXECUTE AS podczas tworzenia lub modyfikowania modułu, musisz mieć IMPERSONATE uprawnienia do określonego podmiotu zabezpieczeń, a także uprawnienia do tworzenia modułu. Zawsze możesz personifikować się samodzielnie. Jeśli nie określono kontekstu wykonywania lub EXECUTE AS CALLER nie zostanie określony, IMPERSONATE uprawnienia nie są wymagane.

Aby określić login_name lub user_name , który ma niejawny dostęp do bazy danych za pośrednictwem członkostwa w grupie systemu Windows, musisz mieć CONTROL uprawnienia do bazy danych.

Przykłady

Poniższy przykład tworzy procedurę przechowywaną w bazie AdventureWorks2025 i przypisuje kontekst wykonania do OWNER.

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

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-08-28