EXECUTE AS-satsen (Transact-SQL)

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

I SQL Server kan du definiera körningskontexten för följande användardefinierade moduler: funktioner (förutom infogade tabellvärdesfunktioner), procedurer, köer och utlösare.

Genom att ange kontexten där modulen körs kan du styra vilket användarkonto databasmotorn använder för att verifiera behörigheter för objekt som refereras till av modulen. Detta ger ytterligare flexibilitet och kontroll vid hantering av behörigheter i objektkedjan som finns mellan användardefinierade moduler och de objekt som refereras av dessa moduler. Behörigheter måste endast beviljas användare i själva modulen, utan att de behöver ge dem explicit behörighet för de refererade objekten. Endast användaren som modulen körs som måste ha behörighet för de objekt som används av modulen.

Transact-SQL syntaxkonventioner

Syntax

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

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

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

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

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

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

Arguments

BESÖKARE

Anger att instruktionerna i modulen körs i kontexten för modulens anropare. Användaren som kör modulen måste ha rätt behörigheter inte bara för själva modulen, utan även för alla databasobjekt som refereras till av modulen.

CALLER är standard för alla moduler utom köer och är samma som SQL Server 2005 (9.x) beteende.

CALLER kan inte anges i en CREATE QUEUE -instruktion ALTER QUEUE .

SELF

EXECUTE AS SELF motsvarar EXECUTE AS <user_name>, där den angivna användaren är den person som skapar eller ändrar modulen. Det faktiska användar-ID:t för den person som skapar eller ändrar modulerna lagras i execute_as_principal_id kolumnen i katalogvyn eller sys.sql_modules i sys.service_queues katalogvyn.

SELF är standardvärdet för köer.

ÄGARE

Anger att -instruktionerna i modulen körs i kontexten för den aktuella ägaren av modulen. Om modulen inte har någon angiven ägare används ägaren av schemat för modulen. OWNER kan inte anges för DDL- eller inloggningsutlösare.

"user_name"

Anger instruktioner i modulen som körs i kontexten för användaren som anges i user_name. Behörigheter för objekt i modulen verifieras mot user_name. user_name kan inte anges för DDL-utlösare med serveromfång eller inloggningsutlösare. Använd login_name i stället.

user_name måste finnas i den aktuella databasen och måste vara ett singleton-konto. user_name kan inte vara en grupp, roll, certifikat, nyckel eller inbyggt konto, till exempel NT AUTHORITY\LocalService, NT AUTHORITY\NetworkServiceeller NT AUTHORITY\LocalSystem.

Användar-ID:t för körningskontexten lagras i metadata och kan visas i execute_as_principal_id kolumnen i sys.sql_modules vyn eller sys.assembly_modules katalogen.

"login_name"

Anger de instruktioner i modulen som körs i kontexten för SQL Server-inloggningen som anges i login_name. Behörigheter för objekt i modulen verifieras mot login_name. login_name kan endast anges för DDL-utlösare med serveromfattning eller inloggningsutlösare.

login_name kan inte vara en grupp, roll, certifikat, nyckel eller inbyggt konto, till exempel NT AUTHORITY\LocalService, NT AUTHORITY\NetworkServiceeller NT AUTHORITY\LocalSystem.

Anmärkningar

Hur databasmotorn utvärderar behörigheter för de objekt som refereras i modulen beror på ägarskapskedjan som finns mellan anropande objekt och refererade objekt. I tidigare versioner av SQL Server var ägarskapslänkning den enda tillgängliga metoden för att undvika att ge den anropande användaren åtkomst till alla refererade objekt.

Ägarskapslänkning har följande begränsningar:

• Gäller endast för DML-instruktioner: SELECT, INSERT, UPDATEoch DELETE.
• Ägarna till anropet och de anropade objekten måste vara desamma.
• Gäller inte för dynamiska frågor i modulen.

Oavsett vilken körningskontext som anges i modulen gäller alltid följande åtgärder:

• När modulen körs verifierar databasmotorn först att användaren som kör modulen har EXECUTE behörighet för modulen.

• Regler för ägarskapslänkning fortsätter att gälla. Det innebär att om ägarna till anropet och de anropade objekten är desamma kontrolleras inga behörigheter för de underliggande objekten.

