Descripción del cambio de contexto
El contexto de ejecución está determinado por el usuario o el inicio de sesión conectado a la sesión o que ejecuta (llama) un módulo. Este contexto establece la identidad con la que se comprueban los permisos para ejecutar instrucciones o realizar acciones. En SQL Server, el contexto de ejecución se puede cambiar a otro usuario o inicio de sesión si se ejecuta la instrucción EXECUTE AS, o bien si se especifica la cláusula EXECUTE AS en un módulo. Después del cambio de contexto, SQL Server comprueba los permisos con el inicio de sesión y el usuario de dicha cuenta, en lugar de hacerlo con la persona que llama al módulo o a la instrucción EXECUTE AS. El inicio de sesión de SQL Server o del usuario de la base de datos se suplanta durante el resto de la sesión o de la ejecución del módulo, o bien hasta que el cambio de contexto se revierta de forma explícita. Para obtener más información sobre el contexto de ejecución, vea Descripción del contexto de ejecución.
Cambio explícito de contexto
El contexto de ejecución de una sesión o un módulo se puede cambiar de forma explícita si se especifica un nombre de usuario o de inicio de sesión en una instrucción EXECUTE AS. La suplantación sigue activa hasta que se produce uno de los siguientes eventos:
Se quita la sesión.
Se cambia el contexto a otro inicio de sesión o usuario.
El contexto se revierte al contexto de ejecución anterior.
La utilización de EXECUTE AS para suplantar de forma explícita a otro usuario es similar a la función SETUSER de versiones anteriores de SQL Server. Para obtener más información, vea EXECUTE AS frente a SETUSER.
Cambio explícito de contexto en el servidor
Para cambiar el contexto de ejecución en el servidor, utilice la instrucción EXECUTE AS LOGIN = 'login_name'. El nombre de inicio de sesión debe ser visible como entidad de seguridad principal en sys.server_principals y el usuario que llama a la instrucción debe contar con el permiso IMPERSONATE en el nombre de inicio de sesión especificado.
El ámbito de la suplantación, cuando el contexto de ejecución se establece en el servidor, es el siguiente:
El token de inicio de sesión de login_name se autentica en la instancia de SQL Server y es válido en dicha instancia.
Se aplican los permisos de servidor y la pertenencia a funciones de login_name.
Utilice la instrucción REVERT para volver al contexto anterior. El usuario que llama a la instrucción REVERT debe estar incluido en la misma base de datos donde se ha producido la suplantación.
Ejemplo
En el ejemplo siguiente, Peter Connelly, un administrador de red de Adventure Works Cycles, desea crear una cuenta de inicio de sesión de SQL Server para un nuevo empleado, Jinghao Liuhas. El inicio de sesión de SQL Server de Peter no necesita el mismo permiso en el servidor necesario para crear inicios de sesión de SQL Server, pero tiene el permiso IMPERSONATE para adventure-works\dan1, un inicio de sesión de SQL Server que dispone del permiso de servidor requerido. Cuando Peter se conecta a SQL Server, el contexto de ejecución de la sesión se deriva de su inicio de sesión de SQL Server. Para crear un inicio de sesión de SQL Server, Peter asume temporalmente el contexto de ejecución de adventure-works\dan1. Después crea el inicio de sesión. Finalmente, renuncia a los permisos que ha asumido.
-- 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;
Cambio explícito de contexto en la base de datos
Para cambiar el contexto en la base de datos, utilice la instrucción EXECUTE AS USER = 'user_name'. El nombre del usuario debe existir como entidad de seguridad en sys.database_principals y el usuario que llama a la instrucción debe contar con permisos IMPERSONATE en el nombre de usuario especificado.
El ámbito de la suplantación, cuando el contexto de ejecución se establece en las bases de datos, es el siguiente:
El token de usuario de user_name se autentica en la instancia de SQL Server y es válido en la base de datos actual. Para obtener información sobre la ampliación de la suplantación de usuarios más allá del ámbito de la base de datos actual, vea Extender la suplantación de la base de datos mediante EXECUTE AS.
Se aplican los permisos de base de datos y la pertenencia a funciones de user_name de la base de datos actual. No se aplican los permisos de servidor concedidos de forma explícita a identidades del token de usuario ni mediante pertenencia a funciones.
Utilice la instrucción REVERT para volver al contexto anterior. El usuario que llama a la instrucción REVERT debe estar incluido en la misma base de datos donde se ha producido la suplantación.
Ejemplo
En el siguiente ejemplo, François Ajenstat, administrador de bases de datos de Adventure Works Cycles, desea ejecutar la instrucción DBCC CHECKDB en la base de datos AdventureWorksDW, pero no dispone de permisos en el nivel de base de datos para realizar la operación. Sin embargo, sí dispone de permisos IMPERSONATE en el usuario dan1, una cuenta que incluye el permiso necesario.
Cuando François se conecta a la base de datos AdventureWorksDW, el contexto de ejecución se asigna a su token de seguridad de usuario. Los permisos para ejecutar instrucciones se comprueban en las entidades de seguridad principales y secundarias del token del usuario. Puesto que no dispone de los permisos necesarios para ejecutar la instrucción DBCC CHECKDB, ejecuta las instrucciones siguientes.
-- 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;
Cambio implícito de contexto
El contexto de ejecución de un módulo, como un procedimiento almacenado, un desencadenador, un cola o un función definida por el usuario, se puede cambiar de forma implícita mediante la especificación de un nombre de usuario o de inicio de sesión en una cláusula EXECUTE AS de la definición del módulo.
Si se especifica el contexto en que se ejecuta el módulo, se puede controlar la cuenta de usuario que utiliza SQL Server para validar permisos en los objetos a los que hace referencia el módulo. Así se consigue una flexibilidad y un control adicionales en la administración de permisos de la cadena de objetos que existe entre los módulos definidos por el usuario y los objetos a los que hacen referencia estos módulos. Los permisos pueden concederse a usuarios únicamente para el propio módulo, sin tener que concederles permisos explícitos para los objetos a los que se hace referencia. Sólo el usuario al que suplanta el módulo necesita disponer de permisos para los objetos a los que dicho módulo tiene acceso.
El nivel de suplantación se determina según el tipo de módulo en que se define la suplantación.
La suplantación en el servidor se puede definir en el siguiente elemento:
- Desencadenadores DDL
El ámbito de suplantación en el servidor es el mismo que el definido anteriormente en "Cambio explícito de contexto en el servidor".
La suplantación en la base de datos se puede definir en los siguiente elementos:
Desencadenadores DML
Colas
Procedimientos almacenados
Funciones definidas por el usuario
El ámbito de suplantación en la base de datos es el mismo que el definido anteriormente en "Cambio explícito de contexto en la base de datos".
Para obtener más información sobre el cambio implícito de contexto, vea Usar EXECUTE AS en módulos.
Ejemplo
En el siguiente ejemplo, Mary es la propietaria de la tabla MyTable. Desea que el usuario Scott pueda truncar la tabla, pero Scott no dispone de permisos directos para ella. Por tanto, Mary crea el procedimiento almacenado dbo.usp_TruncateMyTable y concede a Scott permisos EXECUTE para el procedimiento. Cuando Scott ejecuta el procedimiento almacenado, Database Engine (Motor de base de datos) comprueba los permisos para truncar la tabla como si fuera la propia Mary la que estuviera ejecutando el procedimiento almacenado. Puesto que ella es la propietaria de la tabla, la instrucción se realiza correctamente a pesar de que Scott no dispone de permisos directos en la propia tabla.
CREATE PROCEDURE dbo.usp_TruncateMyTable
WITH EXECUTE AS SELF
AS TRUNCATE TABLE MyDB..MyTable;
Vea también