컨텍스트 전환 이해

다음 예에서 Adventure Works Cycles의 네트워크 관리자인 Peter Connelly는 신입 사원인 Jinghao Liuhas의 SQL Server 로그인 계정을 만들려고 합니다. Peter의 SQL Server 로그인에는 SQL Server 로그인을 만드는 데 필요한 서버 수준 권한이 없지만 필요한 서버 수준 권한을 가진 SQL Server 로그인인 adventure-works\dan1에 대한 IMPERSONATE 권한이 있습니다. Peter가 SQL Server에 연결하면 세션에 대한 실행 컨텍스트는 Peter의 SQL Server 로그인에서 파생됩니다. SQL Server 로그인을 만들기 위해 Peter는 adventure-works\dan1의 실행 컨텍스트를 일시적으로 가정한 다음 로그인을 만듭니다. 마지막으로 Peter는 가정된 사용 권한을 포기합니다.

-- Switch execution context to the adventure-works\dan1 login account.
EXECUTE AS LOGIN = 'adventure-works\dan1';
-- Create the new login account.
CREATE LOGIN Jinghao1 WITH PASSWORD = '3KHJ6dhx(0xVYsdf';
-- Revert to the previous execution context.
REVERT;

다음 예에서 Adventure Works Cycles의 데이터베이스 관리자인 François Ajenstat는 AdventureWorksDW 데이터베이스에 대해 DBCC CHECKDB 문을 실행하려고 하지만 이 작업을 수행할 데이터베이스 수준 권한이 없습니다. 그러나 필요한 권한을 가진 계정인 dan1 사용자에 대한 IMPERSONATE 권한이 있습니다.

François가 AdventureWorksDW 데이터베이스에 연결하면 실행 컨텍스트가 François의 사용자 보안 토큰에 매핑됩니다. user token의 주 보안 주체 및 보조 보안 주체에 대해 문을 실행할 권한을 확인합니다. DBCC CHECKDB 문을 실행하는 데 필요한 권한이 없으므로 다음 문을 실행합니다.

-- EXECUTE AS USER = 'dan1';
-- Create a table in dan1's default schema
CREATE TABLE t_NewTable( data nvarchar(100) );
go
-- Revert to the previous execution context.
REVERT
go;

다음 예에서 Mary는 MyTable 테이블의 소유자입니다. Mary는 사용자 Scott가 테이블을 자를 수 있기를 원하지만 Scott에게 테이블에 대한 직접적인 사용 권한이 없습니다. 따라서 Mary는 dbo.usp_TruncateMyTable 저장 프로시저를 만들고 Scott에게 이 프로시저에 대한 EXECUTE 권한을 부여합니다. Scott이 저장 프로시저를 실행하면 데이터베이스 엔진에서 해당 권한을 확인하여 Mary가 저장 프로시저를 실행하고 있을 때와 동일하게 테이블을 자를 수 있습니다. 테이블 소유자가 Mary이기 때문에 Scott에게 테이블 자체에 대한 직접적인 권한이 없더라도 문이 성공적으로 실행됩니다.

CREATE PROCEDURE dbo.usp_TruncateMyTable
WITH EXECUTE AS SELF
AS TRUNCATE TABLE MyDB..MyTable;