När en användare kör en modul som har angetts för att köras i en annan kontext än CALLER, kontrolleras användarens behörighet att köra modulen, men ytterligare behörighetskontroller av objekt som används av modulen utförs mot det användarkonto som anges i EXECUTE AS -satsen. Användaren som kör modulen personifierar i själva verket den angivna användaren.

Kontexten EXECUTE AS som anges i -satsen i modulen är endast giltig under modulkörningens varaktighet. Kontexten återgår till anroparen när modulkörningen har slutförts.

Ange ett användar- eller inloggningsnamn

En databasanvändare eller serverinloggning som anges i -satsen i EXECUTE AS en modul kan inte tas bort förrän modulen har ändrats för att köras i en annan kontext.

Det användar- eller inloggningsnamn som anges i EXECUTE AS -satsen måste finnas som ett huvudnamn i sys.database_principals respektive sys.server_principals, annars misslyckas åtgärden skapa eller ändra modul. Dessutom måste den användare som skapar eller ändrar modulen ha IMPERSONATE-behörigheter för huvudkontot.

Om användaren har implicit åtkomst till databasen eller instansen av SQL Server via ett Windows-gruppmedlemskap skapas den användare som anges i EXECUTE AS -satsen implicit när modulen skapas när något av följande krav finns:

• Den angivna användaren eller inloggningen är medlem i den fasta serverrollen sysadmin .
• Användaren som skapar modulen har behörighet att skapa huvudnamn.

När inget av dessa krav uppfylls misslyckas åtgärden skapa modul.

Anta till exempel följande villkor:

• CompanyDomain\SQLUsers har åtkomst till Sales databasen.

• CompanyDomain\SqlUser1 är medlem i SQLUsers och har därför åtkomst till Sales databasen.

• Användaren som skapar eller ändrar modulen har behörighet att skapa huvudkonton.

När följande CREATE PROCEDURE instruktion körs CompanyDomain\SqlUser1 skapas implicit som ett databashuvudnamn i Sales databasen.

USE Sales;
GO

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

Använda execute as caller stand-alone-instruktion

Använd den EXECUTE AS CALLER fristående instruktionen i en modul för att ange körningskontexten till modulens anropare.

Anta att följande lagrade procedur anropas av SqlUser2.

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

Använda EXECUTE AS för att definiera anpassade behörighetsuppsättningar

Det kan vara användbart att ange en körningskontext för en modul när du vill definiera anpassade behörighetsuppsättningar. Till exempel har vissa åtgärder, till exempel inte behörigheter som TRUNCATE TABLE kan beviljas. Genom att införliva -instruktionen TRUNCATE TABLE i en modul och ange att modulen ska köras som en användare som har behörighet att ändra tabellen kan du utöka behörigheterna för att trunkera tabellen till den användare som du beviljar EXECUTE behörigheter för modulen till.

Om du vill visa definitionen av modulen med den angivna körningskontexten använder du katalogvyn sys.sql_modules .

Bästa metod

Ange en inloggning eller användare som har de minsta behörigheter som krävs för att utföra de åtgärder som definierats i modulen. Ange till exempel inte ett databasägarkonto om inte dessa behörigheter krävs.

Permissions

Om du vill köra en modul som anges med EXECUTE ASmåste anroparen ha EXECUTE behörighet för modulen.

Om du vill köra en CLR-modul som anges med EXECUTE AS som kommer åt resurser i en annan databas eller server måste måldatabasen eller servern lita på autentiseringen av databasen som modulen kommer från (källdatabasen).

Om du vill ange EXECUTE AS -satsen när du skapar eller ändrar en modul måste du ha IMPERSONATE behörighet för det angivna huvudkontot och även behörigheter för att skapa modulen. Du kan alltid personifiera dig själv. När ingen körningskontext har angetts eller EXECUTE AS CALLER har angetts IMPERSONATE krävs inte behörigheter.

Om du vill ange en login_name eller user_name som har implicit åtkomst till databasen via ett Windows-gruppmedlemskap måste du ha CONTROL behörighet för databasen.

Examples

I följande exempel skapas en lagrad procedur i databasen AdventureWorks2022 och körningskontexten tilldelas till 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

Relaterat innehåll

• sys.assembly_modules (Transact-SQL)
• sys.sql_modules (Transact-SQL)
• sys.service_queues (Transact-SQL)
• REVERT (Transact-SQL)
• KÖR SOM (Transact-SQL)